From neliasso at openjdk.java.net  Tue Feb  1 08:58:11 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 1 Feb 2022 08:58:11 GMT
Subject: RFR: 8280976: Incorrect encoding of avx512 vpsraq instruction with
 mask and constant shift.
In-Reply-To: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
References: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
Message-ID: <kdMhiRw_NYyOEOBxgyT8GVvjSNsDE1eE1UsBTnpvRLE=.0543439a-7fe8-49c6-95e1-1fee6f361756@github.com>

On Mon, 31 Jan 2022 20:15:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Incorrect encoding fixed.
> 
> EVEX.512.66.0F.W1 72 /4 ib VPSRAQ zmm1 {k1}{z}, zmm2/m512/m64bcst, imm8 | F | V/V | AVX512F | Shift quadwords in zmm2/m512/m64bcst right by imm8 while shifting in sign bits using writemask k1.
> -- | -- | -- | -- | --
> 
> Thanks,
> Jatin

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From rrich at openjdk.java.net  Tue Feb  1 09:21:58 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 1 Feb 2022 09:21:58 GMT
Subject: RFR: 8280593: [PPC64, S390] redundant allocation of MacroAssembler
 in StubGenerator ctor [v3]
In-Reply-To: <F0CxlKwsztJ_H-1XPQpFd8ekFsijTRhgeaI2l-oHh7M=.2eca2c4c-5ab3-4433-9d04-58bbc8fbd857@github.com>
References: <F0CxlKwsztJ_H-1XPQpFd8ekFsijTRhgeaI2l-oHh7M=.2eca2c4c-5ab3-4433-9d04-58bbc8fbd857@github.com>
Message-ID: <I0XrzxJ83s1C_4t0nii6ywesMaRKs1RCzuGo8mHbBVI=.c9c17392-6665-4ffb-88e7-0959f0f8e42a@github.com>

> This cleanup removes a redundant allocation from the StubGenerator constructor. The base class' constructor does the very same.
> 
> The fix passed our CI testing.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7215/files
  - new: https://git.openjdk.java.net/jdk/pull/7215/files/dd330af6..658104ed

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

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

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

From roland at openjdk.java.net  Tue Feb  1 09:31:58 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 09:31:58 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
Message-ID: <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>

> The new fix is largely similar to the previous one. 3 bugs were filed
> because of the previous change but there are only really 2 issues:
> 
> - attaching the valid length condition at expansion time to the new
>   array runtime call causes issues. With Shenandoah, passes of loop
>   opts are executed after macro expansion but precedence edges are
>   ignored when assigning controls to nodes which causes loop opts to
>   incorrectly attempt to eliminate the node pointed to by the
>   precedence edge. A similar issue occurs when the runtime call ends
>   up in a subgraph that dies after macro expansion because the
>   precedence edge is not cleared by dead code elimination which causes
>   the runtime call to still be reachable. In the new patch, this is
>   fixed by appending an extra input to the runtime call instead of
>   using a precedence edge.
> 
> - In the previous patch, a top valid length input is used when there's
>   no valid length input that needs to be recorded. That can cause an
>   assert failure during CCP. If valid length initially has type top,
>   the CatchNode out of the AllocateArray then have type (control,
>   control). If next, the valid length input becomes constant 0, the
>   CatchNode has type (top, control). An assert catches that the type
>   of the CatchNode doesn't widen. This fixed by using 1 by default as
>   valid length input and tweaking CatchNode::Value.
> 
> The new patch includes test cases for both issues.

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 five additional commits since the last revision:

 - review
 - Merge branch 'master' into JDK-8279219
 - review
 - tests & fix
 - Revert "8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large"
   
   This reverts commit 04ad668921abbd71dfbc474eed6f1760f7a541b1.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6952/files
  - new: https://git.openjdk.java.net/jdk/pull/6952/files/b3cafb1d..541aa4ea

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

  Stats: 31286 lines in 1169 files changed: 20818 ins; 5776 del; 4692 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6952.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6952/head:pull/6952

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

From roland at openjdk.java.net  Tue Feb  1 09:31:59 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 09:31:59 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v2]
In-Reply-To: <dVlYz1-rJbOfp1igyAPpdPnlU1tBsVoX32-zWtnKa34=.66770576-b845-490d-a47d-08c908d72453@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <oOWfCVT-mO04Fol_Dwd4BFyU2KyJnL4QOYsU8b7f_eY=.ac5316a9-a24e-4b0d-8ccb-fbe3f5163d7b@github.com>
 <dVlYz1-rJbOfp1igyAPpdPnlU1tBsVoX32-zWtnKa34=.66770576-b845-490d-a47d-08c908d72453@github.com>
Message-ID: <PJmiqKh1MniaQK_xQF7BEFTcgL37B109qMzTUyxId_k=.ad08d886-0aa2-4bea-b206-30f80f3782d9@github.com>

On Thu, 27 Jan 2022 17:22:13 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/opto/macro.cpp line 1397:
> 
>> 1395:   // allocate node with the call
>> 1396:   call->copy_call_debug_info(&_igvn, alloc);
>> 1397:   if (valid_length_test != NULL) {
> 
> How about adding a comment or assert that makes it clear that valid_length_test != NULL if it's an array that's allocated? If length == NULL, then valid_length_test is NULL too. Just to ease the reading of this code a bit.

Thanks for looking at this.
What about the comment I just pushed?

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

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

From roland at openjdk.java.net  Tue Feb  1 09:53:37 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 09:53:37 GMT
Subject: RFR: 8280842: Access violation in ciTypeFlow::profiled_count
Message-ID: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>

When the test() method is osr compiled, the exception handler is
marked as a loop head. It has 2 backedges at the 2 throw statements in
the method. ciTypeFlow expects to find some profile data at the
backedges but hotspot doesn't collect counters for athrow. The fix is
to turn the assert into an actual check.

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

Commit messages:
 - fix & test

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

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

From roland at openjdk.java.net  Tue Feb  1 10:07:50 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 10:07:50 GMT
Subject: RFR: 8280842: Access violation in ciTypeFlow::profiled_count [v2]
In-Reply-To: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
References: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
Message-ID: <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>

> When the test() method is osr compiled, the exception handler is
> marked as a loop head. It has 2 backedges at the 2 throw statements in
> the method. ciTypeFlow expects to find some profile data at the
> backedges but hotspot doesn't collect counters for athrow. The fix is
> to turn the assert into an actual check.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  test with -XX:-BackgroundCompilation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7298/files
  - new: https://git.openjdk.java.net/jdk/pull/7298/files/4584f0e4..50c199ae

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

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

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

From roland at openjdk.java.net  Tue Feb  1 10:17:28 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 10:17:28 GMT
Subject: RFR: 8280885: Shenandoah: Some tests failed with
 "EA: missing allocation reference path"
Message-ID: <JeVUt7Uq_gFOby36DD_HFqCrUo9yu2bw4WgH6sGMQvw=.d269226e-c64a-4cba-964f-50f8a07ea7f7@github.com>

EA encounters an unexpected IU barrier. I think it's good enough to
change ShenandoahBarrierSetC2::is_gc_barrier_node() so it returns true
for IU barriers.

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

Commit messages:
 - fix & test

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

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

From neliasso at openjdk.java.net  Tue Feb  1 13:32:11 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 1 Feb 2022 13:32:11 GMT
Subject: RFR: 8280842: Access violation in ciTypeFlow::profiled_count [v2]
In-Reply-To: <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
References: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
 <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
Message-ID: <ENx01dxPYa5g29YzIUFDaeK_RSFb1EoTGEmp6S2reeU=.83cf8fd4-c453-4583-886a-631e689bec27@github.com>

On Tue, 1 Feb 2022 10:07:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> When the test() method is osr compiled, the exception handler is
>> marked as a loop head. It has 2 backedges at the 2 throw statements in
>> the method. ciTypeFlow expects to find some profile data at the
>> backedges but hotspot doesn't collect counters for athrow. The fix is
>> to turn the assert into an actual check.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test with -XX:-BackgroundCompilation

Looks good.

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

Marked as reviewed by neliasso (Reviewer).

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

From neliasso at openjdk.java.net  Tue Feb  1 13:37:13 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 1 Feb 2022 13:37:13 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
Message-ID: <KB5xQb2W5nRXPznbNqGvNACvUNsRQuwucAo2ftHqT2A=.10720107-58bc-41a4-aeeb-50b18be3a052@github.com>

On Tue, 1 Feb 2022 09:31:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The new fix is largely similar to the previous one. 3 bugs were filed
>> because of the previous change but there are only really 2 issues:
>> 
>> - attaching the valid length condition at expansion time to the new
>>   array runtime call causes issues. With Shenandoah, passes of loop
>>   opts are executed after macro expansion but precedence edges are
>>   ignored when assigning controls to nodes which causes loop opts to
>>   incorrectly attempt to eliminate the node pointed to by the
>>   precedence edge. A similar issue occurs when the runtime call ends
>>   up in a subgraph that dies after macro expansion because the
>>   precedence edge is not cleared by dead code elimination which causes
>>   the runtime call to still be reachable. In the new patch, this is
>>   fixed by appending an extra input to the runtime call instead of
>>   using a precedence edge.
>> 
>> - In the previous patch, a top valid length input is used when there's
>>   no valid length input that needs to be recorded. That can cause an
>>   assert failure during CCP. If valid length initially has type top,
>>   the CatchNode out of the AllocateArray then have type (control,
>>   control). If next, the valid length input becomes constant 0, the
>>   CatchNode has type (top, control). An assert catches that the type
>>   of the CatchNode doesn't widen. This fixed by using 1 by default as
>>   valid length input and tweaking CatchNode::Value.
>> 
>> The new patch includes test cases for both issues.
>
> 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 five additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8279219
>  - review
>  - tests & fix
>  - Revert "8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large"
>    
>    This reverts commit 04ad668921abbd71dfbc474eed6f1760f7a541b1.

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From roland at openjdk.java.net  Tue Feb  1 15:10:38 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 15:10:38 GMT
Subject: RFR: 8280600: C2: assert(!had_error) failed: bad dominance
Message-ID: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>

For the inner loop of the test, c2, first, creates a counted loop and
assigns the type -400..1 to the trip count Phi. The loop body has a
range check that guards a CastII on the trip count Phi. That CastII
has type: 0..1 as a result.

Pre/main/post loops are then created. In the process,
PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
the main loop. That CastII's input is the add node of the pre
loop. The loop is also unrolled once. The CastII on the loop entry is
pushed through the add node and replaced by the range check CastII
that has the same input and dominates. As a result, the main loop
tripcount Phi has type -400..1 but init value, 1..2. This causes the
Phi to constant fold to 1. The amount of unrolling and the main loop
bounds are inconsistent (the loop shouldn't be unrolled if it executes
for one iteration) but when the unrolling decision is made the type of
the lower bound of the main loop is not yet accurately known.

The actual crash is the result of a chain of nodes sunk out of the
inner loop and pinned out of the loop with a CastII node. The type of
the CastII and the type of its input after unrolling conflict.

The fix I propose is to change the type of the CastII that's added
before the main loop so it can't be replaced by a dominating
CastII. Given that CastII's role is to carry dependencies for nodes in
the loop body on the loop entry test, I think it's the right thing to
do. I've also been working on 8275202 (C2: optimize out more redundant
conditions) as a way to avoid type inconsistencies like this one.

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

Commit messages:
 - test
 - fix

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

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

From rkennke at openjdk.java.net  Tue Feb  1 15:37:04 2022
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 1 Feb 2022 15:37:04 GMT
Subject: RFR: 8280885: Shenandoah: Some tests failed with
 "EA: missing allocation reference path"
In-Reply-To: <JeVUt7Uq_gFOby36DD_HFqCrUo9yu2bw4WgH6sGMQvw=.d269226e-c64a-4cba-964f-50f8a07ea7f7@github.com>
References: <JeVUt7Uq_gFOby36DD_HFqCrUo9yu2bw4WgH6sGMQvw=.d269226e-c64a-4cba-964f-50f8a07ea7f7@github.com>
Message-ID: <AoLhSTpLgUUz3BrcyLqVwinaiRL6u8LRVwElv4NWyaw=.029946bf-9418-4d6d-a38f-b274268c7041@github.com>

On Tue, 1 Feb 2022 10:03:17 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> EA encounters an unexpected IU barrier. I think it's good enough to
> change ShenandoahBarrierSetC2::is_gc_barrier_node() so it returns true
> for IU barriers.

Looks good! Thanks!

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

Marked as reviewed by rkennke (Reviewer).

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

From roland at openjdk.java.net  Tue Feb  1 15:58:28 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Feb 2022 15:58:28 GMT
Subject: RFR: 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after
 JDK-8276116
Message-ID: <rSKIV1Gha8K9sQeCiFa7Hi2tAGh4PoNJ9PLb4C4_dEc=.a4074b31-1639-4514-a56e-13abe522bf1e@github.com>

Removal of a couple lines of dead code.

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

Commit messages:
 - fix

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

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

From thartmann at openjdk.java.net  Tue Feb  1 16:02:10 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Feb 2022 16:02:10 GMT
Subject: RFR: 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest
 after JDK-8276116
In-Reply-To: <rSKIV1Gha8K9sQeCiFa7Hi2tAGh4PoNJ9PLb4C4_dEc=.a4074b31-1639-4514-a56e-13abe522bf1e@github.com>
References: <rSKIV1Gha8K9sQeCiFa7Hi2tAGh4PoNJ9PLb4C4_dEc=.a4074b31-1639-4514-a56e-13abe522bf1e@github.com>
Message-ID: <arStD_S8aTHhVn9yBUbHqDraa2VaEwuqgnYYQlwEtlc=.a0b11e38-aa61-4aec-a890-56a45ede7eaa@github.com>

On Tue, 1 Feb 2022 15:51:49 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Removal of a couple lines of dead code.

Looks good and trivial.

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Tue Feb  1 16:07:13 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Feb 2022 16:07:13 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
Message-ID: <_xzzVIWqNT1YJgrbAJeQVMRd0NKr14FL_rX69DqulvU=.9f515e3b-562d-4fdb-b6b9-30b9fca5f106@github.com>

On Tue, 1 Feb 2022 09:31:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The new fix is largely similar to the previous one. 3 bugs were filed
>> because of the previous change but there are only really 2 issues:
>> 
>> - attaching the valid length condition at expansion time to the new
>>   array runtime call causes issues. With Shenandoah, passes of loop
>>   opts are executed after macro expansion but precedence edges are
>>   ignored when assigning controls to nodes which causes loop opts to
>>   incorrectly attempt to eliminate the node pointed to by the
>>   precedence edge. A similar issue occurs when the runtime call ends
>>   up in a subgraph that dies after macro expansion because the
>>   precedence edge is not cleared by dead code elimination which causes
>>   the runtime call to still be reachable. In the new patch, this is
>>   fixed by appending an extra input to the runtime call instead of
>>   using a precedence edge.
>> 
>> - In the previous patch, a top valid length input is used when there's
>>   no valid length input that needs to be recorded. That can cause an
>>   assert failure during CCP. If valid length initially has type top,
>>   the CatchNode out of the AllocateArray then have type (control,
>>   control). If next, the valid length input becomes constant 0, the
>>   CatchNode has type (top, control). An assert catches that the type
>>   of the CatchNode doesn't widen. This fixed by using 1 by default as
>>   valid length input and tweaking CatchNode::Value.
>> 
>> The new patch includes test cases for both issues.
>
> 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 five additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8279219
>  - review
>  - tests & fix
>  - Revert "8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large"
>    
>    This reverts commit 04ad668921abbd71dfbc474eed6f1760f7a541b1.

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From kbarrett at openjdk.java.net  Tue Feb  1 16:27:12 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 16:27:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
Message-ID: <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>

On Sat, 29 Jan 2022 14:44:47 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 136:
>> 
>>> 134:   if (nbits == 64) {
>>> 135:     assert(count <= 1, "must be");
>>> 136:     return bits;
>> 
>> For consistency with the < 64 case, shouldn't this be `return (count == 0) ? 0 : bits;` ?
>
> @kimbarrett - Thanks for the review! Good catch! I believe you are correct,
> but let's wait for @adinn to chime in here.

Returning 0 if count == 0 and bits otherwise is consistent with the old code,
assuming the problematic shift doesn't cause UB data corruption or something
otherwise strange.  It might do the "mathematically correct" thing of shifting
out all the bits (so zeroing the value).  Another possibility is that the
implemented shift amount for N is N mod word-size (some platforms do that, but
I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
think there are any other non-strange non-UB-data-corruption possibilities.


result is initially 0.
with the old code:
- if count == 0, there are no iterations, and final result is still 0.
- if count == 1, there is one iteration.
  result <<= nbits
    -- if UB corruption, all bets are off
    -- if shifts by 64, result is unchanged (== 0)
    -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
  result |= (bits & mask)
    -- result == bits
- if count > 1, for additional iterations
  result <<= nbits
    -- if UB corruption, all bets are off
    -- if shifts by 64, result == 0
    -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
  result |= (bits & mask)
    -- result == bits

So with old code, for count > 0, result == bits (or UB corrupted data).

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

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

From vlivanov at openjdk.java.net  Tue Feb  1 16:37:09 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Feb 2022 16:37:09 GMT
Subject: RFR: 8280842: Access violation in ciTypeFlow::profiled_count [v2]
In-Reply-To: <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
References: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
 <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
Message-ID: <vvT0lUK5VtJRkhSp9qfDC4tBzMnU92u8CNR65YsNrYI=.df8404dd-bab4-4ca5-bd46-4512627f96b1@github.com>

On Tue, 1 Feb 2022 10:07:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> When the test() method is osr compiled, the exception handler is
>> marked as a loop head. It has 2 backedges at the 2 throw statements in
>> the method. ciTypeFlow expects to find some profile data at the
>> backedges but hotspot doesn't collect counters for athrow. The fix is
>> to turn the assert into an actual check.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test with -XX:-BackgroundCompilation

Looks good.

Marked as reviewed by vlivanov (Reviewer).

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

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

From kvn at openjdk.java.net  Tue Feb  1 17:42:07 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Feb 2022 17:42:07 GMT
Subject: RFR: 8280842: Access violation in ciTypeFlow::profiled_count [v2]
In-Reply-To: <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
References: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
 <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
Message-ID: <KM9ijk1stdcdpBSstqMPozQXGQiui-3Eip1fA_EqNuI=.c49794f8-23a5-422c-94a1-f5f4337d29be@github.com>

On Tue, 1 Feb 2022 10:07:50 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> When the test() method is osr compiled, the exception handler is
>> marked as a loop head. It has 2 backedges at the 2 throw statements in
>> the method. ciTypeFlow expects to find some profile data at the
>> backedges but hotspot doesn't collect counters for athrow. The fix is
>> to turn the assert into an actual check.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test with -XX:-BackgroundCompilation

Marked as reviewed by kvn (Reviewer).

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

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

From kvn at openjdk.java.net  Tue Feb  1 17:52:12 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Feb 2022 17:52:12 GMT
Subject: RFR: 8280600: C2: assert(!had_error) failed: bad dominance
In-Reply-To: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
References: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
Message-ID: <7LSxhOE62NSoDBR0XrTmeqUn5f77pVfhwCuXxmmj2bQ=.3908b6c4-1c85-4c1b-bc0e-545672fcc9d5@github.com>

On Tue, 1 Feb 2022 15:03:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> For the inner loop of the test, c2, first, creates a counted loop and
> assigns the type -400..1 to the trip count Phi. The loop body has a
> range check that guards a CastII on the trip count Phi. That CastII
> has type: 0..1 as a result.
> 
> Pre/main/post loops are then created. In the process,
> PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
> the main loop. That CastII's input is the add node of the pre
> loop. The loop is also unrolled once. The CastII on the loop entry is
> pushed through the add node and replaced by the range check CastII
> that has the same input and dominates. As a result, the main loop
> tripcount Phi has type -400..1 but init value, 1..2. This causes the
> Phi to constant fold to 1. The amount of unrolling and the main loop
> bounds are inconsistent (the loop shouldn't be unrolled if it executes
> for one iteration) but when the unrolling decision is made the type of
> the lower bound of the main loop is not yet accurately known.
> 
> The actual crash is the result of a chain of nodes sunk out of the
> inner loop and pinned out of the loop with a CastII node. The type of
> the CastII and the type of its input after unrolling conflict.
> 
> The fix I propose is to change the type of the CastII that's added
> before the main loop so it can't be replaced by a dominating
> CastII. Given that CastII's role is to carry dependencies for nodes in
> the loop body on the loop entry test, I think it's the right thing to
> do. I've also been working on 8275202 (C2: optimize out more redundant
> conditions) as a way to avoid type inconsistencies like this one.

Seems good. Will run testing before approval.

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

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

From vlivanov at openjdk.java.net  Tue Feb  1 19:18:25 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Feb 2022 19:18:25 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
Message-ID: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>

Testing: hs-tier1 - hs-tier6

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

Commit messages:
 - Compiler support of CP entries in error state

Changes: https://git.openjdk.java.net/jdk/pull/7314/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7314&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279822
  Stats: 451 lines in 10 files changed: 361 ins; 48 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7314/head:pull/7314

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

From kvn at openjdk.java.net  Tue Feb  1 19:53:14 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Feb 2022 19:53:14 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <8BpyLsZPMXb-tje4J0r43McD6mDpK0mtMY4GuK-Jk14=.f97e0689-bd84-479e-a191-c8e51d885018@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Testing: hs-tier1 - hs-tier6

Looks fine to me but please explain in PR description what you fixed and how.

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

Marked as reviewed by kvn (Reviewer).

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

From vlivanov at openjdk.java.net  Tue Feb  1 20:09:08 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 1 Feb 2022 20:09:08 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <VMvIaHJ4Cso9vU7yCcY132Sl39A1mWAKZVfYOsgtNBo=.fba404ba-fdaf-4209-a526-15b4e48a70dc@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

Vladimir, thanks for the review. I updated the description. (I intended to create a draft PR, but erroneously published it.)

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

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

From kvn at openjdk.java.net  Wed Feb  2 02:47:05 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 2 Feb 2022 02:47:05 GMT
Subject: RFR: 8280600: C2: assert(!had_error) failed: bad dominance
In-Reply-To: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
References: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
Message-ID: <8QB3ggBqM4LidKclMMvZUZZtb9MCQ688LO-jhHXRdtQ=.da394a94-78d6-4f1f-94b3-26a11d5c6cc3@github.com>

On Tue, 1 Feb 2022 15:03:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> For the inner loop of the test, c2, first, creates a counted loop and
> assigns the type -400..1 to the trip count Phi. The loop body has a
> range check that guards a CastII on the trip count Phi. That CastII
> has type: 0..1 as a result.
> 
> Pre/main/post loops are then created. In the process,
> PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
> the main loop. That CastII's input is the add node of the pre
> loop. The loop is also unrolled once. The CastII on the loop entry is
> pushed through the add node and replaced by the range check CastII
> that has the same input and dominates. As a result, the main loop
> tripcount Phi has type -400..1 but init value, 1..2. This causes the
> Phi to constant fold to 1. The amount of unrolling and the main loop
> bounds are inconsistent (the loop shouldn't be unrolled if it executes
> for one iteration) but when the unrolling decision is made the type of
> the lower bound of the main loop is not yet accurately known.
> 
> The actual crash is the result of a chain of nodes sunk out of the
> inner loop and pinned out of the loop with a CastII node. The type of
> the CastII and the type of its input after unrolling conflict.
> 
> The fix I propose is to change the type of the CastII that's added
> before the main loop so it can't be replaced by a dominating
> CastII. Given that CastII's role is to carry dependencies for nodes in
> the loop body on the loop entry test, I think it's the right thing to
> do. I've also been working on 8275202 (C2: optimize out more redundant
> conditions) as a way to avoid type inconsistencies like this one.

Testing passed.

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

Marked as reviewed by kvn (Reviewer).

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

From dlong at openjdk.java.net  Wed Feb  2 03:39:07 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 2 Feb 2022 03:39:07 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v7]
In-Reply-To: <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
Message-ID: <abIurbqw_i9sWe2GdJVE324gLf8gtloU3xvU61kTs74=.8a2ff7b6-3f68-4bf7-b9fe-e7f9420d4b8b@github.com>

On Wed, 2 Feb 2022 01:52:46 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use jlong instead of int64_t"

How about making the traversal mark type unsigned?

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

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

From jbhateja at openjdk.java.net  Wed Feb  2 05:52:06 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 2 Feb 2022 05:52:06 GMT
Subject: RFR: 8280976: Incorrect encoding of avx512 vpsraq instruction with
 mask and constant shift.
In-Reply-To: <kdMhiRw_NYyOEOBxgyT8GVvjSNsDE1eE1UsBTnpvRLE=.0543439a-7fe8-49c6-95e1-1fee6f361756@github.com>
References: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
 <kdMhiRw_NYyOEOBxgyT8GVvjSNsDE1eE1UsBTnpvRLE=.0543439a-7fe8-49c6-95e1-1fee6f361756@github.com>
Message-ID: <rHLqlBVjw0ClW60EIyEhMSWz5PWCT_hywrmq4nPC1c8=.31b9b00a-01a3-4a6b-9a1f-a8290af7e074@github.com>

On Tue, 1 Feb 2022 08:54:39 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> -  Incorrect encoding fixed.
>> 
>> EVEX.512.66.0F.W1 72 /4 ib VPSRAQ zmm1 {k1}{z}, zmm2/m512/m64bcst, imm8 | F | V/V | AVX512F | Shift quadwords in zmm2/m512/m64bcst right by imm8 while shifting in sign bits using writemask k1.
>> -- | -- | -- | -- | --
>> 
>> Thanks,
>> Jatin
>
> Looks good!

Thanks @neliasso , do I need another reviewer approval for this.

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

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

From xliu at openjdk.java.net  Wed Feb  2 07:12:47 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 2 Feb 2022 07:12:47 GMT
Subject: RFR: 8280541: remove self-recursion of
 ConnectionGraph::find_inst_mem() [v2]
In-Reply-To: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
References: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
Message-ID: <ULUqtPuku1ee0zc8GdxBz0O3g1ba-qtT0fTGUfXjkqk=.cf6bb7c5-4f4e-4bb6-ac04-76b604b6c23f@github.com>

> This is a follow-up task of JDK-8276219.
> 
> ConnectionGraph::find_inst_mem() contains a self-recursion for MergeMemNode.
> It drills down into one input of MergeMemNode and tries to locate the memory node
> which has the exact alias_idx. Once it returns, the result won't change from
> recursion. Therefore, it's not necessary to use recursion in this case. We can
> reset the initial state of this function and respin.
> 
> We can use a collection to remember all MergeMem Nodes and update them after then. 
> 
> This patch also makes a cleanup in MergeMemNode::memory_at(). C is not in use in
> that function.

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

  Add an assertion in debug build.
  
  This patch ensures the result is same as recursion.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7204/files
  - new: https://git.openjdk.java.net/jdk/pull/7204/files/ae0d0217..b9d40925

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

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

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

From thartmann at openjdk.java.net  Wed Feb  2 07:16:08 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Feb 2022 07:16:08 GMT
Subject: RFR: 8280600: C2: assert(!had_error) failed: bad dominance
In-Reply-To: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
References: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
Message-ID: <Fezf4m9ph2pAfwMTpKNnC_zDx2Kdbq84ADPTagjcC5E=.ad0902e3-8603-44b5-939e-c82992abfd79@github.com>

On Tue, 1 Feb 2022 15:03:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> For the inner loop of the test, c2, first, creates a counted loop and
> assigns the type -400..1 to the trip count Phi. The loop body has a
> range check that guards a CastII on the trip count Phi. That CastII
> has type: 0..1 as a result.
> 
> Pre/main/post loops are then created. In the process,
> PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
> the main loop. That CastII's input is the add node of the pre
> loop. The loop is also unrolled once. The CastII on the loop entry is
> pushed through the add node and replaced by the range check CastII
> that has the same input and dominates. As a result, the main loop
> tripcount Phi has type -400..1 but init value, 1..2. This causes the
> Phi to constant fold to 1. The amount of unrolling and the main loop
> bounds are inconsistent (the loop shouldn't be unrolled if it executes
> for one iteration) but when the unrolling decision is made the type of
> the lower bound of the main loop is not yet accurately known.
> 
> The actual crash is the result of a chain of nodes sunk out of the
> inner loop and pinned out of the loop with a CastII node. The type of
> the CastII and the type of its input after unrolling conflict.
> 
> The fix I propose is to change the type of the CastII that's added
> before the main loop so it can't be replaced by a dominating
> CastII. Given that CastII's role is to carry dependencies for nodes in
> the loop body on the loop entry test, I think it's the right thing to
> do. I've also been working on 8275202 (C2: optimize out more redundant
> conditions) as a way to avoid type inconsistencies like this one.

Looks reasonable to me.

test/hotspot/jtreg/compiler/loopopts/TestCastIIMakesMainLoopPhiDead.java line 50:

> 48:       TestCastIIMakesMainLoopPhiDead t = new TestCastIIMakesMainLoopPhiDead();
> 49:       for (int i = 0; i < 3; i++) {
> 50:         t.test();

Indentation is inconsistent (4 whitespaces for Java code).

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Wed Feb  2 07:19:04 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Feb 2022 07:19:04 GMT
Subject: RFR: 8280976: Incorrect encoding of avx512 vpsraq instruction with
 mask and constant shift.
In-Reply-To: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
References: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
Message-ID: <3T_i03JYtDjlno5iHR0m-S7yaXQgSsQrl1jDYEZv4Yk=.86c04219-cf37-4134-9b39-9abd9e80aa9a@github.com>

On Mon, 31 Jan 2022 20:15:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Incorrect encoding fixed.
> 
> EVEX.512.66.0F.W1 72 /4 ib VPSRAQ zmm1 {k1}{z}, zmm2/m512/m64bcst, imm8 | F | V/V | AVX512F | Shift quadwords in zmm2/m512/m64bcst right by imm8 while shifting in sign bits using writemask k1.
> -- | -- | -- | -- | --
> 
> Thanks,
> Jatin

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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

From roland at openjdk.java.net  Wed Feb  2 07:37:15 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:37:15 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <KB5xQb2W5nRXPznbNqGvNACvUNsRQuwucAo2ftHqT2A=.10720107-58bc-41a4-aeeb-50b18be3a052@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
 <KB5xQb2W5nRXPznbNqGvNACvUNsRQuwucAo2ftHqT2A=.10720107-58bc-41a4-aeeb-50b18be3a052@github.com>
Message-ID: <X2lPXTnkrqe2kjdiymUqAXWeC7crnIpx2xF7jILPfS0=.c0b0767f-5f70-4374-b3fe-06e4d90a53c1@github.com>

On Tue, 1 Feb 2022 13:33:49 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8279219
>>  - review
>>  - tests & fix
>>  - Revert "8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large"
>>    
>>    This reverts commit 04ad668921abbd71dfbc474eed6f1760f7a541b1.
>
> Looks good!

@neliasso @TobiHartmann thanks for the reviews.

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

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

From roland at openjdk.java.net  Wed Feb  2 07:37:16 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:37:16 GMT
Subject: Integrated: 8279219: [REDO] C2 crash when allocating array of size too
 large
In-Reply-To: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
Message-ID: <Bfl5oEoEN3oeRsC-7PDyslkOnBRuGWxIifY4IlvHYFo=.84eeff77-b20d-4a9b-93cf-df56e8dd8872@github.com>

On Tue, 4 Jan 2022 08:51:30 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The new fix is largely similar to the previous one. 3 bugs were filed
> because of the previous change but there are only really 2 issues:
> 
> - attaching the valid length condition at expansion time to the new
>   array runtime call causes issues. With Shenandoah, passes of loop
>   opts are executed after macro expansion but precedence edges are
>   ignored when assigning controls to nodes which causes loop opts to
>   incorrectly attempt to eliminate the node pointed to by the
>   precedence edge. A similar issue occurs when the runtime call ends
>   up in a subgraph that dies after macro expansion because the
>   precedence edge is not cleared by dead code elimination which causes
>   the runtime call to still be reachable. In the new patch, this is
>   fixed by appending an extra input to the runtime call instead of
>   using a precedence edge.
> 
> - In the previous patch, a top valid length input is used when there's
>   no valid length input that needs to be recorded. That can cause an
>   assert failure during CCP. If valid length initially has type top,
>   the CatchNode out of the AllocateArray then have type (control,
>   control). If next, the valid length input becomes constant 0, the
>   CatchNode has type (top, control). An assert catches that the type
>   of the CatchNode doesn't widen. This fixed by using 1 by default as
>   valid length input and tweaking CatchNode::Value.
> 
> The new patch includes test cases for both issues.

This pull request has now been integrated.

Changeset: d32f99ee
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d32f99ee65679601d6e160e7975fc1e367bfa6f4
Stats:     307 lines in 11 files changed: 231 ins; 53 del; 23 mod

8279219: [REDO] C2 crash when allocating array of size too large

Reviewed-by: thartmann, neliasso

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

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

From roland at openjdk.java.net  Wed Feb  2 07:38:07 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:38:07 GMT
Subject: RFR: 8280885: Shenandoah: Some tests failed with
 "EA: missing allocation reference path"
In-Reply-To: <AoLhSTpLgUUz3BrcyLqVwinaiRL6u8LRVwElv4NWyaw=.029946bf-9418-4d6d-a38f-b274268c7041@github.com>
References: <JeVUt7Uq_gFOby36DD_HFqCrUo9yu2bw4WgH6sGMQvw=.d269226e-c64a-4cba-964f-50f8a07ea7f7@github.com>
 <AoLhSTpLgUUz3BrcyLqVwinaiRL6u8LRVwElv4NWyaw=.029946bf-9418-4d6d-a38f-b274268c7041@github.com>
Message-ID: <Heb5pr0uTo3S_MvL8paVgY9OI9ZOYJZrWVkoKOEAtSM=.b8dd6d6e-577e-489f-9b9c-6b384b494251@github.com>

On Tue, 1 Feb 2022 15:34:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> EA encounters an unexpected IU barrier. I think it's good enough to
>> change ShenandoahBarrierSetC2::is_gc_barrier_node() so it returns true
>> for IU barriers.
>
> Looks good! Thanks!

@rkennke thanks for the review.

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

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

From roland at openjdk.java.net  Wed Feb  2 07:39:19 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:39:19 GMT
Subject: Integrated: 8280842: Access violation in ciTypeFlow::profiled_count
In-Reply-To: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
References: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
Message-ID: <4pCI34hR9DHYBC3Vk0agt0NfLHLcAZJTTXfkiOdPc0w=.1ee10b29-e7d7-4ebd-9530-d46abad90954@github.com>

On Tue, 1 Feb 2022 09:47:28 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> When the test() method is osr compiled, the exception handler is
> marked as a loop head. It has 2 backedges at the 2 throw statements in
> the method. ciTypeFlow expects to find some profile data at the
> backedges but hotspot doesn't collect counters for athrow. The fix is
> to turn the assert into an actual check.

This pull request has now been integrated.

Changeset: 97af3230
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97af32304101397bb33cbbd1e35fd9124f9e2311
Stats:     62 lines in 2 files changed: 60 ins; 1 del; 1 mod

8280842: Access violation in ciTypeFlow::profiled_count

Reviewed-by: neliasso, vlivanov, kvn

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

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

From roland at openjdk.java.net  Wed Feb  2 07:39:17 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:39:17 GMT
Subject: RFR: 8280842: Access violation in ciTypeFlow::profiled_count [v2]
In-Reply-To: <ENx01dxPYa5g29YzIUFDaeK_RSFb1EoTGEmp6S2reeU=.83cf8fd4-c453-4583-886a-631e689bec27@github.com>
References: <itJ3OXx9sAEe1kgv57mw5GWerxOmwXUIt_bsB-ugP40=.7d8684db-68a2-4103-a141-518dcd6f48e5@github.com>
 <VA4Lmsyt6hzmqM0PDUjOLQZXpKcIWi-XWk_atURwPOE=.2ad14c31-6596-4e57-b186-d61314d99ee4@github.com>
 <ENx01dxPYa5g29YzIUFDaeK_RSFb1EoTGEmp6S2reeU=.83cf8fd4-c453-4583-886a-631e689bec27@github.com>
Message-ID: <OX6lOeJ00hRpalGH0erOw6V0T2yr3lw5rgKBE7mQG7s=.b092bea4-7036-4481-b04f-ba79233f1fd3@github.com>

On Tue, 1 Feb 2022 13:28:45 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test with -XX:-BackgroundCompilation
>
> Looks good.

@neliasso @iwanowww @vnkozlov thanks for the reviews.

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

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

From jbhateja at openjdk.java.net  Wed Feb  2 07:40:11 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 2 Feb 2022 07:40:11 GMT
Subject: Integrated: 8280976: Incorrect encoding of avx512 vpsraq instruction
 with mask and constant shift.
In-Reply-To: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
References: <uwi9vGO7U4XOBsGuiu1ynwxWSniE9uQFIvh1agE0gUA=.9abc51e2-dca5-466c-a873-8da2fff5dedf@github.com>
Message-ID: <JYoiGP0IYjBubLsrx6eY5NqvMuF0h2dH_zpxJeZD2z8=.b26d2c62-6bc4-41c3-940a-336837d2aaf3@github.com>

On Mon, 31 Jan 2022 20:15:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Incorrect encoding fixed.
> 
> EVEX.512.66.0F.W1 72 /4 ib VPSRAQ zmm1 {k1}{z}, zmm2/m512/m64bcst, imm8 | F | V/V | AVX512F | Shift quadwords in zmm2/m512/m64bcst right by imm8 while shifting in sign bits using writemask k1.
> -- | -- | -- | -- | --
> 
> Thanks,
> Jatin

This pull request has now been integrated.

Changeset: 48a32b5f
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/48a32b5f3aa1b238bc9857002325579a5b041685
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8280976: Incorrect encoding of avx512 vpsraq instruction with mask and constant shift.

Reviewed-by: neliasso, thartmann

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

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

From roland at openjdk.java.net  Wed Feb  2 07:41:09 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:41:09 GMT
Subject: Integrated: 8280885: Shenandoah: Some tests failed with
 "EA: missing allocation reference path"
In-Reply-To: <JeVUt7Uq_gFOby36DD_HFqCrUo9yu2bw4WgH6sGMQvw=.d269226e-c64a-4cba-964f-50f8a07ea7f7@github.com>
References: <JeVUt7Uq_gFOby36DD_HFqCrUo9yu2bw4WgH6sGMQvw=.d269226e-c64a-4cba-964f-50f8a07ea7f7@github.com>
Message-ID: <PvhwtNVX3WE_rXuZ0L1oKUCyIAiGKkydxryTFBLgJdE=.7b8edf46-81f6-42b3-a8e2-fcf635879882@github.com>

On Tue, 1 Feb 2022 10:03:17 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> EA encounters an unexpected IU barrier. I think it's good enough to
> change ShenandoahBarrierSetC2::is_gc_barrier_node() so it returns true
> for IU barriers.

This pull request has now been integrated.

Changeset: ab638341
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab638341de164965e06bb1d59808670260916b82
Stats:     75 lines in 2 files changed: 74 ins; 0 del; 1 mod

8280885: Shenandoah: Some tests failed with "EA: missing allocation reference path"

Reviewed-by: rkennke

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

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

From roland at openjdk.java.net  Wed Feb  2 07:42:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:42:10 GMT
Subject: RFR: 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest
 after JDK-8276116
In-Reply-To: <arStD_S8aTHhVn9yBUbHqDraa2VaEwuqgnYYQlwEtlc=.a0b11e38-aa61-4aec-a890-56a45ede7eaa@github.com>
References: <rSKIV1Gha8K9sQeCiFa7Hi2tAGh4PoNJ9PLb4C4_dEc=.a4074b31-1639-4514-a56e-13abe522bf1e@github.com>
 <arStD_S8aTHhVn9yBUbHqDraa2VaEwuqgnYYQlwEtlc=.a0b11e38-aa61-4aec-a890-56a45ede7eaa@github.com>
Message-ID: <pNcOs7tj7LLGg7IxsiYUiHOc1nreyPHzSv-suuej4fA=.fe3fe28f-e0b1-4a83-b272-e27b50125d29@github.com>

On Tue, 1 Feb 2022 15:59:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Removal of a couple lines of dead code.
>
> Looks good and trivial.

@TobiHartmann thanks for the review.

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

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

From roland at openjdk.java.net  Wed Feb  2 07:42:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:42:10 GMT
Subject: Integrated: 8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest
 after JDK-8276116
In-Reply-To: <rSKIV1Gha8K9sQeCiFa7Hi2tAGh4PoNJ9PLb4C4_dEc=.a4074b31-1639-4514-a56e-13abe522bf1e@github.com>
References: <rSKIV1Gha8K9sQeCiFa7Hi2tAGh4PoNJ9PLb4C4_dEc=.a4074b31-1639-4514-a56e-13abe522bf1e@github.com>
Message-ID: <dePQzvgFbn1_zAzIIbRQ9dH7EhS25q4PuI0hS-yq2-A=.153f9681-d1fe-4735-9f60-36059c2a008f@github.com>

On Tue, 1 Feb 2022 15:51:49 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Removal of a couple lines of dead code.

This pull request has now been integrated.

Changeset: 4304a772
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4304a7728ec60f7937e0198c4f85384064fe560e
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8279535: C2: Dead code in PhaseIdealLoop::create_loop_nest after JDK-8276116

Reviewed-by: thartmann

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

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

From roland at openjdk.java.net  Wed Feb  2 07:51:53 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:51:53 GMT
Subject: RFR: 8280600: C2: assert(!had_error) failed: bad dominance [v2]
In-Reply-To: <8QB3ggBqM4LidKclMMvZUZZtb9MCQ688LO-jhHXRdtQ=.da394a94-78d6-4f1f-94b3-26a11d5c6cc3@github.com>
References: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
 <8QB3ggBqM4LidKclMMvZUZZtb9MCQ688LO-jhHXRdtQ=.da394a94-78d6-4f1f-94b3-26a11d5c6cc3@github.com>
Message-ID: <3bN0RZaqcBEjrgdaEewxF66o9A2ihtf7YuXCZWvKP9g=.84e0b334-1efd-422d-97e8-5d2258328888@github.com>

On Wed, 2 Feb 2022 02:43:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation
>
> Testing passed.

@vnkozlov thanks for review and testing
@TobiHartmann thanks for the review. I will fix indentation before I push the change.

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

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

From roland at openjdk.java.net  Wed Feb  2 07:51:52 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 07:51:52 GMT
Subject: RFR: 8280600: C2: assert(!had_error) failed: bad dominance [v2]
In-Reply-To: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
References: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
Message-ID: <REdX00XBkeEGmpEsxKm-o6G0nWvxPTpUS-vtAcRw6d4=.aeb6ca2f-9766-4454-b5b2-77aa123ea7e3@github.com>

> For the inner loop of the test, c2, first, creates a counted loop and
> assigns the type -400..1 to the trip count Phi. The loop body has a
> range check that guards a CastII on the trip count Phi. That CastII
> has type: 0..1 as a result.
> 
> Pre/main/post loops are then created. In the process,
> PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
> the main loop. That CastII's input is the add node of the pre
> loop. The loop is also unrolled once. The CastII on the loop entry is
> pushed through the add node and replaced by the range check CastII
> that has the same input and dominates. As a result, the main loop
> tripcount Phi has type -400..1 but init value, 1..2. This causes the
> Phi to constant fold to 1. The amount of unrolling and the main loop
> bounds are inconsistent (the loop shouldn't be unrolled if it executes
> for one iteration) but when the unrolling decision is made the type of
> the lower bound of the main loop is not yet accurately known.
> 
> The actual crash is the result of a chain of nodes sunk out of the
> inner loop and pinned out of the loop with a CastII node. The type of
> the CastII and the type of its input after unrolling conflict.
> 
> The fix I propose is to change the type of the CastII that's added
> before the main loop so it can't be replaced by a dominating
> CastII. Given that CastII's role is to carry dependencies for nodes in
> the loop body on the loop entry test, I think it's the right thing to
> do. I've also been working on 8275202 (C2: optimize out more redundant
> conditions) as a way to avoid type inconsistencies like this one.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  indentation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7307/files
  - new: https://git.openjdk.java.net/jdk/pull/7307/files/c218381f..a888a0fd

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

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

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

From roland at openjdk.java.net  Wed Feb  2 08:04:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 08:04:10 GMT
Subject: Integrated: 8280600: C2: assert(!had_error) failed: bad dominance
In-Reply-To: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
References: <TjLybnhNZlOyXpXcxY03CczebBGgFeRScqmMoHFLkW8=.fbc759a4-8cee-4f4f-9d7b-043e9ff2afce@github.com>
Message-ID: <E11xD-ADP32Y5Wg8eFFKQRGK5OHjPtL-FLwXqFBkL3s=.f32ccc87-882e-4b92-9e31-d42770045fd1@github.com>

On Tue, 1 Feb 2022 15:03:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> For the inner loop of the test, c2, first, creates a counted loop and
> assigns the type -400..1 to the trip count Phi. The loop body has a
> range check that guards a CastII on the trip count Phi. That CastII
> has type: 0..1 as a result.
> 
> Pre/main/post loops are then created. In the process,
> PhaseIdealLoop::cast_incr_before_loop() inserts a CastII right before
> the main loop. That CastII's input is the add node of the pre
> loop. The loop is also unrolled once. The CastII on the loop entry is
> pushed through the add node and replaced by the range check CastII
> that has the same input and dominates. As a result, the main loop
> tripcount Phi has type -400..1 but init value, 1..2. This causes the
> Phi to constant fold to 1. The amount of unrolling and the main loop
> bounds are inconsistent (the loop shouldn't be unrolled if it executes
> for one iteration) but when the unrolling decision is made the type of
> the lower bound of the main loop is not yet accurately known.
> 
> The actual crash is the result of a chain of nodes sunk out of the
> inner loop and pinned out of the loop with a CastII node. The type of
> the CastII and the type of its input after unrolling conflict.
> 
> The fix I propose is to change the type of the CastII that's added
> before the main loop so it can't be replaced by a dominating
> CastII. Given that CastII's role is to carry dependencies for nodes in
> the loop body on the loop entry test, I think it's the right thing to
> do. I've also been working on 8275202 (C2: optimize out more redundant
> conditions) as a way to avoid type inconsistencies like this one.

This pull request has now been integrated.

Changeset: de826ba1
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de826ba18a5e98586029581c2d4bcd27334fbdd1
Stats:     54 lines in 2 files changed: 53 ins; 0 del; 1 mod

8280600: C2: assert(!had_error) failed: bad dominance

Reviewed-by: kvn, thartmann

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

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

From roland at openjdk.java.net  Wed Feb  2 10:44:28 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 10:44:28 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination
Message-ID: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>

The loop exit condition of the test method:

if (i == stop) {
    break;
}

requires insertion of a loop limit predicate when the loop is turned
into a counted loop. stop is a LoadI. Next:

array[stop - i + j] = 0;

is transformed to:

array[stop - i] = 0;

and the range check for that array access becomes candidate for
predication in a subsequent loop opts pass. stop has control just
above the loop limit check when that happens (because it is assigned
control as late as possible). But the loop predicate for the bound
check needs to be above the loop limit check and that causes the
assert failure.

There's already logic in PhaseIdealLoop::build_loop_late_post_work()
to assign control to nodes above predicates so this sort of issues
doesn't occur. But it only applies to node initially on the entry
projection right above the loop head. The fix I propose is to remove
that restriction.

That logic was added by JDK-8203197 and looking back at this change I
noticed I replaced some existing logic with the current logic but,
while the 2 overlap, the current logic is not guaranteed to always
cover some cases handled by the old logic. So I resurrected that old
logic here.

Finally, when running tests, I hit failures because Opaque nodes for
skeleton predicates can now end up above a predicate that is split
thru phi. That causes the Opaque nodes to be split up and breaks
pattern matching. I'm actually not sure this issue is specific to the
change here so I think it's best to treat it as a general issue and
fix it by cloning the chain of nodes that lead to the Opaque node
down.

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

Commit messages:
 - fix & test

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

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

From roland at openjdk.java.net  Wed Feb  2 12:51:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Feb 2022 12:51:10 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses
In-Reply-To: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
Message-ID: <EnhYiAiG-2AcAuZNj3SA8zWlf-RbHuHhE-XqTtfoj0s=.e5150427-92b1-4eb7-8c3d-2d77a3df0536@github.com>

On Mon, 6 Dec 2021 09:59:44 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Outside the type system code itself, c2 usually assumes that a
> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
> klass(). To have proper support for interfaces, that can't be true as
> a type needs to be represented by an instance class and a set of
> interfaces. This patch hides the klass() accessor of
> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
> that makes that code suitable for proper interface support in a
> subsequent change. This patch doesn't add proper interface support yet
> and is mostly refactoring. "Mostly" because there are cases where the
> previous logic would use a ciKlass but the new one works with a
> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
> klass is exact or not. That extra bit of information can sometimes
> help and so could result in slightly different decisions.
> 
> To remove the klass() accessors, the new logic either relies on:
> 
> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
> toop->klass()->is_subtype_of(other_toop->klass())
> the new code is:
> toop->is_java_subtype_of(other_toop)
> 
> - variants of the klass() accessors for narrower cases like
>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>   interface in which case it returns Object),
>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>   the type is exact).
> 
> When I tested this patch, for most changes in this patch, I had the
> previous logic, the new logic and a check that verified that they
> return the same result. I ran as much testing as I could that way.

Another comment to keep alive.

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

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

From duke at openjdk.java.net  Wed Feb  2 12:56:10 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 2 Feb 2022 12:56:10 GMT
Subject: Withdrawn: JDK-8278135: Excessive null check guard deoptimization due
 to java.lang.Class unloaded
In-Reply-To: <OWkfUhkh8KL2oIIs34LmpMP_I9Wu7C-vd5uELId53lw=.c6239b9a-7e9b-4284-90c6-01686eaac6ef@github.com>
References: <OWkfUhkh8KL2oIIs34LmpMP_I9Wu7C-vd5uELId53lw=.c6239b9a-7e9b-4284-90c6-01686eaac6ef@github.com>
Message-ID: <k2uO8IwJuzbLwraPV6N_wq5jABuDEgaRF5qYJk5fciY=.0568017f-4468-4b5a-9d8b-ceffa330140c@github.com>

On Thu, 2 Dec 2021 11:20:48 GMT, ?? <duke at openjdk.java.net> wrote:

> When run the following test, lots of un-necessary null check deoptimization happen.
> 
> Small Test:
> 
> public class CodeDependenciesTest {
>     private Object obj;
>     private String[] strs;
>     private Object[][] objs;
>     private static Class clzOne;
>     private static Class clzTwo;
>     public static void main(String[] args) throws Exception {
>         CodeDependenciesTest codeDependenciesTest = new CodeDependenciesTest();
>         codeDependenciesTest.obj = new String("1");
>         for (int i = 0; i < 300000; i++) {
>             codeDependenciesTest.foo();
>         }
>     }
> 
>     public void foo() {
>         objs = new Object[10][10];
>         for (int i = 0; i < 10; i++) {
>             for (int j = 0; j < 10; j++) {
>                 objs[i][j] = new Object();
>             }
>         }
>         clzOne = InvokeTest.class;
>         clzTwo = clzOne;
>     }
> 
>     static class InvokeTest {
>         public void bar(String i) {
>             try {
>                 Thread.sleep(Long.valueOf(i));
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
> 
> 
> The deoptimization log generated by `-XX:+TraceDeoptimization` is:
> 
> Uncommon trap   bci=63 pc=0x00007f0eafbe1e38, relative_pc=0x00000000000005f8, method=CodeDependenciesTest.foo()V, debug_id=0
> Uncommon trap occurred in CodeDependenciesTest::foo compiler=c2 compile_id=288 (@0x00007f0eafbe1e38) thread=20285 reason=null_assert_or_unreached0 action=make_not_entrant unloaded_class_index=-1 debug_id=0
> DEOPT UNPACKING thread 0x00007f0ec0028190 vframeArray 0x00007f0ec02348a0 mode 2
>      {method} {0x00007f0e7c4004f0} 'foo' '()V' in 'CodeDependenciesTest' - putstatic @ bci 63 sp = 0x00007f0ec8a317c8
> Uncommon trap   bci=63 pc=0x00007f0eafbe0f34, relative_pc=0x0000000000000514, method=CodeDependenciesTest.foo()V, debug_id=0
> Uncommon trap occurred in CodeDependenciesTest::foo compiler=c2 compile_id=287 (@0x00007f0eafbe0f34) thread=20285 reason=null_assert_or_unreached0 action=make_not_entrant unloaded_class_index=-1 debug_id=0
> DEOPT UNPACKING thread 0x00007f0ec0028190 vframeArray 0x00007f0ec0235e40 mode 2
>      {method} {0x00007f0e7c4004f0} 'foo' '()V' in 'CodeDependenciesTest' - putstatic @ bci 63 sp = 0x00007f0ec8a317c8
> 
> 
> The corresponding opto assembly is,
> 
> 230     B20: #  out( B56 B21 ) <- in( B58 B43 B41 B19 )  Freq: 0.999369
> 230     movl    [RBX + #112 (8-bit)], narrowoop: java/lang/Class:exact *        # compressed ptr ! Field: CodeDependenciesTest.clzOne
> 237     movq    R10, RBX        # ptr -> long
> 23a     movq    RBP, java/lang/Class:exact *    # ptr
> 244     movq    R11, RBP        # ptr -> long
> 247     xorq    R11, R10        # long
> 24a     shrq    R11, #22
> 24e     testq   R11, R11
> 251     je     B56  P=0.000001 C=-1.000000
> 
> 257     B21: #  out( B56 B22 ) <- in( B20 )  Freq: 0.999368
> 257     shrq    R10, #9
> 25b     addq    R14, R10        # ptr
> 25e     cmpb    [R14], #4
> 262     je     B56  P=0.000001 C=-1.000000
> 
> 5ed     B56: #  out( N780 ) <- in( B55 B21 B20 )  Freq: 3.02464e-06
> 5ed     movl    RSI, #-20       # int
>         nop     # 1 bytes pad for loops and calls
> 5f3     call,static  wrapper for: uncommon_trap(reason='null_assert_or_unreached0' action='make_not_entrant' debug_id='0')
>         # CodeDependenciesTest::foo @ bci:63 (line 23) L[0]=_ L[1]=_ L[2]=_ STK[0]=RBP
>         # OopMap {rbp=Oop off=1528/0x5f8}
> 5f8     stop    # ShouldNotReachHere
> 
> 
> C2 tries to generate a null-check for the get-static in `clzTwo = clzOne;`,  because it thinks that ciKlass of `java.lang.Class` is not loaded. 
> 
> The ciKlass of `java.lang.Class` is generated by the following stack trace,
> 
> (gdb) bt
> #0  SystemDictionary::find_instance_klass (class_name=0x800481080, class_loader=..., protection_domain=...) at /data/openjdk/jdk_dev/src/hotspot/share/classfile/systemDictionary.cpp:778
> #1  0x00007ffff610769d in SystemDictionary::find_instance_or_array_klass (class_name=0x800481080, class_loader=..., protection_domain=...) at /data/openjdk/jdk_dev/src/hotspot/share/classfile/systemDictionary.cpp:813
> #2  0x00007ffff610a55c in SystemDictionary::find_constrained_instance_or_array_klass (current=0x7ffff020a5e0, class_name=0x800481080, class_loader=...) at /data/openjdk/jdk_dev/src/hotspot/share/classfile/systemDictionary.cpp:1760
> #3  0x00007ffff55f1f29 in ciEnv::get_klass_by_name_impl (this=0x7fffc12066c0, accessing_klass=0x7fff8c0f6278, cpool=..., name=0x7ffff00334f8, require_local=false) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciEnv.cpp:519
> #4  0x00007ffff55f1d81 in ciEnv::get_klass_by_name_impl (this=0x7fffc12066c0, accessing_klass=0x7fff8c0f6278, cpool=..., name=0x7fff8c004518, require_local=false) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciEnv.cpp:488
> #5  0x00007ffff55f2466 in ciEnv::get_klass_by_index_impl (this=0x7fffc12066c0, cpool=..., index=34, is_accessible=@0x7fffc1204540: 112, accessor=0x7fff8c0f6278) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciEnv.cpp:611
> #6  0x00007ffff55f2632 in ciEnv::get_klass_by_index (this=0x7fffc12066c0, cpool=..., index=34, is_accessible=@0x7fffc1204540: 112, accessor=0x7fff8c0f6278) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciEnv.cpp:658
> #7  0x00007ffff55fb1bd in ciField::ciField (this=0x7fff8c0f9208, klass=0x7fff8c0f6278, index=65542) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciField.cpp:101
> #8  0x00007ffff55f344f in ciEnv::get_field_by_index_impl (this=0x7fffc12066c0, accessor=0x7fff8c0f6278, index=65542) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciEnv.cpp:798
> #9  0x00007ffff55f3506 in ciEnv::get_field_by_index (this=0x7fffc12066c0, accessor=0x7fff8c0f6278, index=65542) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciEnv.cpp:811
> #10 0x00007ffff56284ec in ciBytecodeStream::get_field (this=0x7fffc1204850, will_link=@0x7fffc12046cf: false) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciStreams.cpp:274
> #11 0x00007ffff562d10c in ciTypeFlow::StateVector::do_putstatic (this=0x7fff8c1bd078, str=0x7fffc1204850) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciTypeFlow.cpp:798
> #12 0x00007ffff562e960 in ciTypeFlow::StateVector::apply_one_bytecode (this=0x7fff8c1bd078, str=0x7fffc1204850) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciTypeFlow.cpp:1457
> #13 0x00007ffff563218d in ciTypeFlow::flow_block (this=0x7fff8c0f7a50, block=0x7fff8c0f8ec0, state=0x7fff8c1bd078, jsrs=0x7fff8c1bd0b8) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciTypeFlow.cpp:2364
> #14 0x00007ffff563332d in ciTypeFlow::df_flow_types (this=0x7fff8c0f7a50, start=0x7fff8c0f80a8, do_flow=true, temp_vector=0x7fff8c1bd078, temp_set=0x7fff8c1bd0b8) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciTypeFlow.cpp:2675
> #15 0x00007ffff563361f in ciTypeFlow::flow_types (this=0x7fff8c0f7a50) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciTypeFlow.cpp:2725
> #16 0x00007ffff5634081 in ciTypeFlow::do_flow (this=0x7fff8c0f7a50) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciTypeFlow.cpp:2886
> #17 0x00007ffff5605687 in ciMethod::get_flow_analysis (this=0x7fff8c0f6340) at /data/openjdk/jdk_dev/src/hotspot/share/ci/ciMethod.cpp:327
> #18 0x00007ffff5499d34 in InlineTree::check_can_parse (callee=0x7fff8c0f6340) at /data/openjdk/jdk_dev/src/hotspot/share/opto/bytecodeInfo.cpp:535
> #19 0x00007ffff55a0806 in CallGenerator::for_osr (m=0x7fff8c0f6340, osr_bci=22) at /data/openjdk/jdk_dev/src/hotspot/share/opto/callGenerator.cpp:299
> #20 0x00007ffff56aa2d9 in Compile::Compile (this=0x7fffc1205900, ci_env=0x7fffc12066c0, target=0x7fff8c0f6340, osr_bci=22, options=..., directive=0x7ffff01588a0) at /data/openjdk/jdk_dev/src/hotspot/share/opto/compile.cpp:687
> #21 0x00007ffff559da3e in C2Compiler::compile_method (this=0x7ffff0209f40, env=0x7fffc12066c0, target=0x7fff8c0f6340, entry_bci=22, install_code=true, directive=0x7ffff01588a0) at /data/openjdk/jdk_dev/src/hotspot/share/opto/c2compiler.cpp:108
> #22 0x00007ffff56c7f6e in CompileBroker::invoke_compiler_on_method (task=0x7ffff02322d0) at /data/openjdk/jdk_dev/src/hotspot/share/compiler/compileBroker.cpp:2291
> #23 0x00007ffff56c6aed in CompileBroker::compiler_thread_loop () at /data/openjdk/jdk_dev/src/hotspot/share/compiler/compileBroker.cpp:1966
> #24 0x00007ffff56e6f9f in CompilerThread::thread_entry (thread=0x7ffff020a5e0, __the_thread__=0x7ffff020a5e0) at /data/openjdk/jdk_dev/src/hotspot/share/compiler/compilerThread.cpp:59
> #25 0x00007ffff614a42f in JavaThread::thread_main_inner (this=0x7ffff020a5e0) at /data/openjdk/jdk_dev/src/hotspot/share/runtime/thread.cpp:1297
> #26 0x00007ffff614a2c5 in JavaThread::run (this=0x7ffff020a5e0) at /data/openjdk/jdk_dev/src/hotspot/share/runtime/thread.cpp:1280
> #27 0x00007ffff6147b08 in Thread::call_run (this=0x7ffff020a5e0) at /data/openjdk/jdk_dev/src/hotspot/share/runtime/thread.cpp:358
> #28 0x00007ffff5eafa4f in thread_native_entry (thread=0x7ffff020a5e0) at /data/openjdk/jdk_dev/src/hotspot/os/linux/os_linux.cpp:705
> #29 0x00007ffff779cea5 in start_thread (arg=0x7fffc1207700) at pthread_create.c:307
> #30 0x00007ffff72c19fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> 
> 
> When `CodeDependenciesTest.foo` is compiled, the classloader of the holder of this method is AppClassLoader, so it finds `java.lang.Class` in AppClassLoader, and finds nothing, so it thinks that `java.lang.Class` is not loaded, but `java.lang.Class` is a built-in class which is definitely loaded and initialized.
> 
> The following patch is the first patch we implemented, it tries to find Klass in the parent classloader when the Klass can not be found in current classloader. But the patch has potential risk, because user-defined classloader may not follow the 'parent delegation' style of classloading. 
> 
> diff --git a/src/hotspot/share/ci/ciEnv.cpp b/src/hotspot/share/ci/ciEnv.cpp
> index e29b56a..3ceafc4 100644
> --- a/src/hotspot/share/ci/ciEnv.cpp
> +++ b/src/hotspot/share/ci/ciEnv.cpp
> @@ -514,11 +514,17 @@ ciKlass* ciEnv::get_klass_by_name_impl(ciKlass* accessing_klass,
>    {
>      ttyUnlocker ttyul;  // release tty lock to avoid ordering problems
>      MutexLocker ml(current, Compile_lock);
> -    Klass* kls;
> -    if (!require_local) {
> -      kls = SystemDictionary::find_constrained_instance_or_array_klass(current, sym, loader);
> -    } else {
> -      kls = SystemDictionary::find_instance_or_array_klass(sym, loader, domain);
> +    Klass* kls = NULL;
> +    while (true) {
> +      if (!require_local) {
> +        kls = SystemDictionary::find_constrained_instance_or_array_klass(current, sym, loader);
> +      } else {
> +        kls = SystemDictionary::find_instance_or_array_klass(sym, loader, domain);
> +      }
> +      if (kls != NULL || loader() == NULL) {
> +        break;
> +      }
> +      loader = Handle(current, java_lang_ClassLoader::parent(loader()));
>      }
>      found_klass = kls;
>    }
> 
> 
> When the Klass of the field is not loaded, the generated 'null check' helps nothing, we think remove it is the right way to avoid the deoptmization.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.java.net  Wed Feb  2 13:59:32 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 2 Feb 2022 13:59:32 GMT
Subject: RFR: 8281117: Add regression test for JDK-8280587
Message-ID: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>

Recently, bug [JDK-8280600](https://bugs.openjdk.java.net/browse/JDK-8280600) was fixed, see [PR](https://github.com/openjdk/jdk/pull/7307).
[JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) has been detected as a duplicate bug.
However, [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) came with a differen reported test which failed with a different assert.
Therefore, I added this additional test as a second regression test.

I ran this test to check that it passes successfully.

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

Commit messages:
 - fixed copyright
 - 8281117: Add regression test for JDK-8280587

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

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

From chagedorn at openjdk.java.net  Wed Feb  2 14:41:09 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 2 Feb 2022 14:41:09 GMT
Subject: RFR: 8281117: Add regression test for JDK-8280587
In-Reply-To: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
References: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
Message-ID: <H0e-uP0gCNGxLIzyD7ygTzqh2MbOBc0kduD-ouHq764=.1fecebcc-d247-4cd9-8b53-2ab47189ed4f@github.com>

On Wed, 2 Feb 2022 13:51:01 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Recently, bug [JDK-8280600](https://bugs.openjdk.java.net/browse/JDK-8280600) was fixed, see [PR](https://github.com/openjdk/jdk/pull/7307).
> [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) has been detected as a duplicate bug.
> However, [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) came with a differen reported test which failed with a different assert.
> Therefore, I added this additional test as a second regression test.
> 
> I ran this test to check that it passes successfully.

Looks good, thanks for adding this additional test!

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

Marked as reviewed by chagedorn (Reviewer).

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

From lucy at openjdk.java.net  Wed Feb  2 14:46:23 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 2 Feb 2022 14:46:23 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
Message-ID: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>

May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.

SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 

As this is a s390x-only change, other platforms are not impacted.

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

Commit messages:
 - 8281079: [s390] Unify Address Operand Encoding in Instruction Emitters

Changes: https://git.openjdk.java.net/jdk/pull/7324/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7324&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281079
  Stats: 494 lines in 4 files changed: 138 ins; 70 del; 286 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7324/head:pull/7324

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

From thartmann at openjdk.java.net  Wed Feb  2 14:47:03 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Feb 2022 14:47:03 GMT
Subject: RFR: 8281117: Add regression test for JDK-8280587
In-Reply-To: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
References: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
Message-ID: <sCZ_uM11qtITIGzOgRlqiW_cP98jMq7r7YKG3PD8f-4=.38006391-a31f-4c89-b1c4-d1921ae96cf9@github.com>

On Wed, 2 Feb 2022 13:51:01 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Recently, bug [JDK-8280600](https://bugs.openjdk.java.net/browse/JDK-8280600) was fixed, see [PR](https://github.com/openjdk/jdk/pull/7307).
> [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) has been detected as a duplicate bug.
> However, [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) came with a differen reported test which failed with a different assert.
> Therefore, I added this additional test as a second regression test.
> 
> I ran this test to check that it passes successfully.

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From adinn at openjdk.java.net  Wed Feb  2 16:13:14 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Wed, 2 Feb 2022 16:13:14 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
Message-ID: <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>

On Tue, 1 Feb 2022 16:23:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett - Thanks for the review! Good catch! I believe you are correct,
>> but let's wait for @adinn to chime in here.
>
> Returning 0 if count == 0 and bits otherwise is consistent with the old code,
> assuming the problematic shift doesn't cause UB data corruption or something
> otherwise strange.  It might do the "mathematically correct" thing of shifting
> out all the bits (so zeroing the value).  Another possibility is that the
> implemented shift amount for N is N mod word-size (some platforms do that, but
> I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
> think there are any other non-strange non-UB-data-corruption possibilities.
> 
> 
> result is initially 0.
> with the old code:
> - if count == 0, there are no iterations, and final result is still 0.
> - if count == 1, there is one iteration.
>   result <<= nbits
>     -- if UB corruption, all bets are off
>     -- if shifts by 64, result is unchanged (== 0)
>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
>   result |= (bits & mask)
>     -- result == bits
> - if count > 1, for additional iterations
>   result <<= nbits
>     -- if UB corruption, all bets are off
>     -- if shifts by 64, result == 0
>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
>   result |= (bits & mask)
>     -- result == bits
> 
> So with old code, for count > 0, result == bits (or UB corrupted data).

First thing to note is that `replicate` is never actually called with `count == 0`. It's questionable whether it ever should be (especially as this function is really only meant to be used locally to this code) but logically I think the result ought to be 0 if it ever does get called that way.

What `replicate` is meant to do is replicate the bottom `nbits` bits of the `uint64_t` passed via argument `bits` across successive subfields of `result` up to `(count * bits)` worth of bits (sorry ... the names are somewhat inconveniently chosen as far as this discussion is concerned). So, anyway, a count of zero ought to insert 0 bits giving a zero result.

As to how it is used, `replicate` is only called from method `expandLogicalImmediate` with two alternative calling patterns. It is sometimes called like this

    for (int i = 0; i < 6; i++) {
      int nbits = 1 << i;
      . . .
        replicate(and_bit, 1, nbits)

n.b. argument `count` is being supplied as `nbits` and argument `nbits` is supplied as 1 (yeah, naming is hard). These calls serve to insert anywhere between 1 and 32 copies of a single bit into the rightmost portion of the result.

It is also called like this:

    for (int i = 0; i < 6; i++) {
      int nbits = 1 << i;
      . . .
          replicate(and_bits_top, 2 * nbits, 32 / nbits)

This is used to replicate a bit pattern taken from the lower end of the first input across the whole of a uint64_t result. For these calls the input arguments `count` and `nbits` satisfy the following invariants:

    nbits | 64
    count | 64
    nbits * count == 64
    2 <= nbits <= 32
    32 >= count >= 2

I am not actually clear why the caller is calling `replicate` in the way it does. The algorithm is way more complicated than it actually needs to be. The basic idea is to insert imms 1s into a 2^k bit field, right rotate them by immr and then replicate the result across the full 64 bits. There's a few wrinkles which are explained here for those who are interested:

expandLogicalImmediate(uint32_t immN, uint32_t immr, uint32_t imms, uint64_t& bimm)

-  outputs a bit pattern of width 64 by replicating a bit field of width 2^k and returns 1 or fails and returns 0

- when immN is 1 then k is 6 and immr/imms are masked to 6 bit integers.
- when immN is 0 then k is the count of the first 0 bit in imms and immr/imms are masked to k-bit integers (i.e. leading 1s in imms determine dead bits of imms and immr)

A k value of 0 (i.e. immN == 0 and imms = all 1s) fails and returns 0

After masking

An imms value of all 1s (i.e. 2^k - 1) fails and returns 0 (note given the previous check we only get here when  immN == 1)

The bit field can now be constructed as follows:

 - imms + 1 specifies the number of 1s to insert into the 2^k-field (note that imms + 1 < 2^k)
 - immr counts how far to right rotate the 2^k-field

The resulting 2^k-field is then replicated across the full 64-bit result.

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

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

From xliu at openjdk.java.net  Wed Feb  2 18:12:12 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 2 Feb 2022 18:12:12 GMT
Subject: RFR: 8280541: remove self-recursion of
 ConnectionGraph::find_inst_mem() [v2]
In-Reply-To: <Wxn3kMPuVHAWRF2syYJL1yUgtzYQAjtNuuTJ8hmshqM=.70bb239e-c711-48b0-89ae-9c11a3a03530@github.com>
References: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
 <Wxn3kMPuVHAWRF2syYJL1yUgtzYQAjtNuuTJ8hmshqM=.70bb239e-c711-48b0-89ae-9c11a3a03530@github.com>
Message-ID: <sBKmt0hFOkoG53Lg8RjwjB87PcLG6-0_Id0HvbK88OA=.327bdb21-6456-4976-a9ac-3a602bb5977a@github.com>

On Mon, 31 Jan 2022 23:52:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>  Normally when converting recursive to iterative, I would expect to see both push and pop operations, but I only see push operations here.

For the self-recursion case, the invariant of find_inst_mem is "the the result is either MemNode, PhiNode, InitializeNode" and "the memslice of result is alias_idx ".  As a result, the result won't change.  We can leverage this property to backpatch all MergeMem nodes.  It's similar to tail recursion optimization. we reset the stackframe and arguments to avoid recursion.
 
> I don't think it makes sense to remove only self-recursion here.I think it makes the code less readable (see JDK-8276219). 

I agree.  I just feel this code change is easy. Please check the 2nd revision that I bring back the assertion code.  now we have iterative EA. It may give us more compilation-time pressure than before.

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

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

From dcubed at openjdk.java.net  Wed Feb  2 20:14:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 2 Feb 2022 20:14:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
Message-ID: <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>

On Wed, 2 Feb 2022 16:09:50 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Returning 0 if count == 0 and bits otherwise is consistent with the old code,
>> assuming the problematic shift doesn't cause UB data corruption or something
>> otherwise strange.  It might do the "mathematically correct" thing of shifting
>> out all the bits (so zeroing the value).  Another possibility is that the
>> implemented shift amount for N is N mod word-size (some platforms do that, but
>> I haven't looked up aarch64), which in this case is 64 mod 64, or 0.  I don't
>> think there are any other non-strange non-UB-data-corruption possibilities.
>> 
>> 
>> result is initially 0.
>> with the old code:
>> - if count == 0, there are no iterations, and final result is still 0.
>> - if count == 1, there is one iteration.
>>   result <<= nbits
>>     -- if UB corruption, all bets are off
>>     -- if shifts by 64, result is unchanged (== 0)
>>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== 0)
>>   result |= (bits & mask)
>>     -- result == bits
>> - if count > 1, for additional iterations
>>   result <<= nbits
>>     -- if UB corruption, all bets are off
>>     -- if shifts by 64, result == 0
>>     -- if shifts by 64 mod 64 (== 0), result is unchanged (== bits)
>>   result |= (bits & mask)
>>     -- result == bits
>> 
>> So with old code, for count > 0, result == bits (or UB corrupted data).
>
> First thing to note is that `replicate` is never actually called with `count == 0`. It's questionable whether it ever should be (especially as this function is really only meant to be used locally to this code) but logically I think the result ought to be 0 if it ever does get called that way.
> 
> What `replicate` is meant to do is replicate the bottom `nbits` bits of the `uint64_t` passed via argument `bits` across successive subfields of `result` up to `(count * bits)` worth of bits (sorry ... the names are somewhat inconveniently chosen as far as this discussion is concerned). So, anyway, a count of zero ought to insert 0 bits giving a zero result.
> 
> As to how it is used, `replicate` is only called from method `expandLogicalImmediate` with two alternative calling patterns. It is sometimes called like this
> 
>     for (int i = 0; i < 6; i++) {
>       int nbits = 1 << i;
>       . . .
>         replicate(and_bit, 1, nbits)
> 
> n.b. argument `count` is being supplied as `nbits` and argument `nbits` is supplied as 1 (yeah, naming is hard). These calls serve to insert anywhere between 1 and 32 copies of a single bit into the rightmost portion of the result.
> 
> It is also called like this:
> 
>     for (int i = 0; i < 6; i++) {
>       int nbits = 1 << i;
>       . . .
>           replicate(and_bits_top, 2 * nbits, 32 / nbits)
> 
> This is used to replicate a bit pattern taken from the lower end of the first input across the whole of a uint64_t result. For these calls the input arguments `count` and `nbits` satisfy the following invariants:
> 
>     nbits | 64
>     count | 64
>     nbits * count == 64
>     2 <= nbits <= 32
>     32 >= count >= 2
> 
> I am not actually clear why the caller is calling `replicate` in the way it does. The algorithm is way more complicated than it actually needs to be. The basic idea is to insert imms 1s into a 2^k bit field, right rotate them by immr and then replicate the result across the full 64 bits. There's a few wrinkles which are explained here for those who are interested:
> 
> expandLogicalImmediate(uint32_t immN, uint32_t immr, uint32_t imms, uint64_t& bimm)
> 
> -  outputs a bit pattern of width 64 by replicating a bit field of width 2^k and returns 1 or fails and returns 0
> 
> - when immN is 1 then k is 6 and immr/imms are masked to 6 bit integers.
> - when immN is 0 then k is the count of the first 0 bit in imms and immr/imms are masked to k-bit integers (i.e. leading 1s in imms determine dead bits of imms and immr)
> 
> A k value of 0 (i.e. immN == 0 and imms = all 1s) fails and returns 0
> 
> After masking
> 
> An imms value of all 1s (i.e. 2^k - 1) fails and returns 0 (note given the previous check we only get here when  immN == 1)
> 
> The bit field can now be constructed as follows:
> 
>  - imms + 1 specifies the number of 1s to insert into the 2^k-field (note that imms + 1 < 2^k)
>  - immr counts how far to right rotate the 2^k-field
> 
> The resulting 2^k-field is then replicated across the full 64-bit result.

@adinn - Thanks for chiming in on this review thread.

I'm reading and re-reading your comments and it will take me a while
to put it all in proper context.

I do agree with one of your points:

> `replicate` is never actually called with `count == 0`

so that means that this:

    `assert(count <= 1, "must be");`

is a little too loose and should change to:

    `assert(count == 1, "must be");`

if we're going to keep it at all. I think we should keep it, but
I can be convinced otherwise since the original code had no
similar `assert()`.

@kimbarrett - I've re-read your comments and I'm not clear
on whether you think that `result <<= nbits` is UB when
`nbits == 64`. Can you please clarify?

Of course, it's not helping matters that I can't reproduce the
failure mode reported by Apple and we're getting no response
about our request for version info.

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

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

From phh at openjdk.java.net  Wed Feb  2 20:58:02 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 2 Feb 2022 20:58:02 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v7]
In-Reply-To: <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
Message-ID: <rJI4EXWBsl_njvhrUXhTSUKKS0by-eYv0qmiJL4THy8=.010047db-b9b8-49ea-a4ad-85067c109884@github.com>

On Wed, 2 Feb 2022 01:52:46 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use jlong instead of int64_t"

Hi, David, I stand corrected. Is there a document somewhere about the policy, and has anyone gone through Hotspot to remove improper use of jlong?

So, belay my jlong suggestion, but now compileBroker.* should use int64_t. I think my gc_globals.hpp comment still stands.

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

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

From phh at openjdk.java.net  Wed Feb  2 21:20:10 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 2 Feb 2022 21:20:10 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v7]
In-Reply-To: <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
Message-ID: <J_qbkgDJcq7HuNTjiQFrsWeq8LRmOgIilsk_iKMatQ8=.4b0103a1-c5cb-486e-a3bd-76d1cb5983a6@github.com>

On Wed, 2 Feb 2022 01:52:46 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use jlong instead of int64_t"

Marked as reviewed by phh (Reviewer).

The traversal mark type is signed right now, so I'd leave it signed for this PR and file another one if we want to change it to unsigned. There are quite a few places where signed types are used for values that are intuitively unsigned. One reason I can think of to keep using signed types is that it's easy to detect overflow/wrap-around: just check the sign bit. Allows a bit of time to check for overflow/wrap-around without keeping an old value around.

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

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

From duke at openjdk.java.net  Wed Feb  2 21:49:15 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 2 Feb 2022 21:49:15 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v7]
In-Reply-To: <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
Message-ID: <MucgZQWNcWfdbfYng1XzM_VH9ZJ5UBqNaa-tKzeyXUc=.527b7152-27e4-424b-b425-cddaf64723a8@github.com>

On Wed, 2 Feb 2022 01:52:46 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Use jlong instead of int64_t"

Other missed places to change:

jvmci/jvmciEnv.hpp:  long get_long_at(JVMCIPrimitiveArray array, int index);
services/memReporter.hpp:  inline long diff_in_current_scale(size_t s1, size_t s2) const {
services/memReporter.hpp:    long amount = (long)(s1 - s2);
services/memReporter.hpp:    long scale = (long)_scale;
services/memReporter.cpp:  long amount_diff = diff_in_current_scale(current_amount, early_amount);
services/memReporter.cpp:  long reserved_diff = diff_in_current_scale(current_reserved, early_reserved);
services/memReporter.cpp:  long committed_diff = diff_in_current_scale(current_committed, early_committed);
services/memReporter.cpp:      long overhead_diff = diff_in_current_scale(_current_baseline.malloc_tracking_overhead(),
services/memReporter.cpp:  long diff_used = diff_in_current_scale(current_stats.used(),
services/memReporter.cpp:  long diff_waste = diff_in_current_scale(current_waste, early_waste);
runtime/vmThread.cpp:  long interval_ms = SafepointTracing::time_since_last_safepoint_ms();

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

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

From david.holmes at oracle.com  Wed Feb  2 22:13:34 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Feb 2022 08:13:34 +1000
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v7]
In-Reply-To: <rJI4EXWBsl_njvhrUXhTSUKKS0by-eYv0qmiJL4THy8=.010047db-b9b8-49ea-a4ad-85067c109884@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
 <rJI4EXWBsl_njvhrUXhTSUKKS0by-eYv0qmiJL4THy8=.010047db-b9b8-49ea-a4ad-85067c109884@github.com>
Message-ID: <e1c5a6bf-f967-747c-c0a4-f930c5cc525c@oracle.com>

On 3/02/2022 6:58 am, Paul Hohensee wrote:
> On Wed, 2 Feb 2022 01:52:46 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:
> 
>>> 8251505: Use of types in compiler shared code should be consistent.
>>
>> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Revert "Use jlong instead of int64_t"
> 
> Hi, David, I stand corrected. Is there a document somewhere about the policy, and has anyone gone through Hotspot to remove improper use of jlong?

Hi Paul,

Sorry no documented policy, it is just something that a number of folk 
have raised in "recent" years about Java type pollution (mainly jlong) 
in various places in the VM. People have been making the switch 
piecemeal as different areas get worked on.

Cheers,
David

> So, belay my jlong suggestion, but now compileBroker.* should use int64_t. I think my gc_globals.hpp comment still stands.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7294

From david.holmes at oracle.com  Wed Feb  2 22:14:57 2022
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 3 Feb 2022 08:14:57 +1000
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v7]
In-Reply-To: <MucgZQWNcWfdbfYng1XzM_VH9ZJ5UBqNaa-tKzeyXUc=.527b7152-27e4-424b-b425-cddaf64723a8@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <ELqPJgm9ZkmKqxPE60lkrkivbplyZpCzB_NnyEL8zpE=.33725cd0-6679-4fd6-8acd-28a1f77dab35@github.com>
 <MucgZQWNcWfdbfYng1XzM_VH9ZJ5UBqNaa-tKzeyXUc=.527b7152-27e4-424b-b425-cddaf64723a8@github.com>
Message-ID: <2c0f5a4e-6c60-100b-f0d3-a0a047926aef@oracle.com>

On 3/02/2022 7:49 am, Evgeny Astigeevich wrote:
> On Wed, 2 Feb 2022 01:52:46 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:
> 
>>> 8251505: Use of types in compiler shared code should be consistent.
>>
>> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Revert "Use jlong instead of int64_t"
> 
> Other missed places to change:
> 
> jvmci/jvmciEnv.hpp:  long get_long_at(JVMCIPrimitiveArray array, int index);
> services/memReporter.hpp:  inline long diff_in_current_scale(size_t s1, size_t s2) const {
> services/memReporter.hpp:    long amount = (long)(s1 - s2);
> services/memReporter.hpp:    long scale = (long)_scale;
> services/memReporter.cpp:  long amount_diff = diff_in_current_scale(current_amount, early_amount);
> services/memReporter.cpp:  long reserved_diff = diff_in_current_scale(current_reserved, early_reserved);
> services/memReporter.cpp:  long committed_diff = diff_in_current_scale(current_committed, early_committed);
> services/memReporter.cpp:      long overhead_diff = diff_in_current_scale(_current_baseline.malloc_tracking_overhead(),
> services/memReporter.cpp:  long diff_used = diff_in_current_scale(current_stats.used(),
> services/memReporter.cpp:  long diff_waste = diff_in_current_scale(current_waste, early_waste);
> runtime/vmThread.cpp:  long interval_ms = SafepointTracing::time_since_last_safepoint_ms();

Other than jvmci these are not "compiler shared code" - other cleanups 
in other areas will need their own RFE.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7294

From duke at openjdk.java.net  Thu Feb  3 00:03:53 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Thu, 3 Feb 2022 00:03:53 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v8]
In-Reply-To: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
Message-ID: <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>

> 8251505: Use of types in compiler shared code should be consistent.

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Fix JVMCIEnv::get_long_at

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7294/files
  - new: https://git.openjdk.java.net/jdk/pull/7294/files/01f3b1f2..2c0eb15f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7294&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7294&range=06-07

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

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

From phh at openjdk.java.net  Thu Feb  3 00:08:09 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 3 Feb 2022 00:08:09 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v8]
In-Reply-To: <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>
Message-ID: <z3hcLkwSu-nLabBB6ftX2msyWxzfN55oLEI674qZYXQ=.159ac6fd-2150-459e-b200-64ca82cf12b6@github.com>

On Thu, 3 Feb 2022 00:03:53 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JVMCIEnv::get_long_at

Lgtm.

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

Marked as reviewed by phh (Reviewer).

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

From dlong at openjdk.java.net  Thu Feb  3 04:20:41 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 3 Feb 2022 04:20:41 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
Message-ID: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>

Reproduced the problem with a new JASM test rather than relying on idiosyncrasies of javac.
The fix is to not look at the next instruction (which might be the beginning of an unreachable block) if the current instruction doesn't fall through (like "goto"!).

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

Commit messages:
 - Don't look at next bytecode if the current bytecode doesn't fall through

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

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

From kbarrett at openjdk.java.net  Thu Feb  3 04:37:05 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 3 Feb 2022 04:37:05 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
Message-ID: <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>

On Wed, 2 Feb 2022 20:11:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> First thing to note is that `replicate` is never actually called with `count == 0`. It's questionable whether it ever should be (especially as this function is really only meant to be used locally to this code) but logically I think the result ought to be 0 if it ever does get called that way.
>> 
>> What `replicate` is meant to do is replicate the bottom `nbits` bits of the `uint64_t` passed via argument `bits` across successive subfields of `result` up to `(count * bits)` worth of bits (sorry ... the names are somewhat inconveniently chosen as far as this discussion is concerned). So, anyway, a count of zero ought to insert 0 bits giving a zero result.
>> 
>> As to how it is used, `replicate` is only called from method `expandLogicalImmediate` with two alternative calling patterns. It is sometimes called like this
>> 
>>     for (int i = 0; i < 6; i++) {
>>       int nbits = 1 << i;
>>       . . .
>>         replicate(and_bit, 1, nbits)
>> 
>> n.b. argument `count` is being supplied as `nbits` and argument `nbits` is supplied as 1 (yeah, naming is hard). These calls serve to insert anywhere between 1 and 32 copies of a single bit into the rightmost portion of the result.
>> 
>> It is also called like this:
>> 
>>     for (int i = 0; i < 6; i++) {
>>       int nbits = 1 << i;
>>       . . .
>>           replicate(and_bits_top, 2 * nbits, 32 / nbits)
>> 
>> This is used to replicate a bit pattern taken from the lower end of the first input across the whole of a uint64_t result. For these calls the input arguments `count` and `nbits` satisfy the following invariants:
>> 
>>     nbits | 64
>>     count | 64
>>     nbits * count == 64
>>     2 <= nbits <= 32
>>     32 >= count >= 2
>> 
>> I am not actually clear why the caller is calling `replicate` in the way it does. The algorithm is way more complicated than it actually needs to be. The basic idea is to insert imms 1s into a 2^k bit field, right rotate them by immr and then replicate the result across the full 64 bits. There's a few wrinkles which are explained here for those who are interested:
>> 
>> expandLogicalImmediate(uint32_t immN, uint32_t immr, uint32_t imms, uint64_t& bimm)
>> 
>> -  outputs a bit pattern of width 64 by replicating a bit field of width 2^k and returns 1 or fails and returns 0
>> 
>> - when immN is 1 then k is 6 and immr/imms are masked to 6 bit integers.
>> - when immN is 0 then k is the count of the first 0 bit in imms and immr/imms are masked to k-bit integers (i.e. leading 1s in imms determine dead bits of imms and immr)
>> 
>> A k value of 0 (i.e. immN == 0 and imms = all 1s) fails and returns 0
>> 
>> After masking
>> 
>> An imms value of all 1s (i.e. 2^k - 1) fails and returns 0 (note given the previous check we only get here when  immN == 1)
>> 
>> The bit field can now be constructed as follows:
>> 
>>  - imms + 1 specifies the number of 1s to insert into the 2^k-field (note that imms + 1 < 2^k)
>>  - immr counts how far to right rotate the 2^k-field
>> 
>> The resulting 2^k-field is then replicated across the full 64-bit result.
>
> @adinn - Thanks for chiming in on this review thread.
> 
> I'm reading and re-reading your comments and it will take me a while
> to put it all in proper context.
> 
> I do agree with one of your points:
> 
>> `replicate` is never actually called with `count == 0`
> 
> so that means that this:
> 
>     `assert(count <= 1, "must be");`
> 
> is a little too loose and should change to:
> 
>     `assert(count == 1, "must be");`
> 
> if we're going to keep it at all. I think we should keep it, but
> I can be convinced otherwise since the original code had no
> similar `assert()`.
> 
> @kimbarrett - I've re-read your comments and I'm not clear
> on whether you think that `result <<= nbits` is UB when
> `nbits == 64`. Can you please clarify?
> 
> Of course, it's not helping matters that I can't reproduce the
> failure mode reported by Apple and we're getting no response
> about our request for version info.

It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.

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

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

From vlivanov at openjdk.java.net  Thu Feb  3 06:52:11 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 3 Feb 2022 06:52:11 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
In-Reply-To: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
References: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
Message-ID: <-o_Q8_R9Mz3I70DbL_STe7RQfq-59Tca_Ke87HxgE8I=.e479c4bc-3166-4faf-969c-e03490479cae@github.com>

On Thu, 3 Feb 2022 04:11:38 GMT, Dean Long <dlong at openjdk.org> wrote:

> Reproduced the problem with a new JASM test rather than relying on idiosyncrasies of javac.
> The fix is to not look at the next instruction (which might be the beginning of an unreachable block) if the current instruction doesn't fall through (like "goto"!).

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From thartmann at openjdk.java.net  Thu Feb  3 07:02:12 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Feb 2022 07:02:12 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
In-Reply-To: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
References: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
Message-ID: <ckbmN7iQKBWrg4CnYfX-0xzkxTX_wn1UsCsPoiGD4oQ=.34f6c76f-1906-4fd2-9e63-5d511d7b26ff@github.com>

On Thu, 3 Feb 2022 04:11:38 GMT, Dean Long <dlong at openjdk.org> wrote:

> Reproduced the problem with a new JASM test rather than relying on idiosyncrasies of javac.
> The fix is to not look at the next instruction (which might be the beginning of an unreachable block) if the current instruction doesn't fall through (like "goto"!).

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From lucy at openjdk.java.net  Thu Feb  3 07:41:09 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 3 Feb 2022 07:41:09 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
Message-ID: <dWQaQt-wVkjl0HVf2QjCFuTk3KGQs6jhV317p5r_zcs=.fae649a9-4b84-4d22-ad73-a04dbee4092c@github.com>

On Wed, 2 Feb 2022 14:40:58 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
> 
> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
> 
> As this is a s390x-only change, other platforms are not impacted.

Would not know how s390-only changes could make linux x86 tests fail. I assume it's unrelated.

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

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

From adinn at openjdk.java.net  Thu Feb  3 10:26:16 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 3 Feb 2022 10:26:16 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
Message-ID: <iN51kmLhkEiLGLZL6VRYYJRe_-EpT2j-Ew2itxDj95w=.cd02560a-bbe1-4ddd-a4ee-f49ebeb49fbb@github.com>

On Thu, 3 Feb 2022 04:32:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @adinn - Thanks for chiming in on this review thread.
>> 
>> I'm reading and re-reading your comments and it will take me a while
>> to put it all in proper context.
>> 
>> I do agree with one of your points:
>> 
>>> `replicate` is never actually called with `count == 0`
>> 
>> so that means that this:
>> 
>>     `assert(count <= 1, "must be");`
>> 
>> is a little too loose and should change to:
>> 
>>     `assert(count == 1, "must be");`
>> 
>> if we're going to keep it at all. I think we should keep it, but
>> I can be convinced otherwise since the original code had no
>> similar `assert()`.
>> 
>> @kimbarrett - I've re-read your comments and I'm not clear
>> on whether you think that `result <<= nbits` is UB when
>> `nbits == 64`. Can you please clarify?
>> 
>> Of course, it's not helping matters that I can't reproduce the
>> failure mode reported by Apple and we're getting no response
>> about our request for version info.
>
> It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.

> I do agree with one of your points:
>
> > replicate is never actually called with count == 0
>
> so that means that this:
>
> >     assert(count <= 1, "must be");
>
> is a little too loose and should change to:
>
> >     assert(count == 1, "must be");
>
> if we're going to keep it at all. I think we should keep it, but
> I can be convinced otherwise since the original code had no similar assert().

That is entirely reasonable given that replicate is only meant to be used locally and none of these local use cases will ever try to replicate 0 copies of a bit field.

We could actually add one or both of these more general asserts at entry to `replicate` since they apply to all cases, not just when `nbits == 64`:

    assert(count > 0, "must be")
    assert(count * nbits <= 64, "must be")

In other words it is an error to try to replicate zero copies of a bit field and it is an error to try to replicate more copies than can fit into 64 bits.

Note that the second assert removes the need for the current assert and combining it with the first assert also enforces your recommended alternative.

We could also add another general assert

    assert(nbits > 0, "must be")

i.e. it is an error to try to replicate an empty bit field.

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

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

From duke at openjdk.java.net  Thu Feb  3 10:35:11 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 3 Feb 2022 10:35:11 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v8]
In-Reply-To: <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>
Message-ID: <F3oj2EzJkIYMV0QWwwydcMHwkB5E4WJGsdjd9FDjYAQ=.4041a0bf-9ee7-4806-82eb-9d1c29bf9f4e@github.com>

On Thu, 3 Feb 2022 00:03:53 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JVMCIEnv::get_long_at

lgtm

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

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

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

From duke at openjdk.java.net  Thu Feb  3 11:34:11 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 3 Feb 2022 11:34:11 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent.
In-Reply-To: <2c0f5a4e-6c60-100b-f0d3-a0a047926aef@oracle.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <2c0f5a4e-6c60-100b-f0d3-a0a047926aef@oracle.com>
Message-ID: <4FQ-YEzWaDvXTIqe6IYjQUlJCSS7vaoywDQfu7DNX0Y=.3de04253-c875-4bb4-9238-07d48d713183@github.com>

On Wed, 2 Feb 2022 22:16:31 GMT, David Holmes <david.holmes at oracle.com> wrote:

> > Other missed places to change:
> > jvmci/jvmciEnv.hpp:  long get_long_at(JVMCIPrimitiveArray array, int index);
> > services/memReporter.hpp:  inline long diff_in_current_scale(size_t s1, size_t s2) const {
> > services/memReporter.hpp:    long amount = (long)(s1 - s2);
> > services/memReporter.hpp:    long scale = (long)_scale;
> > services/memReporter.cpp:  long amount_diff = diff_in_current_scale(current_amount, early_amount);
> > services/memReporter.cpp:  long reserved_diff = diff_in_current_scale(current_reserved, early_reserved);
> > services/memReporter.cpp:  long committed_diff = diff_in_current_scale(current_committed, early_committed);
> > services/memReporter.cpp:      long overhead_diff = diff_in_current_scale(_current_baseline.malloc_tracking_overhead(),
> > services/memReporter.cpp:  long diff_used = diff_in_current_scale(current_stats.used(),
> > services/memReporter.cpp:  long diff_waste = diff_in_current_scale(current_waste, early_waste);
> > runtime/vmThread.cpp:  long interval_ms = SafepointTracing::time_since_last_safepoint_ms();
> 
> Other than jvmci these are not "compiler shared code" - other cleanups in other areas will need their own RFE.
> 
> Cheers, David

Created:
https://bugs.openjdk.java.net/browse/JDK-8281213
https://bugs.openjdk.java.net/browse/JDK-8281214

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

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

From dcubed at openjdk.java.net  Thu Feb  3 17:25:05 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 17:25:05 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
Message-ID: <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>

On Thu, 3 Feb 2022 04:32:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @adinn - Thanks for chiming in on this review thread.
>> 
>> I'm reading and re-reading your comments and it will take me a while
>> to put it all in proper context.
>> 
>> I do agree with one of your points:
>> 
>>> `replicate` is never actually called with `count == 0`
>> 
>> so that means that this:
>> 
>>     `assert(count <= 1, "must be");`
>> 
>> is a little too loose and should change to:
>> 
>>     `assert(count == 1, "must be");`
>> 
>> if we're going to keep it at all. I think we should keep it, but
>> I can be convinced otherwise since the original code had no
>> similar `assert()`.
>> 
>> @kimbarrett - I've re-read your comments and I'm not clear
>> on whether you think that `result <<= nbits` is UB when
>> `nbits == 64`. Can you please clarify?
>> 
>> Of course, it's not helping matters that I can't reproduce the
>> failure mode reported by Apple and we're getting no response
>> about our request for version info.
>
> It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.

@kimbarrett - Thanks for confirming that we have UB here.

@adinn - I'll take a look and updating the `assert()` calls and retest.

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

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

From duke at openjdk.java.net  Thu Feb  3 19:38:18 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Thu, 3 Feb 2022 19:38:18 GMT
Subject: Integrated: 8251505: Use of types in compiler shared code should be
 consistent.
In-Reply-To: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
Message-ID: <fYpwXe2hq98P1F3joiZWcnzM7BFDm90qfVQcR4WFlGY=.96e6087c-3322-412e-89b5-f6fa50859650@github.com>

On Tue, 1 Feb 2022 03:35:13 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8251505: Use of types in compiler shared code should be consistent.

This pull request has now been integrated.

Changeset: b6935dfb
Author:    Yi-Fan Tsai <yftsai at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6935dfb86a1c011355d2dfb2140be26ec536351
Stats:     33 lines in 10 files changed: 2 ins; 0 del; 31 mod

8251505: Use of types in compiler shared code should be consistent.

Reviewed-by: phh

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

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

From dcubed at openjdk.java.net  Thu Feb  3 21:05:37 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 21:05:37 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
Message-ID: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>

> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
> replicate().
> 
> I was not able to reproduce the reported failure using:
> 
>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
> 
> so I'm moving forward with the proposed fix from a code inspection
> point of view.
> 
> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
> no failures. Tier[3-6] are still running.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  kimbarrett and adinn CR changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7270/files
  - new: https://git.openjdk.java.net/jdk/pull/7270/files/562ceb51..e4afa9e6

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

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

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

From dcubed at openjdk.java.net  Thu Feb  3 21:08:09 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 3 Feb 2022 21:08:09 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
In-Reply-To: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
Message-ID: <imOW0nQqUWMXz3YBko0rX5Mp7ooBGgVtCbjdQA_fvGQ=.d15de1cd-8f3f-4612-8195-1abfa8654f37@github.com>

On Fri, 28 Jan 2022 16:49:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
> replicate().
> 
> I was not able to reproduce the reported failure using:
> 
>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
> 
> so I'm moving forward with the proposed fix from a code inspection
> point of view.
> 
> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
> no failures. Tier[3-6] are still running.

The v01 changes have passed Mach5 Tier1.
Mach5 Tier[23] are still running.

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

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

From dlong at openjdk.java.net  Thu Feb  3 22:01:10 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 3 Feb 2022 22:01:10 GMT
Subject: RFR: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
In-Reply-To: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
References: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
Message-ID: <Bd3HCCm5swVb85OU-l0PyEFJ-gceUmlYe06s78HVrDo=.0f5efb06-fc5d-4221-bd1d-952b0185082b@github.com>

On Thu, 3 Feb 2022 04:11:38 GMT, Dean Long <dlong at openjdk.org> wrote:

> Reproduced the problem with a new JASM test rather than relying on idiosyncrasies of javac.
> The fix is to not look at the next instruction (which might be the beginning of an unreachable block) if the current instruction doesn't fall through (like "goto"!).

Thanks Tobias and Vladimir!

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

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

From dlong at openjdk.java.net  Thu Feb  3 22:14:18 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 3 Feb 2022 22:14:18 GMT
Subject: Integrated: 8271055: Crash during deoptimization with
 "assert(bb->is_reachable()) failed: getting result from unreachable
 basicblock" with -XX:+VerifyStack
In-Reply-To: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
References: <VbH0r2-S-sOJIhbh5fejoiIEM3OGLTIoOzsJHgdOPqs=.800bd723-7054-4a14-9c50-646c3a238354@github.com>
Message-ID: <Vw4T047-tcFlEGHmjtyvGa1KBfOos4w29jj1i7ej-3I=.991bbe7e-244b-487d-8019-5139ee5ebc7b@github.com>

On Thu, 3 Feb 2022 04:11:38 GMT, Dean Long <dlong at openjdk.org> wrote:

> Reproduced the problem with a new JASM test rather than relying on idiosyncrasies of javac.
> The fix is to not look at the next instruction (which might be the beginning of an unreachable block) if the current instruction doesn't fall through (like "goto"!).

This pull request has now been integrated.

Changeset: e44dc638
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e44dc638b8936b1b76ca9ddf9ece0c5c4705a19c
Stats:     121 lines in 3 files changed: 120 ins; 0 del; 1 mod

8271055: Crash during deoptimization with "assert(bb->is_reachable()) failed: getting result from unreachable basicblock" with -XX:+VerifyStack

Co-authored-by: Yi Yang <yyang at openjdk.org>
Co-authored-by: Yi Yang <qingfeng.yy at alibaba-inc.com>
Reviewed-by: vlivanov, thartmann

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

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

From dholmes at openjdk.java.net  Thu Feb  3 22:19:10 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 3 Feb 2022 22:19:10 GMT
Subject: RFR: 8251505: Use of types in compiler shared code should be
 consistent. [v8]
In-Reply-To: <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>
References: <oUUE69vJX22HOlvWAoNrNQuAPRan5XFmorCc-nG9B8Y=.726d5c9f-da84-4a17-8c50-aee35de6dca5@github.com>
 <jdfdBN0PQqNis6ODxAg-6d1P5Gbdtc_lkGLzc8jN0D8=.c75ad7e2-e751-4ed6-b492-8fe9d0be3117@github.com>
Message-ID: <FVRPQ60lItiz6QVvivS2HWdRl0Fp27HBJZdykSoenpM=.432772ec-3a4e-4b62-a353-9a4c08742f6b@github.com>

On Thu, 3 Feb 2022 00:03:53 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8251505: Use of types in compiler shared code should be consistent.
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix JVMCIEnv::get_long_at

These changes also appear okay to me. Where we have changed from 32-bit to 64-bit types we will need to watch for issues with the 32-bit builds.

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

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

From kbarrett at openjdk.java.net  Fri Feb  4 00:41:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Feb 2022 00:41:10 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
Message-ID: <6QFfnnjE6YXTPDRdl0S0pDos0getybxhb-NjEqs-y8A=.6eba0758-8ab3-43dd-9f0c-8db5dcaa1657@github.com>

On Thu, 3 Feb 2022 21:05:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
>> replicate().
>> 
>> I was not able to reproduce the reported failure using:
>> 
>>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
>> 
>> so I'm moving forward with the proposed fix from a code inspection
>> point of view.
>> 
>> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
>> no failures. Tier[3-6] are still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett and adinn CR changes

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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

From rrich at openjdk.java.net  Fri Feb  4 08:01:10 2022
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 4 Feb 2022 08:01:10 GMT
Subject: Integrated: 8280593: [PPC64,
 S390] redundant allocation of MacroAssembler in StubGenerator ctor
In-Reply-To: <F0CxlKwsztJ_H-1XPQpFd8ekFsijTRhgeaI2l-oHh7M=.2eca2c4c-5ab3-4433-9d04-58bbc8fbd857@github.com>
References: <F0CxlKwsztJ_H-1XPQpFd8ekFsijTRhgeaI2l-oHh7M=.2eca2c4c-5ab3-4433-9d04-58bbc8fbd857@github.com>
Message-ID: <5VHSqvT8KM6sHrGGbnCPueuPrY716rLEWBuETlgr7ao=.f551772c-2a3e-4881-8ba4-4306beb1bfbd@github.com>

On Tue, 25 Jan 2022 16:41:33 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This cleanup removes a redundant allocation from the StubGenerator constructor. The base class' constructor does the very same.
> 
> The fix passed our CI testing.

This pull request has now been integrated.

Changeset: c936e705
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c936e7059b848d0e0be5f3234c4367657f2af2a7
Stats:     10 lines in 3 files changed: 0 ins; 5 del; 5 mod

8280593: [PPC64, S390] redundant allocation of MacroAssembler in StubGenerator ctor

Reviewed-by: mdoerr, lucy

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

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

From aph at openjdk.java.net  Fri Feb  4 10:05:07 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 4 Feb 2022 10:05:07 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
 <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
Message-ID: <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>

On Thu, 3 Feb 2022 17:21:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> It's definitely UB according to the language.  Then there's the question of what the hardware might actually implement in the cases where the compiler doesn't recognize it and the relevant instruction(s) are executed with that value.  I know I've seen hardware that used the shift quantity mod word-size.  I think I've seen hardware that would just shift out all the bits, leaving a value of 0.  One reason for the language to make this UB is because of hardware variance.  Oh, and I *think* I've seen hardware where it was UB and would produce "strange" results.
>
> @kimbarrett - Thanks for confirming that we have UB here.
> 
> @adinn - I'll take a look and updating the `assert()` calls and retest.

> First thing to note is that `replicate` is never actually called with `count == 0`.

This is crucial: it means we have no UB.

Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)

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

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

From adinn at openjdk.java.net  Fri Feb  4 10:49:12 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Fri, 4 Feb 2022 10:49:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
 <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
 <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>
Message-ID: <wl6KF6Ij9he0EH0CjeO3vloYEeEmrI-VRI4FgC4ahpI=.6b8c955d-8f04-44e2-9bb1-436856b1cf48@github.com>

On Fri, 4 Feb 2022 10:01:53 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)

Sure,this stuff really needs to be better documented in the code itself. I'll do that as a follow-up to this PR.

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

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

From jaroslav.bachorik at datadoghq.com  Fri Feb  4 11:59:44 2022
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Fri, 4 Feb 2022 12:59:44 +0100
Subject: A noob question about weird sequence of `*synchronization entry` in a
 C2 compiled code
Message-ID: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>

Hello,

First I want to apologize if I am asking in the wrong mailing list or
the situation is stupidly obvious - feel free to just direct me to any
FAQs in such case.

Now, to the problem - we at Datadog profiling team noticed a
significant number of CPU samples with stacktraces ending in frames
with BCI == -1. Just for reference - we might see up to 60% of samples
ending in frames of a particular method to have BCI set to -1.

While we were using JFR to collect those stacktraces the problem went
largely unnoticed because what JFR (or any other stacktrace generating
code in JDK) does is to attribute all such frames to the first
bytecode instruction of that method. This becomes very confusing when
the first instruction is something like `ICONST_0` which is a part of
the corresponding Java source like `int x = 0`.

When using AGCT via async-profiler directly we see the problem
manifested as missing source line and as such it becomes more visible.

>From what I read it is obvious that having BCI set to -1 is a normal
situation for eg. method prologue. However, spending several tens of
percent on a method prologue feels somehow wrong.

Further experiments confirmed that this is only happening after C2
compilation - all profiles collected during the time the method is
only C1 compiled look correct.

We managed to get the full compilation log of the service which is
exhibiting this behaviour and when looking at the C2 assembly code the
amount and the distribution of the `*synchronization entry` points
seems rather confusing.

For the sake of brevity I am going to post here only one small part of
the assembly which is demonstrating the problem. The full compilation
log is pretty large but I could share it if someone would be willing
to take a look at it.

So, here we go
====
Verified Entry Point]
  # {method} {0x00007f2ce3495e18} &apos;parseJfr&apos;
&apos;(Lorg/openjdk/jmc/common/item/IItemCollection;Ljava/time/Duration;ZZZLorg/openjdk/jmc/common/item/IItemFilter;Ljava/util/function/Predicate;[Ljava/lang/String;)Lcom/datadog/profiling/aggregation/ParsedProfile;&apos;
in &apos;com/datadog/profiling/aggregation/parser/jfr/JfrParser&apos;
  0x00007f2dc98db580:   call   0x00007f2ddef241c0           ;   {no_reloc}
  0x00007f2dc98db585:   data16 data16 nop WORD PTR [rax+rax*1+0x0]
  0x00007f2dc98db590:   mov    DWORD PTR [rsp-0x14000],eax
  0x00007f2dc98db597:   push   rbp
  0x00007f2dc98db598:   sub    rsp,0x390                    ;*iload
{reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 995
(line 331)
  0x00007f2dc98db59f:   mov    r13,QWORD PTR [rsi+0x1d0]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db5a6:   mov    r14,QWORD PTR [rsi+0x1c8]
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db5ad:   mov    r11d,DWORD PTR [rsi+0x40]
;*invokeinterface next {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 484
(line 227)
  0x00007f2dc98db5b1:   mov    DWORD PTR [rsp+0x198],r11d
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db5b9:   mov    r10,QWORD PTR [rsi+0x1c0]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db5c0:   mov    QWORD PTR [rsp+0x50],r10
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db5c5:   mov    r10,QWORD PTR [rsi+0x1a0]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db5cc:   mov    QWORD PTR [rsp+0x58],r10
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db5d1:   mov    r10,QWORD PTR [rsi+0x198]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db5d8:   mov    QWORD PTR [rsp+0x60],r10
  0x00007f2dc98db5dd:   mov    r10,QWORD PTR [rsi+0x190]
  0x00007f2dc98db5e4:   mov    QWORD PTR [rsp+0x68],r10
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db5e9:   mov    r10,QWORD PTR [rsi+0x188]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db5f0:   mov    QWORD PTR [rsp+0x70],r10
  0x00007f2dc98db5f5:   mov    r10,QWORD PTR [rsi+0x180]
  0x00007f2dc98db5fc:   mov    QWORD PTR [rsp+0x78],r10
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db601:   mov    r10,QWORD PTR [rsi+0x178]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db608:   mov    QWORD PTR [rsp+0x80],r10
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db610:   mov    r10,QWORD PTR [rsi+0x170]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db617:   mov    QWORD PTR [rsp+0x88],r10
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db61f:   mov    rbx,QWORD PTR [rsi+0x168]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db626:   mov    QWORD PTR [rsp+0x90],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db62e:   mov    rbx,QWORD PTR [rsi+0x160]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db635:   mov    QWORD PTR [rsp+0x98],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db63d:   mov    rbx,QWORD PTR [rsi+0x158]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db644:   mov    QWORD PTR [rsp+0xa0],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db64c:   mov    rbx,QWORD PTR [rsi+0x148]
;*synchronization entry
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at -1 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db653:   mov    QWORD PTR [rsp+0xa8],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db65b:   mov    rbx,QWORD PTR [rsi+0x140]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db662:   mov    QWORD PTR [rsp+0xb0],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db66a:   mov    rbx,QWORD PTR [rsi+0x138]    ;*getfield
next {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 1 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db671:   mov    QWORD PTR [rsp+0xb8],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db679:   mov    rbx,QWORD PTR [rsi+0x130]    ;*getfield
next {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 1 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db680:   mov    QWORD PTR [rsp+0xc0],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db688:   mov    rbx,QWORD PTR [rsi+0x128]    ;*getfield
next {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 1 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db68f:   mov    QWORD PTR [rsp+0xc8],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db697:   mov    rbx,QWORD PTR [rsi+0x120]    ;*getfield
NO_MORE_ELEMENTS {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 5 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db69e:   mov    QWORD PTR [rsp+0xd0],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db6a6:   mov    rbx,QWORD PTR [rsi+0x118]    ;*getfield
NO_MORE_ELEMENTS {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 5 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db6ad:   mov    QWORD PTR [rsp+0xd8],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db6b5:   mov    rbx,QWORD PTR [rsi+0x110]    ;*getfield
NO_MORE_ELEMENTS {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 5 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db6bc:   mov    QWORD PTR [rsp+0xe0],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db6c4:   mov    rbx,QWORD PTR [rsi+0x108]
;*if_acmpeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 8 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db6cb:   mov    QWORD PTR [rsp+0xe8],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db6d3:   mov    rbx,QWORD PTR [rsi+0xf0]
;*if_acmpeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 8 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db6da:   mov    QWORD PTR [rsp+0xf0],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db6e2:   mov    rbx,QWORD PTR [rsi+0xe8]
;*if_acmpeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 8 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db6e9:   mov    QWORD PTR [rsp+0xf8],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db6f1:   mov    rbx,QWORD PTR [rsi+0xe0]
;*if_acmpeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 8 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db6f8:   mov    QWORD PTR [rsp+0x100],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db700:   mov    rbx,QWORD PTR [rsi+0xd8]
;*if_acmpeq {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 8 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db707:   mov    QWORD PTR [rsp+0x108],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db70f:   mov    rbx,QWORD PTR [rsi+0xd0]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db716:   mov    QWORD PTR [rsp+0x110],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db71e:   mov    rbx,QWORD PTR [rsi+0xc8]     ;*ireturn
{reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 16 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db725:   mov    QWORD PTR [rsp+0x118],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db72d:   mov    rbx,QWORD PTR [rsi+0xc0]     ;*ireturn
{reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
org.openjdk.jmc.common.collection.AbstractIterator::hasNext at 16 (line
58)
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
  0x00007f2dc98db734:   mov    QWORD PTR [rsp+0x120],rbx
;*synchronization entry
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at -1
(line 165)
  0x00007f2dc98db73c:   mov    rbx,QWORD PTR [rsi+0xb8]
;*invokeinterface hasNext {reexecute=0 rethrow=0 return_oop=0}
                                                            ; -
com.datadog.profiling.aggregation.parser.jfr.JfrParser::parseJfr at 474
(line 227)
====

Similar sequences are repeated basically everywhere in the compiled method body.

If someone could shed some light on this phenomenon and how it could
be interpreted from the end user point of view (eg. someone looking at
the CPU profiles) it would be very much welcomed.

I am sorry for the lengthy post and I hope to hear from someone soon.

Cheers,

-JB-

From roland at openjdk.java.net  Fri Feb  4 14:54:35 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 4 Feb 2022 14:54:35 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops can
 interfere with loop optimizations
Message-ID: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>

The bytecode of the 2 methods of the benchmark is structured
differently: loopsWithSharedLocal(), the slowest one, has multiple
backedges with a single head while loopsWithScopedLocal() has a single
backedge and all the paths in the loop body merge before the
backedge. loopsWithSharedLocal() has its head cloned which results in
a 2 loops loop nest.

loopsWithSharedLocal() is slow when 2 of the backedges are most
commonly taken with one taken only 3 times as often as the other
one. So a thread executing that code only runs the inner loop for a
few iterations before exiting it and executing the outer loop. I think
what happens is that any time the inner loop is entered, some
predicates are executed and the overhead of the setup of loop strip
mining (if it's enabled) has to be paid. Also, if iteration
splitting/unrolling was applied, the main loop is likely never
executed and all time is spent in the pre/post loops where potentially
some range checks remain.

The fix I propose is that ciTypeFlow, when it clone heads, not only
rewires the most frequent loop but also all this other frequent loops
that share the same head. loopsWithSharedLocal() and
loopsWithScopedLocal() are then fairly similar once c2 parses them.

Without the patch I measure:

LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op

with it:

LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op

But this patch also causes a regression when running one of the
benchmarks added by 8278518. From:

SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op

to:

SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op

The hot method of this benchmark used to be compiled with 2 loops, the
inner one a counted loop. With the patch, it's now compiled with a
single one which can't be converted into a counted loop because the
loop variable is incremented by a different amount along the 2 paths
in the loop body. What I propose to fix this is to add a new loop
transformation that detects that, because of a merge point, a loop
can't be turned into a counted loop and transforms it into 2
loops. The benchmark performs better with this:

SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op

Not quite on par with the previous score but AFAICT this is due to
code generation not being as good (the loop head can't be aligned in
particular).

In short, I propose:

- changing ciTypeFlow so that, when it pays off, a loop with
multiple backedges is compiled as a single loop with a merge point in
the loop body

- adding a new loop transformation so that, when it pays off, a loop
with a merge point in the loop body is converted into a 2 loops loop
nest, essentially the opposite transformation.

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

Commit messages:
 - whitespaces
 - fix & test

Changes: https://git.openjdk.java.net/jdk/pull/7352/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7352&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279888
  Stats: 1081 lines in 9 files changed: 781 ins; 132 del; 168 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7352/head:pull/7352

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

From roland at openjdk.java.net  Fri Feb  4 15:10:09 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 4 Feb 2022 15:10:09 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations
In-Reply-To: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
Message-ID: <3U5F0R3nrV28ouWqLqAklrkCXBGWuaYgv2sidFnkofg=.5a27a901-9913-4092-a026-b5093473c8c8@github.com>

On Fri, 4 Feb 2022 14:41:55 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The bytecode of the 2 methods of the benchmark is structured
> differently: loopsWithSharedLocal(), the slowest one, has multiple
> backedges with a single head while loopsWithScopedLocal() has a single
> backedge and all the paths in the loop body merge before the
> backedge. loopsWithSharedLocal() has its head cloned which results in
> a 2 loops loop nest.
> 
> loopsWithSharedLocal() is slow when 2 of the backedges are most
> commonly taken with one taken only 3 times as often as the other
> one. So a thread executing that code only runs the inner loop for a
> few iterations before exiting it and executing the outer loop. I think
> what happens is that any time the inner loop is entered, some
> predicates are executed and the overhead of the setup of loop strip
> mining (if it's enabled) has to be paid. Also, if iteration
> splitting/unrolling was applied, the main loop is likely never
> executed and all time is spent in the pre/post loops where potentially
> some range checks remain.
> 
> The fix I propose is that ciTypeFlow, when it clone heads, not only
> rewires the most frequent loop but also all this other frequent loops
> that share the same head. loopsWithSharedLocal() and
> loopsWithScopedLocal() are then fairly similar once c2 parses them.
> 
> Without the patch I measure:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
> 
> with it:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
> 
> But this patch also causes a regression when running one of the
> benchmarks added by 8278518. From:
> 
> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
> 
> to:
> 
> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
> 
> The hot method of this benchmark used to be compiled with 2 loops, the
> inner one a counted loop. With the patch, it's now compiled with a
> single one which can't be converted into a counted loop because the
> loop variable is incremented by a different amount along the 2 paths
> in the loop body. What I propose to fix this is to add a new loop
> transformation that detects that, because of a merge point, a loop
> can't be turned into a counted loop and transforms it into 2
> loops. The benchmark performs better with this:
> 
> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
> 
> Not quite on par with the previous score but AFAICT this is due to
> code generation not being as good (the loop head can't be aligned in
> particular).
> 
> In short, I propose:
> 
> - changing ciTypeFlow so that, when it pays off, a loop with
> multiple backedges is compiled as a single loop with a merge point in
> the loop body
> 
> - adding a new loop transformation so that, when it pays off, a loop
> with a merge point in the loop body is converted into a 2 loops loop
> nest, essentially the opposite transformation.

One thing I should have mentioned is that I refactored loop body cloning so that it now calls helper functions. The new loop transform is implemented by calling these functions so it's mostly based on well tested code.

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

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

From dcubed at openjdk.java.net  Fri Feb  4 17:25:15 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:25:15 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <wl6KF6Ij9he0EH0CjeO3vloYEeEmrI-VRI4FgC4ahpI=.6b8c955d-8f04-44e2-9bb1-436856b1cf48@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <rWH1LFS46rWPSKECMU7sXZ5CFIZeWuvmItZ11Hg0noc=.6e042eec-e519-4421-a189-c9ab11fb79b2@github.com>
 <VJdmfqufxdr6pBLke8mu4K8RPFTodDOXZ1aiOUYiNnE=.88202ade-6437-4969-a52a-4e2704f6b8ab@github.com>
 <R4Y21_qcDeJQPryuio6WavtYGRDKRrsB0TwtxqvtuHg=.f2c410fb-7bea-494d-ac98-65d910abeea5@github.com>
 <F1e1RZ5vwuupPCPyHL1c5IuvuWsfAlN-CpgJyLfBsgU=.ed851c4b-7b2c-428e-865a-0a534eb363b9@github.com>
 <4-bZw4mRrzVVxWUPP-uH3S5I95wzXceafgQy9LPpQAA=.1438bdd5-ca07-426d-98f5-ca36a21ecad6@github.com>
 <-2irb1M8YfxkvDqx7qokr1SK-SaSVK0tv-EjoyHV9tw=.0a9bd932-80a4-4325-92b9-ad2fd92744b1@github.com>
 <rX0ChqL_4au9aKs0gaJnxt4VbJoWDeDMFFHagCrxXEY=.05c9772e-5b88-4dc5-a9af-fc87866d2f7a@github.com>
 <0N9FxechUMfug8q0sB98JSxgfCP_y6Amz2Y9HtaoPWw=.68c7df06-26ac-493a-84e2-4e6e65068f5f@github.com>
 <wl6KF6Ij9he0EH0CjeO3vloYEeEmrI-VRI4FgC4ahpI=.6b8c955d-8f04-44e2-9bb1-436856b1cf48@github.com>
Message-ID: <ansW-hL3thvwKdSY8nT8irBxZLm5ivH84xyil9qkfvU=.853779b5-2fd4-41ff-99fa-c157d57eb650@github.com>

On Fri, 4 Feb 2022 10:46:22 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>>> First thing to note is that `replicate` is never actually called with `count == 0`.
>> 
>> This is crucial: it means we have no UB.
>> 
>> Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)
>
>> Could I ask you to take the opportunity add a little of this commentary to the rather opaque code? Pretty please? :-)
> 
> Sure,this stuff really needs to be better documented in the code itself. I'll do that as a follow-up to this PR.

>>    First thing to note is that replicate is never actually called with count == 0.

> This is crucial: it means we have no UB.

The UB occurs when `count == 1` and `nbits == 64`.

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

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

From dcubed at openjdk.java.net  Fri Feb  4 17:25:14 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:25:14 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
Message-ID: <igddDYPW30852pPbxguxBEurDW-_PkKGssuJDn6PQrI=.3e808a75-5d2d-423a-b8ad-19202ad795bf@github.com>

On Thu, 3 Feb 2022 21:05:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
>> replicate().
>> 
>> I was not able to reproduce the reported failure using:
>> 
>>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
>> 
>> so I'm moving forward with the proposed fix from a code inspection
>> point of view.
>> 
>> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
>> no failures. Tier[3-6] are still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett and adinn CR changes

@adinn or @theRealAph - I need one more reviewer to approve so I can integrate this.

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

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

From adinn at openjdk.java.net  Fri Feb  4 17:31:11 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Fri, 4 Feb 2022 17:31:11 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
Message-ID: <OP8cMiTExd3X-Ero4YCSHDUN863qUOR81G0l0VRypzU=.e0ae774d-7ef4-4b51-a6bc-e3a2ac784dfa@github.com>

On Thu, 3 Feb 2022 21:05:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
>> replicate().
>> 
>> I was not able to reproduce the reported failure using:
>> 
>>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
>> 
>> so I'm moving forward with the proposed fix from a code inspection
>> point of view.
>> 
>> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
>> no failures. Tier[3-6] are still running.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kimbarrett and adinn CR changes

Marked as reviewed by adinn (Reviewer).

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

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

From dcubed at openjdk.java.net  Fri Feb  4 17:40:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:40:12 GMT
Subject: RFR: 8280476: [macOS] : hotspot arm64 bug exposed by latest clang
 [v2]
In-Reply-To: <OP8cMiTExd3X-Ero4YCSHDUN863qUOR81G0l0VRypzU=.e0ae774d-7ef4-4b51-a6bc-e3a2ac784dfa@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
 <WzwCcWnNB0LLlxNS-fbp-Jgz6luSEk0HnQ1wvfXCb_Y=.8d3a7b80-9c27-469f-ae45-fad0f764e80c@github.com>
 <OP8cMiTExd3X-Ero4YCSHDUN863qUOR81G0l0VRypzU=.e0ae774d-7ef4-4b51-a6bc-e3a2ac784dfa@github.com>
Message-ID: <467QEJGEe3fFNI0KFk_RaCn58nB-fmyiMyFernvxTmE=.8672e0f1-1cc5-423f-b1ca-066de2dd66b2@github.com>

On Fri, 4 Feb 2022 17:27:53 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kimbarrett and adinn CR changes
>
> Marked as reviewed by adinn (Reviewer).

@adinn - Thanks for the review. As you mentioned above, I'll leave it up to
you to improve the comment in a new PR.

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

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

From dcubed at openjdk.java.net  Fri Feb  4 17:40:12 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Feb 2022 17:40:12 GMT
Subject: Integrated: 8280476: [macOS] : hotspot arm64 bug exposed by latest
 clang
In-Reply-To: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
References: <dR-zSxoh15ULFMlDl9qgXp-WUJZ0MGkNbNx1vWwFXs8=.9a53512c-f7a2-4d88-8e91-1b1883b8c6f8@github.com>
Message-ID: <Axb8N__IT_UBJ-EH65cczsEJ_Wg7eDSaOglGHd0ETLc=.4dcd00a4-fd3d-4c6c-ac09-38a6da61e3bc@github.com>

On Fri, 28 Jan 2022 16:49:32 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to solve undefined behavior in src/hotspot/cpu/aarch64/immediate_aarch64.cpp:
> replicate().
> 
> I was not able to reproduce the reported failure using:
> 
>   Xcode: Version 13.2.1 (13C100) which includes clang Apple LLVM 13.0.0 (clang-1300.0.29.30)
> 
> so I'm moving forward with the proposed fix from a code inspection
> point of view.
> 
> I've tested this fix with Mach5 Tier[1-6]. Tier1 and Tier2 have completed with
> no failures. Tier[3-6] are still running.

This pull request has now been integrated.

Changeset: f5d6fddc
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5d6fddc6df8c5c5456a2544b131833d5227292b
Stats:     11 lines in 1 file changed: 10 ins; 1 del; 0 mod

8280476: [macOS] : hotspot arm64 bug exposed by latest clang

Reviewed-by: kbarrett, adinn

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

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

From xliu at openjdk.java.net  Fri Feb  4 19:55:10 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Fri, 4 Feb 2022 19:55:10 GMT
Subject: RFR: 8281117: Add regression test for JDK-8280587
In-Reply-To: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
References: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
Message-ID: <5thCyoJKGwcDtIqR91N1lTt3qqgfzRA_lAtDdWQ7-jk=.4c5363b3-14cd-472b-b318-d71d2f506aec@github.com>

On Wed, 2 Feb 2022 13:51:01 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Recently, bug [JDK-8280600](https://bugs.openjdk.java.net/browse/JDK-8280600) was fixed, see [PR](https://github.com/openjdk/jdk/pull/7307).
> [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) has been detected as a duplicate bug.
> However, [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) came with a differen reported test which failed with a different assert.
> Therefore, I added this additional test as a second regression test.
> 
> I ran this test to check that it passes successfully.

Marked as reviewed by xliu (Committer).

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

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

From dean.long at oracle.com  Sat Feb  5 09:45:25 2022
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Sat, 5 Feb 2022 01:45:25 -0800
Subject: A noob question about weird sequence of `*synchronization entry`
 in a C2 compiled code
In-Reply-To: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>
References: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>
Message-ID: <c7bff2ef-3986-9833-5405-e12c9832b2ba@oracle.com>

Hi Jaroslav.  It looks like the code is mostly calling and returning. 
It looks like a recursive method that is getting inlined.  The 
"synchronization entry" seems to happen at method entry or exit (where 
the bci is set to -1).

dl

From jaroslav.bachorik at datadoghq.com  Sat Feb  5 20:58:50 2022
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Sat, 5 Feb 2022 21:58:50 +0100
Subject: A noob question about weird sequence of `*synchronization entry`
 in a C2 compiled code
In-Reply-To: <c7bff2ef-3986-9833-5405-e12c9832b2ba@oracle.com>
References: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>
 <c7bff2ef-3986-9833-5405-e12c9832b2ba@oracle.com>
Message-ID: <CAPb8aJ4UZRxfBaaSK+F9LxfFD+js9yeB07B4OJrk8hS2gnpGnw@mail.gmail.com>

Hi Dean,

Thanks for taking a look at this! The recursion does not sound very
plausible, though.
The code is doing something like this

```
227 for (IItem event : eventIterable) {
228   long value = valueAccessor.applyAsLong(event);
229   if (value == 0) {
230     continue;
231   }
232   IMCStackTrace jmcStacktrace = stacktraceAccessor.getMember(event);
233   if (jmcStacktrace == null) {
234     continue;
235   }
  ....
```

Unfortunately, I can not share the full code :( But there is
definitely no recursion happening at L227.

What I find confusing here, is that even if the '*synchronization
entry' items are demarking 'before BCI' for the inlined methods they
get mixed up with the 'before BCI' code of the inilining method,
making it quite impossible to attribute the CPU samples properly - eg.
all 'before BCI' code of all inlined methods would be attached to the
first line of the inilining method in JFR stacktraces messing up the
resulting profile by overemphasizing the costs of the iniling method.

Is this the hard limitation of what is possible to do with the debug
data at this level of optimization? Are some boundaries irreversibly
lost here?

Cheers,

-JB-

On Sat, Feb 5, 2022 at 10:49 AM <dean.long at oracle.com> wrote:
>
> Hi Jaroslav.  It looks like the code is mostly calling and returning.
> It looks like a recursive method that is getting inlined.  The
> "synchronization entry" seems to happen at method entry or exit (where
> the bci is set to -1).
>
> dl

From dean.long at oracle.com  Sun Feb  6 05:45:48 2022
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Sat, 5 Feb 2022 21:45:48 -0800
Subject: [External] : Re: A noob question about weird sequence of
 `*synchronization entry` in a C2 compiled code
In-Reply-To: <CAPb8aJ4UZRxfBaaSK+F9LxfFD+js9yeB07B4OJrk8hS2gnpGnw@mail.gmail.com>
References: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>
 <c7bff2ef-3986-9833-5405-e12c9832b2ba@oracle.com>
 <CAPb8aJ4UZRxfBaaSK+F9LxfFD+js9yeB07B4OJrk8hS2gnpGnw@mail.gmail.com>
Message-ID: <648b6872-b63d-c861-f592-bea89b6a48fd@oracle.com>

On 2/5/22 12:58 PM, Jaroslav Bachor?k wrote:
> Is this the hard limitation of what is possible to do with the debug
> data at this level of optimization? Are some boundaries irreversibly
> lost here?

It's quite likely you've discovered a bug that can be fixed.  If you 
could narrow it down to a self-contained test case, that would really help.

dl

From duke at openjdk.java.net  Mon Feb  7 08:22:15 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 7 Feb 2022 08:22:15 GMT
Subject: Integrated: 8281117: Add regression test for JDK-8280587
In-Reply-To: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
References: <BGvLZW74Jao_ZXnaiBRsOyFMF7P6MIRjHV3WBR8_zeM=.af02bc41-ec87-46b5-a75c-962d6a08e00e@github.com>
Message-ID: <_ZGVJXVE9kkCd_YJdPCvaJBQE1kXztLiQRtN05_fIzE=.1c7cdabb-b8ca-4b14-b324-34236b765e67@github.com>

On Wed, 2 Feb 2022 13:51:01 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Recently, bug [JDK-8280600](https://bugs.openjdk.java.net/browse/JDK-8280600) was fixed, see [PR](https://github.com/openjdk/jdk/pull/7307).
> [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) has been detected as a duplicate bug.
> However, [JDK-8280587](https://bugs.openjdk.java.net/browse/JDK-8280587) came with a differen reported test which failed with a different assert.
> Therefore, I added this additional test as a second regression test.
> 
> I ran this test to check that it passes successfully.

This pull request has now been integrated.

Changeset: f5e08700
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5e0870091ad9534e7a3dd08ef2e3ee7cd781c6d
Stats:     54 lines in 1 file changed: 54 ins; 0 del; 0 mod

8281117: Add regression test for JDK-8280587

Reviewed-by: chagedorn, thartmann, xliu

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

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

From roland at openjdk.java.net  Mon Feb  7 09:09:31 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Feb 2022 09:09:31 GMT
Subject: RFR: 8281322: irTests/TestLongRangeChecks.java fails with strip mining
 off
Message-ID: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>

Some of the long range check transformations take advantage of the
safepoint captured by loop strip mining to extract jvm state (in order
to add back empty predicates to the inner loop of a loop nest). As a
consequence, irTests/TestLongRangeChecks.java fails with strip mining
off and users might experience performance anomalies where changing
GCs affect purely computational code.

The strip mined loop nest creation is a 2 step process:

1- when a CountedLoop is created, an OuterStripMinedLoop is also added
  but it's not fully constructed

2- at macro expansion time, the OuterStripMinedLoop is turned into an
  actual loop by adding Phis and a proper exit condition

I propose always doing 1- whether loop strip mining is enabled or
not. This causes the safepoint to always be captured. Loop strip ming
is not expected to get in the way of loop transformations so this
change in itself should be performance neutral. Then at 2-, if loop
strip mining is not enabled, the OuterStripMinedLoop can be removed
and the safepoint moved back into the loop in case
LoopStripMiningIter=1 or simply removed too.

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

Commit messages:
 - test bug/summary
 - fix & test

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

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

From roland at openjdk.java.net  Mon Feb  7 13:57:41 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Feb 2022 13:57:41 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are properly
 optimized
Message-ID: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>

That came up in previous:

https://github.com/openjdk/jdk/pull/2529#discussion_r583054321

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

Commit messages:
 - tests

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

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

From jaroslav.bachorik at datadoghq.com  Mon Feb  7 15:58:18 2022
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 7 Feb 2022 16:58:18 +0100
Subject: [External] : Re: A noob question about weird sequence of
 `*synchronization entry` in a C2 compiled code
In-Reply-To: <648b6872-b63d-c861-f592-bea89b6a48fd@oracle.com>
References: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>
 <c7bff2ef-3986-9833-5405-e12c9832b2ba@oracle.com>
 <CAPb8aJ4UZRxfBaaSK+F9LxfFD+js9yeB07B4OJrk8hS2gnpGnw@mail.gmail.com>
 <648b6872-b63d-c861-f592-bea89b6a48fd@oracle.com>
Message-ID: <CAPb8aJ7iKct8mnBaADoa26cW0v6cJbxLufxus1saxzLVqHuHGw@mail.gmail.com>

Hi Dean,

The first thing I want to mention is that I isolated  this behaviour
to be triggered by `-XX:DebugNonSafepoints` JVM arg. When this option
is not specified I don't see the pattern at all.

I have extracted a self-contained (almost) reproducer - it is not a
single class, unfortunately, but building and running it is as simple
as executing the attached `./run.sh`
The reproducer has a weak point, though - I am not able to get the
`*synchronization entry` pattern manifesting at the same locations.
Therefore it is more of PoC than a full test case - it requires going
to the assembly print out and searching for `*synchronization entry`
manually.

The project can be found here -
https://drive.google.com/file/d/1Z6rX4NpvNpctVA3AuYfaG0Qxjd4KjrED/view?usp=sharing
It is a zipped gradle java project and the only thing it requires is a
working Java env.

Thanks!

-JB-

On Sun, Feb 6, 2022 at 6:45 AM <dean.long at oracle.com> wrote:
>
> On 2/5/22 12:58 PM, Jaroslav Bachor?k wrote:
> > Is this the hard limitation of what is possible to do with the debug
> > data at this level of optimization? Are some boundaries irreversibly
> > lost here?
>
> It's quite likely you've discovered a bug that can be fixed.  If you
> could narrow it down to a self-contained test case, that would really help.
>
> dl

From jbhateja at openjdk.java.net  Mon Feb  7 20:15:25 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 7 Feb 2022 20:15:25 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
Message-ID: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>

Summary of changes:

- Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
- Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
- Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.


Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
-- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 61.44646857 | 1083.92 | 203.958 | 81.18329766 | 88.958 | 60.096 | 32.44452438
VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.862122657 | 417.203 | 214.949 | 48.4785584 | 105.954 | 117.019 | -10.4432112


Please review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - 8281375: Accelerate bitCount operation for AVX2 and AVX512 target.

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

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

From dean.long at oracle.com  Mon Feb  7 22:20:14 2022
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 7 Feb 2022 14:20:14 -0800
Subject: [External] : Re: A noob question about weird sequence of
 `*synchronization entry` in a C2 compiled code
In-Reply-To: <CAPb8aJ7iKct8mnBaADoa26cW0v6cJbxLufxus1saxzLVqHuHGw@mail.gmail.com>
References: <CAPb8aJ6fEKuCe-i4-P2uamqrw0rk6S=fmwVcL6E8m0RzGaVzyQ@mail.gmail.com>
 <c7bff2ef-3986-9833-5405-e12c9832b2ba@oracle.com>
 <CAPb8aJ4UZRxfBaaSK+F9LxfFD+js9yeB07B4OJrk8hS2gnpGnw@mail.gmail.com>
 <648b6872-b63d-c861-f592-bea89b6a48fd@oracle.com>
 <CAPb8aJ7iKct8mnBaADoa26cW0v6cJbxLufxus1saxzLVqHuHGw@mail.gmail.com>
Message-ID: <322745e1-ab69-17f7-571f-ed2d5580204c@oracle.com>

It turns out the problem with DebugNonSafepoints is a known issue.  See 
https://bugs.openjdk.java.net/browse/JDK-8201516.

dl

On 2/7/22 7:58 AM, Jaroslav Bachor?k wrote:
> Hi Dean,
> 
> The first thing I want to mention is that I isolated  this behaviour
> to be triggered by `-XX:DebugNonSafepoints` JVM arg. When this option
> is not specified I don't see the pattern at all.
> 
> I have extracted a self-contained (almost) reproducer - it is not a
> single class, unfortunately, but building and running it is as simple
> as executing the attached `./run.sh`
> The reproducer has a weak point, though - I am not able to get the
> `*synchronization entry` pattern manifesting at the same locations.
> Therefore it is more of PoC than a full test case - it requires going
> to the assembly print out and searching for `*synchronization entry`
> manually.
> 
> The project can be found here -
> https://urldefense.com/v3/__https://drive.google.com/file/d/1Z6rX4NpvNpctVA3AuYfaG0Qxjd4KjrED/view?usp=sharing__;!!ACWV5N9M2RV99hQ!f9PhKRCRHuSdH__32-XrLtTdu0RoQCQz8wJGjvsqF83SjHg4R2_vAcUJOJFYqd4$
> It is a zipped gradle java project and the only thing it requires is a
> working Java env.
> 
> Thanks!
> 
> -JB-
> 
> On Sun, Feb 6, 2022 at 6:45 AM <dean.long at oracle.com> wrote:
>>
>> On 2/5/22 12:58 PM, Jaroslav Bachor?k wrote:
>>> Is this the hard limitation of what is possible to do with the debug
>>> data at this level of optimization? Are some boundaries irreversibly
>>> lost here?
>>
>> It's quite likely you've discovered a bug that can be fixed.  If you
>> could narrow it down to a self-contained test case, that would really help.
>>
>> dl

From dlong at openjdk.java.net  Tue Feb  8 01:30:06 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 8 Feb 2022 01:30:06 GMT
Subject: RFR: 8280541: remove self-recursion of
 ConnectionGraph::find_inst_mem() [v2]
In-Reply-To: <ULUqtPuku1ee0zc8GdxBz0O3g1ba-qtT0fTGUfXjkqk=.cf6bb7c5-4f4e-4bb6-ac04-76b604b6c23f@github.com>
References: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
 <ULUqtPuku1ee0zc8GdxBz0O3g1ba-qtT0fTGUfXjkqk=.cf6bb7c5-4f4e-4bb6-ac04-76b604b6c23f@github.com>
Message-ID: <qnyrXMrQc96QaX54JkY7_0JEukJSCiCcocIYXJ9GUUE=.9a661ea2-0a06-4278-a155-88d61aacc88f@github.com>

On Wed, 2 Feb 2022 07:12:47 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This is a follow-up task of JDK-8276219.
>> 
>> ConnectionGraph::find_inst_mem() contains a self-recursion for MergeMemNode.
>> It drills down into one input of MergeMemNode and tries to locate the memory node
>> which has the exact alias_idx. Once it returns, the result won't change from
>> recursion. Therefore, it's not necessary to use recursion in this case. We can
>> reset the initial state of this function and respin.
>> 
>> We can use a collection to remember all MergeMem Nodes and update them after then. 
>> 
>> This patch also makes a cleanup in MergeMemNode::memory_at(). C is not in use in
>> that function.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an assertion in debug build.
>   
>   This patch ensures the result is same as recursion.

If the result won't change, then perhaps the self-recursion case should return instead of falling through.  Then it really is tail-recursion elimination.  However, knowing that falling through won't change the value makes several assumptions based on the current code, and those assumptions could break if the code changes.  To follow the original algorithm, the new version should fall through, which means having the loop pop elements off a stack.  Either way, this is not a trivial change to me.

I also noticed that moving the C->failing() check could also cause different behavior, but maybe it's harmless.

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

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

From duke at openjdk.java.net  Tue Feb  8 06:06:12 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Feb 2022 06:06:12 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
Message-ID: <HKjf-_-uqRW7b5eg0nCpZ058yD9aHH05RBv5STo0E8I=.3e83bf39-9710-4ceb-872a-95f0e1fdf5f8@github.com>

On Tue, 4 Jan 2022 08:47:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds support for arrays in compiled code constant tables and uses it for various vector replicate operations on x86.
>> 
>> Test: GHA, linux x64 tier 1-3
>> 
>> Thank you very much.
>
> Quan Anh Mai 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 constantVectorUpdate
>  - update copyright
>  - missing type in array_constant
>  - Merge branch 'master' into constantVector
>  - use constant table for remaining types
>  - Merge branch 'master' into constantVector
>  - refactor
>  - replicate using constant
>  - Merge branch 'master' into constantVector
>  - initial commit

Hi, may anyone take a look at this PR, please. Thank you very much.

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

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

From shade at openjdk.java.net  Tue Feb  8 07:23:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 8 Feb 2022 07:23:10 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
Message-ID: <SFtuct7rVbp36lQfSqGZhmUa7dI6eTc1mg8iWaWLw8k=.0fda8530-f076-4f8d-9e66-e1cf044d9636@github.com>

On Fri, 28 Jan 2022 10:36:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the discussion in the bug.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_32 fastdebug `java/lang/instrument`
>>  - [x] Linux AArch64 fastdebug `java/lang/instrument`
>>  - [x] Linux ARM32 fastdebug `java/lang/instrument`
>>  - [x] Linux PPC64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_32 fastdebug `tier1`
>>  - [x] Linux AArch64 fastdebug `tier1`
>>  - [x] Linux PPC64 fastdebug `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ARM32 checks

This needs attention of compiler/C1 reviewer :)

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

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

From neliasso at openjdk.java.net  Tue Feb  8 09:05:11 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 8 Feb 2022 09:05:11 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>

On Mon, 7 Feb 2022 20:08:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Hi Jatin, nice work!

One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.

Best regards,
Nils

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

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

From neliasso at openjdk.java.net  Tue Feb  8 09:06:07 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 8 Feb 2022 09:06:07 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
Message-ID: <Fs9U-NrGLAMxC3Wfd7Ae7xTTfLBZDTRyptEezKS2DKM=.429ef1d4-fcdd-448f-99ae-ccdf61e99ac0@github.com>

On Mon, 7 Feb 2022 13:49:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> That came up in previous:
> 
> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321

Looks good! Approved.

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

Marked as reviewed by neliasso (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Feb  8 10:08:16 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 8 Feb 2022 10:08:16 GMT
Subject: RFR: 8281322: irTests/TestLongRangeChecks.java fails with strip
 mining off
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <TM91d4AlOBaxdrcwXG9CiLktaDKwF_qubeMwyCaK-sE=.629b9f0f-b409-4bb5-b442-c1edecaa92f0@github.com>

On Mon, 7 Feb 2022 08:53:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

That looks reasonable. I'll submit some testing.

src/hotspot/share/opto/loopnode.cpp line 2574:

> 2572: 
> 2573:     // make counted loop exit test always fail to
> 2574:     igvn->replace_input_of(cle, 1, outer_test);

Might be clearer to directly use `igvn->intcon(0)` instead of `outer_test`.

src/hotspot/share/opto/loopnode.cpp line 2582:

> 2580:     // make the outer loop go away
> 2581:     igvn->replace_input_of(this, LoopBackControl, igvn->C->top());
> 2582:     igvn->C->print_method(PHASE_DEBUG, 2);

Probably a left-over and can be removed.

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

Marked as reviewed by chagedorn (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Feb  8 10:15:06 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 8 Feb 2022 10:15:06 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
Message-ID: <wLBH7wGsBDBM6WZ099QN9wLenyiSBEqZeBZ9bpj-s48=.bcf39f94-837f-4786-a04e-fdc44e6f97a3@github.com>

On Mon, 7 Feb 2022 13:49:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> That came up in previous:
> 
> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From thartmann at openjdk.java.net  Tue Feb  8 10:36:11 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Feb 2022 10:36:11 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <fjeTf7oDUQ9aCFpzmQltU0pTCcsdPRFlbPZEBWzb7tI=.9d78eaf3-ef7e-466b-97a6-12dff9c280b7@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

Looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Tue Feb  8 10:50:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Feb 2022 10:50:05 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses
In-Reply-To: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
Message-ID: <zmpIEbVHZTQZj4fgv2OX1_4M7roFDaD_A05SlCv5I1o=.b7e83452-1db8-4ea6-b27a-dc2cb5375b87@github.com>

On Mon, 6 Dec 2021 09:59:44 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Outside the type system code itself, c2 usually assumes that a
> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
> klass(). To have proper support for interfaces, that can't be true as
> a type needs to be represented by an instance class and a set of
> interfaces. This patch hides the klass() accessor of
> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
> that makes that code suitable for proper interface support in a
> subsequent change. This patch doesn't add proper interface support yet
> and is mostly refactoring. "Mostly" because there are cases where the
> previous logic would use a ciKlass but the new one works with a
> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
> klass is exact or not. That extra bit of information can sometimes
> help and so could result in slightly different decisions.
> 
> To remove the klass() accessors, the new logic either relies on:
> 
> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
> toop->klass()->is_subtype_of(other_toop->klass())
> the new code is:
> toop->is_java_subtype_of(other_toop)
> 
> - variants of the klass() accessors for narrower cases like
>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>   interface in which case it returns Object),
>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>   the type is exact).
> 
> When I tested this patch, for most changes in this patch, I had the
> previous logic, the new logic and a check that verified that they
> return the same result. I ran as much testing as I could that way.

Quickly ran this through testing, seeing build failures:


[2022-02-08T10:43:57,398Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24420/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d28f4559-13f6-46e3-b407-8090e4d3f411/runs/ecf578fc-ee25-4f6e-a577-ebd7c77ee02d/workspace/open/src/hotspot/share/opto/graphKit.cpp:3987:17: error: 'klass' is a protected member of 'TypeOopPtr'
[2022-02-08T10:43:57,398Z]   if (ary_type->klass()->is_array_klass()) {
[2022-02-08T10:43:57,398Z]                 ^
[2022-02-08T10:43:57,398Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24420/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d28f4559-13f6-46e3-b407-8090e4d3f411/runs/ecf578fc-ee25-4f6e-a577-ebd7c77ee02d/workspace/open/src/hotspot/share/opto/type.hpp:1096:20: note: declared protected here
[2022-02-08T10:43:57,398Z]   virtual ciKlass* klass() const { return _klass;     }
[2022-02-08T10:43:57,398Z]                    ^
[2022-02-08T10:43:57,398Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24420/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d28f4559-13f6-46e3-b407-8090e4d3f411/runs/ecf578fc-ee25-4f6e-a577-ebd7c77ee02d/workspace/open/src/hotspot/share/opto/graphKit.cpp:3988:30: error: 'klass' is a protected member of 'TypeOopPtr'
[2022-02-08T10:43:57,398Z]     BasicType bt = ary_type->klass()->as_array_klass()->element_type()->basic_type();
[2022-02-08T10:43:57,398Z]                              ^
[2022-02-08T10:43:57,398Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24420/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d28f4559-13f6-46e3-b407-8090e4d3f411/runs/ecf578fc-ee25-4f6e-a577-ebd7c77ee02d/workspace/open/src/hotspot/share/opto/type.hpp:1096:20: note: declared protected here
[2022-02-08T10:43:57,398Z]   virtual ciKlass* klass() const { return _klass;     }

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

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

From roland at openjdk.java.net  Tue Feb  8 13:44:11 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 8 Feb 2022 13:44:11 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <Fs9U-NrGLAMxC3Wfd7Ae7xTTfLBZDTRyptEezKS2DKM=.429ef1d4-fcdd-448f-99ae-ccdf61e99ac0@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
 <Fs9U-NrGLAMxC3Wfd7Ae7xTTfLBZDTRyptEezKS2DKM=.429ef1d4-fcdd-448f-99ae-ccdf61e99ac0@github.com>
Message-ID: <P1TSAbWgfN3BUgM-UowQQ-lYnVqZH2eaq2UIhorRjUw=.9d307d47-b25a-482b-9104-c315371474ed@github.com>

On Tue, 8 Feb 2022 09:02:33 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> That came up in previous:
>> 
>> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321
>
> Looks good! Approved.

@neliasso @chhagedorn thanks for the reviews.

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

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

From roland at openjdk.java.net  Tue Feb  8 13:44:12 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 8 Feb 2022 13:44:12 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
Message-ID: <qF_pVM1K1JNH8qqWphxUf8xvhMEgsyixLf6dn3MJ1I4=.15792f1b-54b8-40e2-81d6-e801e347777f@github.com>

On Mon, 7 Feb 2022 13:49:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> That came up in previous:
> 
> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321

@vnkozlov are the proposed tests what you had in mind?

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

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

From vlivanov at openjdk.java.net  Tue Feb  8 14:55:53 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 8 Feb 2022 14:55:53 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported [v2]
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <zkLhmbUpSp4oh5DjiboABU1c8tyLSL1WsDuHD7m_MlQ=.526f94a8-ae4e-4157-b2e2-26c53d9037ed@github.com>

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

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 three additional commits since the last revision:

 - fatal -> assert
 - Merge branch 'master' into 8279822.cpe_in_error
 - Compiler support of CP entries in error state

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7314/files
  - new: https://git.openjdk.java.net/jdk/pull/7314/files/b6cc375c..9bdf70ff

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

  Stats: 4160 lines in 186 files changed: 3210 ins; 452 del; 498 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7314/head:pull/7314

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

From jiefu at openjdk.java.net  Tue Feb  8 15:02:11 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 8 Feb 2022 15:02:11 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
Message-ID: <aBS8HUh36IjufnKTksVSYhuGYH6JlhpZBA3n88wLmc0=.a68fb698-5a45-408e-8445-fd458ecc3bfe@github.com>

On Tue, 4 Jan 2022 08:47:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds support for arrays in compiled code constant tables and uses it for various vector replicate operations on x86.
>> 
>> Test: GHA, linux x64 tier 1-3
>> 
>> Thank you very much.
>
> Quan Anh Mai 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 constantVectorUpdate
>  - update copyright
>  - missing type in array_constant
>  - Merge branch 'master' into constantVector
>  - use constant table for remaining types
>  - Merge branch 'master' into constantVector
>  - refactor
>  - replicate using constant
>  - Merge branch 'master' into constantVector
>  - initial commit

src/hotspot/share/opto/constantTable.cpp line 44:

> 42:   switch (type()) {
> 43:   case T_INT:     return (_v._value.i == other._v._value.i);
> 44:   case T_FLOAT:   return jint_cast(_v._value.f) == jint_cast(other._v._value.f);

Why did you add `jint_cast`?

Does it mean the original impl for `T_FLOAD` wouldn't work as expected?

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

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

From redestad at openjdk.java.net  Tue Feb  8 15:28:11 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 8 Feb 2022 15:28:11 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
Message-ID: <LrPV51XZAyPyesh-kkNXpnkyWJ42qN-jAfXdICNDLFc=.00738f7c-a267-4918-bf2d-92496a97a375@github.com>

On Tue, 4 Jan 2022 08:47:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds support for arrays in compiled code constant tables and uses it for various vector replicate operations on x86.
>> 
>> Test: GHA, linux x64 tier 1-3
>> 
>> Thank you very much.
>
> Quan Anh Mai 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 constantVectorUpdate
>  - update copyright
>  - missing type in array_constant
>  - Merge branch 'master' into constantVector
>  - use constant table for remaining types
>  - Merge branch 'master' into constantVector
>  - refactor
>  - replicate using constant
>  - Merge branch 'master' into constantVector
>  - initial commit

Could we use this facility to get rid of the `Integer.sizeTable` which is only used by C2? See https://bugs.openjdk.java.net/browse/JDK-8143900

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

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

From duke at openjdk.java.net  Tue Feb  8 16:30:37 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 8 Feb 2022 16:30:37 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)" and
 "~(c-x)" into "x+(-c-1)"
Message-ID: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>

Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.

The results of the microbenchmark are as follows:

Baseline:                                                                                                                                         
Benchmark                        Mode  Cnt  Score   Error  Units
SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op

Patch:
Benchmark                        Mode  Cnt  Score   Error  Units
SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

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

Commit messages:
 - include bug id.
 - include a microbenmark.
 - Convert c-(~x) into x+(c+1) in SubNode and convert ~(c-x) into x+(-c-1) in XorNode.

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

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

From thartmann at openjdk.java.net  Tue Feb  8 16:30:37 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Feb 2022 16:30:37 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)"
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <FSlW8ElViys2SDSThZAelJKqvhykVicQEsf05CrYIvU=.c09b4b32-e3f5-4fba-94e6-101bdebc545f@github.com>

On Tue, 8 Feb 2022 05:51:37 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

A bug has been filed https://bugs.openjdk.java.net/browse/JDK-8281453.

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

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

From duke at openjdk.java.net  Tue Feb  8 17:51:13 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Feb 2022 17:51:13 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <aBS8HUh36IjufnKTksVSYhuGYH6JlhpZBA3n88wLmc0=.a68fb698-5a45-408e-8445-fd458ecc3bfe@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
 <aBS8HUh36IjufnKTksVSYhuGYH6JlhpZBA3n88wLmc0=.a68fb698-5a45-408e-8445-fd458ecc3bfe@github.com>
Message-ID: <9UFkQ1aPZmrqSLNBwPLqyznawP0VPhV8kdIN4Uibkms=.370e23a8-78cb-445a-9b94-18dcd48ef864@github.com>

On Tue, 8 Feb 2022 14:59:03 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai 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 constantVectorUpdate
>>  - update copyright
>>  - missing type in array_constant
>>  - Merge branch 'master' into constantVector
>>  - use constant table for remaining types
>>  - Merge branch 'master' into constantVector
>>  - refactor
>>  - replicate using constant
>>  - Merge branch 'master' into constantVector
>>  - initial commit
>
> src/hotspot/share/opto/constantTable.cpp line 44:
> 
>> 42:   switch (type()) {
>> 43:   case T_INT:     return (_v._value.i == other._v._value.i);
>> 44:   case T_FLOAT:   return jint_cast(_v._value.f) == jint_cast(other._v._value.f);
> 
> Why did you add `jint_cast`?
> 
> Does it mean the original impl for `T_FLOAD` wouldn't work as expected?

They are the same. The current one uses type punning to do a bit cast. The updated one just makes the cast more explicit and consolidates the theoretical UB of type punning so that we can fix it more easily in the future.
Thanks.

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

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

From duke at openjdk.java.net  Tue Feb  8 18:00:13 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Feb 2022 18:00:13 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <LrPV51XZAyPyesh-kkNXpnkyWJ42qN-jAfXdICNDLFc=.00738f7c-a267-4918-bf2d-92496a97a375@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
 <LrPV51XZAyPyesh-kkNXpnkyWJ42qN-jAfXdICNDLFc=.00738f7c-a267-4918-bf2d-92496a97a375@github.com>
Message-ID: <LaNwuPS-Ks4gF8OeAJFowXfCwO3rTe1D15uZFcM7yHI=.bcc899c1-cd7c-43d2-82d0-576d774afdc0@github.com>

On Tue, 8 Feb 2022 15:24:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Quan Anh Mai 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 constantVectorUpdate
>>  - update copyright
>>  - missing type in array_constant
>>  - Merge branch 'master' into constantVector
>>  - use constant table for remaining types
>>  - Merge branch 'master' into constantVector
>>  - refactor
>>  - replicate using constant
>>  - Merge branch 'master' into constantVector
>>  - initial commit
>
> Could we use this facility to get rid of the `Integer.sizeTable` which is only used by C2? See https://bugs.openjdk.java.net/browse/JDK-8143900

@cl4es Yes I think we can utilize this to do so, we just need to expose a constant array and the load to the middle-end then.

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

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

From kvn at openjdk.java.net  Tue Feb  8 18:29:12 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 8 Feb 2022 18:29:12 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
Message-ID: <LrHv4CbdvlRR9Cz3vmB6tyv2wQax2OIWZ8gyyu8z8rA=.798db242-6f7f-46c2-936c-4e36f03bb63a@github.com>

On Mon, 7 Feb 2022 13:49:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> That came up in previous:
> 
> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321

Yes, this is exactly what I wanted.

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

Marked as reviewed by kvn (Reviewer).

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

From vlivanov at openjdk.java.net  Tue Feb  8 18:58:13 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 8 Feb 2022 18:58:13 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
Message-ID: <Ct-X-F_TJ0BIeEwhHLjYzZkoJcm45tua_Zjh_NOOtSg=.f7560b52-ccc3-4514-8cf3-b890c4f8645b@github.com>

On Tue, 4 Jan 2022 08:47:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds support for arrays in compiled code constant tables and uses it for various vector replicate operations on x86.
>> 
>> Test: GHA, linux x64 tier 1-3
>> 
>> Thank you very much.
>
> Quan Anh Mai 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 constantVectorUpdate
>  - update copyright
>  - missing type in array_constant
>  - Merge branch 'master' into constantVector
>  - use constant table for remaining types
>  - Merge branch 'master' into constantVector
>  - refactor
>  - replicate using constant
>  - Merge branch 'master' into constantVector
>  - initial commit

Nice improvement!

src/hotspot/share/opto/constantTable.hpp line 41:

> 39:   private:
> 40:     BasicType _type;
> 41:     bool _is_array;

Can you rely on `_type` and just use `T_ARRAY` tag for that purpose?

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

Marked as reviewed by vlivanov (Reviewer).

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

From duke at openjdk.java.net  Tue Feb  8 22:31:13 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Feb 2022 22:31:13 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
Message-ID: <DfKipiWaRQDZfaqAyk0YlIWegDwKTwv-J0KuotP3gcc=.f1f2af58-b8dd-4070-aec2-d040760dc8b9@github.com>

On Tue, 4 Jan 2022 08:47:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds support for arrays in compiled code constant tables and uses it for various vector replicate operations on x86.
>> 
>> Test: GHA, linux x64 tier 1-3
>> 
>> Thank you very much.
>
> Quan Anh Mai 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 constantVectorUpdate
>  - update copyright
>  - missing type in array_constant
>  - Merge branch 'master' into constantVector
>  - use constant table for remaining types
>  - Merge branch 'master' into constantVector
>  - refactor
>  - replicate using constant
>  - Merge branch 'master' into constantVector
>  - initial commit

Thanks a lot for your testings and reviews.

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

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

From duke at openjdk.java.net  Tue Feb  8 22:31:14 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Feb 2022 22:31:14 GMT
Subject: RFR: 8278947: Support for array constants in constant table [v2]
In-Reply-To: <Ct-X-F_TJ0BIeEwhHLjYzZkoJcm45tua_Zjh_NOOtSg=.f7560b52-ccc3-4514-8cf3-b890c4f8645b@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
 <B8ss1gs9yfgS7X_aOBrWig7ftd4lQ4exL2PnkmTRzyo=.1c23013b-61f1-4222-92cc-3f5540874d99@github.com>
 <Ct-X-F_TJ0BIeEwhHLjYzZkoJcm45tua_Zjh_NOOtSg=.f7560b52-ccc3-4514-8cf3-b890c4f8645b@github.com>
Message-ID: <9WT6MUBfh12IqMQFOz3ywTvXaQzOB0MedptH5gAQKRk=.c1305131-8406-46e3-b938-2e1d8c2964bd@github.com>

On Tue, 8 Feb 2022 18:53:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Quan Anh Mai 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 constantVectorUpdate
>>  - update copyright
>>  - missing type in array_constant
>>  - Merge branch 'master' into constantVector
>>  - use constant table for remaining types
>>  - Merge branch 'master' into constantVector
>>  - refactor
>>  - replicate using constant
>>  - Merge branch 'master' into constantVector
>>  - initial commit
>
> src/hotspot/share/opto/constantTable.hpp line 41:
> 
>> 39:   private:
>> 40:     BasicType _type;
>> 41:     bool _is_array;
> 
> Can you rely on `_type` and just use `T_ARRAY` tag for that purpose?

In that case, an additional field would be needed to identify the type of the elements anyway.

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

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

From duke at openjdk.java.net  Tue Feb  8 23:41:13 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Feb 2022 23:41:13 GMT
Subject: Integrated: 8278947: Support for array constants in constant table
In-Reply-To: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
References: <2cu-iUFYs-hPu5QX_9Y9LwulgCczVK82oyDUj5ovI5c=.2a3c7529-dec1-4b8b-aaac-ff4368fb0d8f@github.com>
Message-ID: <UlL4gyyu-iAGWh78UHKN2VthE05FoEPgI0ATwd_S1mE=.7f2c565b-6797-420a-88be-838c5a24c591@github.com>

On Tue, 21 Dec 2021 11:24:20 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch adds support for arrays in compiled code constant tables and uses it for various vector replicate operations on x86.
> 
> Test: GHA, linux x64 tier 1-3
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: fb17a8ec
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb17a8ece0a3593c51a8be60533916bf70778a93
Stats:     295 lines in 6 files changed: 123 ins; 95 del; 77 mod

8278947: Support for array constants in constant table

Reviewed-by: kvn, vlivanov

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

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

From thartmann at openjdk.java.net  Wed Feb  9 07:23:07 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Feb 2022 07:23:07 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination
In-Reply-To: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
Message-ID: <1IHug8oWt1wTrr_WxgfSoDjxov5QemilqkREHKPjEKI=.09b2f894-6988-47d0-b668-f5da0a3af2ae@github.com>

On Wed, 2 Feb 2022 10:38:11 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The loop exit condition of the test method:
> 
> if (i == stop) {
>     break;
> }
> 
> requires insertion of a loop limit predicate when the loop is turned
> into a counted loop. stop is a LoadI. Next:
> 
> array[stop - i + j] = 0;
> 
> is transformed to:
> 
> array[stop - i] = 0;
> 
> and the range check for that array access becomes candidate for
> predication in a subsequent loop opts pass. stop has control just
> above the loop limit check when that happens (because it is assigned
> control as late as possible). But the loop predicate for the bound
> check needs to be above the loop limit check and that causes the
> assert failure.
> 
> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
> to assign control to nodes above predicates so this sort of issues
> doesn't occur. But it only applies to node initially on the entry
> projection right above the loop head. The fix I propose is to remove
> that restriction.
> 
> That logic was added by JDK-8203197 and looking back at this change I
> noticed I replaced some existing logic with the current logic but,
> while the 2 overlap, the current logic is not guaranteed to always
> cover some cases handled by the old logic. So I resurrected that old
> logic here.
> 
> Finally, when running tests, I hit failures because Opaque nodes for
> skeleton predicates can now end up above a predicate that is split
> thru phi. That causes the Opaque nodes to be split up and breaks
> pattern matching. I'm actually not sure this issue is specific to the
> change here so I think it's best to treat it as a general issue and
> fix it by cloning the chain of nodes that lead to the Opaque node
> down.

I executed some testing and hit the following failure with the `serviceability/sa/ClhsdbCDS*` tests (`-XX:+UseParallelGC -XX:+UseNUMA`:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fc8d7407dcf, pid=18320, tid=18366
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x135adcf]  PhaseIdealLoop::get_ctrl(Node*)+0x4f

Current CompileTask:
C2:   1131  710       4       sun.jvm.hotspot.oops.Symbol::asByteArray (34 bytes)

Stack: [0x00007fc8aacee000,0x00007fc8aadef000],  sp=0x00007fc8aade8650,  free space=1001k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x135adcf]  PhaseIdealLoop::get_ctrl(Node*)+0x4f
V  [libjvm.so+0x17ed176]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0x2f6
V  [libjvm.so+0x17ecf4a]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0xca
V  [libjvm.so+0x17ecf4a]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0xca
V  [libjvm.so+0x17ecf4a]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0xca
V  [libjvm.so+0x17f26ed]  PhaseIdealLoop::do_split_if(Node*, RegionNode**, RegionNode**)+0x77d
V  [libjvm.so+0x13b2651]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x201
V  [libjvm.so+0x13a482b]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x12fb
V  [libjvm.so+0xa9c88a]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x28a
V  [libjvm.so+0xa99055]  Compile::Optimize()+0x1035
V  [libjvm.so+0xa9b295]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1575
V  [libjvm.so+0x8b1d99]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x669
V  [libjvm.so+0xaab178]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc88
V  [libjvm.so+0xaabf58]  CompileBroker::compiler_thread_loop()+0x668
V  [libjvm.so+0x193711a]  JavaThread::thread_main_inner()+0x25a
V  [libjvm.so+0x193f460]  Thread::call_run()+0x100
V  [libjvm.so+0x1621fb4]  thread_native_entry(Thread*)+0x104



# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8c892ad8b, pid=232, tid=41068
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# V  [jvm.dll+0xcbad8b]  PhaseIdealLoop::split_up+0x203b

Current CompileTask:
C2:   1167  562       4       sun.jvm.hotspot.debugger.DebuggerBase::readCInteger (295 bytes)

Stack: [0x000000d711500000,0x000000d711600000],  sp=0x000000d7115f9f70,  free space=999k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xcbad8b]  PhaseIdealLoop::split_up+0x203b  (split_if.cpp:271)
V  [jvm.dll+0xcb8ec4]  PhaseIdealLoop::split_up+0x174  (split_if.cpp:77)
V  [jvm.dll+0xcb8ec4]  PhaseIdealLoop::split_up+0x174  (split_if.cpp:77)
V  [jvm.dll+0xcb8ec4]  PhaseIdealLoop::split_up+0x174  (split_if.cpp:77)
V  [jvm.dll+0xcb6776]  PhaseIdealLoop::do_split_if+0x346  (split_if.cpp:498)
V  [jvm.dll+0xa5f851]  PhaseIdealLoop::split_if_with_blocks+0x1a1  (loopopts.cpp:1812)
V  [jvm.dll+0xa32ec8]  PhaseIdealLoop::build_and_optimize+0xff8  (loopnode.cpp:4366)
V  [jvm.dll+0x4f3d45]  Compile::Optimize+0x1145  (compile.cpp:2266)
V  [jvm.dll+0x4f0b87]  Compile::Compile+0x14b7  (compile.cpp:810)
V  [jvm.dll+0x4138a5]  C2Compiler::compile_method+0x145  (c2compiler.cpp:115)
V  [jvm.dll+0x50a216]  CompileBroker::invoke_compiler_on_method+0x756  (compileBroker.cpp:2293)
V  [jvm.dll+0x507a06]  CompileBroker::compiler_thread_loop+0x276  (compileBroker.cpp:1967)
V  [jvm.dll+0xd8d317]  JavaThread::thread_main_inner+0x297  (thread.cpp:1296)
V  [jvm.dll+0xd82e64]  Thread::call_run+0x1b4  (thread.cpp:361)
V  [jvm.dll+0xbcb449]  thread_native_entry+0xb9  (os_windows.cpp:544)
C  [ucrtbase.dll+0x1fb80]  _o__realloc_base+0x60
C  [KERNEL32.DLL+0x84d4]  BaseThreadInitThunk+0x14
C  [ntdll.dll+0x51791]  RtlUserThreadStart+0x21
``` 

And with `tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java` on macosx-aarch64:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0xa) at pc=0x000000010295de98, pid=78752, tid=23555
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (build 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x89de98]  _ZN14PhaseIdealLoop11do_split_ifEP4NodePP10RegionNodeS4_+0x650

Current CompileTask:
C2: 104626 23310       4       java.net.URI$Parser::parseHierarchical (178 bytes)

Stack: [0x00000001709bc000,0x0000000170bbf000],  sp=0x0000000170bbaad0,  free space=2042k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x89de98]  _ZN14PhaseIdealLoop11do_split_ifEP4NodePP10RegionNodeS4_+0x650
V  [libjvm.dylib+0x70df7c]  _ZN14PhaseIdealLoop20split_if_with_blocksER9VectorSetR10Node_Stack+0x11c
V  [libjvm.dylib+0x700ec0]  _ZN14PhaseIdealLoop18build_and_optimizeE12LoopOptsMode+0x838
V  [libjvm.dylib+0x2ca9c4]  _ZN14PhaseIdealLoop8optimizeER12PhaseIterGVN12LoopOptsMode+0x108
V  [libjvm.dylib+0x2cac24]  _ZN7Compile14optimize_loopsER12PhaseIterGVN12LoopOptsMode+0xb0
V  [libjvm.dylib+0x2c7734]  _ZN7Compile8OptimizeEv+0xef4
V  [libjvm.dylib+0x2c59fc]  _ZN7CompileC2EP5ciEnvP8ciMethodi7OptionsP12DirectiveSet+0xaa0
V  [libjvm.dylib+0x23438c]  _ZN10C2Compiler14compile_methodEP5ciEnvP8ciMethodibP12DirectiveSet+0x134
V  [libjvm.dylib+0x2d67e4]  _ZN13CompileBroker25invoke_compiler_on_methodEP11CompileTask+0x3d4
V  [libjvm.dylib+0x2d6378]  _ZN13CompileBroker20compiler_thread_loopEv+0x440
V  [libjvm.dylib+0x93bea8]  _ZN10JavaThread17thread_main_innerEv+0xa0
V  [libjvm.dylib+0x93a908]  _ZN6Thread8call_runEv+0xe0
V  [libjvm.dylib+0x7f19e8]  _ZL19thread_native_entryP6Thread+0x158
C  [libsystem_pthread.dylib+0x7240]  _pthread_start+0x94

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

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

From thartmann at openjdk.java.net  Wed Feb  9 07:29:09 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Feb 2022 07:29:09 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations
In-Reply-To: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
Message-ID: <KDDBA0I_WdpQU3_foBPNZwIXcldlxJEbIaYf2u9ryns=.bcd9b234-c663-4b60-8546-921bc3a65bae@github.com>

On Fri, 4 Feb 2022 14:41:55 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The bytecode of the 2 methods of the benchmark is structured
> differently: loopsWithSharedLocal(), the slowest one, has multiple
> backedges with a single head while loopsWithScopedLocal() has a single
> backedge and all the paths in the loop body merge before the
> backedge. loopsWithSharedLocal() has its head cloned which results in
> a 2 loops loop nest.
> 
> loopsWithSharedLocal() is slow when 2 of the backedges are most
> commonly taken with one taken only 3 times as often as the other
> one. So a thread executing that code only runs the inner loop for a
> few iterations before exiting it and executing the outer loop. I think
> what happens is that any time the inner loop is entered, some
> predicates are executed and the overhead of the setup of loop strip
> mining (if it's enabled) has to be paid. Also, if iteration
> splitting/unrolling was applied, the main loop is likely never
> executed and all time is spent in the pre/post loops where potentially
> some range checks remain.
> 
> The fix I propose is that ciTypeFlow, when it clone heads, not only
> rewires the most frequent loop but also all this other frequent loops
> that share the same head. loopsWithSharedLocal() and
> loopsWithScopedLocal() are then fairly similar once c2 parses them.
> 
> Without the patch I measure:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
> 
> with it:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
> 
> But this patch also causes a regression when running one of the
> benchmarks added by 8278518. From:
> 
> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
> 
> to:
> 
> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
> 
> The hot method of this benchmark used to be compiled with 2 loops, the
> inner one a counted loop. With the patch, it's now compiled with a
> single one which can't be converted into a counted loop because the
> loop variable is incremented by a different amount along the 2 paths
> in the loop body. What I propose to fix this is to add a new loop
> transformation that detects that, because of a merge point, a loop
> can't be turned into a counted loop and transforms it into 2
> loops. The benchmark performs better with this:
> 
> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
> 
> Not quite on par with the previous score but AFAICT this is due to
> code generation not being as good (the loop head can't be aligned in
> particular).
> 
> In short, I propose:
> 
> - changing ciTypeFlow so that, when it pays off, a loop with
> multiple backedges is compiled as a single loop with a merge point in
> the loop body
> 
> - adding a new loop transformation so that, when it pays off, a loop
> with a merge point in the loop body is converted into a 2 loops loop
> nest, essentially the opposite transformation.

I executed some testing and I'm seeing massive (> 700) failures due to the `negative trip count?` assert. For example, `compiler/c2/Test6603011.java` with `-server -Xmixed`:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (.../open/src/hotspot/share/opto/loopPredicate.cpp:1447), pid=11690, tid=11708
#  assert(!follow_branches || loop_trip_cnt >= 0) failed: negative trip count?
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-02-08-1039057.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-02-08-1039057.tobias.hartmann.jdk2, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x135c470]  PhaseIdealLoop::loop_predication_impl(IdealLoopTree*) [clone .part.0]+0xf70

Current CompileTask:
C2:  10125 4309    b  4       jdk.internal.org.objectweb.asm.ClassReader::readUtf (161 bytes)

Stack: [0x00007f83f4c3a000,0x00007f83f4d3b000],  sp=0x00007f83f4d34c60,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x135c470]  PhaseIdealLoop::loop_predication_impl(IdealLoopTree*) [clone .part.0]+0xf70
V  [libjvm.so+0x135c739]  IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x109
V  [libjvm.so+0x13a4b47]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x1327
V  [libjvm.so+0xa9cbea]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x28a
V  [libjvm.so+0xa99513]  Compile::Optimize()+0x1193
V  [libjvm.so+0xa9b5f5]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1575
V  [libjvm.so+0x8b1e29]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x669
V  [libjvm.so+0xaab4d8]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc88
V  [libjvm.so+0xaac2b8]  CompileBroker::compiler_thread_loop()+0x668
V  [libjvm.so+0x19382da]  JavaThread::thread_main_inner()+0x25a
V  [libjvm.so+0x1940620]  Thread::call_run()+0x100
V  [libjvm.so+0x1623cd4]  thread_native_entry(Thread*)+0x104

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

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

From thartmann at openjdk.java.net  Wed Feb  9 07:44:08 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Feb 2022 07:44:08 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v5]
In-Reply-To: <tQI4zYKoYVc1Izd9libv95_22lImNIyB6hHMsR93Igk=.80fd7bed-2f90-476f-a9ec-2698cc9c2abb@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
 <tQI4zYKoYVc1Izd9libv95_22lImNIyB6hHMsR93Igk=.80fd7bed-2f90-476f-a9ec-2698cc9c2abb@github.com>
Message-ID: <DpjmQlQbMVZoWPmsAuutzQc5HBeVARL5Uv0JsxhoPVc=.aca304be-e3a6-4a0a-a85a-8c3549f787b2@github.com>

On Wed, 26 Jan 2022 16:04:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> 8259609 (C2: optimize long range checks in long counted loops) only
>> covered the case of a counted loop with a positive stride and a range
>> check with a positive scale. This change generalizes the long range
>> check transformation to all 4 combinations of stride and scale signs.
>> 
>> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
>> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
>> generalizing the formulas to other cases.
>> 
>> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
>> required for the case of negative scale in an int loop. The range
>> check then has the shape:
>> 
>> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
>> 
>> with ConI, the zero constant.
>> 
>> This change also addresses this comment from John:
>> 
>> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
>> 
>> as part of 8276116 (C2: optimize long range checks in int counted loops)
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Executed some quick testing and the build failed:

[2022-02-09T07:35:21,066Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2574:47: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
[2022-02-09T07:35:21,066Z]     if (is_iv(exp->in(which = 1), iv, exp_bt) && exp->in(2)->is_Con() ||
[2022-02-09T07:35:21,066Z]         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ ~~
[2022-02-09T07:35:21,066Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2574:47: note: place parentheses around the '&&' expression to silence this warning
[2022-02-09T07:35:21,066Z]     if (is_iv(exp->in(which = 1), iv, exp_bt) && exp->in(2)->is_Con() ||
[2022-02-09T07:35:21,067Z]                                               ^
[2022-02-09T07:35:21,067Z]         (                                                            )
[2022-02-09T07:35:21,067Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2575:47: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
[2022-02-09T07:35:21,067Z]         is_iv(exp->in(which = 2), iv, exp_bt) && exp->in(1)->is_Con()) {
[2022-02-09T07:35:21,067Z]         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
[2022-02-09T07:35:21,067Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2575:47: note: place parentheses around the '&&' expression to silence this warning
[2022-02-09T07:35:21,067Z]         is_iv(exp->in(which = 2), iv, exp_bt) && exp->in(1)->is_Con()) {
[2022-02-09T07:35:21,067Z]                                               ^

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

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

From eliu at openjdk.java.net  Wed Feb  9 08:12:04 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 9 Feb 2022 08:12:04 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <PK4lPB-DX74k8eDkWHCNcw5ZvGS3u-X527sbJVp86V8=.f45e95ae-8a65-4202-ad2e-3ed276fa0b25@github.com>

On Mon, 7 Feb 2022 20:08:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

src/hotspot/cpu/x86/matcher_x86.hpp line 194:

> 192:     }
> 193:   }
> 194: 

Could you explain more about the meaning of "cost" here? Should it be the actual count of instruction or latency?

src/hotspot/share/opto/loopTransform.cpp line 975:

> 973:       case Op_PopCountVI:
> 974:       case Op_PopCountVL: {
> 975:         const TypeVect * vt = n->bottom_type()->is_vect();

style issue: const TypeVect* vt

src/hotspot/share/opto/loopTransform.cpp line 976:

> 974:       case Op_PopCountVL: {
> 975:         const TypeVect * vt = n->bottom_type()->is_vect();
> 976:         body_size += Matcher::vector_op_cost(n->Opcode(), vt->element_basic_type(), vt->length());

For other platforms, I think `vector_op_cost` should be better to return 0 at this moment.

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

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

From duke at openjdk.java.net  Wed Feb  9 09:30:36 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 9 Feb 2022 09:30:36 GMT
Subject: RFR: 8252496: C2: Useless code in MergeMemNode::Ideal
Message-ID: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>

This code was there since `initial load`. At that point there was other code that still depended on this code.
The other code was removed [here](https://github.com/eme64/jdk/commit/79ad5512cfe5c4ef7d0b61616f3763c62d3427a5). This was the change set for [JDK-8243670](https://bugs.openjdk.java.net/browse/JDK-8243670).
Our code was left behind.

I removed the useless code, and ran tests to verify that nothing broke due to side-effects.

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

Commit messages:
 - 8252496: C2: Useless code in MergeMemNode::Ideal

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

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

From thartmann at openjdk.java.net  Wed Feb  9 09:37:09 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Feb 2022 09:37:09 GMT
Subject: RFR: 8252496: C2: Useless code in MergeMemNode::Ideal
In-Reply-To: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
References: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
Message-ID: <3-T9zJfHDhFXtHOfFxB0J3SHKjXxuQJz999-ieP0ANE=.91167168-40ce-4ba4-b470-4af332e313bc@github.com>

On Wed, 9 Feb 2022 09:23:50 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> This code was there since `initial load`. At that point there was other code that still depended on this code.
> The other code was removed [here](https://github.com/eme64/jdk/commit/79ad5512cfe5c4ef7d0b61616f3763c62d3427a5). This was the change set for [JDK-8243670](https://bugs.openjdk.java.net/browse/JDK-8243670).
> Our code was left behind.
> 
> I removed the useless code, and ran tests to verify that nothing broke due to side-effects.

Looks good and trivial.

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

Marked as reviewed by thartmann (Reviewer).

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

From chagedorn at openjdk.java.net  Wed Feb  9 09:57:07 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 9 Feb 2022 09:57:07 GMT
Subject: RFR: 8252496: C2: Useless code in MergeMemNode::Ideal
In-Reply-To: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
References: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
Message-ID: <XNBg70lx1r_wc0WTlfM3bGvl8koXPq704j0-tSfnX-A=.33193e94-4f5e-4c94-b09b-69909b5f52e3@github.com>

On Wed, 9 Feb 2022 09:23:50 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> This code was there since `initial load`. At that point there was other code that still depended on this code.
> The other code was removed [here](https://github.com/eme64/jdk/commit/79ad5512cfe5c4ef7d0b61616f3763c62d3427a5). This was the change set for [JDK-8243670](https://bugs.openjdk.java.net/browse/JDK-8243670).
> Our code was left behind.
> 
> I removed the useless code, and ran tests to verify that nothing broke due to side-effects.

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From roland at openjdk.java.net  Wed Feb  9 10:22:13 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Feb 2022 10:22:13 GMT
Subject: RFR: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <LrHv4CbdvlRR9Cz3vmB6tyv2wQax2OIWZ8gyyu8z8rA=.798db242-6f7f-46c2-936c-4e36f03bb63a@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
 <LrHv4CbdvlRR9Cz3vmB6tyv2wQax2OIWZ8gyyu8z8rA=.798db242-6f7f-46c2-936c-4e36f03bb63a@github.com>
Message-ID: <6O8WXaP79Iy19vjYRgQhI1kH2KWGqU3IOzE9z5g7VO8=.a85b002f-7d07-48c9-a7b0-88631a290306@github.com>

On Tue, 8 Feb 2022 18:26:12 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> That came up in previous:
>> 
>> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321
>
> Yes, this is exactly what I wanted.

@vnkozlov thanks for looking at this.

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

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

From roland at openjdk.java.net  Wed Feb  9 10:22:14 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Feb 2022 10:22:14 GMT
Subject: Integrated: 8262721: Add Tests to verify single iteration loops are
 properly optimized
In-Reply-To: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
References: <V4rhYhi6K8G82F7M1IKhcAW1OhXYiV67pRvIaTTQvHo=.11c6735d-1185-418c-8fbc-798a6cabaa53@github.com>
Message-ID: <sG08gWw8xKUy-SE7xBAmYPfO8PTjW452D0EA5shL7IY=.db1963e4-57c3-4d4a-b7a3-1cd7001049fa@github.com>

On Mon, 7 Feb 2022 13:49:27 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> That came up in previous:
> 
> https://github.com/openjdk/jdk/pull/2529#discussion_r583054321

This pull request has now been integrated.

Changeset: 69e390a0
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69e390a0e86f82eaa7bcdbc3ef509734dbe3b22f
Stats:     139 lines in 1 file changed: 139 ins; 0 del; 0 mod

8262721: Add Tests to verify single iteration loops are properly optimized

Reviewed-by: neliasso, chagedorn, kvn

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

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

From roland at openjdk.java.net  Wed Feb  9 10:23:46 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Feb 2022 10:23:46 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v2]
In-Reply-To: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
Message-ID: <EPhDMRb-8V_7XtzGiD5-xNUCyMubRPCOrDGhw6Lyy_U=.216476ae-e92e-4642-bb7a-baf8d779f0bf@github.com>

> The bytecode of the 2 methods of the benchmark is structured
> differently: loopsWithSharedLocal(), the slowest one, has multiple
> backedges with a single head while loopsWithScopedLocal() has a single
> backedge and all the paths in the loop body merge before the
> backedge. loopsWithSharedLocal() has its head cloned which results in
> a 2 loops loop nest.
> 
> loopsWithSharedLocal() is slow when 2 of the backedges are most
> commonly taken with one taken only 3 times as often as the other
> one. So a thread executing that code only runs the inner loop for a
> few iterations before exiting it and executing the outer loop. I think
> what happens is that any time the inner loop is entered, some
> predicates are executed and the overhead of the setup of loop strip
> mining (if it's enabled) has to be paid. Also, if iteration
> splitting/unrolling was applied, the main loop is likely never
> executed and all time is spent in the pre/post loops where potentially
> some range checks remain.
> 
> The fix I propose is that ciTypeFlow, when it clone heads, not only
> rewires the most frequent loop but also all this other frequent loops
> that share the same head. loopsWithSharedLocal() and
> loopsWithScopedLocal() are then fairly similar once c2 parses them.
> 
> Without the patch I measure:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
> 
> with it:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
> 
> But this patch also causes a regression when running one of the
> benchmarks added by 8278518. From:
> 
> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
> 
> to:
> 
> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
> 
> The hot method of this benchmark used to be compiled with 2 loops, the
> inner one a counted loop. With the patch, it's now compiled with a
> single one which can't be converted into a counted loop because the
> loop variable is incremented by a different amount along the 2 paths
> in the loop body. What I propose to fix this is to add a new loop
> transformation that detects that, because of a merge point, a loop
> can't be turned into a counted loop and transforms it into 2
> loops. The benchmark performs better with this:
> 
> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
> 
> Not quite on par with the previous score but AFAICT this is due to
> code generation not being as good (the loop head can't be aligned in
> particular).
> 
> In short, I propose:
> 
> - changing ciTypeFlow so that, when it pays off, a loop with
> multiple backedges is compiled as a single loop with a merge point in
> the loop body
> 
> - adding a new loop transformation so that, when it pays off, a loop
> with a merge point in the loop body is converted into a 2 loops loop
> nest, essentially the opposite transformation.

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:

 - fix
 - Merge branch 'master' into JDK-8279888
 - whitespaces
 - fix & test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7352/files
  - new: https://git.openjdk.java.net/jdk/pull/7352/files/ab550d16..cabd514b

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

  Stats: 2392 lines in 76 files changed: 1623 ins; 524 del; 245 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7352/head:pull/7352

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

From roland at openjdk.java.net  Wed Feb  9 10:23:49 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Feb 2022 10:23:49 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations
In-Reply-To: <KDDBA0I_WdpQU3_foBPNZwIXcldlxJEbIaYf2u9ryns=.bcd9b234-c663-4b60-8546-921bc3a65bae@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <KDDBA0I_WdpQU3_foBPNZwIXcldlxJEbIaYf2u9ryns=.bcd9b234-c663-4b60-8546-921bc3a65bae@github.com>
Message-ID: <YArDq9909GXdTCJzuD08w2WqPO6FFKsub5_N5g78wzY=.f449f805-705b-4489-98b0-55cdbda284e3@github.com>

On Wed, 9 Feb 2022 07:25:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I executed some testing and I'm seeing massive (> 700) failures due to the `negative trip count?` assert. For example, `compiler/c2/Test6603011.java` with `-server -Xmixed`:

Thanks for running tests. A last minute tweak that's not as harmless as I thought. It should be fixed now.

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

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

From stuefe at openjdk.java.net  Wed Feb  9 11:14:26 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 9 Feb 2022 11:14:26 GMT
Subject: RFR: JDK-8281522: Rename ADLC classes which have the same name as
 hotspot variants
Message-ID: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>

After some prior offlist discussions with Oracle staff, I propose to change the names of some of the adlc classes and functions to avoid name clashes with their hotspot counterparts. This has bugged me for a while since my IDE gets often confused about this when working on hotspot arena code.

This patch prefixes "Arena", "Chunk", "CHeapObj" and "AllStatic", "AllocateHeap", "ReallocateHeap" with "Adl...". The replacement is purely mechanical, no functional change happens here.

Thanks, Thomas

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

Commit messages:
 - rename files
 - Fix indentation
 - Fix Copyrights
 - Rename Arena
 - Rename Chunk
 - Rename AllStatic
 - rename CHeapObj
 - rename AllocateHeap, ReAllocateHeap

Changes: https://git.openjdk.java.net/jdk/pull/7400/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7400&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281522
  Stats: 726 lines in 13 files changed: 346 ins; 346 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7400/head:pull/7400

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

From vlivanov at openjdk.java.net  Wed Feb  9 12:35:09 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 9 Feb 2022 12:35:09 GMT
Subject: RFR: 8252496: C2: Useless code in MergeMemNode::Ideal
In-Reply-To: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
References: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
Message-ID: <4bvzI3A2fjT2YuwOc4kQDJ_EI4BRgo0pUYSGUnt5JV0=.2f630318-1a32-4a29-8e65-a7a05046da03@github.com>

On Wed, 9 Feb 2022 09:23:50 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> This code was there since `initial load`. At that point there was other code that still depended on this code.
> The other code was removed [here](https://github.com/eme64/jdk/commit/79ad5512cfe5c4ef7d0b61616f3763c62d3427a5). This was the change set for [JDK-8243670](https://bugs.openjdk.java.net/browse/JDK-8243670).
> Our code was left behind.
> 
> I removed the useless code, and ran tests to verify that nothing broke due to side-effects.

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

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

From roland at openjdk.java.net  Wed Feb  9 12:55:39 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Feb 2022 12:55:39 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination [v2]
In-Reply-To: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
Message-ID: <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>

> The loop exit condition of the test method:
> 
> if (i == stop) {
>     break;
> }
> 
> requires insertion of a loop limit predicate when the loop is turned
> into a counted loop. stop is a LoadI. Next:
> 
> array[stop - i + j] = 0;
> 
> is transformed to:
> 
> array[stop - i] = 0;
> 
> and the range check for that array access becomes candidate for
> predication in a subsequent loop opts pass. stop has control just
> above the loop limit check when that happens (because it is assigned
> control as late as possible). But the loop predicate for the bound
> check needs to be above the loop limit check and that causes the
> assert failure.
> 
> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
> to assign control to nodes above predicates so this sort of issues
> doesn't occur. But it only applies to node initially on the entry
> projection right above the loop head. The fix I propose is to remove
> that restriction.
> 
> That logic was added by JDK-8203197 and looking back at this change I
> noticed I replaced some existing logic with the current logic but,
> while the 2 overlap, the current logic is not guaranteed to always
> cover some cases handled by the old logic. So I resurrected that old
> logic here.
> 
> Finally, when running tests, I hit failures because Opaque nodes for
> skeleton predicates can now end up above a predicate that is split
> thru phi. That causes the Opaque nodes to be split up and breaks
> pattern matching. I'm actually not sure this issue is specific to the
> change here so I think it's best to treat it as a general issue and
> fix it by cloning the chain of nodes that lead to the Opaque node
> down.

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 three additional commits since the last revision:

 - fix
 - Merge branch 'master' into JDK-8280799
 - fix & test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7319/files
  - new: https://git.openjdk.java.net/jdk/pull/7319/files/7b606869..accc338e

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

  Stats: 9465 lines in 353 files changed: 6414 ins; 1819 del; 1232 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7319.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7319/head:pull/7319

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

From roland at openjdk.java.net  Wed Feb  9 12:55:40 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Feb 2022 12:55:40 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination
In-Reply-To: <1IHug8oWt1wTrr_WxgfSoDjxov5QemilqkREHKPjEKI=.09b2f894-6988-47d0-b668-f5da0a3af2ae@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
 <1IHug8oWt1wTrr_WxgfSoDjxov5QemilqkREHKPjEKI=.09b2f894-6988-47d0-b668-f5da0a3af2ae@github.com>
Message-ID: <54qVW7s6DMXV9tfeW42rOosRGFUwWNuWgk5rfPD-WqQ=.ba50728f-360c-48dd-90a8-7dffa68bcbf2@github.com>

On Wed, 9 Feb 2022 07:19:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The loop exit condition of the test method:
>> 
>> if (i == stop) {
>>     break;
>> }
>> 
>> requires insertion of a loop limit predicate when the loop is turned
>> into a counted loop. stop is a LoadI. Next:
>> 
>> array[stop - i + j] = 0;
>> 
>> is transformed to:
>> 
>> array[stop - i] = 0;
>> 
>> and the range check for that array access becomes candidate for
>> predication in a subsequent loop opts pass. stop has control just
>> above the loop limit check when that happens (because it is assigned
>> control as late as possible). But the loop predicate for the bound
>> check needs to be above the loop limit check and that causes the
>> assert failure.
>> 
>> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
>> to assign control to nodes above predicates so this sort of issues
>> doesn't occur. But it only applies to node initially on the entry
>> projection right above the loop head. The fix I propose is to remove
>> that restriction.
>> 
>> That logic was added by JDK-8203197 and looking back at this change I
>> noticed I replaced some existing logic with the current logic but,
>> while the 2 overlap, the current logic is not guaranteed to always
>> cover some cases handled by the old logic. So I resurrected that old
>> logic here.
>> 
>> Finally, when running tests, I hit failures because Opaque nodes for
>> skeleton predicates can now end up above a predicate that is split
>> thru phi. That causes the Opaque nodes to be split up and breaks
>> pattern matching. I'm actually not sure this issue is specific to the
>> change here so I think it's best to treat it as a general issue and
>> fix it by cloning the chain of nodes that lead to the Opaque node
>> down.
>
> I executed some testing and hit the following failure with the `serviceability/sa/ClhsdbCDS*` tests (`-XX:+UseParallelGC -XX:+UseNUMA`:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGSEGV (0xb) at pc=0x00007fc8d7407dcf, pid=18320, tid=18366
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x135adcf]  PhaseIdealLoop::get_ctrl(Node*)+0x4f
> 
> Current CompileTask:
> C2:   1131  710       4       sun.jvm.hotspot.oops.Symbol::asByteArray (34 bytes)
> 
> Stack: [0x00007fc8aacee000,0x00007fc8aadef000],  sp=0x00007fc8aade8650,  free space=1001k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x135adcf]  PhaseIdealLoop::get_ctrl(Node*)+0x4f
> V  [libjvm.so+0x17ed176]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0x2f6
> V  [libjvm.so+0x17ecf4a]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0xca
> V  [libjvm.so+0x17ecf4a]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0xca
> V  [libjvm.so+0x17ecf4a]  PhaseIdealLoop::split_up(Node*, Node*, Node*) [clone .part.0]+0xca
> V  [libjvm.so+0x17f26ed]  PhaseIdealLoop::do_split_if(Node*, RegionNode**, RegionNode**)+0x77d
> V  [libjvm.so+0x13b2651]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x201
> V  [libjvm.so+0x13a482b]  PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0x12fb
> V  [libjvm.so+0xa9c88a]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x28a
> V  [libjvm.so+0xa99055]  Compile::Optimize()+0x1035
> V  [libjvm.so+0xa9b295]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1575
> V  [libjvm.so+0x8b1d99]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x669
> V  [libjvm.so+0xaab178]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xc88
> V  [libjvm.so+0xaabf58]  CompileBroker::compiler_thread_loop()+0x668
> V  [libjvm.so+0x193711a]  JavaThread::thread_main_inner()+0x25a
> V  [libjvm.so+0x193f460]  Thread::call_run()+0x100
> V  [libjvm.so+0x1621fb4]  thread_native_entry(Thread*)+0x104
> 
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8c892ad8b, pid=232, tid=41068
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
> # Problematic frame:
> # V  [jvm.dll+0xcbad8b]  PhaseIdealLoop::split_up+0x203b
> 
> Current CompileTask:
> C2:   1167  562       4       sun.jvm.hotspot.debugger.DebuggerBase::readCInteger (295 bytes)
> 
> Stack: [0x000000d711500000,0x000000d711600000],  sp=0x000000d7115f9f70,  free space=999k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [jvm.dll+0xcbad8b]  PhaseIdealLoop::split_up+0x203b  (split_if.cpp:271)
> V  [jvm.dll+0xcb8ec4]  PhaseIdealLoop::split_up+0x174  (split_if.cpp:77)
> V  [jvm.dll+0xcb8ec4]  PhaseIdealLoop::split_up+0x174  (split_if.cpp:77)
> V  [jvm.dll+0xcb8ec4]  PhaseIdealLoop::split_up+0x174  (split_if.cpp:77)
> V  [jvm.dll+0xcb6776]  PhaseIdealLoop::do_split_if+0x346  (split_if.cpp:498)
> V  [jvm.dll+0xa5f851]  PhaseIdealLoop::split_if_with_blocks+0x1a1  (loopopts.cpp:1812)
> V  [jvm.dll+0xa32ec8]  PhaseIdealLoop::build_and_optimize+0xff8  (loopnode.cpp:4366)
> V  [jvm.dll+0x4f3d45]  Compile::Optimize+0x1145  (compile.cpp:2266)
> V  [jvm.dll+0x4f0b87]  Compile::Compile+0x14b7  (compile.cpp:810)
> V  [jvm.dll+0x4138a5]  C2Compiler::compile_method+0x145  (c2compiler.cpp:115)
> V  [jvm.dll+0x50a216]  CompileBroker::invoke_compiler_on_method+0x756  (compileBroker.cpp:2293)
> V  [jvm.dll+0x507a06]  CompileBroker::compiler_thread_loop+0x276  (compileBroker.cpp:1967)
> V  [jvm.dll+0xd8d317]  JavaThread::thread_main_inner+0x297  (thread.cpp:1296)
> V  [jvm.dll+0xd82e64]  Thread::call_run+0x1b4  (thread.cpp:361)
> V  [jvm.dll+0xbcb449]  thread_native_entry+0xb9  (os_windows.cpp:544)
> C  [ucrtbase.dll+0x1fb80]  _o__realloc_base+0x60
> C  [KERNEL32.DLL+0x84d4]  BaseThreadInitThunk+0x14
> C  [ntdll.dll+0x51791]  RtlUserThreadStart+0x21
> ``` 
> 
> And with `tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java` on macosx-aarch64:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  SIGBUS (0xa) at pc=0x000000010295de98, pid=78752, tid=23555
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (build 19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (19-internal+0-2022-02-08-1034049.tobias.hartmann.jdk2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
> # Problematic frame:
> # V  [libjvm.dylib+0x89de98]  _ZN14PhaseIdealLoop11do_split_ifEP4NodePP10RegionNodeS4_+0x650
> 
> Current CompileTask:
> C2: 104626 23310       4       java.net.URI$Parser::parseHierarchical (178 bytes)
> 
> Stack: [0x00000001709bc000,0x0000000170bbf000],  sp=0x0000000170bbaad0,  free space=2042k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.dylib+0x89de98]  _ZN14PhaseIdealLoop11do_split_ifEP4NodePP10RegionNodeS4_+0x650
> V  [libjvm.dylib+0x70df7c]  _ZN14PhaseIdealLoop20split_if_with_blocksER9VectorSetR10Node_Stack+0x11c
> V  [libjvm.dylib+0x700ec0]  _ZN14PhaseIdealLoop18build_and_optimizeE12LoopOptsMode+0x838
> V  [libjvm.dylib+0x2ca9c4]  _ZN14PhaseIdealLoop8optimizeER12PhaseIterGVN12LoopOptsMode+0x108
> V  [libjvm.dylib+0x2cac24]  _ZN7Compile14optimize_loopsER12PhaseIterGVN12LoopOptsMode+0xb0
> V  [libjvm.dylib+0x2c7734]  _ZN7Compile8OptimizeEv+0xef4
> V  [libjvm.dylib+0x2c59fc]  _ZN7CompileC2EP5ciEnvP8ciMethodi7OptionsP12DirectiveSet+0xaa0
> V  [libjvm.dylib+0x23438c]  _ZN10C2Compiler14compile_methodEP5ciEnvP8ciMethodibP12DirectiveSet+0x134
> V  [libjvm.dylib+0x2d67e4]  _ZN13CompileBroker25invoke_compiler_on_methodEP11CompileTask+0x3d4
> V  [libjvm.dylib+0x2d6378]  _ZN13CompileBroker20compiler_thread_loopEv+0x440
> V  [libjvm.dylib+0x93bea8]  _ZN10JavaThread17thread_main_innerEv+0xa0
> V  [libjvm.dylib+0x93a908]  _ZN6Thread8call_runEv+0xe0
> V  [libjvm.dylib+0x7f19e8]  _ZL19thread_native_entryP6Thread+0x158
> C  [libsystem_pthread.dylib+0x7240]  _pthread_start+0x94

@TobiHartmann thanks for running testing. I reproduced one of them (thanks for helping with that too) and fixed it. Would you mind running testing again?

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

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

From thartmann at openjdk.java.net  Wed Feb  9 13:41:11 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Feb 2022 13:41:11 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination [v2]
In-Reply-To: <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
 <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
Message-ID: <fFKdtdHR8iNm8K432ibJO-baeP0Qmh0V_pKzYtspxCI=.d8b55eb6-8333-4bd1-9f5c-cf105ee14113@github.com>

On Wed, 9 Feb 2022 12:55:39 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The loop exit condition of the test method:
>> 
>> if (i == stop) {
>>     break;
>> }
>> 
>> requires insertion of a loop limit predicate when the loop is turned
>> into a counted loop. stop is a LoadI. Next:
>> 
>> array[stop - i + j] = 0;
>> 
>> is transformed to:
>> 
>> array[stop - i] = 0;
>> 
>> and the range check for that array access becomes candidate for
>> predication in a subsequent loop opts pass. stop has control just
>> above the loop limit check when that happens (because it is assigned
>> control as late as possible). But the loop predicate for the bound
>> check needs to be above the loop limit check and that causes the
>> assert failure.
>> 
>> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
>> to assign control to nodes above predicates so this sort of issues
>> doesn't occur. But it only applies to node initially on the entry
>> projection right above the loop head. The fix I propose is to remove
>> that restriction.
>> 
>> That logic was added by JDK-8203197 and looking back at this change I
>> noticed I replaced some existing logic with the current logic but,
>> while the 2 overlap, the current logic is not guaranteed to always
>> cover some cases handled by the old logic. So I resurrected that old
>> logic here.
>> 
>> Finally, when running tests, I hit failures because Opaque nodes for
>> skeleton predicates can now end up above a predicate that is split
>> thru phi. That causes the Opaque nodes to be split up and breaks
>> pattern matching. I'm actually not sure this issue is specific to the
>> change here so I think it's best to treat it as a general issue and
>> fix it by cloning the chain of nodes that lead to the Opaque node
>> down.
>
> 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 three additional commits since the last revision:
> 
>  - fix
>  - Merge branch 'master' into JDK-8280799
>  - fix & test

Sure, I'll re-run testing and report back.

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

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

From vlivanov at openjdk.java.net  Wed Feb  9 14:00:23 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 9 Feb 2022 14:00:23 GMT
Subject: RFR: 8279822: CI: Constant pool entries in error state are not
 supported [v2]
In-Reply-To: <zkLhmbUpSp4oh5DjiboABU1c8tyLSL1WsDuHD7m_MlQ=.526f94a8-ae4e-4157-b2e2-26c53d9037ed@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
 <zkLhmbUpSp4oh5DjiboABU1c8tyLSL1WsDuHD7m_MlQ=.526f94a8-ae4e-4157-b2e2-26c53d9037ed@github.com>
Message-ID: <kaQK9AUUEzaqyhTOp5fxzs_Hv4mcxwBp0z3ja67bTPc=.f5f34998-138c-4956-b871-d4d0b3043121@github.com>

On Tue, 8 Feb 2022 14:55:53 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
>> 
>> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
>> 
>> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
>> 
>> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
>> 
>> Testing: hs-tier1 - hs-tier6
>
> 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 three additional commits since the last revision:
> 
>  - fatal -> assert
>  - Merge branch 'master' into 8279822.cpe_in_error
>  - Compiler support of CP entries in error state

Thanks for the reviews, Vladimir and Tobias.

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

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

From vlivanov at openjdk.java.net  Wed Feb  9 14:00:24 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 9 Feb 2022 14:00:24 GMT
Subject: Integrated: 8279822: CI: Constant pool entries in error state are not
 supported
In-Reply-To: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
References: <v8KruFyBtgr_d7YqYfdMbnLBJZrULJnvNhIZy3BZNxg=.c599f7f6-4bed-4a54-9078-c68881e4ef2a@github.com>
Message-ID: <dcQRg0EkNxNQNqhQm2Vi_Mw_JLTS5EAuuIOLq93sVK4=.322b2bda-3861-45be-a3a1-2edbdf3dfba5@github.com>

On Tue, 1 Feb 2022 19:09:31 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Compiler interface doesn't expect to see constant pool entries in error state and crashes when those are encountered.
> 
> JDK-8262377 improved handling of class constants in error state (`JVM_CONSTANT_UnresolvedClassInError`), but there were more cases left unnoticed (`CONSTANT_MethodHandle`, `CONSTANT_MethodType`, and `CONSTANT_Dynamic`). 
> 
> Proposed fix introduces proper support in CI of unresolved constants in error state and improves handling of such cases in C1/C2.
> 
> Also,  for `CONSTANT_MethodHandle` it turned out that some of `LinkageError`s don't transition relevant CP entry into error state (leaving it in unresolved state forever). The fix addresses it.
> 
> Testing: hs-tier1 - hs-tier6

This pull request has now been integrated.

Changeset: c5c8c064
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5c8c0644d9442846de15422285fffeb91c3e0a1
Stats:     451 lines in 10 files changed: 361 ins; 48 del; 42 mod

8279822: CI: Constant pool entries in error state are not supported

Reviewed-by: kvn, thartmann

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

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

From duke at openjdk.java.net  Wed Feb  9 15:55:37 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Wed, 9 Feb 2022 15:55:37 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
Message-ID: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>

Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.

The results of the microbenchmark are as follows:

Baseline:                                                                                                                                         
Benchmark                                Mode  Cnt  Score   Error  Units
SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op

Patch:
Benchmark                                Mode  Cnt  Score   Error  Units
SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op

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

Commit messages:
 - include ir test.
 - include the microbenchmark.
 - incude source that converts "(x|y)-(x^y)" into "x&y" in SubINode::Ideal and SubLNode::Ideal.

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

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

From chagedorn at openjdk.java.net  Wed Feb  9 15:55:38 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 9 Feb 2022 15:55:38 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
In-Reply-To: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
Message-ID: <9UreTvznSK5fTMv8laZeoN8AAQnLA7XnSAzoCd3emT0=.70fc5400-c839-4396-98a9-4673a3a094a6@github.com>

On Wed, 9 Feb 2022 00:44:08 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                                Mode  Cnt  Score   Error  Units
> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op
> 
> Patch:
> Benchmark                                Mode  Cnt  Score   Error  Units
> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op

A bug has been filed https://bugs.openjdk.java.net/browse/JDK-8281518.

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

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

From duke at openjdk.java.net  Wed Feb  9 16:04:48 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Wed, 9 Feb 2022 16:04:48 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
Message-ID: <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>

> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                                Mode  Cnt  Score   Error  Units
> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op
> 
> Patch:
> Benchmark                                Mode  Cnt  Score   Error  Units
> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  include bug id.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7395/files
  - new: https://git.openjdk.java.net/jdk/pull/7395/files/5e8fb4c7..5abc414f

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

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

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

From duke at openjdk.java.net  Wed Feb  9 16:04:49 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 9 Feb 2022 16:04:49 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
In-Reply-To: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
Message-ID: <43MoOGA4aicCK-48JnhtrxbjZRsqzCNEjKHzRsQWnm8=.04308bf2-16cb-4632-8cc2-7bff23d61399@github.com>

On Wed, 9 Feb 2022 00:44:08 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                                Mode  Cnt  Score   Error  Units
> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op
> 
> Patch:
> Benchmark                                Mode  Cnt  Score   Error  Units
> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op

There is a large number of transformations in this bitwise operation family such as `(x & y) | (x ^ y) == x | y`, `(x & y) ^ (x | y) == x ^ y`, `(x ^ y) ^ (x | y) == x & y` , etc and that does not even touch operations involving 3 operands. It seems both gcc and clang perform these 2-operand bitwise transformations so you could look at them to see if there is a more general way to achieve all combinations.
Thanks.

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

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

From duke at openjdk.java.net  Wed Feb  9 16:16:09 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 9 Feb 2022 16:16:09 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)"
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <JxLShkjYwqKV0ECiSmpz_R7Za5SNLRLvd6HNw-R0Fsk=.dad28be6-4cc5-4d1e-b51c-ed5d4a243c88@github.com>

On Tue, 8 Feb 2022 05:51:37 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

Since `~x == -1 - x` and these 2 operations' costs are essentially the same. It would be much easier if you just check whether the not result is used in an arithmetic operation and transform the former to the latter. The reverse is also true, if you find a `-1 - x` being fed into a bitwise just transform it to a `~x` then.
Thanks.

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

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

From adinn at openjdk.java.net  Wed Feb  9 16:24:11 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Wed, 9 Feb 2022 16:24:11 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
 <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
Message-ID: <xCRcEqb5RrGyuZIDp6ArOj9vUoLtdEeT0OV9aABkUzU=.ee7ac78d-317a-4113-8b4b-ee87f4fb15a4@github.com>

On Wed, 9 Feb 2022 16:04:48 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
>> 
>> The results of the microbenchmark are as follows:
>> 
>> Baseline:                                                                                                                                         
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op
>> 
>> Patch:
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include bug id.

I am not clear whether there is a justification for pushing this change. We are in danger of heading down the garden path looking for optimization fairies.

The above transformation adds extra case handling overhead to the AD matcher when processing a Subtract node which slows down compilation to a small degree for a relatively common case (most apps use subtraction). On the credit side it may generate a small speed up in generated code when the pattern is matched, the saving also depending on not just on seeing this pattern but also on how often the resulting generated code gets executed. So, we have a trade-off.

For any app there are probably going to be a lot of times where the compiler matches subtract nodes. There are probably going to be very few cases where this pattern will turn up -- even if you include cases where it happens through recursive reduction -- and even less where the resulting generated code gets executed many times. At some point we need to trade off the compiler overhead for all applications against the potential gains for some applications. The micro-benchmark only addresses one side of that trade-off.

I'd really like to see a better justification for including this patch and the related transformations suggested by @merykitty before proceeding.

n.b. the fact that gcc and clang do this is not really a good argument. In Java the trade-off is one runtime cost against another which is not the case for those compilers.

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

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

From duke at openjdk.java.net  Wed Feb  9 16:30:09 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 9 Feb 2022 16:30:09 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <lY7KSnA0fe0h652PJPYEzgs9SIqAA0ndwc4mOL_r2zs=.3158b3df-2498-4e89-8c85-a227164c095b@github.com>

On Mon, 7 Feb 2022 20:08:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Hi,

I think you can dump a lane into the constant table and use `vpbroadcasti128` for the look-up table.

Thanks.

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

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

From duke at openjdk.java.net  Wed Feb  9 16:38:11 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 9 Feb 2022 16:38:11 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
 <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
Message-ID: <u97sqQBMcY_fyRFQ-GUwdE6Os0BEjcXzD4Z3diVsjew=.4c1cec7d-8aa7-4f11-ac7d-f9f5415e40c7@github.com>

On Wed, 9 Feb 2022 16:04:48 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
>> 
>> The results of the microbenchmark are as follows:
>> 
>> Baseline:                                                                                                                                         
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op
>> 
>> Patch:
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include bug id.

Hi,

For clarification, my idea is to look at GCC and clang's codebases to see if there is a more general way to achieve every transformation elegantly instead of naively matching every combination, which may mitigate the cost for each additional transformation.

Thanks.

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

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

From aph at openjdk.java.net  Wed Feb  9 16:44:10 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 9 Feb 2022 16:44:10 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
 <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
Message-ID: <j2KDSloioL20L41-oqF-tzi7D0PyLC9P7Fm1bVQNUnc=.bd9ba509-f913-4c11-9353-350462c177f1@github.com>

On Wed, 9 Feb 2022 16:04:48 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Convert `(x|y)-(x^y)` into `x&y`, in `SubINode::Ideal` and `SubLNode::Ideal`.
>> 
>> The results of the microbenchmark are as follows:
>> 
>> Baseline:                                                                                                                                         
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.481 ? 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.482 ? 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.901 ? 0.007  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.894 ? 0.004  ns/op
>> 
>> Patch:
>> Benchmark                                Mode  Cnt  Score   Error  Units
>> SubIdeal_XOrY_Minus_XXorY_.baselineInt   avgt   60  0.480 ? 0.003  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.baselineLong  avgt   60  0.483 ? 0.005  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testInt       avgt   60  0.600 ? 0.004  ns/op
>> SubIdeal_XOrY_Minus_XXorY_.testLong      avgt   60  0.602 ? 0.004  ns/op
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include bug id.

> I am not clear whether there is a justification for pushing this change. We are in danger of heading down the garden path looking for optimization fairies.
> 
> n.b. the fact that gcc and clang do this is not really a good argument. In Java the trade-off is one runtime cost against another which is not the case for those compilers.

I agree. If we're dong this kind of optimization it makes little sense to do it piecemeal. Maybe, just maybe, there's some opportunity for some more general boolean simplification, but even then it's not clear how much of it is worth doing.

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

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

From jbhateja at openjdk.java.net  Wed Feb  9 17:38:19 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Feb 2022 17:38:19 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
In-Reply-To: <PK4lPB-DX74k8eDkWHCNcw5ZvGS3u-X527sbJVp86V8=.f45e95ae-8a65-4202-ad2e-3ed276fa0b25@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <PK4lPB-DX74k8eDkWHCNcw5ZvGS3u-X527sbJVp86V8=.f45e95ae-8a65-4202-ad2e-3ed276fa0b25@github.com>
Message-ID: <vQypLiPdBPQfrcVaYbiv_PLEpMMdeF3FqmZniD42EnI=.00a9ebb7-490e-42b2-bd36-071803300240@github.com>

On Wed, 9 Feb 2022 08:05:32 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> src/hotspot/share/opto/loopTransform.cpp line 976:
> 
>> 974:       case Op_PopCountVL: {
>> 975:         const TypeVect * vt = n->bottom_type()->is_vect();
>> 976:         body_size += Matcher::vector_op_cost(n->Opcode(), vt->element_basic_type(), vt->length());
> 
> For other platforms, I think `vector_op_cost` should be better to return 0 at this moment.

If a target support PopCountVI/VL minimum cost should 1, Zero will mean instruction has no cost at all.

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

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

From xliu at openjdk.java.net  Wed Feb  9 18:21:13 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 9 Feb 2022 18:21:13 GMT
Subject: RFR: 8280541: remove self-recursion of
 ConnectionGraph::find_inst_mem() [v2]
In-Reply-To: <ULUqtPuku1ee0zc8GdxBz0O3g1ba-qtT0fTGUfXjkqk=.cf6bb7c5-4f4e-4bb6-ac04-76b604b6c23f@github.com>
References: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
 <ULUqtPuku1ee0zc8GdxBz0O3g1ba-qtT0fTGUfXjkqk=.cf6bb7c5-4f4e-4bb6-ac04-76b604b6c23f@github.com>
Message-ID: <eLJhCvYc-WjoU6f0mUllN1gCdltKAglttxFiSaGTLBY=.57d9612a-8187-49ae-9f7c-66d8e8d111f2@github.com>

On Wed, 2 Feb 2022 07:12:47 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This is a follow-up task of JDK-8276219.
>> 
>> ConnectionGraph::find_inst_mem() contains a self-recursion for MergeMemNode.
>> It drills down into one input of MergeMemNode and tries to locate the memory node
>> which has the exact alias_idx. Once it returns, the result won't change from
>> recursion. Therefore, it's not necessary to use recursion in this case. We can
>> reset the initial state of this function and respin.
>> 
>> We can use a collection to remember all MergeMem Nodes and update them after then. 
>> 
>> This patch also makes a cleanup in MergeMemNode::memory_at(). C is not in use in
>> that function.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an assertion in debug build.
>   
>   This patch ensures the result is same as recursion.

@

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

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

From xliu at openjdk.java.net  Wed Feb  9 18:21:13 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 9 Feb 2022 18:21:13 GMT
Subject: Withdrawn: 8280541: remove self-recursion of
 ConnectionGraph::find_inst_mem()
In-Reply-To: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
References: <MXL05VGgne9yWbpeOU3ygn_zoUwCg5E5WtHm-x-jzag=.9f8b2e15-71d6-41b8-afd6-752e50c321ad@github.com>
Message-ID: <w6B1FQIAP1SIMOOsY10VlLGm9zEtOodyfI_t9841vBo=.7259c98c-f178-47d6-8321-94d4a84538db@github.com>

On Mon, 24 Jan 2022 22:57:15 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This is a follow-up task of JDK-8276219.
> 
> ConnectionGraph::find_inst_mem() contains a self-recursion for MergeMemNode.
> It drills down into one input of MergeMemNode and tries to locate the memory node
> which has the exact alias_idx. Once it returns, the result won't change from
> recursion. Therefore, it's not necessary to use recursion in this case. We can
> reset the initial state of this function and respin.
> 
> We can use a collection to remember all MergeMem Nodes and update them after then. 
> 
> This patch also makes a cleanup in MergeMemNode::memory_at(). C is not in use in
> that function.

This pull request has been closed without being integrated.

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

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

From jbhateja at openjdk.java.net  Wed Feb  9 18:21:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Feb 2022 18:21:43 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8281375: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/34113b02..4da75cc5

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

  Stats: 11 lines in 3 files changed: 6 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7373/head:pull/7373

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

From jbhateja at openjdk.java.net  Wed Feb  9 18:41:07 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Feb 2022 18:41:07 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <PK4lPB-DX74k8eDkWHCNcw5ZvGS3u-X527sbJVp86V8=.f45e95ae-8a65-4202-ad2e-3ed276fa0b25@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <PK4lPB-DX74k8eDkWHCNcw5ZvGS3u-X527sbJVp86V8=.f45e95ae-8a65-4202-ad2e-3ed276fa0b25@github.com>
Message-ID: <e1xnKpCOZeAbQpVeJUoHlJCdxpDjFCKfT36nWfKmKPA=.9edc5ba0-4cc6-4883-940c-9841e93d2aab@github.com>

On Wed, 9 Feb 2022 07:56:55 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> src/hotspot/cpu/x86/matcher_x86.hpp line 194:
> 
>> 192:     }
>> 193:   }
>> 194: 
> 
> Could you explain more about the meaning of "cost" here? Should it be the actual count of instruction or latency?

Currently its a rough approximation of generated instruction size over X86 since its mainly used to influence SLP unrolling factor.

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

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

From duke at openjdk.java.net  Wed Feb  9 20:18:07 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Wed, 9 Feb 2022 20:18:07 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <xCRcEqb5RrGyuZIDp6ArOj9vUoLtdEeT0OV9aABkUzU=.ee7ac78d-317a-4113-8b4b-ee87f4fb15a4@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
 <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
 <xCRcEqb5RrGyuZIDp6ArOj9vUoLtdEeT0OV9aABkUzU=.ee7ac78d-317a-4113-8b4b-ee87f4fb15a4@github.com>
Message-ID: <ITR3sS2CZdTg0jdvZJQ7ryNBzQmPPVatyg40WEfZYQQ=.412e7453-05f5-485f-9cb8-26536928ef90@github.com>

On Wed, 9 Feb 2022 16:21:16 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> For any app there are probably going to be a lot of times where the compiler matches subtract nodes. There are probably going to be very few cases where this pattern will turn up -- even if you include cases where it happens through recursive reduction -- and even less where the resulting generated code gets executed many times. At some point we need to trade off the compiler overhead for all applications against the potential gains for some applications. The micro-benchmark only addresses one side of that trade-off.

Thanks for your input. I totally agree JIT cares compilation overhead way more than those static compilers, but I was wondering if there is a good way to benchmark the general cases where this pattern is few seen. I know there are some benckmark suites for Java such as specjvm or renaissance but I don't think they are a good fit here. What I wanted to ask is what is an objective metric in the community to decide if we should adopt a new optimization, if there is one.

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

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

From dlong at openjdk.java.net  Wed Feb  9 23:17:10 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 9 Feb 2022 23:17:10 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
Message-ID: <HoEBU9i-ZVPtSgAWWDxGzF8pJ-Y1Pt89nv8H-3jdn6s=.472647e8-f65c-48f4-b27b-23d71654ecf5@github.com>

On Fri, 28 Jan 2022 10:36:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the discussion in the bug.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_32 fastdebug `java/lang/instrument`
>>  - [x] Linux AArch64 fastdebug `java/lang/instrument`
>>  - [x] Linux ARM32 fastdebug `java/lang/instrument`
>>  - [x] Linux PPC64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_32 fastdebug `tier1`
>>  - [x] Linux AArch64 fastdebug `tier1`
>>  - [x] Linux PPC64 fastdebug `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ARM32 checks

What's the reason for keeping load_immediate requiring a jlong?  It appears that all the immediates currently used will fit in a 32-bit signed int.  I suggest reverting back to "int" and simplifying this patch.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1418:

> 1416:   __ add(length, header_size_long, length);
> 1417:   if (round_mask != 0) {
> 1418:     LIR_Opr round_mask_opr = load_immediate(~(jlong)round_mask, T_LONG);

Explicitly casting to jlong here seems unnecessary.  We don't do that at line 1425.

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

Changes requested by dlong (Reviewer).

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

From sviswanathan at openjdk.java.net  Wed Feb  9 23:27:07 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 9 Feb 2022 23:27:07 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts
In-Reply-To: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
Message-ID: <EyIVF9jkyQkp_CGkS61PGbLfOmWpMJMKjkZfzBPms_U=.b8b1e26e-1fc9-44f0-9009-3b8c3f453cfc@github.com>

On Sat, 5 Feb 2022 15:34:08 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
> 
> Thank you very much.

src/hotspot/cpu/x86/assembler_x86.cpp line 4782:

> 4780:   vector_len == AVX_256bit? VM_Version::supports_avx2() :
> 4781:   vector_len == AVX_512bit? VM_Version::supports_evex() : 0, " ");
> 4782:   InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true);

legacy_mode should be false here instead of _legacy_mode_bw.

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

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

From iveresov at openjdk.java.net  Wed Feb  9 23:52:09 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 9 Feb 2022 23:52:09 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <HoEBU9i-ZVPtSgAWWDxGzF8pJ-Y1Pt89nv8H-3jdn6s=.472647e8-f65c-48f4-b27b-23d71654ecf5@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
 <HoEBU9i-ZVPtSgAWWDxGzF8pJ-Y1Pt89nv8H-3jdn6s=.472647e8-f65c-48f4-b27b-23d71654ecf5@github.com>
Message-ID: <VvZ17pp07YVxxi-0gIcLf_jtLackKCcOa5WU6ZYOLlo=.b5677cba-180e-40b6-9c2e-9d138814be9b@github.com>

On Wed, 9 Feb 2022 23:11:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert ARM32 checks
>
> What's the reason for keeping load_immediate requiring a jlong?  It appears that all the immediates currently used will fit in a 32-bit signed int.  I suggest reverting back to "int" and simplifying this patch.

@dean-long I think the argument has to be a jlong since he's passing a long inverted mask. It has to be 64bit.

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

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

From iveresov at openjdk.java.net  Thu Feb 10 00:03:10 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Thu, 10 Feb 2022 00:03:10 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <HoEBU9i-ZVPtSgAWWDxGzF8pJ-Y1Pt89nv8H-3jdn6s=.472647e8-f65c-48f4-b27b-23d71654ecf5@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
 <HoEBU9i-ZVPtSgAWWDxGzF8pJ-Y1Pt89nv8H-3jdn6s=.472647e8-f65c-48f4-b27b-23d71654ecf5@github.com>
Message-ID: <51PvmKTEjy2X4dDIeuj-06FCHnOIxn9fspkdnNt4jIU=.0e5d97e5-5734-493a-bea0-6509a3ea209a@github.com>

On Wed, 9 Feb 2022 23:13:59 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert ARM32 checks
>
> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1418:
> 
>> 1416:   __ add(length, header_size_long, length);
>> 1417:   if (round_mask != 0) {
>> 1418:     LIR_Opr round_mask_opr = load_immediate(~(jlong)round_mask, T_LONG);
> 
> Explicitly casting to jlong here seems unnecessary.  We don't do that at line 1425.

It's going to work for the current value of `round_mask` either way, but I think in general I would cast to an `unsigned long` and then flip the bits. A signed cast will fill the upper bits with ones if the original value was negative. It's usually not what you want with masking.

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

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

From dlong at openjdk.java.net  Thu Feb 10 01:41:05 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 10 Feb 2022 01:41:05 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <51PvmKTEjy2X4dDIeuj-06FCHnOIxn9fspkdnNt4jIU=.0e5d97e5-5734-493a-bea0-6509a3ea209a@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
 <HoEBU9i-ZVPtSgAWWDxGzF8pJ-Y1Pt89nv8H-3jdn6s=.472647e8-f65c-48f4-b27b-23d71654ecf5@github.com>
 <51PvmKTEjy2X4dDIeuj-06FCHnOIxn9fspkdnNt4jIU=.0e5d97e5-5734-493a-bea0-6509a3ea209a@github.com>
Message-ID: <Pq35hTMclOpYBQn_hZlqpxZ-hv7S8eeaVzr3i9KNw3A=.9a234e43-87b9-4486-a1f7-5962e2a55d7d@github.com>

On Wed, 9 Feb 2022 23:59:30 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_LIRGenerator.cpp line 1418:
>> 
>>> 1416:   __ add(length, header_size_long, length);
>>> 1417:   if (round_mask != 0) {
>>> 1418:     LIR_Opr round_mask_opr = load_immediate(~(jlong)round_mask, T_LONG);
>> 
>> Explicitly casting to jlong here seems unnecessary.  We don't do that at line 1425.
>
> It's going to work for the current value of `round_mask` either way, but I think in general I would cast to an `unsigned long` and then flip the bits. A signed cast will fill the upper bits with ones if the original value was negative. It's usually not what you want with masking.

Yes, there is an ambiguity with the old version.  It passes an `int` to longConst(jlong), so the value is signed extended.  If we wanted to treat it as unsigned, we couldn't.

Since we only need the 64-bit T_LONG immediate for _LP64, and only for this one call, I would also be happy with a new load_immediate_64 or load_immediate_jlong that takes a jlong.  Or this section could be changed to use a 32-bit mask and then do the i2l after, like above.  I'm also willing to accept the current changes as is.  I don't have a strong opinion either way.

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

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

From jbhateja at openjdk.java.net  Thu Feb 10 02:25:15 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 10 Feb 2022 02:25:15 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
In-Reply-To: <lY7KSnA0fe0h652PJPYEzgs9SIqAA0ndwc4mOL_r2zs=.3158b3df-2498-4e89-8c85-a227164c095b@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <lY7KSnA0fe0h652PJPYEzgs9SIqAA0ndwc4mOL_r2zs=.3158b3df-2498-4e89-8c85-a227164c095b@github.com>
Message-ID: <bcp5bXRAuarqDYxBCQNyoY7UE1T8bAsbKSLjq8e4MA0=.95f6207e-e29e-46e2-bf49-3a4a5cf130c2@github.com>

On Wed, 9 Feb 2022 16:26:44 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> I think you can dump a lane into the constant table and use `vpbroadcasti128` for the look-up table.
> 
> Thanks.

-  POPCOUNT lookup table replicates after 16 bytes, $constantaddress accepts a long value (8bytes) which gets replicated and dumped in the Constant Table.
-  Values loaded from constant table many not be aligned to 64 byte boundary and thus may result into perf degradation due to cache line split when loading them into 64 byte vector.

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

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

From eliu at openjdk.java.net  Thu Feb 10 02:54:03 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Thu, 10 Feb 2022 02:54:03 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <e1xnKpCOZeAbQpVeJUoHlJCdxpDjFCKfT36nWfKmKPA=.9edc5ba0-4cc6-4883-940c-9841e93d2aab@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <PK4lPB-DX74k8eDkWHCNcw5ZvGS3u-X527sbJVp86V8=.f45e95ae-8a65-4202-ad2e-3ed276fa0b25@github.com>
 <e1xnKpCOZeAbQpVeJUoHlJCdxpDjFCKfT36nWfKmKPA=.9edc5ba0-4cc6-4883-940c-9841e93d2aab@github.com>
Message-ID: <epop5rJUAfaK5e4Yw-pSfcWu50-JUkd-Eln2wg9MbF4=.4f3de373-536c-40ef-b7e6-aa7291b027f2@github.com>

On Wed, 9 Feb 2022 18:38:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/matcher_x86.hpp line 194:
>> 
>>> 192:     }
>>> 193:   }
>>> 194: 
>> 
>> Could you explain more about the meaning of "cost" here? Should it be the actual count of instruction or latency?
>
> Currently its a rough approximation of generated instruction size over X86 since its mainly used to influence SLP unrolling factor.

Thanks! My concern is that the name "vector_op_cost", which looks like very general but it only cares about size overhead at this moment. In other place maybe we need to concern the time overhead. I prefer to give the function a more specific name.

>> src/hotspot/share/opto/loopTransform.cpp line 976:
>> 
>>> 974:       case Op_PopCountVL: {
>>> 975:         const TypeVect * vt = n->bottom_type()->is_vect();
>>> 976:         body_size += Matcher::vector_op_cost(n->Opcode(), vt->element_basic_type(), vt->length());
>> 
>> For other platforms, I think `vector_op_cost` should be better to return 0 at this moment.
>
> If a target support PopCountVI/VL minimum cost should 1, Zero will mean instruction has no cost at all.

I thought the total cost has been counted by `uint body_size = _body.size()`. So that for other platforms, the total cost now is one more if counted PopCountVI/VL.

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

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

From iveresov at openjdk.java.net  Thu Feb 10 04:41:09 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Thu, 10 Feb 2022 04:41:09 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
Message-ID: <p-8GCypYTqHo-0Eu4eeFOYRyxNtKY_bOyuC4kiyLZbk=.f447f777-7d9e-41e1-9f25-47f4594428a7@github.com>

On Fri, 28 Jan 2022 10:36:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the discussion in the bug.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_32 fastdebug `java/lang/instrument`
>>  - [x] Linux AArch64 fastdebug `java/lang/instrument`
>>  - [x] Linux ARM32 fastdebug `java/lang/instrument`
>>  - [x] Linux PPC64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_32 fastdebug `tier1`
>>  - [x] Linux AArch64 fastdebug `tier1`
>>  - [x] Linux PPC64 fastdebug `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ARM32 checks

Marked as reviewed by iveresov (Reviewer).

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

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

From duke at openjdk.java.net  Thu Feb 10 06:23:06 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 10 Feb 2022 06:23:06 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>
Message-ID: <o_7hkc8hAzt8Xllk6bVVCCU-bbsNLLsl4RshyxfJlzE=.2611017c-f1e6-4f38-8ebb-79c7d61e3a04@github.com>

On Wed, 9 Feb 2022 18:21:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

We recently have [JDK-8278947](https://bugs.openjdk.java.net/browse/JDK-8278947) for this. With some adjustment you can ask for alignment of the constant, too.
Thanks.

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

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

From duke at openjdk.java.net  Thu Feb 10 09:04:09 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 10 Feb 2022 09:04:09 GMT
Subject: RFR: 8252496: C2: Useless code in MergeMemNode::Ideal
In-Reply-To: <4bvzI3A2fjT2YuwOc4kQDJ_EI4BRgo0pUYSGUnt5JV0=.2f630318-1a32-4a29-8e65-a7a05046da03@github.com>
References: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
 <4bvzI3A2fjT2YuwOc4kQDJ_EI4BRgo0pUYSGUnt5JV0=.2f630318-1a32-4a29-8e65-a7a05046da03@github.com>
Message-ID: <hSTBGk74fq0SEjFYT6drndqcvmW45sOY2K3U9hCsRdk=.3ddabb6f-501d-42b6-b06e-51e09474cfec@github.com>

On Wed, 9 Feb 2022 12:31:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This code was there since `initial load`. At that point there was other code that still depended on this code.
>> The other code was removed [here](https://github.com/eme64/jdk/commit/79ad5512cfe5c4ef7d0b61616f3763c62d3427a5). This was the change set for [JDK-8243670](https://bugs.openjdk.java.net/browse/JDK-8243670).
>> Our code was left behind.
>> 
>> I removed the useless code, and ran tests to verify that nothing broke due to side-effects.
>
> Looks good.

@iwanowww @chhagedorn @TobiHartmann thanks for the reviews!

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

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

From rcastanedalo at openjdk.java.net  Thu Feb 10 09:16:26 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 10 Feb 2022 09:16:26 GMT
Subject: RFR: 8281539: IGV: schedule approximation computes immediate
 dominators wrongly
Message-ID: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>

The `ServerCompiler` module in IGV computes an approximation of C2's schedule for unscheduled graphs, for clustering and showing control flow information in the "Control Flow" window. This approximation uses domination information to guide the scheduling of nodes into basic blocks. Currently, this information is computed with a custom algorithm implementation that gives wrong results for some graphs, as shown in [the issue report](https://bugs.openjdk.java.net/browse/JDK-8281539).

This change simply replaces the custom implementation with one from the [T. J. Watson Libraries for Analysis (WALA)](https://github.com/wala/WALA), a popular set of static analysis libraries licensed under the [OSI](http://www.opensource.org/)-approved [Eclipse Public License](http://www.eclipse.org/legal/epl-v10.html). The replacement gives correct domination information for the reported graphs and reduces significantly the complexity of the `ServerCompiler` module.

#### Testing

- Tested manually that the dominator tree computed for a few selected graphs (included the reported one) is correct.
- Tested manually, for large graphs, that the dominator tree computation takes a negligible fraction (around 1%) of the entire graph scheduling time.
- Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

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

Commit messages:
 - Update copyright year
 - Replace custom dominator tree implementation with one from the T. J. Watson Libraries for Analysis (WALA)

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

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

From duke at openjdk.java.net  Thu Feb 10 09:33:09 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 10 Feb 2022 09:33:09 GMT
Subject: Integrated: 8252496: C2: Useless code in MergeMemNode::Ideal
In-Reply-To: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
References: <mBf4kmQBHhhSMoc9J5XemdFDnbHOQIOHwDz1SjODO4s=.ab467346-b19d-4399-a55c-d49a8f2d220d@github.com>
Message-ID: <Rz3L7HjbNLxgg5fWLP5woSkgwezM57-xgX4KgGjE-3k=.52db37a6-0aa1-4b8a-ab0d-4e9b40ca2f6a@github.com>

On Wed, 9 Feb 2022 09:23:50 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> This code was there since `initial load`. At that point there was other code that still depended on this code.
> The other code was removed [here](https://github.com/eme64/jdk/commit/79ad5512cfe5c4ef7d0b61616f3763c62d3427a5). This was the change set for [JDK-8243670](https://bugs.openjdk.java.net/browse/JDK-8243670).
> Our code was left behind.
> 
> I removed the useless code, and ran tests to verify that nothing broke due to side-effects.

This pull request has now been integrated.

Changeset: fa0a72c0
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa0a72c030432f9ea4ad9913a2bb4096324410aa
Stats:     24 lines in 1 file changed: 0 ins; 24 del; 0 mod

8252496: C2: Useless code in MergeMemNode::Ideal

Reviewed-by: thartmann, chagedorn, vlivanov

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

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

From dlong at openjdk.java.net  Thu Feb 10 09:38:07 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 10 Feb 2022 09:38:07 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
Message-ID: <3f7lgY7gAHTTvw94gdXuIgDYCesgAWl6vvk-h_r7VAg=.b56c8207-2658-41c9-875c-4fd315153d21@github.com>

On Fri, 28 Jan 2022 10:36:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the discussion in the bug.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_32 fastdebug `java/lang/instrument`
>>  - [x] Linux AArch64 fastdebug `java/lang/instrument`
>>  - [x] Linux ARM32 fastdebug `java/lang/instrument`
>>  - [x] Linux PPC64 fastdebug `java/lang/instrument`
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_32 fastdebug `tier1`
>>  - [x] Linux AArch64 fastdebug `tier1`
>>  - [x] Linux PPC64 fastdebug `tier1`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert ARM32 checks

Marked as reviewed by dlong (Reviewer).

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

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

From ihse at openjdk.java.net  Thu Feb 10 10:34:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Feb 2022 10:34:10 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <4nC5k7QaTy0Z9_-7o_sErdrsRFzxvIqC01Xr5V_xvgg=.d4dbd7e7-71b7-45f8-a136-19c0fa87bd65@github.com>

On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Yes bot, thank you for the reminder.

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

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

From jbhateja at openjdk.java.net  Thu Feb 10 12:24:14 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 10 Feb 2022 12:24:14 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts
In-Reply-To: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
Message-ID: <1EkBcO28e83W0erDN6flFX6eR88aovKxVIGJqOiF40I=.5db87001-570d-4679-9b3a-7937b72233ed@github.com>

On Sat, 5 Feb 2022 15:34:08 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
> 
> Thank you very much.

src/hotspot/cpu/x86/x86.ad line 7288:

> 7286:         break;
> 7287:       default: assert(false, "%s", type2name(to_elem_bt));
> 7288:     }

Please move this into a macro assembly routine.

src/hotspot/cpu/x86/x86.ad line 7310:

> 7308:       default: assert(false, "%s", type2name(to_elem_bt));
> 7309:     }
> 7310:   %}

Same as above.

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

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

From vlivanov at openjdk.java.net  Thu Feb 10 13:25:30 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 13:25:30 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
Message-ID: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>

Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.

Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 

The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 

Testing: hs-tier1 - hs-tier4

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

Commit messages:
 - 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant pool entries

Changes: https://git.openjdk.java.net/jdk/pull/7423/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7423&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280473
  Stats: 476 lines in 12 files changed: 374 ins; 60 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7423.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7423/head:pull/7423

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

From adinn at openjdk.java.net  Thu Feb 10 14:52:07 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 10 Feb 2022 14:52:07 GMT
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <ITR3sS2CZdTg0jdvZJQ7ryNBzQmPPVatyg40WEfZYQQ=.412e7453-05f5-485f-9cb8-26536928ef90@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
 <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
 <xCRcEqb5RrGyuZIDp6ArOj9vUoLtdEeT0OV9aABkUzU=.ee7ac78d-317a-4113-8b4b-ee87f4fb15a4@github.com>
 <ITR3sS2CZdTg0jdvZJQ7ryNBzQmPPVatyg40WEfZYQQ=.412e7453-05f5-485f-9cb8-26536928ef90@github.com>
Message-ID: <3fRDYcWnaJBCTrRTWGR6vV5CeM9SxZUTpvjI-DSlcMY=.f3804835-909d-47c8-88cd-a2a4419a35be@github.com>

On Wed, 9 Feb 2022 20:14:33 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> I was wondering if there is a good way to benchmark the general cases where this pattern is few seen

It's very difficult to find a way to assess the positive and negative aspects of a change like this. Micro-benchmarks only really provide a ballpark guide to the *potential* benefit because they test the effect of the change in isolation. Even then they only tell part of the story because they ignore the degree to which that benefit will be realized. The potential costs are even harder to estimate. They will vary from app to app according to what gets compiled and which paths the compilation takes. They will even vary from run to run of the same app because the JVM does not guarantee precise repeatability across restarts even if you keep all inputs the same.

For quite a few ideal transformations it is clear that they will be applicable very frequently and hence that they are worth implementing. That's often clear because we know that frequently used Java language constructs translate to graphs that will have a shape that matches the input checked for by the ideal code. In other cases, we can know that related ideal transforms will recursively combine to generate the target shape. For many other possible transforms we are in a grey area where we cannot know if the cost of checking for will repay in saved execution.

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

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

From duke at openjdk.java.net  Thu Feb 10 15:14:44 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 10 Feb 2022 15:14:44 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
Message-ID: <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>

> Hi,
> 
> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - minor rename
 - address reviews

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7358/files
  - new: https://git.openjdk.java.net/jdk/pull/7358/files/22a70fe1..8028be52

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

  Stats: 81 lines in 4 files changed: 32 ins; 44 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7358.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7358/head:pull/7358

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

From duke at openjdk.java.net  Thu Feb 10 15:14:46 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 10 Feb 2022 15:14:46 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <EyIVF9jkyQkp_CGkS61PGbLfOmWpMJMKjkZfzBPms_U=.b8b1e26e-1fc9-44f0-9009-3b8c3f453cfc@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <EyIVF9jkyQkp_CGkS61PGbLfOmWpMJMKjkZfzBPms_U=.b8b1e26e-1fc9-44f0-9009-3b8c3f453cfc@github.com>
Message-ID: <lC0CLtI3PU_gmVK9uuDeekxAi5ajNIEk7zEJyJKqPB8=.a2c708e2-3433-466b-adb4-46e3ea21143c@github.com>

On Wed, 9 Feb 2022 22:52:47 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - minor rename
>>  - address reviews
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 4782:
> 
>> 4780:   vector_len == AVX_256bit? VM_Version::supports_avx2() :
>> 4781:   vector_len == AVX_512bit? VM_Version::supports_evex() : 0, " ");
>> 4782:   InstructionAttr attributes(vector_len, /* rex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true);
> 
> legacy_mode should be false here instead of _legacy_mode_bw.

Fixed, thanks.

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

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

From duke at openjdk.java.net  Thu Feb 10 15:14:49 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 10 Feb 2022 15:14:49 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <1EkBcO28e83W0erDN6flFX6eR88aovKxVIGJqOiF40I=.5db87001-570d-4679-9b3a-7937b72233ed@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <1EkBcO28e83W0erDN6flFX6eR88aovKxVIGJqOiF40I=.5db87001-570d-4679-9b3a-7937b72233ed@github.com>
Message-ID: <1U-v8HDdffTAyMecRVwaQhZUi3mmITIGDpuXsbHni5o=.b0bc2c3f-ac7f-4c0d-831c-7586673d5aea@github.com>

On Thu, 10 Feb 2022 05:05:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - minor rename
>>  - address reviews
>
> src/hotspot/cpu/x86/x86.ad line 7288:
> 
>> 7286:         break;
>> 7287:       default: assert(false, "%s", type2name(to_elem_bt));
>> 7288:     }
> 
> Please move this into a macro assembly routine.

Fixed, thanks.

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

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

From neliasso at openjdk.java.net  Thu Feb 10 15:22:30 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 10 Feb 2022 15:22:30 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase
Message-ID: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>

1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.

-XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"

The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)

I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.

2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.

3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 

Please review,
Nils Eliasson

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

Commit messages:
 - Fix checks
 - Add validator check
 - Add Test
 - Fix product build
 - PrintIdealPhase

Changes: https://git.openjdk.java.net/jdk/pull/7392/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7392&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281505
  Stats: 407 lines in 10 files changed: 305 ins; 31 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7392.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7392/head:pull/7392

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

From neliasso at openjdk.java.net  Thu Feb 10 16:10:03 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 10 Feb 2022 16:10:03 GMT
Subject: RFR: 8281539: IGV: schedule approximation computes immediate
 dominators wrongly
In-Reply-To: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
References: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
Message-ID: <sxRy9dzWujVpW1l3SvFFzenWr5LfcSvO9QUuI82v8Oc=.988f3bad-ff40-4593-813c-2805273d5022@github.com>

On Wed, 9 Feb 2022 15:16:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The `ServerCompiler` module in IGV computes an approximation of C2's schedule for unscheduled graphs, for clustering and showing control flow information in the "Control Flow" window. This approximation uses domination information to guide the scheduling of nodes into basic blocks. Currently, this information is computed with a custom algorithm implementation that gives wrong results for some graphs, as shown in [the issue report](https://bugs.openjdk.java.net/browse/JDK-8281539).
> 
> This change simply replaces the custom implementation with one from the [T. J. Watson Libraries for Analysis (WALA)](https://github.com/wala/WALA), a popular set of static analysis libraries licensed under the [OSI](http://www.opensource.org/)-approved [Eclipse Public License](http://www.eclipse.org/legal/epl-v10.html). The replacement gives correct domination information for the reported graphs and reduces significantly the complexity of the `ServerCompiler` module.
> 
> #### Testing
> 
> - Tested manually that the dominator tree computed for a few selected graphs (included the reported one) is correct.
> - Tested manually, for large graphs, that the dominator tree computation takes a negligible fraction (around 1%) of the entire graph scheduling time.
> - Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

Hi @robcasloz 

This looks great! I'll try it out.

// Nils

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

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

From neliasso at openjdk.java.net  Thu Feb 10 16:18:11 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 10 Feb 2022 16:18:11 GMT
Subject: RFR: JDK-8281522: Rename ADLC classes which have the same name as
 hotspot variants
In-Reply-To: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
References: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
Message-ID: <W4ddIRFF2b-KCq0rdM_2Gxt3uWM8juyPGAvO5wX-SWs=.863c3551-0cc7-47d5-9a6d-b4b887db90eb@github.com>

On Wed, 9 Feb 2022 08:10:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After some prior offlist discussions with Oracle staff, I propose to change the names of some of the adlc classes and functions to avoid name clashes with their hotspot counterparts. This has bugged me for a while since my IDE gets often confused about this when working on hotspot arena code.
> 
> This patch prefixes "Arena", "Chunk", "CHeapObj" and "AllStatic", "AllocateHeap", "ReallocateHeap" with "Adl...". The replacement is purely mechanical, no functional change happens here.
> 
> Thanks, Thomas

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From duke at openjdk.java.net  Thu Feb 10 17:03:11 2022
From: duke at openjdk.java.net (Eirik Bjorsnos)
Date: Thu, 10 Feb 2022 17:03:11 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <3uxWH3gWOJP2n5r1IfWw3yqCjFeZstpie--H6oU4jdc=.fa4212f5-adaa-4312-ace7-73b7daf58672@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

Not a review, but I've tested this and  can confirm it resolves the bailout issue as reported in the mail thread linked to in JDK-8280473.

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

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

From vlivanov at openjdk.java.net  Thu Feb 10 17:25:23 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 17:25:23 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
Message-ID: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>

It's another attempt to fix JDK-8256368 (previous one was #1453). 

@coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 

After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.

Original description:

Method linkage of invokehandle instructions involve an upcall into Java
(MethodHandleNatives::linkMethod), but the result is not cached. Unless the
upcall behaves idempotently (which is highly desirable, but not guaranteed),
repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
switching to a higher tier involves call site re-resolution in generated code,
but re-resolution installs a fresh method which puts execution back into
interpreter.

(Another prerequisite is no inlining through a invokehandle which doesn't
normally happen in practice - relevant methods are marked w/ @ForceInline -
except some testing modes, -Xcomp in particular.)

Proposed fix is to inspect ConstantPoolCache first. Previous resolution
attempts from interpreter and C1 records their results there and it stabilises
the execution.

Testing: hs-tier1 - hs-tier4

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

Commit messages:
 - Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

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

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

From kvn at openjdk.java.net  Thu Feb 10 17:55:05 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 10 Feb 2022 17:55:05 GMT
Subject: RFR: JDK-8281522: Rename ADLC classes which have the same name as
 hotspot variants
In-Reply-To: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
References: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
Message-ID: <bSDB3iNxB3SxHWGUQd84fB8AOvyqmXMbA36foRiLulU=.5a9cd099-6e96-4460-b613-9d7c6a984711@github.com>

On Wed, 9 Feb 2022 08:10:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After some prior offlist discussions with Oracle staff, I propose to change the names of some of the adlc classes and functions to avoid name clashes with their hotspot counterparts. This has bugged me for a while since my IDE gets often confused about this when working on hotspot arena code.
> 
> This patch prefixes "Arena", "Chunk", "CHeapObj" and "AllStatic", "AllocateHeap", "ReallocateHeap" with "Adl...". The replacement is purely mechanical, no functional change happens here.
> 
> Thanks, Thomas

Good

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

Marked as reviewed by kvn (Reviewer).

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

From vlivanov at openjdk.java.net  Thu Feb 10 17:55:08 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 17:55:08 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <0UAFkc0ur1_iF_Iv291gsJkJtPyuCFfCbXt5ljpX4FI=.2c6f650a-64b7-463e-b44b-4bbf7dadad35@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

Thanks for validating the fix, Eirik.

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

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

From psandoz at openjdk.java.net  Thu Feb 10 18:31:05 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 10 Feb 2022 18:31:05 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>
Message-ID: <Nk_U5o2qYVe1pOilo9jJjGOVr61df5VHOdRpTUC4p70=.18f03ba2-6ba4-4117-abff-5f743e9209d1@github.com>

On Thu, 10 Feb 2022 15:14:44 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor rename
>  - address reviews

Running some tests.

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

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

From psandoz at openjdk.java.net  Thu Feb 10 18:59:05 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 10 Feb 2022 18:59:05 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>
Message-ID: <Mw8wnUYFgKMIS124_zvUI4wtV_s7YHydLEwiwkOC0Fw=.72a1e123-3272-40d7-8d95-746fa3da061b@github.com>

On Thu, 10 Feb 2022 15:14:44 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor rename
>  - address reviews

Observing the following failures on CPUs with "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags:

-XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation


TestVectorCastAVX512.java:

Failed IR Rules (1)
------------------
- Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUI256toL512(int[],long[])":
  * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastI2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
    - counts: Graph contains wrong number of nodes:
        Regex 1: (\\d+(\\s){2}(VectorUCastI2X.*)+(\\s){2}===.*)
        Expected 1 but found 0 nodes.


TestVectorCastAVX1.java:

- Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toS64(byte[],short[])":
  * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
    - counts: Graph contains wrong number of nodes:
        Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*)
        Expected 1 but found 0 nodes.

- Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toI128(byte[],int[])":
  * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
    - counts: Graph contains wrong number of nodes:
        Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*)
        Expected 1 but found 0 nodes.

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

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

From vlivanov at openjdk.java.net  Thu Feb 10 19:17:11 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 19:17:11 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
Message-ID: <TE0IyQyh0FW5kw1R58fEgOkkJu7sljnL5h7Ia-EskmI=.d4e371d9-0c99-470b-9c98-a0fb6f5d736f@github.com>

On Tue, 1 Feb 2022 09:31:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The new fix is largely similar to the previous one. 3 bugs were filed
>> because of the previous change but there are only really 2 issues:
>> 
>> - attaching the valid length condition at expansion time to the new
>>   array runtime call causes issues. With Shenandoah, passes of loop
>>   opts are executed after macro expansion but precedence edges are
>>   ignored when assigning controls to nodes which causes loop opts to
>>   incorrectly attempt to eliminate the node pointed to by the
>>   precedence edge. A similar issue occurs when the runtime call ends
>>   up in a subgraph that dies after macro expansion because the
>>   precedence edge is not cleared by dead code elimination which causes
>>   the runtime call to still be reachable. In the new patch, this is
>>   fixed by appending an extra input to the runtime call instead of
>>   using a precedence edge.
>> 
>> - In the previous patch, a top valid length input is used when there's
>>   no valid length input that needs to be recorded. That can cause an
>>   assert failure during CCP. If valid length initially has type top,
>>   the CatchNode out of the AllocateArray then have type (control,
>>   control). If next, the valid length input becomes constant 0, the
>>   CatchNode has type (top, control). An assert catches that the type
>>   of the CatchNode doesn't widen. This fixed by using 1 by default as
>>   valid length input and tweaking CatchNode::Value.
>> 
>> The new patch includes test cases for both issues.
>
> 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 five additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8279219
>  - review
>  - tests & fix
>  - Revert "8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large"
>    
>    This reverts commit 04ad668921abbd71dfbc474eed6f1760f7a541b1.

src/hotspot/share/opto/graphKit.cpp line 3977:

> 3975:   Node* valid_length_test = _gvn.intcon(1);
> 3976:   if (ary_type->klass()->is_array_klass()) {
> 3977:     BasicType bt = ary_type->klass()->as_array_klass()->element_type()->basic_type();

FTR `array_element_basic_type()` is more appropriate here. 
`basic_type()` reports `T_INT` for all sub-word element types and it may lead to underestimation of maximum array length.

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

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

From vladimir.x.ivanov at oracle.com  Thu Feb 10 19:29:45 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 22:29:45 +0300
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>

(BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)

Hi Cesar,

Thanks for looking into enhancing EA.

Overall, the proposal looks reasonable.

I suggest to look more closely at split_unique_types().
It introduces a dedicated class of alias categories for fields of the 
allocation being eliminated and clones memory graph. I don't see why it 
shouldn't work for multiple allocations.

Moreover, split_unique_types() will break if you start optimizing 
multiple allocations at once. The notion of unique alias should be 
adjusted and cover the union of unique aliases for all interacting 
allocations.

Seems like you need to enhance SR to work on non-intersecting clusters 
of allocations.

One thing to take care of: scalar replacement relies on 
TypeOopPtr::instance_id().

   // If not InstanceTop or InstanceBot, indicates that this is
   // a particular instance of this type which is distinct.
   // This is the node index of the allocation node creating this instance.
   int           _instance_id;

It'll break when multiple allocations are in play.

Best regards,
Vladimir Ivanov

On 09.02.2022 04:45, Cesar Soares Lucas wrote:
> Hi there again!
> 
> Can you please give me feedback on the following approach to at least partially
> address [1], the scalar replacement allocation merge issue?
> 
> The problem that I am trying to solve arises when allocations are merged after a
> control flow split. The code below shows _one example_ of such a situation.
> 
> public int ex1(boolean cond, int x, int y) {
>  ? ? Point p = new Point(x, y);
>  ? ? if (cond)
>  ? ? ? ? p = new Point(y, x);
>  ? ? // Allocations for p are merged here.
>  ? ? return p.calc();
> }
> 
> Assuming the method calls on "p" are inlined then the allocations will not
> escape the method. The C2 IR for this method will look like this:
> 
> public int ex1(boolean cond, int first, int second) {
>  ? ? p0 = Allocate(...);
>  ? ? ...
>  ? ? p0.x = first;
>  ? ? p0.y = second;
> 
>  ? ? if (cond) {
>  ? ? ? ? p1 = Allocate(...);
>  ? ? ? ? ...
>  ? ? ? ? p1.x = second;
>  ? ? ? ? p1.y = first;
>  ? ? }
> 
>  ? ? p = phi(p0, p1)
> 
>  ? ? return p.x - p.y;
> }
> 
> However, one of the constraints implemented here [2], specifically the third
> one, will prevent the objects from being scalar replaced.
> 
> The approach that I'm considering for solving the problem is to replace the Phi
> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of the objects
> in the original Phi. The IR for `ex1` would look something like this after the
> transformation:
> 
> public int ex1(boolean cond, int first, int second) {
>  ? ? p0 = Allocate(...);
>  ? ? ...
>  ? ? p0.x = first;
>  ? ? p0.y = second;
> 
>  ? ? if (cond) {
>  ? ? ? ? p1 = Allocate(...);
>  ? ? ? ? ...
>  ? ? ? ? p1.x = second;
>  ? ? ? ? p1.y = first;
>  ? ? }
> 
>  ? ? pX = phi(first, second)
>  ? ? pY = phi(second, first)
> 
>  ? ? return pX - pY;
> }
> 
> I understand that this transformation might not be applicable for all cases and
> that it's not as simple as illustrated above. Also, it seems to me that much of
> what I'd have to implement is already implemented in other steps of the Scalar
> Replacement pipeline (which is a good thing). To work around these
> implementation details I plan to use as much of the existing code as possible.
> The algorithm for the transformation would be like this:
> 
> split_phis(phi)
>  ? ? # If output of phi escapes, or something uses its identity, etc
>  ? ? # then we can't remove it. The conditions here might possible be the
>  ? ? # same as the ones implemented in `PhaseMacroExpand::can_eliminate_allocation`
>  ? ? if cant_remove_phi_output(phi)
>  ? ? ? ? return ;
> 
>  ? ? # Collect a set of tuples(F,U) containing nodes U that uses field F
>  ? ? # member of the object resulting from `phi`.
>  ? ? fields_used = collect_fields_used_after_phi(phi)
> 
>  ? ? foreach field in fields_used
>  ? ? ? ? producers = {}
> 
>  ? ? ? ? # Create a list with the last Store for each field "field" on the
>  ? ? ? ? # scope of each of the Phi input objects.
>  ? ? ? ? foreach o in phi.inputs
>  ? ? ? ? ? ? # The function called below might re-use a lot of the code/logic in `PhaseMacroExpand::scalar_replacement`
>  ? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>          
>  ? ? ? ? # Create a new phi node whose inputs are the Store's to 'field'
>  ? ? ? ? field_phi = create_new_phi(producers)
> 
>  ? ? ? ? update_consumers(field, field_phi)
> 
> The implementation that I envisioned would be as a "pre-process" [3] step just
> after EA but before the constraint checks in `adjust_scalar_replaceable_state`
> [2]. If we agree that the overall Scalar Replacement implementation goes through
> the following major phases:
> 
>  ? ? 1. Identify the Escape Status of objects.
>  ? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>  ? ? 3. Make call to Split_unique_types [4].
>  ? ? 4 Iterate over object and array allocations.
>  ? ? ? ? 4.1 Check if allocation can be eliminated.
>  ? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>  ? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
> 
> The transformation that I am proposing would change the overall flow to look
> like this:
> 
>  ? ? 1. Identify the Escape Status of objects.
>  ? ? 2. ----> New: "Split phi functions" <----
>  ? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>  ? ? 3. Make call to Split_unique_types [14].
>  ? ? 4 Iterate over object and array allocations.
>  ? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be eliminated" <----
>  ? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>  ? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
> 
> Please let me know what you think and thank you for taking the time to review
> this!
> 
> 
> Regards,
> Cesar
> 
> Notes:
> 
>  ? ? [1] I am not sure yet how this approach will play with the case of a merge
>  ? ? ? ? with NULL.
>   
>  ? ? [2] https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809
> 
>  ? ? [3] Another option would be to "patch" the current implementation to be able
>  ? ? ? ? to handle the merges. I am not certain that the "patch" approach would be
>  ? ? ? ? better, however, the "pre-process" approach is certainly much easier to test
>  ? ? ? ? and more readable.
> 
>  ? ? [4] I cannot say I understand 100% the effects of executing
>  ? ? ? ? split_unique_types(). Would the transformation that I am proposing need to
>  ? ? ? ? be after the call to split_unique_types?

From vlivanov at openjdk.java.net  Thu Feb 10 19:36:21 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 10 Feb 2022 19:36:21 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <TE0IyQyh0FW5kw1R58fEgOkkJu7sljnL5h7Ia-EskmI=.d4e371d9-0c99-470b-9c98-a0fb6f5d736f@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
 <TE0IyQyh0FW5kw1R58fEgOkkJu7sljnL5h7Ia-EskmI=.d4e371d9-0c99-470b-9c98-a0fb6f5d736f@github.com>
Message-ID: <1saTsa87zgK9VX5VElTKmZ0hI3DAbvbq2pSJnNzJjmk=.8083a165-f7da-47a0-81df-fd6581c01f32@github.com>

On Thu, 10 Feb 2022 19:13:13 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8279219
>>  - review
>>  - tests & fix
>>  - Revert "8279204: [BACKOUT] JDK-8278413: C2 crash when allocating array of size too large"
>>    
>>    This reverts commit 04ad668921abbd71dfbc474eed6f1760f7a541b1.
>
> src/hotspot/share/opto/graphKit.cpp line 3977:
> 
>> 3975:   Node* valid_length_test = _gvn.intcon(1);
>> 3976:   if (ary_type->klass()->is_array_klass()) {
>> 3977:     BasicType bt = ary_type->klass()->as_array_klass()->element_type()->basic_type();
> 
> FTR `array_element_basic_type()` is more appropriate here. 
> `basic_type()` reports `T_INT` for all sub-word element types and it may lead to underestimation of maximum array length.

Thinking more about it, it seems like a bug. For a large enough allocation, it may erroneously classify it as erroneous. Will it trigger wrong exception being thrown?

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

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

From duke at openjdk.java.net  Thu Feb 10 22:24:05 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Thu, 10 Feb 2022 22:24:05 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2 Ideal
 transformations
Message-ID: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>

Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:

- Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
- Add more default IR regex's to IR-based test framework.

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

Commit messages:
 - Tests for some Ideal transformations

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

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

From dlong at openjdk.java.net  Thu Feb 10 22:50:20 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 10 Feb 2022 22:50:20 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <gGHeRzzJcV21AfCKa53Xmdr6TnoUe1oEb8NuZ2i3k_k=.41eb29c1-2c22-4aff-99e2-97095fb67f8c@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

src/hotspot/share/ci/ciEnv.cpp line 760:

> 758:     }
> 759:     ciInstance* constant = get_object(string)->as_instance();
> 760:     return ciConstant(T_OBJECT, constant);

Please explain what happens for array constants now.

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

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

From dlong at openjdk.java.net  Thu Feb 10 22:54:10 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 10 Feb 2022 22:54:10 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <kowwDoElyew1G0MGX0QV9LUxdbUm67RJmHUBs4RV_WQ=.4cf19ca0-7306-4b49-bd98-7d874d840508@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

src/hotspot/share/c1/c1_InstructionPrinter.cpp line 265:

> 263: 
> 264: void InstructionPrinter::print_unsafe_op(UnsafeOp* op, const char* name) {
> 265:   output()->print("%s(", name);

Do we need a matching ')' somewhere?

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

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

From dlong at openjdk.java.net  Thu Feb 10 22:59:22 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 10 Feb 2022 22:59:22 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <hVISNCqlIQFhbaEtg8RdNy96i6pHPthDAoBX2ixdKeM=.e8d9030f-b710-48f9-8b4e-afc235ae39a0@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

Looks reasonable.  I just had a few questions (inline comments).

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

Marked as reviewed by dlong (Reviewer).

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

From eastig at amazon.co.uk  Thu Feb 10 23:02:08 2022
From: eastig at amazon.co.uk (Astigeevich, Evgeny)
Date: Thu, 10 Feb 2022 23:02:08 +0000
Subject: RFC: AArch64: Set Segmented CodeCache default size to 127M
Message-ID: <64AB1C1E-4151-4979-BF15-CC71D00E98DB@amazon.com>

Hello,

We?d like to discuss a proposal for setting TieredCompilation Segmented CodeCache default size to 127M on AArch64 (https://bugs.openjdk.java.net/browse/JDK-8280150).

The current default size of TieredCompilation CodeCache is 240M: 116M "non-profiled" segment + 116M "profiled" segment + 8M "non-nmethods" segment. AArch64 ISA has direct calls and jumps range limited to 128M. The C1/C2 compilers generate far jumps, calls and trampolines to overcome the limitation of direct jumps/calls. They use MacroAssembler::far_branches which compares ReservedCodeCacheSize with the direct jumps/calls range. With 240M CodeCache JIT has to use far jumps/trampolines. Such far jumps/trampolines result in performance and code size overhead.

Our observations [1] suggest most applications running on AArch64 platforms have hot code not exceeding 128M.

AArch64 has a default ReservedCodeCacheSize of 48M. For tiered compilation the value is multiplied by 5 getting it to 240M. We experimented with CodeCache configuration: 48M "non-profiled" segment + 48M "profiled" segment + 8M "non-nmethods" segment. We ran SpecJbb2015, DaCapo at f480064 (https://github.com/dacapobench/dacapobench/tree/dev-chopin), Renaissance 0.14, and internal services.

We did not see any statistically significant regressions. SpecJbb improved max-jOPS by +1.68% and critical-jOPS by +1.34%. For DaCapo, eclipse improved by 3.57%, tomcat by 1.45% and tradesoap by 3.03%. Only two Renaissance benchmarks had statistically significant results: dotty (+9.0%)  and finagle-http (+3.9%). Others had changes which were comparable with the coefficient of variation. All benchmarks had significant decreases in max use of the non-profiled and profiled segments (see data below).

To mitigate risks of 104M not being enough we?d like to change the default size of TieredCompilation CodeCache to 127M (which is just below the size where the JIT would generate far jumps and trampolines): 60M "non-profiled" segment + 60M "profiled" segment + 7M "non-nmethods" segment. We did partial runs with 127M CodeCache. Their results were similar to the 104M configuration.

Average maximum used memory(Kb) in segments (it was checked numbers of compiled methods were similar in both cases):

NPS=non-profiled segment
PS=profiled segment
NNS=non-nmethods segment

SpecJbb
+----------+---------+--------+---------+--------+--------+----------+---------+----------+
| 116M NPS | 116M PS | 8M NNS | 48M NPS | 48M PS | 8M NNS | diff NPS | diff PS | diff NNS |
+----------+---------+--------+---------+--------+--------+----------+---------+----------+
|    12491 |   13968 |   4274 |   10649 |  12276 |   4234 | -14.7%   | -12.1%  | -0.9%    |
+----------+---------+--------+---------+--------+--------+----------+---------+----------+

DaCapo
+------------+----------+---------+--------+---------+--------+--------+----------+---------+----------+
| benchmark  | 116M NPS | 116M PS | 8M NNS | 48M NPS | 48M PS | 8M NNS | diff NPS | diff PS | diff NNS |
+------------+----------+---------+--------+---------+--------+--------+----------+---------+----------+
| avrora     |    2301  |   6324  |  4167  |   1887  |  5049  |  4080  | -18.00%  | -20.20% | -2.10%   |
| batik      |    6108  |   5301  |  4128  |   4686  |  4289  |  4114  | -23.30%  | -19.10% | -0.30%   |
| biojava    |    2018  |   5907  |  4047  |   1703  |  5364  |  4026  | -15.60%  | -9.20%  | -0.50%   |
| eclipse    |   30862  |  26824  |  4275  |  27314  | 24330  |  4180  | -11.50%  | -9.30%  | -2.20%   |
| jme        |    1567  |   5987  |  3502  |   1315  |  5205  |  3491  | -16.10%  | -13.10% | -0.30%   |
| lusearch   |    5424  |   9145  |  4201  |   4699  |  7147  |  4100  | -13.40%  | -21.90% | -2.40%   |
| pmd        |   12011  |  14438  |  4232  |  10701  | 12456  |  4140  | -10.90%  | -13.70% | -2.20%   |
| sunflow    |    1707  |   4341  |  4082  |   1220  |  3174  |  4040  | -28.60%  | -26.90% | -1.00%   |
| tomcat     |   15228  |  23595  |  4292  |  13519  | 20686  |  4187  | -11.20%  | -12.30% | -2.50%   |
| graphchi   |    1243  |   5238  |  4009  |   1063  |  4375  |  3998  | -14.50%  | -16.50% | -0.30%   |
| xalan      |    5270  |   8363  |  4191  |   4784  |  6643  |  4100  | -9.20%   | -20.60% | -2.20%   |
| fop        |   11597  |  20814  |  4336  |  10361  | 18485  |  4256  | -10.70%  | -11.20% | -1.80%   |
| luindex    |    4013  |   5531  |  3697  |   3083  |  4384  |  3507  | -23.20%  | -20.70% | -5.20%   |
| zxing      |    4577  |   7267  |  4255  |   4044  |  5820  |  4164  | -11.60%  | -19.90% | -2.10%   |
| tradebeans |   10313  |  26983  |  4603  |   9210  | 24954  |  4522  | -10.70%  | -7.50%  | -1.80%   |
| tradesoap  |   16939  |  35276  |  4649  |  15245  | 30888  |  4549  | -10.00%  | -12.40% | -2.10%   |
+------------+----------+---------+--------+---------+--------+--------+----------+---------+----------+

Renaissance
+------------------+----------+---------+--------+---------+--------+--------+----------+---------+----------+
|    benchmark     | 116M NPS | 116M PS | 8M NNS | 48M NPS | 48M PS | 8M NNS | diff NPS | diff PS | diff NNS |
+------------------+----------+---------+--------+---------+--------+--------+----------+---------+----------+
| akka-uct         |     4053 |    9615 |   3661 |    3001 |   8381 |   3559 | -26.00%  | -12.80% | -2.80%   |
| als              |    20732 |   39367 |   4554 |   18914 |  32400 |   4464 | -8.80%   | -17.70% | -2.00%   |
| chi-square       |     7922 |   23568 |   3828 |    7160 |  20603 |   3759 | -9.60%   | -12.60% | -1.80%   |
| dec-tree         |    23938 |   55512 |   4026 |   21857 |  36866 |   3946 | -8.70%   | -33.60% | -2.00%   |
| dotty            |    42405 |   40963 |   3712 |   37997 |  32770 |   3621 | -10.40%  | -20.00% | -2.50%   |
| finagle-chirper  |    21150 |   19833 |   3795 |   18652 |  17479 |   3693 | -11.80%  | -11.90% | -2.70%   |
| finagle-http     |    11950 |   19553 |   3778 |   10675 |  17234 |   3709 | -10.70%  | -11.90% | -1.80%   |
| fj-kmeans        |      960 |    4756 |   3504 |     882 |   4437 |   3484 | -8.10%   | -6.70%  | -0.60%   |
| future-genetic   |     1760 |    5470 |   3526 |    1466 |   4449 |   3497 | -16.70%  | -18.70% | -0.80%   |
| gauss-mix        |    11910 |   21406 |   4459 |   10675 |  18741 |   4382 | -10.40%  | -12.40% | -1.70%   |
| log-regression   |    25230 |   42802 |   4108 |   22791 |  34542 |   3989 | -9.70%   | -19.30% | -2.90%   |
| mnemonics        |     1094 |    3914 |   3501 |    1010 |   3669 |   3480 | -7.70%   | -6.30%  | -0.60%   |
| movie-lens       |    20571 |   23472 |   4495 |   18500 |  20728 |   4424 | -10.10%  | -11.70% | -1.60%   |
| naive-bayes      |    24305 |   45967 |   4030 |   22124 |  35135 |   3929 | -9.00%   | -23.60% | -2.50%   |
| page-rank        |     9386 |   24226 |   3817 |    8554 |  22081 |   3769 | -8.90%   | -8.90%  | -1.30%   |
| par-mnemonics    |     1217 |    4318 |   3501 |    1128 |   4098 |   3477 | -7.30%   | -5.10%  | -0.70%   |
| philosophers     |     2647 |    5765 |   3571 |    2146 |   4293 |   3506 | -18.90%  | -25.50% | -1.80%   |
| reactors         |     2663 |    5266 |   3632 |    2278 |   4321 |   3513 | -14.50%  | -17.90% | -3.30%   |
| rx-scrabble      |     2511 |    6721 |   3535 |    2131 |   5037 |   3506 | -15.10%  | -25.10% | -0.80%   |
| scala-doku       |     2106 |    6408 |   3522 |    1775 |   4744 |   3500 | -15.70%  | -26.00% | -0.60%   |
| scala-kmeans     |     1104 |    4634 |   3497 |    1002 |   4345 |   3481 | -9.20%   | -6.20%  | -0.50%   |
| scala-stm-bench7 |     3492 |    6611 |   3601 |    3158 |   5302 |   3509 | -9.60%   | -19.80% | -2.60%   |
| scrabble         |     1816 |    6046 |   3546 |    1460 |   4902 |   3496 | -19.60%  | -18.90% | -1.40%   |
+------------------+----------+---------+--------+---------+--------+--------+----------+---------+----------+

[1] CodeCache usage data from:
- Latest versions of SpecJbb, DaCapo and Renaissance benchmarks.
- An internal service with 15000+ compiled Java methods running without compilation issues with 64M CodeCache (TieredCompilation off) and with 127M segmented CodeCache.
- A recommendation to use 64M CodeCache (TieredCompilation off) to improve performance (https://github.com/aws/aws-graviton-getting-started/blob/main/java.md).
- IDEs like IntelliJ, CLion can use more 130M but they don't rely on the default values.




Amazon Development Centre (London) Ltd. Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.



From john.r.rose at oracle.com  Fri Feb 11 01:05:04 2022
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 10 Feb 2022 17:05:04 -0800
Subject: RFR: 8281518: New optimization: convert "(x|y)-(x^y)" into "x&y"
 [v2]
In-Reply-To: <u97sqQBMcY_fyRFQ-GUwdE6Os0BEjcXzD4Z3diVsjew=.4c1cec7d-8aa7-4f11-ac7d-f9f5415e40c7@github.com>
References: <dmGc0I10NzFCl_MpsqOvDrGVGtUfbg7aPlpYST5cNLg=.96791cca-c083-4044-ae7f-1e532acc10c6@github.com>
 <FeIn4hGaYHxneO0fJHttSXcG1969Zema1B6WwsImj2Q=.62002457-5b45-47f6-87ac-8a910391d004@github.com>
 <u97sqQBMcY_fyRFQ-GUwdE6Os0BEjcXzD4Z3diVsjew=.4c1cec7d-8aa7-4f11-ac7d-f9f5415e40c7@github.com>
Message-ID: <79DB54F0-2737-4B99-A833-B465070B4A57@oracle.com>

On 9 Feb 2022, at 8:38, Quan Anh Mai wrote:

>> For clarification, my idea is to look at GCC and clang's codebases to 
>> see if there is a more general way to achieve every transformation 
>> elegantly instead of naively matching every combination, which may 
>> mitigate the cost for each additional transformation.
>

Yes, that thought occurred to me as well.  It seems like we are on the 
verge of seeing dozens of identities like the currently proposed one, 
each with its own wad of hand-maintained optimizer code.  On balance it 
will make the optimizer harder to maintain.  That would be OK if it got 
us significant performance benefit, but surely it doesn?t.

What *would* get us benefit in a cost-effective way would be to take 
this optimization and several previous ones (and future ones) and 
refactor them into a single comprehensive analysis based on truth 
tables, which would normalize bitwise expressions up to some particular 
complexity (say, up to three input variables and up to depth 2, with 
variety of operators).  This is a minor research project, but (I think) 
a worthy one.

? John

From dlong at openjdk.java.net  Fri Feb 11 02:29:08 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Feb 2022 02:29:08 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <5JpjYn4xFLnWVCQ-FPp4wN__zUwIZEkW0mm2eIINkcA=.93fe90cf-6bf3-492c-af03-ff0d1d2938e7@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

Marked as reviewed by dlong (Reviewer).

Looks good.  Is there any reason why we had this optimization for invokedynamic but not invokehandle?

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

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

From kvn at openjdk.java.net  Fri Feb 11 03:30:05 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 03:30:05 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <hOnwrRUSK3rkukv6fU-H8vpnhlKF0RArS_2vEgG-ymw=.6d6da3fb-7a8d-450a-9210-12b97cc11188@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

Marked as reviewed by kvn (Reviewer).

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

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

From vladimir.kozlov at oracle.com  Fri Feb 11 04:07:18 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 10 Feb 2022 20:07:18 -0800
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
Message-ID: <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>

For this simple case we can teach C2's IGVN to split fields loads through Phi so that phi(p0, p1) is not used and 
allocations as well. We can do that because we know that allocations and phi do not escape.

public int ex1(boolean cond, int first, int second) {
     p0 = Allocate(...);
     ...
     p0.x = first;
     p0.y = second;

     if (cond) {
         p1 = Allocate(...);
         ...
         p1.x = second;
         p1.y = first;
     }

     p = phi(p0, p1) // unused and will be removed


     return phi(p0.x,p1.x) - phi(p0.y, p1.y);
}

Thanks,
Vladimir K

On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
> 
> Hi Cesar,
> 
> Thanks for looking into enhancing EA.
> 
> Overall, the proposal looks reasonable.
> 
> I suggest to look more closely at split_unique_types().
> It introduces a dedicated class of alias categories for fields of the allocation being eliminated and clones memory 
> graph. I don't see why it shouldn't work for multiple allocations.
> 
> Moreover, split_unique_types() will break if you start optimizing multiple allocations at once. The notion of unique 
> alias should be adjusted and cover the union of unique aliases for all interacting allocations.
> 
> Seems like you need to enhance SR to work on non-intersecting clusters of allocations.
> 
> One thing to take care of: scalar replacement relies on TypeOopPtr::instance_id().
> 
>  ? // If not InstanceTop or InstanceBot, indicates that this is
>  ? // a particular instance of this type which is distinct.
>  ? // This is the node index of the allocation node creating this instance.
>  ? int?????????? _instance_id;
> 
> It'll break when multiple allocations are in play.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>> Hi there again!
>>
>> Can you please give me feedback on the following approach to at least partially
>> address [1], the scalar replacement allocation merge issue?
>>
>> The problem that I am trying to solve arises when allocations are merged after a
>> control flow split. The code below shows _one example_ of such a situation.
>>
>> public int ex1(boolean cond, int x, int y) {
>> ?? ? Point p = new Point(x, y);
>> ?? ? if (cond)
>> ?? ? ? ? p = new Point(y, x);
>> ?? ? // Allocations for p are merged here.
>> ?? ? return p.calc();
>> }
>>
>> Assuming the method calls on "p" are inlined then the allocations will not
>> escape the method. The C2 IR for this method will look like this:
>>
>> public int ex1(boolean cond, int first, int second) {
>> ?? ? p0 = Allocate(...);
>> ?? ? ...
>> ?? ? p0.x = first;
>> ?? ? p0.y = second;
>>
>> ?? ? if (cond) {
>> ?? ? ? ? p1 = Allocate(...);
>> ?? ? ? ? ...
>> ?? ? ? ? p1.x = second;
>> ?? ? ? ? p1.y = first;
>> ?? ? }
>>
>> ?? ? p = phi(p0, p1)
>>
>> ?? ? return p.x - p.y;
>> }
>>
>> However, one of the constraints implemented here [2], specifically the third
>> one, will prevent the objects from being scalar replaced.
>>
>> The approach that I'm considering for solving the problem is to replace the Phi
>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of the objects
>> in the original Phi. The IR for `ex1` would look something like this after the
>> transformation:
>>
>> public int ex1(boolean cond, int first, int second) {
>> ?? ? p0 = Allocate(...);
>> ?? ? ...
>> ?? ? p0.x = first;
>> ?? ? p0.y = second;
>>
>> ?? ? if (cond) {
>> ?? ? ? ? p1 = Allocate(...);
>> ?? ? ? ? ...
>> ?? ? ? ? p1.x = second;
>> ?? ? ? ? p1.y = first;
>> ?? ? }
>>
>> ?? ? pX = phi(first, second)
>> ?? ? pY = phi(second, first)
>>
>> ?? ? return pX - pY;
>> }
>>
>> I understand that this transformation might not be applicable for all cases and
>> that it's not as simple as illustrated above. Also, it seems to me that much of
>> what I'd have to implement is already implemented in other steps of the Scalar
>> Replacement pipeline (which is a good thing). To work around these
>> implementation details I plan to use as much of the existing code as possible.
>> The algorithm for the transformation would be like this:
>>
>> split_phis(phi)
>> ?? ? # If output of phi escapes, or something uses its identity, etc
>> ?? ? # then we can't remove it. The conditions here might possible be the
>> ?? ? # same as the ones implemented in `PhaseMacroExpand::can_eliminate_allocation`
>> ?? ? if cant_remove_phi_output(phi)
>> ?? ? ? ? return ;
>>
>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses field F
>> ?? ? # member of the object resulting from `phi`.
>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>
>> ?? ? foreach field in fields_used
>> ?? ? ? ? producers = {}
>>
>> ?? ? ? ? # Create a list with the last Store for each field "field" on the
>> ?? ? ? ? # scope of each of the Phi input objects.
>> ?? ? ? ? foreach o in phi.inputs
>> ?? ? ? ? ? ? # The function called below might re-use a lot of the code/logic in `PhaseMacroExpand::scalar_replacement`
>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 'field'
>> ?? ? ? ? field_phi = create_new_phi(producers)
>>
>> ?? ? ? ? update_consumers(field, field_phi)
>>
>> The implementation that I envisioned would be as a "pre-process" [3] step just
>> after EA but before the constraint checks in `adjust_scalar_replaceable_state`
>> [2]. If we agree that the overall Scalar Replacement implementation goes through
>> the following major phases:
>>
>> ?? ? 1. Identify the Escape Status of objects.
>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>> ?? ? 3. Make call to Split_unique_types [4].
>> ?? ? 4 Iterate over object and array allocations.
>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>
>> The transformation that I am proposing would change the overall flow to look
>> like this:
>>
>> ?? ? 1. Identify the Escape Status of objects.
>> ?? ? 2. ----> New: "Split phi functions" <----
>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>> ?? ? 3. Make call to Split_unique_types [14].
>> ?? ? 4 Iterate over object and array allocations.
>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be eliminated" <----
>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>
>> Please let me know what you think and thank you for taking the time to review
>> this!
>>
>>
>> Regards,
>> Cesar
>>
>> Notes:
>>
>> ?? ? [1] I am not sure yet how this approach will play with the case of a merge
>> ?? ? ? ? with NULL.
>> ?? ? [2] 
>> https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809
>>
>> ?? ? [3] Another option would be to "patch" the current implementation to be able
>> ?? ? ? ? to handle the merges. I am not certain that the "patch" approach would be
>> ?? ? ? ? better, however, the "pre-process" approach is certainly much easier to test
>> ?? ? ? ? and more readable.
>>
>> ?? ? [4] I cannot say I understand 100% the effects of executing
>> ?? ? ? ? split_unique_types(). Would the transformation that I am proposing need to
>> ?? ? ? ? be after the call to split_unique_types?

From kvn at openjdk.java.net  Fri Feb 11 04:23:08 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 04:23:08 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase
In-Reply-To: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
Message-ID: <OS4s7Rl0mM2VfOEsuOKYq2LpFy1HddxIQLYtcUqhgjk=.a092475b-aefc-4ca2-a895-0e258466d101@github.com>

On Tue, 8 Feb 2022 22:34:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
> 
> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
> 
> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
> 
> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
> 
> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
> 
> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
> 
> Please review,
> Nils Eliasson

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Fri Feb 11 04:26:07 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 04:26:07 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <erloLRpiqEtP6iHIpqf_cx1pneLaO9CtL2439yjse1g=.7a35a8de-39d2-481a-87f7-4428ecbd0180@github.com>

On Thu, 10 Feb 2022 22:12:53 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

Nice. I will run testing to make sure they work in all configurations (which we testing).

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

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

From kvn at openjdk.java.net  Fri Feb 11 04:55:08 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 04:55:08 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <HbuWXG6EFwBZZyOpmJYek25TCaPvSCDSf5Oyl76lmR8=.39fdcf80-30db-46e7-9854-92148128a4f0@github.com>

On Thu, 10 Feb 2022 22:12:53 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

I got compilation failures for new tests. For example:

test/hotspot/jtreg/compiler/c2/irTests/SubLNodeIdealizationTests.java:83: error: cannot find symbol
    @IR(failOn = {IRNode.SUB})
                        ^
  symbol:   variable SUB
  location: class IRNode

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

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

From stuefe at openjdk.java.net  Fri Feb 11 05:38:18 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Feb 2022 05:38:18 GMT
Subject: RFR: JDK-8281522: Rename ADLC classes which have the same name as
 hotspot variants
In-Reply-To: <W4ddIRFF2b-KCq0rdM_2Gxt3uWM8juyPGAvO5wX-SWs=.863c3551-0cc7-47d5-9a6d-b4b887db90eb@github.com>
References: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
 <W4ddIRFF2b-KCq0rdM_2Gxt3uWM8juyPGAvO5wX-SWs=.863c3551-0cc7-47d5-9a6d-b4b887db90eb@github.com>
Message-ID: <6TNS_lsIse7XYATzIy6uUaLw4rrM-a79IjeiNl5dOZI=.05951bc5-86bd-499b-b450-95ca46336398@github.com>

On Thu, 10 Feb 2022 16:14:39 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> After some prior offlist discussions with Oracle staff, I propose to change the names of some of the adlc classes and functions to avoid name clashes with their hotspot counterparts. This has bugged me for a while since my IDE gets often confused about this when working on hotspot arena code.
>> 
>> This patch prefixes "Arena", "Chunk", "CHeapObj" and "AllStatic", "AllocateHeap", "ReallocateHeap" with "Adl...". The replacement is purely mechanical, no functional change happens here.
>> 
>> Thanks, Thomas
>
> Looks good!

Thanks @neliasso and @vnkozlov

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

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

From stuefe at openjdk.java.net  Fri Feb 11 05:38:19 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 11 Feb 2022 05:38:19 GMT
Subject: Integrated: JDK-8281522: Rename ADLC classes which have the same name
 as hotspot variants
In-Reply-To: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
References: <2K2L9feknYiYQ6mH09KJ8Nrb1_pBAtoVmymqU0-1FqE=.59fc5002-0c6c-4b08-8ef7-38552ac32cec@github.com>
Message-ID: <ppIzPXqVzJ7-Hdar8ZzSFW8xoDjJoCAxc83YmBP1ARk=.5a7cfdd6-81dd-4570-b140-0fce10a70f6e@github.com>

On Wed, 9 Feb 2022 08:10:04 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> After some prior offlist discussions with Oracle staff, I propose to change the names of some of the adlc classes and functions to avoid name clashes with their hotspot counterparts. This has bugged me for a while since my IDE gets often confused about this when working on hotspot arena code.
> 
> This patch prefixes "Arena", "Chunk", "CHeapObj" and "AllStatic", "AllocateHeap", "ReallocateHeap" with "Adl...". The replacement is purely mechanical, no functional change happens here.
> 
> Thanks, Thomas

This pull request has now been integrated.

Changeset: eee6a562
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eee6a5622dca683d4d6a701daa48e09e8d17b54e
Stats:     726 lines in 13 files changed: 346 ins; 346 del; 34 mod

8281522: Rename ADLC classes which have the same name as hotspot variants

Reviewed-by: neliasso, kvn

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

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

From chagedorn at openjdk.java.net  Fri Feb 11 08:05:04 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 11 Feb 2022 08:05:04 GMT
Subject: RFR: 8281539: IGV: schedule approximation computes immediate
 dominators wrongly
In-Reply-To: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
References: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
Message-ID: <bz637SG_e7itKBMK3fw1fqW-6VCXmUVsHtUNAevd4yE=.63731a01-6136-4cae-a477-c3437d0362f9@github.com>

On Wed, 9 Feb 2022 15:16:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The `ServerCompiler` module in IGV computes an approximation of C2's schedule for unscheduled graphs, for clustering and showing control flow information in the "Control Flow" window. This approximation uses domination information to guide the scheduling of nodes into basic blocks. Currently, this information is computed with a custom algorithm implementation that gives wrong results for some graphs, as shown in [the issue report](https://bugs.openjdk.java.net/browse/JDK-8281539).
> 
> This change simply replaces the custom implementation with one from the [T. J. Watson Libraries for Analysis (WALA)](https://github.com/wala/WALA), a popular set of static analysis libraries licensed under the [OSI](http://www.opensource.org/)-approved [Eclipse Public License](http://www.eclipse.org/legal/epl-v10.html). The replacement gives correct domination information for the reported graphs and reduces significantly the complexity of the `ServerCompiler` module.
> 
> #### Testing
> 
> - Tested manually that the dominator tree computed for a few selected graphs (included the reported one) is correct.
> - Tested manually, for large graphs, that the dominator tree computation takes a negligible fraction (around 1%) of the entire graph scheduling time.
> - Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From chagedorn at openjdk.java.net  Fri Feb 11 08:25:09 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 11 Feb 2022 08:25:09 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <6vCeELhT5JAv16U7xeag4cpK0sekIUzUaBV2QGikISw=.f894dfa4-cd8c-42a8-84c5-9e2f8e0391ff@github.com>

On Thu, 10 Feb 2022 22:12:53 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

Nice work! Thanks for coming back to this with the updates. I'll have a closer look next week.

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

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

From roland at openjdk.java.net  Fri Feb 11 09:05:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 11 Feb 2022 09:05:10 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <1saTsa87zgK9VX5VElTKmZ0hI3DAbvbq2pSJnNzJjmk=.8083a165-f7da-47a0-81df-fd6581c01f32@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
 <TE0IyQyh0FW5kw1R58fEgOkkJu7sljnL5h7Ia-EskmI=.d4e371d9-0c99-470b-9c98-a0fb6f5d736f@github.com>
 <1saTsa87zgK9VX5VElTKmZ0hI3DAbvbq2pSJnNzJjmk=.8083a165-f7da-47a0-81df-fd6581c01f32@github.com>
Message-ID: <qSjDndno80V4JxbH5V6DI-qDu_bWfaud_kkQ2HBivEM=.8590d272-8fa3-4f93-8ef1-6ac6e451451e@github.com>

On Thu, 10 Feb 2022 19:32:55 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/graphKit.cpp line 3977:
>> 
>>> 3975:   Node* valid_length_test = _gvn.intcon(1);
>>> 3976:   if (ary_type->klass()->is_array_klass()) {
>>> 3977:     BasicType bt = ary_type->klass()->as_array_klass()->element_type()->basic_type();
>> 
>> FTR `array_element_basic_type()` is more appropriate here. 
>> `basic_type()` reports `T_INT` for all sub-word element types and it may lead to underestimation of maximum array length.
>
> Thinking more about it, it seems like a bug. For a large enough allocation, it may erroneously classify it as erroneous. Will it trigger wrong exception being thrown?

Thanks for looking at this.
That's not what I observe. bt = T_BYTE for new byte[..].

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

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

From nils.eliasson at oracle.com  Fri Feb 11 09:38:42 2022
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Fri, 11 Feb 2022 10:38:42 +0100
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
Message-ID: <4fe4310c-9509-3ab7-fefe-e8e2edffd402@oracle.com>

This is also useful if only one of the paths are a local allocation. We 
must just be sure that the original phi actually can be removed.

public int ex1(boolean cond, int first, int second) {

 ??? p0 = call(...)

 ??? if (cond) {
 ??????? p1 = Allocate(...);
 ??????? ...
 ??????? p1.x = second;
 ??????? p1.y = first;
 ??? }

 ??? p = phi(p0, p1) // unused and will be removed


 ??? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
}

Regards,
Nils

On 2022-02-11 05:07, Vladimir Kozlov wrote:
> For this simple case we can teach C2's IGVN to split fields loads 
> through Phi so that phi(p0, p1) is not used and allocations as well. 
> We can do that because we know that allocations and phi do not escape.
>
> public int ex1(boolean cond, int first, int second) {
> ??? p0 = Allocate(...);
> ??? ...
> ??? p0.x = first;
> ??? p0.y = second;
>
> ??? if (cond) {
> ??????? p1 = Allocate(...);
> ??????? ...
> ??????? p1.x = second;
> ??????? p1.y = first;
> ??? }
>
> ??? p = phi(p0, p1) // unused and will be removed
>
>
> ??? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
> }
>
> Thanks,
> Vladimir K 


From thartmann at openjdk.java.net  Fri Feb 11 09:49:07 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Feb 2022 09:49:07 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v2]
In-Reply-To: <EPhDMRb-8V_7XtzGiD5-xNUCyMubRPCOrDGhw6Lyy_U=.216476ae-e92e-4642-bb7a-baf8d779f0bf@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <EPhDMRb-8V_7XtzGiD5-xNUCyMubRPCOrDGhw6Lyy_U=.216476ae-e92e-4642-bb7a-baf8d779f0bf@github.com>
Message-ID: <JzYKGrGMEvF_bOwrIdiWZBJSJmzHgWGm168_Tb2gcg4=.4b6a9293-bf1e-4caa-8631-8f2e96785562@github.com>

On Wed, 9 Feb 2022 10:23:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The bytecode of the 2 methods of the benchmark is structured
>> differently: loopsWithSharedLocal(), the slowest one, has multiple
>> backedges with a single head while loopsWithScopedLocal() has a single
>> backedge and all the paths in the loop body merge before the
>> backedge. loopsWithSharedLocal() has its head cloned which results in
>> a 2 loops loop nest.
>> 
>> loopsWithSharedLocal() is slow when 2 of the backedges are most
>> commonly taken with one taken only 3 times as often as the other
>> one. So a thread executing that code only runs the inner loop for a
>> few iterations before exiting it and executing the outer loop. I think
>> what happens is that any time the inner loop is entered, some
>> predicates are executed and the overhead of the setup of loop strip
>> mining (if it's enabled) has to be paid. Also, if iteration
>> splitting/unrolling was applied, the main loop is likely never
>> executed and all time is spent in the pre/post loops where potentially
>> some range checks remain.
>> 
>> The fix I propose is that ciTypeFlow, when it clone heads, not only
>> rewires the most frequent loop but also all this other frequent loops
>> that share the same head. loopsWithSharedLocal() and
>> loopsWithScopedLocal() are then fairly similar once c2 parses them.
>> 
>> Without the patch I measure:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
>> 
>> with it:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
>> 
>> But this patch also causes a regression when running one of the
>> benchmarks added by 8278518. From:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
>> 
>> to:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
>> 
>> The hot method of this benchmark used to be compiled with 2 loops, the
>> inner one a counted loop. With the patch, it's now compiled with a
>> single one which can't be converted into a counted loop because the
>> loop variable is incremented by a different amount along the 2 paths
>> in the loop body. What I propose to fix this is to add a new loop
>> transformation that detects that, because of a merge point, a loop
>> can't be turned into a counted loop and transforms it into 2
>> loops. The benchmark performs better with this:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
>> 
>> Not quite on par with the previous score but AFAICT this is due to
>> code generation not being as good (the loop head can't be aligned in
>> particular).
>> 
>> In short, I propose:
>> 
>> - changing ciTypeFlow so that, when it pays off, a loop with
>> multiple backedges is compiled as a single loop with a merge point in
>> the loop body
>> 
>> - adding a new loop transformation so that, when it pays off, a loop
>> with a merge point in the loop body is converted into a 2 loops loop
>> nest, essentially the opposite transformation.
>
> 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:
> 
>  - fix
>  - Merge branch 'master' into JDK-8279888
>  - whitespaces
>  - fix & test

Testing now passed but I need more time to review this.

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

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

From thartmann at openjdk.java.net  Fri Feb 11 10:01:08 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Feb 2022 10:01:08 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination [v2]
In-Reply-To: <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
 <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
Message-ID: <35zlqTS7tCHO6GO-5GnhU0-MU2S5FKUr-sAtuiPtcEA=.f37b9ac4-4224-4d2a-8088-3c46d0a49019@github.com>

On Wed, 9 Feb 2022 12:55:39 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The loop exit condition of the test method:
>> 
>> if (i == stop) {
>>     break;
>> }
>> 
>> requires insertion of a loop limit predicate when the loop is turned
>> into a counted loop. stop is a LoadI. Next:
>> 
>> array[stop - i + j] = 0;
>> 
>> is transformed to:
>> 
>> array[stop - i] = 0;
>> 
>> and the range check for that array access becomes candidate for
>> predication in a subsequent loop opts pass. stop has control just
>> above the loop limit check when that happens (because it is assigned
>> control as late as possible). But the loop predicate for the bound
>> check needs to be above the loop limit check and that causes the
>> assert failure.
>> 
>> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
>> to assign control to nodes above predicates so this sort of issues
>> doesn't occur. But it only applies to node initially on the entry
>> projection right above the loop head. The fix I propose is to remove
>> that restriction.
>> 
>> That logic was added by JDK-8203197 and looking back at this change I
>> noticed I replaced some existing logic with the current logic but,
>> while the 2 overlap, the current logic is not guaranteed to always
>> cover some cases handled by the old logic. So I resurrected that old
>> logic here.
>> 
>> Finally, when running tests, I hit failures because Opaque nodes for
>> skeleton predicates can now end up above a predicate that is split
>> thru phi. That causes the Opaque nodes to be split up and breaks
>> pattern matching. I'm actually not sure this issue is specific to the
>> change here so I think it's best to treat it as a general issue and
>> fix it by cloning the chain of nodes that lead to the Opaque node
>> down.
>
> 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 three additional commits since the last revision:
> 
>  - fix
>  - Merge branch 'master' into JDK-8280799
>  - fix & test

All tests passed and the fix looks reasonable to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Fri Feb 11 10:09:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Feb 2022 10:09:05 GMT
Subject: RFR: 8281322: irTests/TestLongRangeChecks.java fails with strip
 mining off
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <U5mhGwub7FLr-KdEUBnW4nhMucQneRs_i-cAtJQS1AE=.bd326571-d143-4f81-802b-0cf236676848@github.com>

On Mon, 7 Feb 2022 08:53:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

For the record: Christian's testing found issues (he reported them to Roland already).

I think it would be good to change the bug title to something more descriptive.

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

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

From thartmann at openjdk.java.net  Fri Feb 11 10:17:06 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Feb 2022 10:17:06 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase
In-Reply-To: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
Message-ID: <tANm_TGNy6XHZQ56MpsafqE29qzp6pJY3A4QTSKvuPk=.4e4c8134-2eaa-4564-88ff-c5c8d426758a@github.com>

On Tue, 8 Feb 2022 22:34:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
> 
> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
> 
> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
> 
> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
> 
> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
> 
> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
> 
> Please review,
> Nils Eliasson

Looks good to me.

test/hotspot/jtreg/compiler/oracle/PrintIdealPhaseTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

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

Marked as reviewed by thartmann (Reviewer).

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

From vlivanov at openjdk.java.net  Fri Feb 11 10:21:05 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 11 Feb 2022 10:21:05 GMT
Subject: RFR: 8256368: Avoid repeated upcalls into Java to re-resolve MH/VH
 linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <JP9U1gVxEHsAmUvJt7u8NWPPL1NNzKLAzRinQnivx3o=.7e3e5e15-7e70-4cdc-a5ca-e81ce1b8b726@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

Thanks for the reviews, Vladimir and Dean.

> Is there any reason why we had this optimization for invokedynamic but not invokehandle?

It's optional for `invokehandle`, but mandatory for `invokedynamic`. 

`invokedynamic` can be linked by arbitrary user code (as part of bootstrap method execution) and calling BSM multiple times would violate the JVMS. There are no guarantees about BSM behavior, so it can produce different results on repeated invocations. 

In contrast, `invokehandle` is linked solely by trusted code (`MethodHandleNatives.linkMethod`) and it's fine to re-resolve the call site on failure (`LinkageError`), since the result should be the same (unless it was an intermittent JVM failure, like OOM or StackOverflowError).

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

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

From vlivanov at openjdk.java.net  Fri Feb 11 10:26:09 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 11 Feb 2022 10:26:09 GMT
Subject: RFR: 8279219: [REDO] C2 crash when allocating array of size too
 large [v3]
In-Reply-To: <qSjDndno80V4JxbH5V6DI-qDu_bWfaud_kkQ2HBivEM=.8590d272-8fa3-4f93-8ef1-6ac6e451451e@github.com>
References: <U_ThWuyAqrSN3H0YPZTOcm3dQAasZtJcNbp-Dmmh-48=.dca0074b-c11b-44b1-aa79-bbb15fe78cb7@github.com>
 <w9deI5ZRCRjHVcXDpUHQRC7YMcZib_NS2qmHxvVnl3U=.baa70828-4fc7-4da3-8bd4-f62b57b1220f@github.com>
 <TE0IyQyh0FW5kw1R58fEgOkkJu7sljnL5h7Ia-EskmI=.d4e371d9-0c99-470b-9c98-a0fb6f5d736f@github.com>
 <1saTsa87zgK9VX5VElTKmZ0hI3DAbvbq2pSJnNzJjmk=.8083a165-f7da-47a0-81df-fd6581c01f32@github.com>
 <qSjDndno80V4JxbH5V6DI-qDu_bWfaud_kkQ2HBivEM=.8590d272-8fa3-4f93-8ef1-6ac6e451451e@github.com>
Message-ID: <R4mJtNtYqvXnGFCyBryUK9e9AwmlZUqqfAQbzGXPc84=.dd48b96f-bef1-4922-8411-a84ee08b3ed9@github.com>

On Fri, 11 Feb 2022 09:01:20 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Thinking more about it, it seems like a bug. For a large enough allocation, it may erroneously classify it as erroneous. Will it trigger wrong exception being thrown?
>
> Thanks for looking at this.
> That's not what I observe. bt = T_BYTE for new byte[..].

You are right. (Was looking at it in the context of #6717.)

I missed that it is `ciArrayKlass::element_type()` which returns `ciType*` (instead of `Type*`) and `ciTypeArrayKlass::element_type()` relies on `Klass::layout_helper_element_type` to acquire proper element type. 

Sorry for the noise.

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

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

From vlivanov at openjdk.java.net  Fri Feb 11 10:34:05 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 11 Feb 2022 10:34:05 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <kowwDoElyew1G0MGX0QV9LUxdbUm67RJmHUBs4RV_WQ=.4cf19ca0-7306-4b49-bd98-7d874d840508@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
 <kowwDoElyew1G0MGX0QV9LUxdbUm67RJmHUBs4RV_WQ=.4cf19ca0-7306-4b49-bd98-7d874d840508@github.com>
Message-ID: <ZLpsjk6EAJUU-kpOMnMLo5iNr0ZXhJrlLn4WFbkFSos=.ad1a3fbd-17a8-4057-a3db-422896cb60e4@github.com>

On Thu, 10 Feb 2022 22:50:56 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
>> 
>> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
>> 
>> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
>> 
>> Testing: hs-tier1 - hs-tier4
>
> src/hotspot/share/c1/c1_InstructionPrinter.cpp line 265:
> 
>> 263: 
>> 264: void InstructionPrinter::print_unsafe_op(UnsafeOp* op, const char* name) {
>> 265:   output()->print("%s(", name);
> 
> Do we need a matching ')' somewhere?

It's already there (but on the caller side):

void InstructionPrinter::do_UnsafeGet(UnsafeGet* x) {
  print_unsafe_op(x, x->is_raw() ? "UnsafeGet (raw)" : "UnsafeGet");
  output()->put(')');
}

> src/hotspot/share/ci/ciEnv.cpp line 760:
> 
>> 758:     }
>> 759:     ciInstance* constant = get_object(string)->as_instance();
>> 760:     return ciConstant(T_OBJECT, constant);
> 
> Please explain what happens for array constants now.

It is part of `JVM_CONSTANT_String` resolution, so string constant is expected here.

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

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

From neliasso at openjdk.java.net  Fri Feb 11 10:51:51 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 11 Feb 2022 10:51:51 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v2]
In-Reply-To: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
Message-ID: <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>

> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
> 
> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
> 
> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
> 
> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
> 
> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
> 
> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
> 
> Please review,
> Nils Eliasson

Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:

 - Updated copyright year
 - Change list to hashset

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7392/files
  - new: https://git.openjdk.java.net/jdk/pull/7392/files/7a5c3ce9..1a73bbfe

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

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

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

From neliasso at openjdk.java.net  Fri Feb 11 10:51:53 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 11 Feb 2022 10:51:53 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v2]
In-Reply-To: <OS4s7Rl0mM2VfOEsuOKYq2LpFy1HddxIQLYtcUqhgjk=.a092475b-aefc-4ca2-a895-0e258466d101@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <OS4s7Rl0mM2VfOEsuOKYq2LpFy1HddxIQLYtcUqhgjk=.a092475b-aefc-4ca2-a895-0e258466d101@github.com>
Message-ID: <bkxSpuFFlz5PRRS4uDRpLzsNnKRfKer00vV0eQakAVE=.abf22eb6-fd49-439f-b6cb-bab8c20211d7@github.com>

On Fri, 11 Feb 2022 04:19:56 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated copyright year
>>  - Change list to hashset
>
> Good.

@vnkozlov @TobiHartmann Thanks for having a look!

I updated the copyright year.

I also found that sometimes the test method can be compiled multiple times, so I changed the List to a HashSet. Also removed redundant command line parameters.

Best regards,
Nils

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

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

From thartmann at openjdk.java.net  Fri Feb 11 11:02:07 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Feb 2022 11:02:07 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v2]
In-Reply-To: <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>
Message-ID: <XGzKlua8-o_FSMhFosHvNKhUCI8S3GSNjQF8lS2GJks=.6823a0b9-753f-4e5c-a218-e9dc567309c7@github.com>

On Fri, 11 Feb 2022 10:51:51 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
>> 
>> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
>> 
>> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
>> 
>> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
>> 
>> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
>> 
>> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated copyright year
>  - Change list to hashset

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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

From jbhateja at openjdk.java.net  Fri Feb 11 13:09:01 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 11 Feb 2022 13:09:01 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <o_7hkc8hAzt8Xllk6bVVCCU-bbsNLLsl4RshyxfJlzE=.2611017c-f1e6-4f38-8ebb-79c7d61e3a04@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>
 <o_7hkc8hAzt8Xllk6bVVCCU-bbsNLLsl4RshyxfJlzE=.2611017c-f1e6-4f38-8ebb-79c7d61e3a04@github.com>
Message-ID: <iJLsf4mT5ceP5Z-AcFe4WteeRyytqDRLcBrf0b0NdYA=.828b6cd9-37a3-4f63-bd63-5b68a6ab0626@github.com>

On Thu, 10 Feb 2022 06:19:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> We recently have [JDK-8278947](https://bugs.openjdk.java.net/browse/JDK-8278947) for this. With some adjustment you can ask for alignment of the constant, too. Thanks.

- Emitting 64 byte constants may prove to be costly, given that code-size of a native method used while taking in-lining decisions takes constant table size into consideration,  also X86 instructions are variable sized (1-15 bytes) hence rematerializing constants using couple of instructions may be efficient in terms of both code size and latency. Given that loading a 64 byte constant not aligned to 64 byte address boundary may  span across multiple cache lines.
- But we can evaluate and consider extensions done by your patch separately.

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

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

From duke at openjdk.java.net  Fri Feb 11 14:00:09 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 11 Feb 2022 14:00:09 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>
Message-ID: <8TTw1uV2I3NuR1U4kKHAVquzYOaLO-GxIwg9Bo7RHFQ=.8a0e372b-8dce-460f-a685-22b7c8fdaf65@github.com>

On Wed, 9 Feb 2022 18:21:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

Since the lookup table is the replicate of 16 bytes, it is possible to just emit a 16-byte lane and broadcast it to the whole vector. IIRC a broadcast has the same cost as a normal load. I think it is up to you to decide if a 16-byte constant is reasonable but it is surely much more manageable than a 64-byte constant.

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

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

From jvernee at openjdk.java.net  Fri Feb 11 15:20:21 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 11 Feb 2022 15:20:21 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
Message-ID: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>

Hi,

This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.

It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.

As for code orginization. I opted for having separate calls to output tracing messages, rather than folding the tracing into `set_(fields_)escape_state`, and `set_scalar_replaceability`, in order to be able to add more context to the trace messages (such as dump of call node if the object escapes as an argument to a call). As well as avoiding having to construct a complex reason string in multiple places.

There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?

<details>
<summary>Sample output (click to unfold)</summary>

The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(66) -> escapes as argument to call.


+++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
+++++ Calculating escapse states and scalar replaceability
LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top

</details>

Testing: 
- Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
- Tier1-4 (in progress).

Thanks,
Jorn

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

Commit messages:
 - Add missing newlines
 - Pass outputStream to dump_header
 - Remove redundant resource mark
 - Rewrite with reason string
 - format string warning
 - Add TraceEscapeAnalysis flag

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

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

From neliasso at openjdk.java.net  Fri Feb 11 15:52:15 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 11 Feb 2022 15:52:15 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <JHeYne0-oEQQTa8TGeO2rBpLE-DEYWolRC4kKbgbgZ4=.4849f971-bcfd-4251-bf7f-61e1615c6770@github.com>

On Thu, 10 Feb 2022 16:41:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(66) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

src/hotspot/share/opto/compile.hpp line 622:

> 620:   bool              print_intrinsics() const     { return _print_intrinsics; }
> 621:   void          set_print_intrinsics(bool z)     { _print_intrinsics = z; }
> 622:   bool              trace_escape_analysis() const{ return _trace_escape_analysis; }

You can skip the setter and getter and just use compile->directive()->TraceEscapeAnalysisOption at the use sites.

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

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

From chagedorn at openjdk.java.net  Fri Feb 11 16:18:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 11 Feb 2022 16:18:10 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v2]
In-Reply-To: <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>
Message-ID: <H9g_xit9UlyWiJaM_Pa2hI5AAGs7K_16wgb2eXblGKQ=.5640c705-3190-4b38-ab07-d683ac561d31@github.com>

On Fri, 11 Feb 2022 10:51:51 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
>> 
>> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
>> 
>> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
>> 
>> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
>> 
>> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
>> 
>> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated copyright year
>  - Change list to hashset

Nice work! That will make things easier (and better in terms of performance) for [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). Looks good to me, too.

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

Marked as reviewed by chagedorn (Reviewer).

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

From jbhateja at openjdk.java.net  Fri Feb 11 17:56:12 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 11 Feb 2022 17:56:12 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v2]
In-Reply-To: <8TTw1uV2I3NuR1U4kKHAVquzYOaLO-GxIwg9Bo7RHFQ=.8a0e372b-8dce-460f-a685-22b7c8fdaf65@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <eokLfM-4Nog0QAeGF_wks_pBI2mJbi2ITgYwnUk-QU8=.233734a2-44f7-466b-9db5-d36ba7096a73@github.com>
 <8TTw1uV2I3NuR1U4kKHAVquzYOaLO-GxIwg9Bo7RHFQ=.8a0e372b-8dce-460f-a685-22b7c8fdaf65@github.com>
Message-ID: <u4KNTfKiobG1fRMaXQsa3uE9LMry-ZWhN57FagCJ_80=.35e4e15c-f374-442e-8ed6-e527c5524579@github.com>

On Fri, 11 Feb 2022 13:56:31 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Since the lookup table is the replicate of 16 bytes, it is possible to just emit a 16-byte lane and broadcast it to the whole vector. IIRC a broadcast has the same cost as a normal load. I think it is up to you to decide if a 16-byte constant is reasonable but it is surely much more manageable than a 64-byte constant.

Hi 

Yes, it varies from case to case, like replicating 8 byte in a vector may be cheaper than loading from constant table. If we are able to rematerialize the value without touching the memory its should be the preference.  Also adding bulky constant table may have side effects which may impact other optimization which considers native code size as a heuristic,  generating load time constant tables are sharable. We can make good use of enhancement in substituent patches.

Best Regards,
Jatin

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

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

From vladimir.kozlov at oracle.com  Fri Feb 11 18:01:06 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 10:01:06 -0800
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <4fe4310c-9509-3ab7-fefe-e8e2edffd402@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <4fe4310c-9509-3ab7-fefe-e8e2edffd402@oracle.com>
Message-ID: <08ce070f-339d-38b4-7867-d74d4f671dfc@oracle.com>

We can't do that unless we know that p0 does not escape in call() (we do such analysis in EA code already).
Otherwise there could be concurrent p0's fields updates.

Thanks,
Vladimir K

On 2/11/22 1:38 AM, Nils Eliasson wrote:
> This is also useful if only one of the paths are a local allocation. We must just be sure that the original phi actually 
> can be removed.
> 
> public int ex1(boolean cond, int first, int second) {
> 
>  ??? p0 = call(...)
> 
>  ??? if (cond) {
>  ??????? p1 = Allocate(...);
>  ??????? ...
>  ??????? p1.x = second;
>  ??????? p1.y = first;
>  ??? }
> 
>  ??? p = phi(p0, p1) // unused and will be removed
> 
> 
>  ??? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
> }
> 
> Regards,
> Nils
> 
> On 2022-02-11 05:07, Vladimir Kozlov wrote:
>> For this simple case we can teach C2's IGVN to split fields loads through Phi so that phi(p0, p1) is not used and 
>> allocations as well. We can do that because we know that allocations and phi do not escape.
>>
>> public int ex1(boolean cond, int first, int second) {
>> ??? p0 = Allocate(...);
>> ??? ...
>> ??? p0.x = first;
>> ??? p0.y = second;
>>
>> ??? if (cond) {
>> ??????? p1 = Allocate(...);
>> ??????? ...
>> ??????? p1.x = second;
>> ??????? p1.y = first;
>> ??? }
>>
>> ??? p = phi(p0, p1) // unused and will be removed
>>
>>
>> ??? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>> }
>>
>> Thanks,
>> Vladimir K 
> 

From neliasso at openjdk.java.net  Fri Feb 11 18:02:04 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 11 Feb 2022 18:02:04 GMT
Subject: RFR: 8281539: IGV: schedule approximation computes immediate
 dominators wrongly
In-Reply-To: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
References: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
Message-ID: <StDjdIY3ZYAknQDSIFMixvHb1-LZNAqRTIyjYcQn-Nk=.bf3cd5aa-312e-4da0-b5d4-4e93631388b0@github.com>

On Wed, 9 Feb 2022 15:16:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The `ServerCompiler` module in IGV computes an approximation of C2's schedule for unscheduled graphs, for clustering and showing control flow information in the "Control Flow" window. This approximation uses domination information to guide the scheduling of nodes into basic blocks. Currently, this information is computed with a custom algorithm implementation that gives wrong results for some graphs, as shown in [the issue report](https://bugs.openjdk.java.net/browse/JDK-8281539).
> 
> This change simply replaces the custom implementation with one from the [T. J. Watson Libraries for Analysis (WALA)](https://github.com/wala/WALA), a popular set of static analysis libraries licensed under the [OSI](http://www.opensource.org/)-approved [Eclipse Public License](http://www.eclipse.org/legal/epl-v10.html). The replacement gives correct domination information for the reported graphs and reduces significantly the complexity of the `ServerCompiler` module.
> 
> #### Testing
> 
> - Tested manually that the dominator tree computed for a few selected graphs (included the reported one) is correct.
> - Tested manually, for large graphs, that the dominator tree computation takes a negligible fraction (around 1%) of the entire graph scheduling time.
> - Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

I can still find some peculiarities - but gosh - it's fast! Let's push this!

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

Marked as reviewed by neliasso (Reviewer).

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

From kvn at openjdk.java.net  Fri Feb 11 18:10:11 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 18:10:11 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination [v2]
In-Reply-To: <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
 <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
Message-ID: <yB2eV6vgrkyB99GqYmMa4C-4h7UsuDSB5-kJ_ih3uH8=.39149cc8-3275-4066-ba3d-9e86aea93bb9@github.com>

On Wed, 9 Feb 2022 12:55:39 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The loop exit condition of the test method:
>> 
>> if (i == stop) {
>>     break;
>> }
>> 
>> requires insertion of a loop limit predicate when the loop is turned
>> into a counted loop. stop is a LoadI. Next:
>> 
>> array[stop - i + j] = 0;
>> 
>> is transformed to:
>> 
>> array[stop - i] = 0;
>> 
>> and the range check for that array access becomes candidate for
>> predication in a subsequent loop opts pass. stop has control just
>> above the loop limit check when that happens (because it is assigned
>> control as late as possible). But the loop predicate for the bound
>> check needs to be above the loop limit check and that causes the
>> assert failure.
>> 
>> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
>> to assign control to nodes above predicates so this sort of issues
>> doesn't occur. But it only applies to node initially on the entry
>> projection right above the loop head. The fix I propose is to remove
>> that restriction.
>> 
>> That logic was added by JDK-8203197 and looking back at this change I
>> noticed I replaced some existing logic with the current logic but,
>> while the 2 overlap, the current logic is not guaranteed to always
>> cover some cases handled by the old logic. So I resurrected that old
>> logic here.
>> 
>> Finally, when running tests, I hit failures because Opaque nodes for
>> skeleton predicates can now end up above a predicate that is split
>> thru phi. That causes the Opaque nodes to be split up and breaks
>> pattern matching. I'm actually not sure this issue is specific to the
>> change here so I think it's best to treat it as a general issue and
>> fix it by cloning the chain of nodes that lead to the Opaque node
>> down.
>
> 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 three additional commits since the last revision:
> 
>  - fix
>  - Merge branch 'master' into JDK-8280799
>  - fix & test

Scratch my previous comment. `least` value could be updated in new code so we need second check.

src/hotspot/share/opto/loopnode.cpp line 5758:

> 5756:   // Try not to place code on a loop entry projection
> 5757:   // which can inhibit range check elimination.
> 5758:   if (least != early) {

It is the same check as new above - you can combine these scopes.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Fri Feb 11 18:23:09 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 18:23:09 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v2]
In-Reply-To: <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <FAI-iXp9hyxq-RUWZBRswNpnaQFOYFh-N9FJb_OAPoA=.cf973088-e9f8-4dd2-b019-2942210b62b3@github.com>
Message-ID: <jGPRjKrkzOo6MIE6vN9rQ03Vh9Zwltp60OSnjPIpE1Q=.058fbdce-6d12-44b1-90a6-543f15b447a9@github.com>

On Fri, 11 Feb 2022 10:51:51 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
>> 
>> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
>> 
>> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
>> 
>> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
>> 
>> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
>> 
>> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated copyright year
>  - Change list to hashset

Update is good.

Looks like `zero` and `minimal` builds failed with this change:

src/hotspot/share/compiler/compilerDirectives.cpp:388:20: error: 'PrintIdealPhaseIndex' was not declared in this scope
[19](https://github.com/neliasso/jdk/runs/5155280503?check_suite_focus=true#step:19:19)
  388 |     if (!_modified[PrintIdealPhaseIndex]) {
[20](https://github.com/neliasso/jdk/runs/5155280503?check_suite_focus=true#step:19:20)
      |                    ^~~~~~~~~~~~~~~~~~~~
 ```

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7392Changes requested by kvn (Reviewer).

From vladimir.x.ivanov at oracle.com  Fri Feb 11 18:24:42 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 11 Feb 2022 21:24:42 +0300
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
Message-ID: <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>


> For this simple case we can teach C2's IGVN to split fields loads 
> through Phi so that phi(p0, p1) is not used and allocations as well. We 
> can do that because we know that allocations and phi do not escape.

Seems like split_unique_types() pass is a prerequisite to make such 
transformations predictable on a larger scale. It simplifies the memory 
graph and untangles instance-related memory operations from the rest of 
the graph.

Otherwise, I believe wide memory states/merges would pose serious 
problems. E.g., when a load is split through a phi, you need to pick 
correct memory states for the new loads above the phi which quickly 
becomes quite a challenging task.

Best regards,
Vladimir Ivanov

> 
> public int ex1(boolean cond, int first, int second) {
>  ??? p0 = Allocate(...);
>  ??? ...
>  ??? p0.x = first;
>  ??? p0.y = second;
> 
>  ??? if (cond) {
>  ??????? p1 = Allocate(...);
>  ??????? ...
>  ??????? p1.x = second;
>  ??????? p1.y = first;
>  ??? }
> 
>  ??? p = phi(p0, p1) // unused and will be removed
> 
> 
>  ??? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
> }
> 
> Thanks,
> Vladimir K
> 
> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>
>> Hi Cesar,
>>
>> Thanks for looking into enhancing EA.
>>
>> Overall, the proposal looks reasonable.
>>
>> I suggest to look more closely at split_unique_types().
>> It introduces a dedicated class of alias categories for fields of the 
>> allocation being eliminated and clones memory graph. I don't see why 
>> it shouldn't work for multiple allocations.
>>
>> Moreover, split_unique_types() will break if you start optimizing 
>> multiple allocations at once. The notion of unique alias should be 
>> adjusted and cover the union of unique aliases for all interacting 
>> allocations.
>>
>> Seems like you need to enhance SR to work on non-intersecting clusters 
>> of allocations.
>>
>> One thing to take care of: scalar replacement relies on 
>> TypeOopPtr::instance_id().
>>
>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>> ?? // a particular instance of this type which is distinct.
>> ?? // This is the node index of the allocation node creating this 
>> instance.
>> ?? int?????????? _instance_id;
>>
>> It'll break when multiple allocations are in play.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>> Hi there again!
>>>
>>> Can you please give me feedback on the following approach to at least 
>>> partially
>>> address [1], the scalar replacement allocation merge issue?
>>>
>>> The problem that I am trying to solve arises when allocations are 
>>> merged after a
>>> control flow split. The code below shows _one example_ of such a 
>>> situation.
>>>
>>> public int ex1(boolean cond, int x, int y) {
>>> ?? ? Point p = new Point(x, y);
>>> ?? ? if (cond)
>>> ?? ? ? ? p = new Point(y, x);
>>> ?? ? // Allocations for p are merged here.
>>> ?? ? return p.calc();
>>> }
>>>
>>> Assuming the method calls on "p" are inlined then the allocations 
>>> will not
>>> escape the method. The C2 IR for this method will look like this:
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>> ?? ? p0 = Allocate(...);
>>> ?? ? ...
>>> ?? ? p0.x = first;
>>> ?? ? p0.y = second;
>>>
>>> ?? ? if (cond) {
>>> ?? ? ? ? p1 = Allocate(...);
>>> ?? ? ? ? ...
>>> ?? ? ? ? p1.x = second;
>>> ?? ? ? ? p1.y = first;
>>> ?? ? }
>>>
>>> ?? ? p = phi(p0, p1)
>>>
>>> ?? ? return p.x - p.y;
>>> }
>>>
>>> However, one of the constraints implemented here [2], specifically 
>>> the third
>>> one, will prevent the objects from being scalar replaced.
>>>
>>> The approach that I'm considering for solving the problem is to 
>>> replace the Phi
>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of 
>>> the objects
>>> in the original Phi. The IR for `ex1` would look something like this 
>>> after the
>>> transformation:
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>> ?? ? p0 = Allocate(...);
>>> ?? ? ...
>>> ?? ? p0.x = first;
>>> ?? ? p0.y = second;
>>>
>>> ?? ? if (cond) {
>>> ?? ? ? ? p1 = Allocate(...);
>>> ?? ? ? ? ...
>>> ?? ? ? ? p1.x = second;
>>> ?? ? ? ? p1.y = first;
>>> ?? ? }
>>>
>>> ?? ? pX = phi(first, second)
>>> ?? ? pY = phi(second, first)
>>>
>>> ?? ? return pX - pY;
>>> }
>>>
>>> I understand that this transformation might not be applicable for all 
>>> cases and
>>> that it's not as simple as illustrated above. Also, it seems to me 
>>> that much of
>>> what I'd have to implement is already implemented in other steps of 
>>> the Scalar
>>> Replacement pipeline (which is a good thing). To work around these
>>> implementation details I plan to use as much of the existing code as 
>>> possible.
>>> The algorithm for the transformation would be like this:
>>>
>>> split_phis(phi)
>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>> ?? ? # then we can't remove it. The conditions here might possible be 
>>> the
>>> ?? ? # same as the ones implemented in 
>>> `PhaseMacroExpand::can_eliminate_allocation`
>>> ?? ? if cant_remove_phi_output(phi)
>>> ?? ? ? ? return ;
>>>
>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses field F
>>> ?? ? # member of the object resulting from `phi`.
>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>
>>> ?? ? foreach field in fields_used
>>> ?? ? ? ? producers = {}
>>>
>>> ?? ? ? ? # Create a list with the last Store for each field "field" 
>>> on the
>>> ?? ? ? ? # scope of each of the Phi input objects.
>>> ?? ? ? ? foreach o in phi.inputs
>>> ?? ? ? ? ? ? # The function called below might re-use a lot of the 
>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 'field'
>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>
>>> ?? ? ? ? update_consumers(field, field_phi)
>>>
>>> The implementation that I envisioned would be as a "pre-process" [3] 
>>> step just
>>> after EA but before the constraint checks in 
>>> `adjust_scalar_replaceable_state`
>>> [2]. If we agree that the overall Scalar Replacement implementation 
>>> goes through
>>> the following major phases:
>>>
>>> ?? ? 1. Identify the Escape Status of objects.
>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based 
>>> on a set of constraints.
>>> ?? ? 3. Make call to Split_unique_types [4].
>>> ?? ? 4 Iterate over object and array allocations.
>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>> Safepoints.
>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, 
>>> ArrayCopy and CastP2X.
>>>
>>> The transformation that I am proposing would change the overall flow 
>>> to look
>>> like this:
>>>
>>> ?? ? 1. Identify the Escape Status of objects.
>>> ?? ? 2. ----> New: "Split phi functions" <----
>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based 
>>> on a set of constraints.
>>> ?? ? 3. Make call to Split_unique_types [14].
>>> ?? ? 4 Iterate over object and array allocations.
>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be 
>>> eliminated" <----
>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>> Safepoints.
>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, 
>>> ArrayCopy and CastP2X.
>>>
>>> Please let me know what you think and thank you for taking the time 
>>> to review
>>> this!
>>>
>>>
>>> Regards,
>>> Cesar
>>>
>>> Notes:
>>>
>>> ?? ? [1] I am not sure yet how this approach will play with the case 
>>> of a merge
>>> ?? ? ? ? with NULL.
>>> ?? ? [2] 
>>> https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809 
>>>
>>>
>>> ?? ? [3] Another option would be to "patch" the current 
>>> implementation to be able
>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" 
>>> approach would be
>>> ?? ? ? ? better, however, the "pre-process" approach is certainly 
>>> much easier to test
>>> ?? ? ? ? and more readable.
>>>
>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>> ?? ? ? ? split_unique_types(). Would the transformation that I am 
>>> proposing need to
>>> ?? ? ? ? be after the call to split_unique_types?

From kvn at openjdk.java.net  Fri Feb 11 18:29:08 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 18:29:08 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <a8LlPF-FIzSumkH29b9vHZ1JyO1CFlQCH4qDRq5TOsE=.1b1c85e8-0ab7-47d0-b695-32499a65594e@github.com>

On Thu, 10 Feb 2022 16:41:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(66) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

This is very nice. I like it. Can you show short example of output?

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

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

From kvn at openjdk.java.net  Fri Feb 11 18:34:05 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 18:34:05 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <zdZMKZqoE2P4L_GFZjJbTb30AUdsr_mBb3JcMrPQn6Y=.07842cb7-13a6-46fd-a3e2-81c56cdd90af@github.com>

On Thu, 10 Feb 2022 16:41:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(66) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

src/hotspot/share/opto/escape.hpp line 589:

> 587:   }
> 588: 
> 589: #ifndef PRODUCT

Should be `#ifdef ASSERT` since it is called only in `DEBUG_ONLY`.
Or may be better change `DEBUG_ONLY()` macros in call sites and arguments to `NOT_PRODUCT()`. That way we can use it in optimized VM.

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

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

From kvn at openjdk.java.net  Fri Feb 11 18:39:09 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 18:39:09 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <OBKj8sIyFJtX-12yRjOX4eN8ubthi4jl9Z5i9LunPI0=.22d432a6-f89b-402c-94a9-36ce53d612b2@github.com>

On Thu, 10 Feb 2022 16:41:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(66) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

I missed the click to see example. Looks good!

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

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

From neliasso at openjdk.java.net  Fri Feb 11 18:47:00 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 11 Feb 2022 18:47:00 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v3]
In-Reply-To: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
Message-ID: <xQAmRVPF1pUI6P__Ls0U--q6K9zUeR5_v_wFklRMf3c=.37e74305-34c2-451a-9bef-b740cacdb606@github.com>

> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
> 
> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
> 
> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
> 
> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
> 
> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
> 
> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
> 
> Please review,
> Nils Eliasson

Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:

  Guard C2 only code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7392/files
  - new: https://git.openjdk.java.net/jdk/pull/7392/files/1a73bbfe..ff0a44cb

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

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

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

From vladimir.kozlov at oracle.com  Fri Feb 11 18:51:16 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 10:51:16 -0800
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
Message-ID: <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>

On 2/11/22 10:24 AM, Vladimir Ivanov wrote:
> 
>> For this simple case we can teach C2's IGVN to split fields loads through Phi so that phi(p0, p1) is not used and 
>> allocations as well. We can do that because we know that allocations and phi do not escape.
> 
> Seems like split_unique_types() pass is a prerequisite to make such transformations predictable on a larger scale. It 
> simplifies the memory graph and untangles instance-related memory operations from the rest of the graph.

Can you elaborate on your suggestion?

As you correctly pointed in your original post, EA and SR heavily depend on _instance_id which is Allocation node's _idx 
value. And the solution for this is either remove reference to merge phi. Or introduce new "virtual allocation" which 
fields are populated by loads - but it is again needs to split through phi.

> 
> Otherwise, I believe wide memory states/merges would pose serious problems. E.g., when a load is split through a phi, 
> you need to pick correct memory states for the new loads above the phi which quickly becomes quite a challenging task.

Especially in loops. Actually I did tried such approach before and I agree that it is hard.

Thanks,
Vladimir K

> 
> Best regards,
> Vladimir Ivanov
> 
>>
>> public int ex1(boolean cond, int first, int second) {
>> ???? p0 = Allocate(...);
>> ???? ...
>> ???? p0.x = first;
>> ???? p0.y = second;
>>
>> ???? if (cond) {
>> ???????? p1 = Allocate(...);
>> ???????? ...
>> ???????? p1.x = second;
>> ???????? p1.y = first;
>> ???? }
>>
>> ???? p = phi(p0, p1) // unused and will be removed
>>
>>
>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>> }
>>
>> Thanks,
>> Vladimir K
>>
>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>>
>>> Hi Cesar,
>>>
>>> Thanks for looking into enhancing EA.
>>>
>>> Overall, the proposal looks reasonable.
>>>
>>> I suggest to look more closely at split_unique_types().
>>> It introduces a dedicated class of alias categories for fields of the allocation being eliminated and clones memory 
>>> graph. I don't see why it shouldn't work for multiple allocations.
>>>
>>> Moreover, split_unique_types() will break if you start optimizing multiple allocations at once. The notion of unique 
>>> alias should be adjusted and cover the union of unique aliases for all interacting allocations.
>>>
>>> Seems like you need to enhance SR to work on non-intersecting clusters of allocations.
>>>
>>> One thing to take care of: scalar replacement relies on TypeOopPtr::instance_id().
>>>
>>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>>> ?? // a particular instance of this type which is distinct.
>>> ?? // This is the node index of the allocation node creating this instance.
>>> ?? int?????????? _instance_id;
>>>
>>> It'll break when multiple allocations are in play.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>> Hi there again!
>>>>
>>>> Can you please give me feedback on the following approach to at least partially
>>>> address [1], the scalar replacement allocation merge issue?
>>>>
>>>> The problem that I am trying to solve arises when allocations are merged after a
>>>> control flow split. The code below shows _one example_ of such a situation.
>>>>
>>>> public int ex1(boolean cond, int x, int y) {
>>>> ?? ? Point p = new Point(x, y);
>>>> ?? ? if (cond)
>>>> ?? ? ? ? p = new Point(y, x);
>>>> ?? ? // Allocations for p are merged here.
>>>> ?? ? return p.calc();
>>>> }
>>>>
>>>> Assuming the method calls on "p" are inlined then the allocations will not
>>>> escape the method. The C2 IR for this method will look like this:
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>> ?? ? p0 = Allocate(...);
>>>> ?? ? ...
>>>> ?? ? p0.x = first;
>>>> ?? ? p0.y = second;
>>>>
>>>> ?? ? if (cond) {
>>>> ?? ? ? ? p1 = Allocate(...);
>>>> ?? ? ? ? ...
>>>> ?? ? ? ? p1.x = second;
>>>> ?? ? ? ? p1.y = first;
>>>> ?? ? }
>>>>
>>>> ?? ? p = phi(p0, p1)
>>>>
>>>> ?? ? return p.x - p.y;
>>>> }
>>>>
>>>> However, one of the constraints implemented here [2], specifically the third
>>>> one, will prevent the objects from being scalar replaced.
>>>>
>>>> The approach that I'm considering for solving the problem is to replace the Phi
>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of the objects
>>>> in the original Phi. The IR for `ex1` would look something like this after the
>>>> transformation:
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>> ?? ? p0 = Allocate(...);
>>>> ?? ? ...
>>>> ?? ? p0.x = first;
>>>> ?? ? p0.y = second;
>>>>
>>>> ?? ? if (cond) {
>>>> ?? ? ? ? p1 = Allocate(...);
>>>> ?? ? ? ? ...
>>>> ?? ? ? ? p1.x = second;
>>>> ?? ? ? ? p1.y = first;
>>>> ?? ? }
>>>>
>>>> ?? ? pX = phi(first, second)
>>>> ?? ? pY = phi(second, first)
>>>>
>>>> ?? ? return pX - pY;
>>>> }
>>>>
>>>> I understand that this transformation might not be applicable for all cases and
>>>> that it's not as simple as illustrated above. Also, it seems to me that much of
>>>> what I'd have to implement is already implemented in other steps of the Scalar
>>>> Replacement pipeline (which is a good thing). To work around these
>>>> implementation details I plan to use as much of the existing code as possible.
>>>> The algorithm for the transformation would be like this:
>>>>
>>>> split_phis(phi)
>>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>>> ?? ? # then we can't remove it. The conditions here might possible be the
>>>> ?? ? # same as the ones implemented in `PhaseMacroExpand::can_eliminate_allocation`
>>>> ?? ? if cant_remove_phi_output(phi)
>>>> ?? ? ? ? return ;
>>>>
>>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses field F
>>>> ?? ? # member of the object resulting from `phi`.
>>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>>
>>>> ?? ? foreach field in fields_used
>>>> ?? ? ? ? producers = {}
>>>>
>>>> ?? ? ? ? # Create a list with the last Store for each field "field" on the
>>>> ?? ? ? ? # scope of each of the Phi input objects.
>>>> ?? ? ? ? foreach o in phi.inputs
>>>> ?? ? ? ? ? ? # The function called below might re-use a lot of the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 'field'
>>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>>
>>>> ?? ? ? ? update_consumers(field, field_phi)
>>>>
>>>> The implementation that I envisioned would be as a "pre-process" [3] step just
>>>> after EA but before the constraint checks in `adjust_scalar_replaceable_state`
>>>> [2]. If we agree that the overall Scalar Replacement implementation goes through
>>>> the following major phases:
>>>>
>>>> ?? ? 1. Identify the Escape Status of objects.
>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>>>> ?? ? 3. Make call to Split_unique_types [4].
>>>> ?? ? 4 Iterate over object and array allocations.
>>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>>>
>>>> The transformation that I am proposing would change the overall flow to look
>>>> like this:
>>>>
>>>> ?? ? 1. Identify the Escape Status of objects.
>>>> ?? ? 2. ----> New: "Split phi functions" <----
>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>>>> ?? ? 3. Make call to Split_unique_types [14].
>>>> ?? ? 4 Iterate over object and array allocations.
>>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be eliminated" <----
>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>>>
>>>> Please let me know what you think and thank you for taking the time to review
>>>> this!
>>>>
>>>>
>>>> Regards,
>>>> Cesar
>>>>
>>>> Notes:
>>>>
>>>> ?? ? [1] I am not sure yet how this approach will play with the case of a merge
>>>> ?? ? ? ? with NULL.
>>>> ?? ? [2] 
>>>> https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809
>>>>
>>>> ?? ? [3] Another option would be to "patch" the current implementation to be able
>>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" approach would be
>>>> ?? ? ? ? better, however, the "pre-process" approach is certainly much easier to test
>>>> ?? ? ? ? and more readable.
>>>>
>>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>>> ?? ? ? ? split_unique_types(). Would the transformation that I am proposing need to
>>>> ?? ? ? ? be after the call to split_unique_types?

From kvn at openjdk.java.net  Fri Feb 11 18:56:08 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 18:56:08 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v3]
In-Reply-To: <xQAmRVPF1pUI6P__Ls0U--q6K9zUeR5_v_wFklRMf3c=.37e74305-34c2-451a-9bef-b740cacdb606@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <xQAmRVPF1pUI6P__Ls0U--q6K9zUeR5_v_wFklRMf3c=.37e74305-34c2-451a-9bef-b740cacdb606@github.com>
Message-ID: <FddIxLJ7DXZvyntn0OFGRCTfDc7_ej-FLOoafFmjgGw=.7715eca5-dc80-48d3-a51b-d9a460b34458@github.com>

On Fri, 11 Feb 2022 18:47:00 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
>> 
>> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
>> 
>> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
>> 
>> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
>> 
>> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
>> 
>> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard C2 only code

Good.

Wait result of GIT testing.

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

Marked as reviewed by kvn (Reviewer).

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

From jvernee at openjdk.java.net  Fri Feb 11 19:19:16 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 11 Feb 2022 19:19:16 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <zdZMKZqoE2P4L_GFZjJbTb30AUdsr_mBb3JcMrPQn6Y=.07842cb7-13a6-46fd-a3e2-81c56cdd90af@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <zdZMKZqoE2P4L_GFZjJbTb30AUdsr_mBb3JcMrPQn6Y=.07842cb7-13a6-46fd-a3e2-81c56cdd90af@github.com>
Message-ID: <K9PFXPkiSnOoXIr0W4f-r0-BJfsdD0EVJaV3ndQwzbo=.c5753ab9-f81a-43b8-bd57-a872299af909@github.com>

On Fri, 11 Feb 2022 18:31:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4 (in progress).
>> 
>> Thanks,
>> Jorn
>
> src/hotspot/share/opto/escape.hpp line 589:
> 
>> 587:   }
>> 588: 
>> 589: #ifndef PRODUCT
> 
> Should be `#ifdef ASSERT` since it is called only in `DEBUG_ONLY`.
> Or may be better change `DEBUG_ONLY()` macros in call sites and arguments to `NOT_PRODUCT()`. That way we can use it in optimized VM.

Thanks. I wasn't sure if `DEBUG_ONLY` was the right one.

The flag itself in compilerDirectives.hpp uses `NOT_PRODUCT`, so I will switch to that.

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

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

From jvernee at openjdk.java.net  Fri Feb 11 19:25:18 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 11 Feb 2022 19:25:18 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <JHeYne0-oEQQTa8TGeO2rBpLE-DEYWolRC4kKbgbgZ4=.4849f971-bcfd-4251-bf7f-61e1615c6770@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <JHeYne0-oEQQTa8TGeO2rBpLE-DEYWolRC4kKbgbgZ4=.4849f971-bcfd-4251-bf7f-61e1615c6770@github.com>
Message-ID: <eaIrSpXT3ZQ666HtCq-bSHkEIvOawoaUThWmnnx5re8=.8463caac-4ac1-4beb-a770-41664d250943@github.com>

On Fri, 11 Feb 2022 15:48:54 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4 (in progress).
>> 
>> Thanks,
>> Jorn
>
> src/hotspot/share/opto/compile.hpp line 622:
> 
>> 620:   bool              print_intrinsics() const     { return _print_intrinsics; }
>> 621:   void          set_print_intrinsics(bool z)     { _print_intrinsics = z; }
>> 622:   bool              trace_escape_analysis() const{ return _trace_escape_analysis; }
> 
> You can skip the setter and getter and just use compile->directive()->TraceEscapeAnalysisOption at the use sites.

Okay, I will drop the getter/setter.

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

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

From Divino.Cesar at microsoft.com  Fri Feb 11 20:14:24 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Fri, 11 Feb 2022 20:14:24 +0000
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
Message-ID: <BY5PR21MB147382D09454A0E1DD758E049A309@BY5PR21MB1473.namprd21.prod.outlook.com>

Thank you all for the feedback. Very much appreciated!

What I like most about the idea of replacing phi(p0, p1)? with several phi(Store(p0.x), Store(p1.x), etc. is that the code becomes "detached" from the way that p0 and p1 were created. I think this might be helpful when eventually we try to bring partial escape analysis.

I understand that split_unique_types() and SR will break if we have multiple allocations since they are dependent on the Allocate ID. However, my understanding of this method isn't deep: I know what it does but I don't really know why it is necessary on a deep level. If you could elaborate on that, it would be very helpful to me.

> As you correctly pointed in your original post, EA and SR heavily depend on _instance_id which is Allocation node's _idx value.
> And the solution for this is either remove reference to merge phi. Or introduce new "virtual allocation" which fields are
> populated by loads - but it is again needs to split through phi.

Vladimir K., are you suggesting something like this:

 public int ex1(boolean cond, int first, int second) {
      p0 = ...;
      p0.x = first;
      p0.y = second;

      if (cond) {
          p1 = ...
          p1.x = second;
          p1.y = first;
      }

      p = VirtualAllocate(...);
      p.x = phi(first, second);
      p.y = phi(second, first);

      return p.x - p.y;
 }

Would the phi/merges for individual fields cause problems in split_unique_types/SR?


Regards,
Cesar

________________________________
From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Sent: February 11, 2022 10:51 AM
To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; Cesar Soares Lucas <Divino.Cesar at microsoft.com>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>; Martijn Verburg <Martijn.Verburg at microsoft.com>
Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement

On 2/11/22 10:24 AM, Vladimir Ivanov wrote:
>
>> For this simple case we can teach C2's IGVN to split fields loads through Phi so that phi(p0, p1) is not used and
>> allocations as well. We can do that because we know that allocations and phi do not escape.
>
> Seems like split_unique_types() pass is a prerequisite to make such transformations predictable on a larger scale. It
> simplifies the memory graph and untangles instance-related memory operations from the rest of the graph.

Can you elaborate on your suggestion?

As you correctly pointed in your original post, EA and SR heavily depend on _instance_id which is Allocation node's _idx
value. And the solution for this is either remove reference to merge phi. Or introduce new "virtual allocation" which
fields are populated by loads - but it is again needs to split through phi.

>
> Otherwise, I believe wide memory states/merges would pose serious problems. E.g., when a load is split through a phi,
> you need to pick correct memory states for the new loads above the phi which quickly becomes quite a challenging task.

Especially in loops. Actually I did tried such approach before and I agree that it is hard.

Thanks,
Vladimir K

>
> Best regards,
> Vladimir Ivanov
>
>>
>> public int ex1(boolean cond, int first, int second) {
>>      p0 = Allocate(...);
>>      ...
>>      p0.x = first;
>>      p0.y = second;
>>
>>      if (cond) {
>>          p1 = Allocate(...);
>>          ...
>>          p1.x = second;
>>          p1.y = first;
>>      }
>>
>>      p = phi(p0, p1) // unused and will be removed
>>
>>
>>      return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>> }
>>
>> Thanks,
>> Vladimir K
>>
>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>>
>>> Hi Cesar,
>>>
>>> Thanks for looking into enhancing EA.
>>>
>>> Overall, the proposal looks reasonable.
>>>
>>> I suggest to look more closely at split_unique_types().
>>> It introduces a dedicated class of alias categories for fields of the allocation being eliminated and clones memory
>>> graph. I don't see why it shouldn't work for multiple allocations.
>>>
>>> Moreover, split_unique_types() will break if you start optimizing multiple allocations at once. The notion of unique
>>> alias should be adjusted and cover the union of unique aliases for all interacting allocations.
>>>
>>> Seems like you need to enhance SR to work on non-intersecting clusters of allocations.
>>>
>>> One thing to take care of: scalar replacement relies on TypeOopPtr::instance_id().
>>>
>>>    // If not InstanceTop or InstanceBot, indicates that this is
>>>    // a particular instance of this type which is distinct.
>>>    // This is the node index of the allocation node creating this instance.
>>>    int           _instance_id;
>>>
>>> It'll break when multiple allocations are in play.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>> Hi there again!
>>>>
>>>> Can you please give me feedback on the following approach to at least partially
>>>> address [1], the scalar replacement allocation merge issue?
>>>>
>>>> The problem that I am trying to solve arises when allocations are merged after a
>>>> control flow split. The code below shows _one example_ of such a situation.
>>>>
>>>> public int ex1(boolean cond, int x, int y) {
>>>>      Point p = new Point(x, y);
>>>>      if (cond)
>>>>          p = new Point(y, x);
>>>>      // Allocations for p are merged here.
>>>>      return p.calc();
>>>> }
>>>>
>>>> Assuming the method calls on "p" are inlined then the allocations will not
>>>> escape the method. The C2 IR for this method will look like this:
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>>      p0 = Allocate(...);
>>>>      ...
>>>>      p0.x = first;
>>>>      p0.y = second;
>>>>
>>>>      if (cond) {
>>>>          p1 = Allocate(...);
>>>>          ...
>>>>          p1.x = second;
>>>>          p1.y = first;
>>>>      }
>>>>
>>>>      p = phi(p0, p1)
>>>>
>>>>      return p.x - p.y;
>>>> }
>>>>
>>>> However, one of the constraints implemented here [2], specifically the third
>>>> one, will prevent the objects from being scalar replaced.
>>>>
>>>> The approach that I'm considering for solving the problem is to replace the Phi
>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of the objects
>>>> in the original Phi. The IR for `ex1` would look something like this after the
>>>> transformation:
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>>      p0 = Allocate(...);
>>>>      ...
>>>>      p0.x = first;
>>>>      p0.y = second;
>>>>
>>>>      if (cond) {
>>>>          p1 = Allocate(...);
>>>>          ...
>>>>          p1.x = second;
>>>>          p1.y = first;
>>>>      }
>>>>
>>>>      pX = phi(first, second)
>>>>      pY = phi(second, first)
>>>>
>>>>      return pX - pY;
>>>> }
>>>>
>>>> I understand that this transformation might not be applicable for all cases and
>>>> that it's not as simple as illustrated above. Also, it seems to me that much of
>>>> what I'd have to implement is already implemented in other steps of the Scalar
>>>> Replacement pipeline (which is a good thing). To work around these
>>>> implementation details I plan to use as much of the existing code as possible.
>>>> The algorithm for the transformation would be like this:
>>>>
>>>> split_phis(phi)
>>>>      # If output of phi escapes, or something uses its identity, etc
>>>>      # then we can't remove it. The conditions here might possible be the
>>>>      # same as the ones implemented in `PhaseMacroExpand::can_eliminate_allocation`
>>>>      if cant_remove_phi_output(phi)
>>>>          return ;
>>>>
>>>>      # Collect a set of tuples(F,U) containing nodes U that uses field F
>>>>      # member of the object resulting from `phi`.
>>>>      fields_used = collect_fields_used_after_phi(phi)
>>>>
>>>>      foreach field in fields_used
>>>>          producers = {}
>>>>
>>>>          # Create a list with the last Store for each field "field" on the
>>>>          # scope of each of the Phi input objects.
>>>>          foreach o in phi.inputs
>>>>              # The function called below might re-use a lot of the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>              producers += last_store_to_o_field(0, field)
>>>>          # Create a new phi node whose inputs are the Store's to 'field'
>>>>          field_phi = create_new_phi(producers)
>>>>
>>>>          update_consumers(field, field_phi)
>>>>
>>>> The implementation that I envisioned would be as a "pre-process" [3] step just
>>>> after EA but before the constraint checks in `adjust_scalar_replaceable_state`
>>>> [2]. If we agree that the overall Scalar Replacement implementation goes through
>>>> the following major phases:
>>>>
>>>>      1. Identify the Escape Status of objects.
>>>>      2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>>>>      3. Make call to Split_unique_types [4].
>>>>      4 Iterate over object and array allocations.
>>>>          4.1 Check if allocation can be eliminated.
>>>>          4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>>>>          4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>>>
>>>> The transformation that I am proposing would change the overall flow to look
>>>> like this:
>>>>
>>>>      1. Identify the Escape Status of objects.
>>>>      2. ----> New: "Split phi functions" <----
>>>>      2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>>>>      3. Make call to Split_unique_types [14].
>>>>      4 Iterate over object and array allocations.
>>>>          4.1 ----> Moved to split_phi: "Check if allocation can be eliminated" <----
>>>>          4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>>>>          4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>>>
>>>> Please let me know what you think and thank you for taking the time to review
>>>> this!
>>>>
>>>>
>>>> Regards,
>>>> Cesar
>>>>
>>>> Notes:
>>>>
>>>>      [1] I am not sure yet how this approach will play with the case of a merge
>>>>          with NULL.
>>>>      [2]
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fescape.cpp%23L1809&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cc2580fe523c640d628d708d9ed8f81f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637802022912055025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eNNCJjkdjWPcmIxl0VVqkpjdRcaCCSDB5Focx0R9EuY%3D&amp;reserved=0
>>>>
>>>>      [3] Another option would be to "patch" the current implementation to be able
>>>>          to handle the merges. I am not certain that the "patch" approach would be
>>>>          better, however, the "pre-process" approach is certainly much easier to test
>>>>          and more readable.
>>>>
>>>>      [4] I cannot say I understand 100% the effects of executing
>>>>          split_unique_types(). Would the transformation that I am proposing need to
>>>>          be after the call to split_unique_types?

From vladimir.kozlov at oracle.com  Fri Feb 11 21:03:54 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 11 Feb 2022 13:03:54 -0800
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <BY5PR21MB147382D09454A0E1DD758E049A309@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <BY5PR21MB147382D09454A0E1DD758E049A309@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <1ee1c53b-7f10-9f41-70f3-aefc74a35cbe@oracle.com>

On 2/11/22 12:14 PM, Cesar Soares Lucas wrote:
> Thank you all for the feedback. Very much appreciated!
> 
> What I like most about the idea of replacing?phi(p0, p1)? with several phi(Store(p0.x), Store(p1.x), etc. is that the 
> code becomes "detached" from the way that p0 and p1 were created. I think this might be helpful when eventually we try 
> to bring partial escape analysis.
> 
> I understand that split_unique_types() and SR will break if we have multiple allocations since they are dependent on the 
> Allocate ID. However, my understanding of this method isn't deep: I know what it does but I don't really know why it is 
> necessary on a deep level. If you could elaborate on that, it would be very helpful to me.

split_unique_types() created clean memory slices related only to such objects (by cloning related nodes).

Actually Roland suggested before to always run split_unique_types(), even if non-escaping object is not scalar 
replaceable. I think this is what Vladimir I. is also suggesting.

It will significantly simplify the work we have to do in IGVN.

> 
>  > As you correctly pointed in your original post, EA and SR heavily depend on _instance_id which is Allocation node's 
> _idx value.
>  > And the solution for this is either remove reference to merge phi. Or introduce new "virtual allocation" which fields 
> are
>  > populated by loads - but it is again needs to split through phi.
> 
> Vladimir K., are you suggesting something like this:

Yes, that is what I had in mind but it could be more complicated to implement.
The idea is to have new _instance_id after merge. It may not be useful for this simple case but may help in others.
We would still need to improve split_unique_types to find values to store in its fields.

> 
>  ?public int ex1(boolean cond, int first, int second) {
>  ? ? ? p0 = ...;
>  ? ? ? p0.x = first;
>  ? ? ? p0.y = second;
>  ? ? ? if (cond) {
>  ? ? ? ? ? p1 = ...
>  ? ? ? ? ? p1.x = second;
>  ? ? ? ? ? p1.y = first;
>  ? ? ? }
>  ? ? ? p = VirtualAllocate(...);
>  ? ? ? p.x = phi(first, second);
>  ? ? ? p.y = phi(second, first);
>  ? ? ? return p.x - p.y;
>  ?}
> 
> Would the phi/merges for individual fields cause problems in split_unique_types/SR?

Split_unique_types/SR work on allocation's references and not on what is stored in its fields.

Thanks,
Vladimir

> 
> 
> Regards,
> Cesar
> 
> ------------------------------------------------------------------------------------------------------------------------
> *From:* Vladimir Kozlov <vladimir.kozlov at oracle.com>
> *Sent:* February 11, 2022 10:51 AM
> *To:* Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; Cesar Soares Lucas <Divino.Cesar at microsoft.com>; hotspot compiler 
> <hotspot-compiler-dev at openjdk.java.net>
> *Cc:* Brian Stafford <Brian.Stafford at microsoft.com>; Martijn Verburg <Martijn.Verburg at microsoft.com>
> *Subject:* Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> On 2/11/22 10:24 AM, Vladimir Ivanov wrote:
>> 
>>> For this simple case we can teach C2's IGVN to split fields loads through Phi so that phi(p0, p1) is not used and
>>> allocations as well. We can do that because we know that allocations and phi do not escape.
>> 
>> Seems like split_unique_types() pass is a prerequisite to make such transformations predictable on a larger scale. It
>> simplifies the memory graph and untangles instance-related memory operations from the rest of the graph.
> 
> Can you elaborate on your suggestion?
> 
> As you correctly pointed in your original post, EA and SR heavily depend on _instance_id which is Allocation node's _idx
> value. And the solution for this is either remove reference to merge phi. Or introduce new "virtual allocation" which
> fields are populated by loads - but it is again needs to split through phi.
> 
>> 
>> Otherwise, I believe wide memory states/merges would pose serious problems. E.g., when a load is split through a phi,
>> you need to pick correct memory states for the new loads above the phi which quickly becomes quite a challenging task.
> 
> Especially in loops. Actually I did tried such approach before and I agree that it is hard.
> 
> Thanks,
> Vladimir K
> 
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>> ???? p0 = Allocate(...);
>>> ???? ...
>>> ???? p0.x = first;
>>> ???? p0.y = second;
>>>
>>> ???? if (cond) {
>>> ???????? p1 = Allocate(...);
>>> ???????? ...
>>> ???????? p1.x = second;
>>> ???????? p1.y = first;
>>> ???? }
>>>
>>> ???? p = phi(p0, p1) // unused and will be removed
>>>
>>>
>>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>> }
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>>>
>>>> Hi Cesar,
>>>>
>>>> Thanks for looking into enhancing EA.
>>>>
>>>> Overall, the proposal looks reasonable.
>>>>
>>>> I suggest to look more closely at split_unique_types().
>>>> It introduces a dedicated class of alias categories for fields of the allocation being eliminated and clones memory
>>>> graph. I don't see why it shouldn't work for multiple allocations.
>>>>
>>>> Moreover, split_unique_types() will break if you start optimizing multiple allocations at once. The notion of unique
>>>> alias should be adjusted and cover the union of unique aliases for all interacting allocations.
>>>>
>>>> Seems like you need to enhance SR to work on non-intersecting clusters of allocations.
>>>>
>>>> One thing to take care of: scalar replacement relies on TypeOopPtr::instance_id().
>>>>
>>>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>>>> ?? // a particular instance of this type which is distinct.
>>>> ?? // This is the node index of the allocation node creating this instance.
>>>> ?? int?????????? _instance_id;
>>>>
>>>> It'll break when multiple allocations are in play.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>> Hi there again!
>>>>>
>>>>> Can you please give me feedback on the following approach to at least partially
>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>
>>>>> The problem that I am trying to solve arises when allocations are merged after a
>>>>> control flow split. The code below shows _one example_ of such a situation.
>>>>>
>>>>> public int ex1(boolean cond, int x, int y) {
>>>>> ?? ? Point p = new Point(x, y);
>>>>> ?? ? if (cond)
>>>>> ?? ? ? ? p = new Point(y, x);
>>>>> ?? ? // Allocations for p are merged here.
>>>>> ?? ? return p.calc();
>>>>> }
>>>>>
>>>>> Assuming the method calls on "p" are inlined then the allocations will not
>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>> ?? ? p0 = Allocate(...);
>>>>> ?? ? ...
>>>>> ?? ? p0.x = first;
>>>>> ?? ? p0.y = second;
>>>>>
>>>>> ?? ? if (cond) {
>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>> ?? ? ? ? ...
>>>>> ?? ? ? ? p1.x = second;
>>>>> ?? ? ? ? p1.y = first;
>>>>> ?? ? }
>>>>>
>>>>> ?? ? p = phi(p0, p1)
>>>>>
>>>>> ?? ? return p.x - p.y;
>>>>> }
>>>>>
>>>>> However, one of the constraints implemented here [2], specifically the third
>>>>> one, will prevent the objects from being scalar replaced.
>>>>>
>>>>> The approach that I'm considering for solving the problem is to replace the Phi
>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of the objects
>>>>> in the original Phi. The IR for `ex1` would look something like this after the
>>>>> transformation:
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>> ?? ? p0 = Allocate(...);
>>>>> ?? ? ...
>>>>> ?? ? p0.x = first;
>>>>> ?? ? p0.y = second;
>>>>>
>>>>> ?? ? if (cond) {
>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>> ?? ? ? ? ...
>>>>> ?? ? ? ? p1.x = second;
>>>>> ?? ? ? ? p1.y = first;
>>>>> ?? ? }
>>>>>
>>>>> ?? ? pX = phi(first, second)
>>>>> ?? ? pY = phi(second, first)
>>>>>
>>>>> ?? ? return pX - pY;
>>>>> }
>>>>>
>>>>> I understand that this transformation might not be applicable for all cases and
>>>>> that it's not as simple as illustrated above. Also, it seems to me that much of
>>>>> what I'd have to implement is already implemented in other steps of the Scalar
>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>> implementation details I plan to use as much of the existing code as possible.
>>>>> The algorithm for the transformation would be like this:
>>>>>
>>>>> split_phis(phi)
>>>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>>>> ?? ? # then we can't remove it. The conditions here might possible be the
>>>>> ?? ? # same as the ones implemented in `PhaseMacroExpand::can_eliminate_allocation`
>>>>> ?? ? if cant_remove_phi_output(phi)
>>>>> ?? ? ? ? return ;
>>>>>
>>>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses field F
>>>>> ?? ? # member of the object resulting from `phi`.
>>>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>>>
>>>>> ?? ? foreach field in fields_used
>>>>> ?? ? ? ? producers = {}
>>>>>
>>>>> ?? ? ? ? # Create a list with the last Store for each field "field" on the
>>>>> ?? ? ? ? # scope of each of the Phi input objects.
>>>>> ?? ? ? ? foreach o in phi.inputs
>>>>> ?? ? ? ? ? ? # The function called below might re-use a lot of the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 'field'
>>>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>>>
>>>>> ?? ? ? ? update_consumers(field, field_phi)
>>>>>
>>>>> The implementation that I envisioned would be as a "pre-process" [3] step just
>>>>> after EA but before the constraint checks in `adjust_scalar_replaceable_state`
>>>>> [2]. If we agree that the overall Scalar Replacement implementation goes through
>>>>> the following major phases:
>>>>>
>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>>>>> ?? ? 3. Make call to Split_unique_types [4].
>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>>>>
>>>>> The transformation that I am proposing would change the overall flow to look
>>>>> like this:
>>>>>
>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>> ?? ? 2. ----> New: "Split phi functions" <----
>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based on a set of constraints.
>>>>> ?? ? 3. Make call to Split_unique_types [14].
>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be eliminated" <----
>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in Safepoints.
>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: AddP, ArrayCopy and CastP2X.
>>>>>
>>>>> Please let me know what you think and thank you for taking the time to review
>>>>> this!
>>>>>
>>>>>
>>>>> Regards,
>>>>> Cesar
>>>>>
>>>>> Notes:
>>>>>
>>>>> ?? ? [1] I am not sure yet how this approach will play with the case of a merge
>>>>> ?? ? ? ? with NULL.
>>>>> ?? ? [2] 
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fescape.cpp%23L1809&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cc2580fe523c640d628d708d9ed8f81f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637802022912055025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eNNCJjkdjWPcmIxl0VVqkpjdRcaCCSDB5Focx0R9EuY%3D&amp;reserved=0 
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cc2580fe523c640d628d708d9ed8f81f3*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637802022912055025*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=eNNCJjkdjWPcmIxl0VVqkpjdRcaCCSDB5Focx0R9EuY*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!e1Tzr2hFook2sJaiA9-MXwtcKvodRKFQqkwhQ8dvjTwf0ynm2nYg54zUTBwUJuxvji6W0Q$>
>>>>>
>>>>> ?? ? [3] Another option would be to "patch" the current implementation to be able
>>>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" approach would be
>>>>> ?? ? ? ? better, however, the "pre-process" approach is certainly much easier to test
>>>>> ?? ? ? ? and more readable.
>>>>>
>>>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>>>> ?? ? ? ? split_unique_types(). Would the transformation that I am proposing need to
>>>>> ?? ? ? ? be after the call to split_unique_types?

From duke at openjdk.java.net  Fri Feb 11 21:07:14 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 11 Feb 2022 21:07:14 GMT
Subject: Withdrawn: 8274982: Add a test for 8269574.
In-Reply-To: <suEKp7wGDJyYn0Sn432SW9uQXs2YTpiecvy8yki8YaM=.0e369669-52ce-4924-a00e-7ca404891e56@github.com>
References: <suEKp7wGDJyYn0Sn432SW9uQXs2YTpiecvy8yki8YaM=.0e369669-52ce-4924-a00e-7ca404891e56@github.com>
Message-ID: <ZLzaTSfHdo1Vqu6SsrV7GYjfV_83-dzDjHjCClDXFoA=.30f2dd56-f607-48f7-bd50-aabda5288f6d@github.com>

On Mon, 11 Oct 2021 09:55:28 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> This PR contains a relatively simple test which verifies that JVMTI-agents are correctly informed about exceptions caught in C2-compiled code. The 8269574 introduces pre-allocated exceptions in some paths, so the test tries to produce a number of various exceptions and check that provided small JVMTI agent got notified about all of them.

This pull request has been closed without being integrated.

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

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

From vladimir.x.ivanov at oracle.com  Fri Feb 11 22:22:34 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 12 Feb 2022 01:22:34 +0300
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
Message-ID: <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>


>>> For this simple case we can teach C2's IGVN to split fields loads 
>>> through Phi so that phi(p0, p1) is not used and allocations as well. 
>>> We can do that because we know that allocations and phi do not escape.
>>
>> Seems like split_unique_types() pass is a prerequisite to make such 
>> transformations predictable on a larger scale. It simplifies the 
>> memory graph and untangles instance-related memory operations from the 
>> rest of the graph.
> 
> Can you elaborate on your suggestion?
> 
> As you correctly pointed in your original post, EA and SR heavily depend 
> on _instance_id which is Allocation node's _idx value. And the solution 
> for this is either remove reference to merge phi. Or introduce new 
> "virtual allocation" which fields are populated by loads - but it is 
> again needs to split through phi.

My rough proposal is to group interfering non-escaping allocations into 
"clusters" and introduce separate memory slices for such clusters (as 
part of split_unique_types()). The clusters should not intersect, 
otherwise, the slice won't be unique anymore.

Once memory graph for unique alias is separated, it should be much 
simpler to further optimize it. If all memory operations are folded, the 
allocation can go away.

Splitting memory operations through phis should help untangle the 
allocations. So, even if one allocation can't be fully scalarized, it 
shouldn't keep other allocations from being scalarized (unless they alias).

I don't have a good understanding how new logic will interact with 
unique instance slices & _instance_id. Maybe a gradual transition from 
original graph to clustered slices to unique instance slices.

Best regards,
Vladimir Ivanov

>>
>> Otherwise, I believe wide memory states/merges would pose serious 
>> problems. E.g., when a load is split through a phi, you need to pick 
>> correct memory states for the new loads above the phi which quickly 
>> becomes quite a challenging task.
> 
> Especially in loops. Actually I did tried such approach before and I 
> agree that it is hard.
> 
> Thanks,
> Vladimir K
> 
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>> ???? p0 = Allocate(...);
>>> ???? ...
>>> ???? p0.x = first;
>>> ???? p0.y = second;
>>>
>>> ???? if (cond) {
>>> ???????? p1 = Allocate(...);
>>> ???????? ...
>>> ???????? p1.x = second;
>>> ???????? p1.y = first;
>>> ???? }
>>>
>>> ???? p = phi(p0, p1) // unused and will be removed
>>>
>>>
>>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>> }
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>>>
>>>> Hi Cesar,
>>>>
>>>> Thanks for looking into enhancing EA.
>>>>
>>>> Overall, the proposal looks reasonable.
>>>>
>>>> I suggest to look more closely at split_unique_types().
>>>> It introduces a dedicated class of alias categories for fields of 
>>>> the allocation being eliminated and clones memory graph. I don't see 
>>>> why it shouldn't work for multiple allocations.
>>>>
>>>> Moreover, split_unique_types() will break if you start optimizing 
>>>> multiple allocations at once. The notion of unique alias should be 
>>>> adjusted and cover the union of unique aliases for all interacting 
>>>> allocations.
>>>>
>>>> Seems like you need to enhance SR to work on non-intersecting 
>>>> clusters of allocations.
>>>>
>>>> One thing to take care of: scalar replacement relies on 
>>>> TypeOopPtr::instance_id().
>>>>
>>>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>>>> ?? // a particular instance of this type which is distinct.
>>>> ?? // This is the node index of the allocation node creating this 
>>>> instance.
>>>> ?? int?????????? _instance_id;
>>>>
>>>> It'll break when multiple allocations are in play.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>> Hi there again!
>>>>>
>>>>> Can you please give me feedback on the following approach to at 
>>>>> least partially
>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>
>>>>> The problem that I am trying to solve arises when allocations are 
>>>>> merged after a
>>>>> control flow split. The code below shows _one example_ of such a 
>>>>> situation.
>>>>>
>>>>> public int ex1(boolean cond, int x, int y) {
>>>>> ?? ? Point p = new Point(x, y);
>>>>> ?? ? if (cond)
>>>>> ?? ? ? ? p = new Point(y, x);
>>>>> ?? ? // Allocations for p are merged here.
>>>>> ?? ? return p.calc();
>>>>> }
>>>>>
>>>>> Assuming the method calls on "p" are inlined then the allocations 
>>>>> will not
>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>> ?? ? p0 = Allocate(...);
>>>>> ?? ? ...
>>>>> ?? ? p0.x = first;
>>>>> ?? ? p0.y = second;
>>>>>
>>>>> ?? ? if (cond) {
>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>> ?? ? ? ? ...
>>>>> ?? ? ? ? p1.x = second;
>>>>> ?? ? ? ? p1.y = first;
>>>>> ?? ? }
>>>>>
>>>>> ?? ? p = phi(p0, p1)
>>>>>
>>>>> ?? ? return p.x - p.y;
>>>>> }
>>>>>
>>>>> However, one of the constraints implemented here [2], specifically 
>>>>> the third
>>>>> one, will prevent the objects from being scalar replaced.
>>>>>
>>>>> The approach that I'm considering for solving the problem is to 
>>>>> replace the Phi
>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of 
>>>>> the objects
>>>>> in the original Phi. The IR for `ex1` would look something like 
>>>>> this after the
>>>>> transformation:
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>> ?? ? p0 = Allocate(...);
>>>>> ?? ? ...
>>>>> ?? ? p0.x = first;
>>>>> ?? ? p0.y = second;
>>>>>
>>>>> ?? ? if (cond) {
>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>> ?? ? ? ? ...
>>>>> ?? ? ? ? p1.x = second;
>>>>> ?? ? ? ? p1.y = first;
>>>>> ?? ? }
>>>>>
>>>>> ?? ? pX = phi(first, second)
>>>>> ?? ? pY = phi(second, first)
>>>>>
>>>>> ?? ? return pX - pY;
>>>>> }
>>>>>
>>>>> I understand that this transformation might not be applicable for 
>>>>> all cases and
>>>>> that it's not as simple as illustrated above. Also, it seems to me 
>>>>> that much of
>>>>> what I'd have to implement is already implemented in other steps of 
>>>>> the Scalar
>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>> implementation details I plan to use as much of the existing code 
>>>>> as possible.
>>>>> The algorithm for the transformation would be like this:
>>>>>
>>>>> split_phis(phi)
>>>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>>>> ?? ? # then we can't remove it. The conditions here might possible 
>>>>> be the
>>>>> ?? ? # same as the ones implemented in 
>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>> ?? ? if cant_remove_phi_output(phi)
>>>>> ?? ? ? ? return ;
>>>>>
>>>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses 
>>>>> field F
>>>>> ?? ? # member of the object resulting from `phi`.
>>>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>>>
>>>>> ?? ? foreach field in fields_used
>>>>> ?? ? ? ? producers = {}
>>>>>
>>>>> ?? ? ? ? # Create a list with the last Store for each field "field" 
>>>>> on the
>>>>> ?? ? ? ? # scope of each of the Phi input objects.
>>>>> ?? ? ? ? foreach o in phi.inputs
>>>>> ?? ? ? ? ? ? # The function called below might re-use a lot of the 
>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 
>>>>> 'field'
>>>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>>>
>>>>> ?? ? ? ? update_consumers(field, field_phi)
>>>>>
>>>>> The implementation that I envisioned would be as a "pre-process" 
>>>>> [3] step just
>>>>> after EA but before the constraint checks in 
>>>>> `adjust_scalar_replaceable_state`
>>>>> [2]. If we agree that the overall Scalar Replacement implementation 
>>>>> goes through
>>>>> the following major phases:
>>>>>
>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based 
>>>>> on a set of constraints.
>>>>> ?? ? 3. Make call to Split_unique_types [4].
>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>>>> Safepoints.
>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>> AddP, ArrayCopy and CastP2X.
>>>>>
>>>>> The transformation that I am proposing would change the overall 
>>>>> flow to look
>>>>> like this:
>>>>>
>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>> ?? ? 2. ----> New: "Split phi functions" <----
>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status based 
>>>>> on a set of constraints.
>>>>> ?? ? 3. Make call to Split_unique_types [14].
>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be 
>>>>> eliminated" <----
>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>>>> Safepoints.
>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>> AddP, ArrayCopy and CastP2X.
>>>>>
>>>>> Please let me know what you think and thank you for taking the time 
>>>>> to review
>>>>> this!
>>>>>
>>>>>
>>>>> Regards,
>>>>> Cesar
>>>>>
>>>>> Notes:
>>>>>
>>>>> ?? ? [1] I am not sure yet how this approach will play with the 
>>>>> case of a merge
>>>>> ?? ? ? ? with NULL.
>>>>> ?? ? [2] 
>>>>> https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809 
>>>>>
>>>>>
>>>>> ?? ? [3] Another option would be to "patch" the current 
>>>>> implementation to be able
>>>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" 
>>>>> approach would be
>>>>> ?? ? ? ? better, however, the "pre-process" approach is certainly 
>>>>> much easier to test
>>>>> ?? ? ? ? and more readable.
>>>>>
>>>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>>>> ?? ? ? ? split_unique_types(). Would the transformation that I am 
>>>>> proposing need to
>>>>> ?? ? ? ? be after the call to split_unique_types?

From vladimir.x.ivanov at oracle.com  Fri Feb 11 22:34:48 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Sat, 12 Feb 2022 01:34:48 +0300
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <1ee1c53b-7f10-9f41-70f3-aefc74a35cbe@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <BY5PR21MB147382D09454A0E1DD758E049A309@BY5PR21MB1473.namprd21.prod.outlook.com>
 <1ee1c53b-7f10-9f41-70f3-aefc74a35cbe@oracle.com>
Message-ID: <7ff2317a-58b4-e59e-aade-fbe96bfeaea7@oracle.com>


> Actually Roland suggested before to always run split_unique_types(), 
> even if non-escaping object is not scalar replaceable.
I second Roland suggestion. Irrespective of SR enhancements being 
discussed, it's beneficial to introduce unique instance slices for 
non-escaping allocations which aren't scalar replaceable.

(I experimented a bit with that idea before [1] and got some promising 
results.)

Best regards,
Vladimir Ivanov

[1] https://github.com/iwanowww/jdk/tree/split_unique_types

>>
>> ?> As you correctly pointed in your original post, EA and SR heavily 
>> depend on _instance_id which is Allocation node's _idx value.
>> ?> And the solution for this is either remove reference to merge phi. 
>> Or introduce new "virtual allocation" which fields are
>> ?> populated by loads - but it is again needs to split through phi.
>>
>> Vladimir K., are you suggesting something like this:
> 
> Yes, that is what I had in mind but it could be more complicated to 
> implement.
> The idea is to have new _instance_id after merge. It may not be useful 
> for this simple case but may help in others.
> We would still need to improve split_unique_types to find values to 
> store in its fields.
> 
>>
>> ??public int ex1(boolean cond, int first, int second) {
>> ?? ? ? p0 = ...;
>> ?? ? ? p0.x = first;
>> ?? ? ? p0.y = second;
>> ?? ? ? if (cond) {
>> ?? ? ? ? ? p1 = ...
>> ?? ? ? ? ? p1.x = second;
>> ?? ? ? ? ? p1.y = first;
>> ?? ? ? }
>> ?? ? ? p = VirtualAllocate(...);
>> ?? ? ? p.x = phi(first, second);
>> ?? ? ? p.y = phi(second, first);
>> ?? ? ? return p.x - p.y;
>> ??}
>>
>> Would the phi/merges for individual fields cause problems in 
>> split_unique_types/SR?
> 
> Split_unique_types/SR work on allocation's references and not on what is 
> stored in its fields.
> 
> Thanks,
> Vladimir
> 
>>
>>
>> Regards,
>> Cesar
>>
>> ------------------------------------------------------------------------------------------------------------------------ 
>>
>> *From:* Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> *Sent:* February 11, 2022 10:51 AM
>> *To:* Vladimir Ivanov <vladimir.x.ivanov at oracle.com>; Cesar Soares 
>> Lucas <Divino.Cesar at microsoft.com>; hotspot compiler 
>> <hotspot-compiler-dev at openjdk.java.net>
>> *Cc:* Brian Stafford <Brian.Stafford at microsoft.com>; Martijn Verburg 
>> <Martijn.Verburg at microsoft.com>
>> *Subject:* Re: RFC : Approach to handle Allocation Merges in C2 Scalar 
>> Replacement
>> On 2/11/22 10:24 AM, Vladimir Ivanov wrote:
>>>
>>>> For this simple case we can teach C2's IGVN to split fields loads 
>>>> through Phi so that phi(p0, p1) is not used and
>>>> allocations as well. We can do that because we know that allocations 
>>>> and phi do not escape.
>>>
>>> Seems like split_unique_types() pass is a prerequisite to make such 
>>> transformations predictable on a larger scale. It
>>> simplifies the memory graph and untangles instance-related memory 
>>> operations from the rest of the graph.
>>
>> Can you elaborate on your suggestion?
>>
>> As you correctly pointed in your original post, EA and SR heavily 
>> depend on _instance_id which is Allocation node's _idx
>> value. And the solution for this is either remove reference to merge 
>> phi. Or introduce new "virtual allocation" which
>> fields are populated by loads - but it is again needs to split through 
>> phi.
>>
>>>
>>> Otherwise, I believe wide memory states/merges would pose serious 
>>> problems. E.g., when a load is split through a phi,
>>> you need to pick correct memory states for the new loads above the 
>>> phi which quickly becomes quite a challenging task.
>>
>> Especially in loops. Actually I did tried such approach before and I 
>> agree that it is hard.
>>
>> Thanks,
>> Vladimir K
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>> ???? p0 = Allocate(...);
>>>> ???? ...
>>>> ???? p0.x = first;
>>>> ???? p0.y = second;
>>>>
>>>> ???? if (cond) {
>>>> ???????? p1 = Allocate(...);
>>>> ???????? ...
>>>> ???????? p1.x = second;
>>>> ???????? p1.y = first;
>>>> ???? }
>>>>
>>>> ???? p = phi(p0, p1) // unused and will be removed
>>>>
>>>>
>>>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>> }
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>> (BCCing hotspot-dev and moving the discussion to 
>>>>> hotspot-compiler-dev.)
>>>>>
>>>>> Hi Cesar,
>>>>>
>>>>> Thanks for looking into enhancing EA.
>>>>>
>>>>> Overall, the proposal looks reasonable.
>>>>>
>>>>> I suggest to look more closely at split_unique_types().
>>>>> It introduces a dedicated class of alias categories for fields of 
>>>>> the allocation being eliminated and clones memory
>>>>> graph. I don't see why it shouldn't work for multiple allocations.
>>>>>
>>>>> Moreover, split_unique_types() will break if you start optimizing 
>>>>> multiple allocations at once. The notion of unique
>>>>> alias should be adjusted and cover the union of unique aliases for 
>>>>> all interacting allocations.
>>>>>
>>>>> Seems like you need to enhance SR to work on non-intersecting 
>>>>> clusters of allocations.
>>>>>
>>>>> One thing to take care of: scalar replacement relies on 
>>>>> TypeOopPtr::instance_id().
>>>>>
>>>>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>>>>> ?? // a particular instance of this type which is distinct.
>>>>> ?? // This is the node index of the allocation node creating this 
>>>>> instance.
>>>>> ?? int?????????? _instance_id;
>>>>>
>>>>> It'll break when multiple allocations are in play.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>> Hi there again!
>>>>>>
>>>>>> Can you please give me feedback on the following approach to at 
>>>>>> least partially
>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>
>>>>>> The problem that I am trying to solve arises when allocations are 
>>>>>> merged after a
>>>>>> control flow split. The code below shows _one example_ of such a 
>>>>>> situation.
>>>>>>
>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>> ?? ? Point p = new Point(x, y);
>>>>>> ?? ? if (cond)
>>>>>> ?? ? ? ? p = new Point(y, x);
>>>>>> ?? ? // Allocations for p are merged here.
>>>>>> ?? ? return p.calc();
>>>>>> }
>>>>>>
>>>>>> Assuming the method calls on "p" are inlined then the allocations 
>>>>>> will not
>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>> ?? ? p0 = Allocate(...);
>>>>>> ?? ? ...
>>>>>> ?? ? p0.x = first;
>>>>>> ?? ? p0.y = second;
>>>>>>
>>>>>> ?? ? if (cond) {
>>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>>> ?? ? ? ? ...
>>>>>> ?? ? ? ? p1.x = second;
>>>>>> ?? ? ? ? p1.y = first;
>>>>>> ?? ? }
>>>>>>
>>>>>> ?? ? p = phi(p0, p1)
>>>>>>
>>>>>> ?? ? return p.x - p.y;
>>>>>> }
>>>>>>
>>>>>> However, one of the constraints implemented here [2], specifically 
>>>>>> the third
>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>
>>>>>> The approach that I'm considering for solving the problem is to 
>>>>>> replace the Phi
>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields 
>>>>>> of the objects
>>>>>> in the original Phi. The IR for `ex1` would look something like 
>>>>>> this after the
>>>>>> transformation:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>> ?? ? p0 = Allocate(...);
>>>>>> ?? ? ...
>>>>>> ?? ? p0.x = first;
>>>>>> ?? ? p0.y = second;
>>>>>>
>>>>>> ?? ? if (cond) {
>>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>>> ?? ? ? ? ...
>>>>>> ?? ? ? ? p1.x = second;
>>>>>> ?? ? ? ? p1.y = first;
>>>>>> ?? ? }
>>>>>>
>>>>>> ?? ? pX = phi(first, second)
>>>>>> ?? ? pY = phi(second, first)
>>>>>>
>>>>>> ?? ? return pX - pY;
>>>>>> }
>>>>>>
>>>>>> I understand that this transformation might not be applicable for 
>>>>>> all cases and
>>>>>> that it's not as simple as illustrated above. Also, it seems to me 
>>>>>> that much of
>>>>>> what I'd have to implement is already implemented in other steps 
>>>>>> of the Scalar
>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>> implementation details I plan to use as much of the existing code 
>>>>>> as possible.
>>>>>> The algorithm for the transformation would be like this:
>>>>>>
>>>>>> split_phis(phi)
>>>>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>>>>> ?? ? # then we can't remove it. The conditions here might possible 
>>>>>> be the
>>>>>> ?? ? # same as the ones implemented in 
>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>> ?? ? if cant_remove_phi_output(phi)
>>>>>> ?? ? ? ? return ;
>>>>>>
>>>>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses 
>>>>>> field F
>>>>>> ?? ? # member of the object resulting from `phi`.
>>>>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>>>>
>>>>>> ?? ? foreach field in fields_used
>>>>>> ?? ? ? ? producers = {}
>>>>>>
>>>>>> ?? ? ? ? # Create a list with the last Store for each field 
>>>>>> "field" on the
>>>>>> ?? ? ? ? # scope of each of the Phi input objects.
>>>>>> ?? ? ? ? foreach o in phi.inputs
>>>>>> ?? ? ? ? ? ? # The function called below might re-use a lot of the 
>>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>>>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 
>>>>>> 'field'
>>>>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>>>>
>>>>>> ?? ? ? ? update_consumers(field, field_phi)
>>>>>>
>>>>>> The implementation that I envisioned would be as a "pre-process" 
>>>>>> [3] step just
>>>>>> after EA but before the constraint checks in 
>>>>>> `adjust_scalar_replaceable_state`
>>>>>> [2]. If we agree that the overall Scalar Replacement 
>>>>>> implementation goes through
>>>>>> the following major phases:
>>>>>>
>>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status 
>>>>>> based on a set of constraints.
>>>>>> ?? ? 3. Make call to Split_unique_types [4].
>>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>>>>> Safepoints.
>>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> The transformation that I am proposing would change the overall 
>>>>>> flow to look
>>>>>> like this:
>>>>>>
>>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>>> ?? ? 2. ----> New: "Split phi functions" <----
>>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status 
>>>>>> based on a set of constraints.
>>>>>> ?? ? 3. Make call to Split_unique_types [14].
>>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be 
>>>>>> eliminated" <----
>>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>>>>> Safepoints.
>>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> Please let me know what you think and thank you for taking the 
>>>>>> time to review
>>>>>> this!
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Cesar
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>> ?? ? [1] I am not sure yet how this approach will play with the 
>>>>>> case of a merge
>>>>>> ?? ? ? ? with NULL.
>>>>>> ?? ? [2] 
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fescape.cpp%23L1809&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cc2580fe523c640d628d708d9ed8f81f3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637802022912055025%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eNNCJjkdjWPcmIxl0VVqkpjdRcaCCSDB5Focx0R9EuY%3D&amp;reserved=0 
>>
>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cc2580fe523c640d628d708d9ed8f81f3*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637802022912055025*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=eNNCJjkdjWPcmIxl0VVqkpjdRcaCCSDB5Focx0R9EuY*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!e1Tzr2hFook2sJaiA9-MXwtcKvodRKFQqkwhQ8dvjTwf0ynm2nYg54zUTBwUJuxvji6W0Q$> 
>>
>>>>>>
>>>>>> ?? ? [3] Another option would be to "patch" the current 
>>>>>> implementation to be able
>>>>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" 
>>>>>> approach would be
>>>>>> ?? ? ? ? better, however, the "pre-process" approach is certainly 
>>>>>> much easier to test
>>>>>> ?? ? ? ? and more readable.
>>>>>>
>>>>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>>>>> ?? ? ? ? split_unique_types(). Would the transformation that I am 
>>>>>> proposing need to
>>>>>> ?? ? ? ? be after the call to split_unique_types?

From duke at openjdk.java.net  Sat Feb 12 07:15:21 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Sat, 12 Feb 2022 07:15:21 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel
Message-ID: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>

Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)

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

Commit messages:
 - Fix TieredStopAtLevel requirements for certain tests

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

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

From jbhateja at openjdk.java.net  Sat Feb 12 15:14:45 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 12 Feb 2022 15:14:45 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v3]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <giQvPrCTzkj6LpFpTkrFzqFGCj5rAuAiR_rI0yWyHY0=.466d1488-4455-4dfa-9b41-bd8a495dfe13@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8281375: Review comments resoultion.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/4da75cc5..6f390f61

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

  Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7373/head:pull/7373

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

From jbhateja at openjdk.java.net  Sun Feb 13 02:55:14 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Feb 2022 02:55:14 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v2]
In-Reply-To: <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <LQMZEAy-QU55kNt5fwFQSI8JPGuYz-nRWhuWVkKMt5c=.e5245c2f-c111-4c3d-829c-db44bca43e47@github.com>
 <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com>
Message-ID: <SKEroM6QsoBV4Btj6kAemSCqqRfHT4mm33Avdy1L8l4=.fcd38193-3821-4573-8bca-300e22f875fe@github.com>

On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4
> 
> The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80).

Hi @sviswa7 ,
As per JLS 17 section 15.4 Java follows round to nearest rounding policy for all floating point operations except conversion to integer and remainder where it uses round toward zero.  

So it may not be feasible to modify global MXCSR.RC setting,  also modifying MXCSR setting just before rounding and re-setting back to its original value after operation will also not work as OOO processor is free to re-order LMXCSR instruction if used without any barriers and thus it may also influence other floating point operation. 
I am pushing an incremental patch which is vectorizes existing rounding APIs and is showing significant gain over existing implementation.

Best Regards,
Jatin

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

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

From jbhateja at openjdk.java.net  Sun Feb 13 03:09:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Feb 2022 03:09:43 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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:

 - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - 8279508: Adding a test for scalar intrinsification.
 - 8279508: Auto-vectorize Math.round API

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/575d2935..2dc364fa

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

  Stats: 33695 lines in 1192 files changed: 23243 ins; 5703 del; 4749 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

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

From duke at openjdk.java.net  Sun Feb 13 03:23:06 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 13 Feb 2022 03:23:06 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
Message-ID: <HY93TdvVThuY7yV2NPR7CqRW7EjDEffrRo2mHd1wTpM=.a0bc8b13-cb9d-4ef0-a151-2aa231e0c1fc@github.com>

On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
>> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> 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:
> 
>  - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Adding a test for scalar intrinsification.
>  - 8279508: Auto-vectorize Math.round API

Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.

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

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

From duke at openjdk.java.net  Sun Feb 13 05:18:34 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 13 Feb 2022 05:18:34 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v3]
In-Reply-To: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
Message-ID: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>

> Hi,
> 
> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  missing ForceInline

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7358/files
  - new: https://git.openjdk.java.net/jdk/pull/7358/files/8028be52..cf78527b

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

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

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

From duke at openjdk.java.net  Sun Feb 13 05:18:36 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 13 Feb 2022 05:18:36 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <Mw8wnUYFgKMIS124_zvUI4wtV_s7YHydLEwiwkOC0Fw=.72a1e123-3272-40d7-8d95-746fa3da061b@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>
 <Mw8wnUYFgKMIS124_zvUI4wtV_s7YHydLEwiwkOC0Fw=.72a1e123-3272-40d7-8d95-746fa3da061b@github.com>
Message-ID: <RhoQzZ82rJ1zpohq2Z-8JEuJCA-hM46UXwz5H-GOchU=.d5c06efe-41d1-404d-8a9a-bef65102dd32@github.com>

On Thu, 10 Feb 2022 18:55:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - minor rename
>>  - address reviews
>
> Observing the following failures on CPUs with "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags:
> 
> -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation
> 
> 
> TestVectorCastAVX512.java:
> 
> Failed IR Rules (1)
> ------------------
> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUI256toL512(int[],long[])":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastI2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\\d+(\\s){2}(VectorUCastI2X.*)+(\\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> 
> TestVectorCastAVX1.java:
> 
> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toS64(byte[],short[])":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toI128(byte[],int[])":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*)
>         Expected 1 but found 0 nodes.

@PaulSandoz Thanks a lot for your testing, the reason seems to be due to `LaneType::asIntegral` missing `ForceInline` annotation. I have run the reshape test 10 times without getting any failure while with previous patch there is often 1 or 2.
Thanks.

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

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

From duke at openjdk.java.net  Sun Feb 13 08:39:11 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 13 Feb 2022 08:39:11 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
Message-ID: <MdXxpQTvJnax2dacUVyo4VxKXA9UwCQ0qe67mNwmHgs=.e9714016-6e63-43e5-a1dc-3af6e46d21e9@github.com>

On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
>> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> 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:
> 
>  - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Adding a test for scalar intrinsification.
>  - 8279508: Auto-vectorize Math.round API

Also, it seems you have tried using `roundss/sd/ps/pd` followed by a cast to correct the rounding behaviour but decided to take another approach. Some comments around the functions explaining why that is so would be preferable. Thanks.

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

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

From aph at openjdk.java.net  Sun Feb 13 11:01:06 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 13 Feb 2022 11:01:06 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
Message-ID: <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>

On Sun, 13 Feb 2022 03:09:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
>> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> 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:
> 
>  - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Adding a test for scalar intrinsification.
>  - 8279508: Auto-vectorize Math.round API

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4066:

> 4064: }
> 4065: 
> 4066: void C2_MacroAssembler::vector_cast_double_special_cases_evex(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,

What does this do? Comment, even pseudo code, would be nice.

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

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

From jbhateja at openjdk.java.net  Sun Feb 13 13:12:07 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Feb 2022 13:12:07 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
 <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
Message-ID: <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>

On Sun, 13 Feb 2022 10:58:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> 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:
>> 
>>  - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>>  - 8279508: Adding a test for scalar intrinsification.
>>  - 8279508: Auto-vectorize Math.round API
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4066:
> 
>> 4064: }
>> 4065: 
>> 4066: void C2_MacroAssembler::vector_cast_double_special_cases_evex(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,
> 
> What does this do? Comment, even pseudo code, would be nice.

> Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.

Hi @merykitty ,  You are correct, we can embed RC mode in instruction encoding round instructions (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values also are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects.

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

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

From jbhateja at openjdk.java.net  Sun Feb 13 13:16:16 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Feb 2022 13:16:16 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
 <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
 <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>
Message-ID: <iCaaelBgPdReusZLD-8eM-XDbw_xWsV5mv1vq4umRcg=.58de564c-df8f-4d20-96fd-e64389421cc0@github.com>

On Sun, 13 Feb 2022 13:08:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4066:
>> 
>>> 4064: }
>>> 4065: 
>>> 4066: void C2_MacroAssembler::vector_cast_double_special_cases_evex(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,
>> 
>> What does this do? Comment, even pseudo code, would be nice.
>
>> Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.
> 
> Hi @merykitty ,  You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values also are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects.

> What does this do? Comment, even pseudo code, would be nice.

Thanks @theRealAph , I shall append the comments over the routine.
BTW, entire rounding algorithm can also be implemented using  Vector API which can perform if-conversion using masked operations.

class roundf {
   public static VectorSpecies ISPECIES = IntVector.SPECIES_512;
   public static VectorSpecies SPECIES = FloatVector.SPECIES_512;

   public static int round_vector(float[] a, int[] r, int ctr) {
      IntVector shiftVBC = (IntVector) ISPECIES.broadcast(24 - 2 + 127);
      for (int i = 0; i < a.length; i += SPECIES.length()) {
         FloatVector fv = FloatVector.fromArray(SPECIES, a, i);
         IntVector iv = fv.reinterpretAsInts();
         IntVector biasedExpV = iv.lanewise(VectorOperators.AND, 0x7F800000);
         biasedExpV = biasedExpV.lanewise(VectorOperators.ASHR, 23);
         IntVector shiftV = shiftVBC.lanewise(VectorOperators.SUB, biasedExpV);
         VectorMask cond = shiftV.lanewise(VectorOperators.AND, -32)
               .compare(VectorOperators.EQ, 0);
         IntVector res = iv.lanewise(VectorOperators.AND, 0x007FFFFF)
               .lanewise(VectorOperators.OR, 0x007FFFFF + 1);
         VectorMask cond1 = iv.compare(VectorOperators.LT, 0);
         VectorMask cond2 = cond1.and(cond);
         res = res.lanewise(VectorOperators.NEG, cond2);
         res = res.lanewise(VectorOperators.ASHR, shiftV)
               .lanewise(VectorOperators.ADD, 1)
               .lanewise(VectorOperators.ASHR, 1);
         res = fv.convert(VectorOperators.F2I, 0)
               .reinterpretAsInts()
               .blend(res, cond);
         res.intoArray(r, i);
      }
      return r[ctr];
   }

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

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

From yyang at openjdk.java.net  Mon Feb 14 06:12:43 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 14 Feb 2022 06:12:43 GMT
Subject: RFR: 8281701: Mismatched array filling pattern can be stopped earlier
Message-ID: <erp8Wc2aa98V5aiNnKXs4tiZRzoS1qgv7O6c4oUxCso=.b9a91deb-59c3-4e20-91f6-3ed0e31e5c3e@github.com>

This patch 1. checks the valid counted loop earlier 2. checks stored value/stored address earlier 3. During array filling matching, unpack_offsets is a reverse operation of array_element_address, so it seems that unpacked elements are always invariant: [0]:Constant [1]:ConvI2B/LShift/Phi(??I don't know why we could find a phi, but I kept the original code) 4. Some refactor.

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

Commit messages:
 - 8281701 Mismatched array filling pattern can be stopped earlier

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

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

From chagedorn at openjdk.java.net  Mon Feb 14 06:59:09 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Feb 2022 06:59:09 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v3]
In-Reply-To: <xQAmRVPF1pUI6P__Ls0U--q6K9zUeR5_v_wFklRMf3c=.37e74305-34c2-451a-9bef-b740cacdb606@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <xQAmRVPF1pUI6P__Ls0U--q6K9zUeR5_v_wFklRMf3c=.37e74305-34c2-451a-9bef-b740cacdb606@github.com>
Message-ID: <3nfFLJLEGsx1CyCxkqfVp6cmYLTUGgB31AW4q8vg4PM=.73b55db1-eabe-4aaa-9447-e0afa2a57456@github.com>

On Fri, 11 Feb 2022 18:47:00 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
>> 
>> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
>> 
>> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
>> 
>> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
>> 
>> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
>> 
>> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Guard C2 only code

Marked as reviewed by chagedorn (Reviewer).

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

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

From chagedorn at openjdk.java.net  Mon Feb 14 08:20:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Feb 2022 08:20:10 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <P9_dov7nIOw_jTHibewXYfywOp2fngbKyc7d4TAfbk4=.57e2d7ff-9d07-4290-a1ee-645726faa298@github.com>

On Thu, 10 Feb 2022 22:12:53 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

Apart from some minor things and some possible missing cases when comparing the `int` vs `long` tests, it looks good to me!

test/hotspot/jtreg/compiler/c2/irTests/AddLNodeIdealizationTests.java line 73:

> 71:         Asserts.assertEQ((a - b) + (b + c), test6(a, b, c));
> 72:         Asserts.assertEQ((a - b) + (c + b), test7(a, b, c));
> 73:         Asserts.assertEQ((a - b) + (c - a), test8(a, b, c));

`AddI` additionally has 

Asserts.assertEQ((a - b) + (b - c), test8(a, b, c));

Was this left out on purpose?

test/hotspot/jtreg/compiler/c2/irTests/DivINodeIdealizationTests.java line 128:

> 126:     @IR(counts = {IRNode.MUL, "1",
> 127:                   IRNode.DIV, "1",
> 128:                   IRNode.TRAP, "1"

Maybe we could add a new default regex `IRNode.DIV_BY_ZERO_TRAP`?

test/hotspot/jtreg/compiler/c2/irTests/DivINodeIdealizationTests.java line 149:

> 147:                  })
> 148:     // Checks (x & -(2^c0)) / 2^c1 => (x >> c1) & (2^c0 >> c1) => (x >> c1) & c3 where 2^c0 > |2^c1| and c3 = 2^c0 >> c1
> 149:     // Having a large enough and in the dividend removes the need to account for rounding when converting to shifts and multiplies as in divByPow2()

Maybe you capitalize `and` -> `AND`, same further down. I first read it as a normal word "and" which was confusing :-)

test/hotspot/jtreg/compiler/c2/irTests/SubLNodeIdealizationTests.java line 79:

> 77:         Asserts.assertEQ(a*b - b*c        , test16(a, b, c));
> 78:         Asserts.assertEQ(a*c - b*c        , test17(a, b, c));
> 79:         Asserts.assertEQ(a*b - c*a        , test18(a, b, c));

Some cases are missing compared to `SubI`. Did you omit them on purpose?

test/hotspot/jtreg/compiler/c2/irTests/loopOpts/LoopIdealizationTests.java line 94:

> 92:                this.blackhole();
> 93:                i++;
> 94:            }

Wrong indentation.

test/hotspot/jtreg/compiler/c2/irTests/loopOpts/LoopIdealizationTests.java line 129:

> 127:         while (i < 500){
> 128:             this.blackhole();
> 129:             if (i == 0){

Spacing

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

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

From neliasso at openjdk.java.net  Mon Feb 14 08:31:20 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 14 Feb 2022 08:31:20 GMT
Subject: RFR: 8281505: Add CompileCommand PrintIdealPhase [v3]
In-Reply-To: <FddIxLJ7DXZvyntn0OFGRCTfDc7_ej-FLOoafFmjgGw=.7715eca5-dc80-48d3-a51b-d9a460b34458@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
 <xQAmRVPF1pUI6P__Ls0U--q6K9zUeR5_v_wFklRMf3c=.37e74305-34c2-451a-9bef-b740cacdb606@github.com>
 <FddIxLJ7DXZvyntn0OFGRCTfDc7_ej-FLOoafFmjgGw=.7715eca5-dc80-48d3-a51b-d9a460b34458@github.com>
Message-ID: <SyiHBvVB5uL-fErwEq0WZt0DVreQ2Dq9OCbnKyUmLVA=.0aca2990-bbae-4da9-a629-2f3b1c95719a@github.com>

On Fri, 11 Feb 2022 18:53:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Guard C2 only code
>
> Good.
> 
> Wait result of GIT testing.

Thanks for the reviews and feedback! @vnkozlov @TobiHartmann @chhagedorn

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

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

From neliasso at openjdk.java.net  Mon Feb 14 08:31:21 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 14 Feb 2022 08:31:21 GMT
Subject: Integrated: 8281505: Add CompileCommand PrintIdealPhase
In-Reply-To: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
References: <4Z-kFv1ei-shAjDxjR_vq3p1tw6jVyp-BeXAHr7_zUE=.3dee5bdd-bdf4-4027-8623-b29b7f37f941@github.com>
Message-ID: <gRAC3ZltPuZ0Dd_5Z73JLzW7RSm_ZJ0bkoGJWvYERbI=.80eed8fe-7af0-4fda-a200-b422044c82c6@github.com>

On Tue, 8 Feb 2022 22:34:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> 1. This patch adds the CompileCommand PrintIdealPhase. It allows to specify a list of compiler phases that will print the ideal IR.
> 
> -XX:CompileCommand=PrintIdealPhase,Class::method,MATCHING,FINAL_CODE"
> 
> The motivation for this is that during work with the IR framework I have found the need for printing specific phases, and the previously added PrintIdealLevel is forced to use levels that just prints to much. (I will remove PrintIdealLevel in a separate patch since it's not needed anymore.)
> 
> I have chosen not to add PrintIdealPhase as a VM flag, but keep it as CompileCommand/CompilerControl only.
> 
> 2. This patch also changes the print_ideal output to emit the start tag with the phase name instead of the description, so that the name in the CompileCommand matches with what ends up in the tag. That tag is a new addition since PrintIdealLevel, so no one is using it yet.
> 
> 3. This patch also removes an unused allocation in register_jfr_phasetype_serializer. 
> 
> Please review,
> Nils Eliasson

This pull request has now been integrated.

Changeset: 483d4b97
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/483d4b97e0ae4ab7b0d87058901f57688a0f0811
Stats:     408 lines in 10 files changed: 306 ins; 31 del; 71 mod

8281505: Add CompileCommand PrintIdealPhase

Reviewed-by: kvn, thartmann, chagedorn

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

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

From rcastanedalo at openjdk.java.net  Mon Feb 14 08:35:09 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 14 Feb 2022 08:35:09 GMT
Subject: RFR: 8281539: IGV: schedule approximation computes immediate
 dominators wrongly
In-Reply-To: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
References: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
Message-ID: <bsHU5b4y7PxOQAZhoGMLGfEennHw5hkGwgFnFGGH2IQ=.61c750be-699f-4af8-9f61-3e0a2a2fa762@github.com>

On Wed, 9 Feb 2022 15:16:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The `ServerCompiler` module in IGV computes an approximation of C2's schedule for unscheduled graphs, for clustering and showing control flow information in the "Control Flow" window. This approximation uses domination information to guide the scheduling of nodes into basic blocks. Currently, this information is computed with a custom algorithm implementation that gives wrong results for some graphs, as shown in [the issue report](https://bugs.openjdk.java.net/browse/JDK-8281539).
> 
> This change simply replaces the custom implementation with one from the [T. J. Watson Libraries for Analysis (WALA)](https://github.com/wala/WALA), a popular set of static analysis libraries licensed under the [OSI](http://www.opensource.org/)-approved [Eclipse Public License](http://www.eclipse.org/legal/epl-v10.html). The replacement gives correct domination information for the reported graphs and reduces significantly the complexity of the `ServerCompiler` module.
> 
> #### Testing
> 
> - Tested manually that the dominator tree computed for a few selected graphs (included the reported one) is correct.
> - Tested manually, for large graphs, that the dominator tree computation takes a negligible fraction (around 1%) of the entire graph scheduling time.
> - Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

Thanks Christian and Nils for reviewing!

@neliasso: yes, there are multiple sources of inaccuracy in IGV's schedule approximation, and this change addresses just one of them. [JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568) addresses another one (work in progress), and I am still collecting and documenting others.

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

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

From roland at openjdk.java.net  Mon Feb 14 08:39:16 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Feb 2022 08:39:16 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination [v2]
In-Reply-To: <fFKdtdHR8iNm8K432ibJO-baeP0Qmh0V_pKzYtspxCI=.d8b55eb6-8333-4bd1-9f5c-cf105ee14113@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
 <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
 <fFKdtdHR8iNm8K432ibJO-baeP0Qmh0V_pKzYtspxCI=.d8b55eb6-8333-4bd1-9f5c-cf105ee14113@github.com>
Message-ID: <acVVsre0XtNnPZ-gtqkVM9X6wjGMCRVqTRG0CG0K4_w=.08d5a77c-0773-40bc-8c24-9cb01a8a8219@github.com>

On Wed, 9 Feb 2022 13:37:53 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - fix
>>  - Merge branch 'master' into JDK-8280799
>>  - fix & test
>
> Sure, I'll re-run testing and report back.

Thanks @TobiHartmann and @vnkozlov for the reviews.

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

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

From roland at openjdk.java.net  Mon Feb 14 08:39:17 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Feb 2022 08:39:17 GMT
Subject: Integrated: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination
In-Reply-To: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
Message-ID: <mDcd0bdypgdco30E8LUYCdJnAJaWdiJMxqQka1h1dOs=.8e5a3db4-a34c-4281-9131-8a9da9a00903@github.com>

On Wed, 2 Feb 2022 10:38:11 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The loop exit condition of the test method:
> 
> if (i == stop) {
>     break;
> }
> 
> requires insertion of a loop limit predicate when the loop is turned
> into a counted loop. stop is a LoadI. Next:
> 
> array[stop - i + j] = 0;
> 
> is transformed to:
> 
> array[stop - i] = 0;
> 
> and the range check for that array access becomes candidate for
> predication in a subsequent loop opts pass. stop has control just
> above the loop limit check when that happens (because it is assigned
> control as late as possible). But the loop predicate for the bound
> check needs to be above the loop limit check and that causes the
> assert failure.
> 
> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
> to assign control to nodes above predicates so this sort of issues
> doesn't occur. But it only applies to node initially on the entry
> projection right above the loop head. The fix I propose is to remove
> that restriction.
> 
> That logic was added by JDK-8203197 and looking back at this change I
> noticed I replaced some existing logic with the current logic but,
> while the 2 overlap, the current logic is not guaranteed to always
> cover some cases handled by the old logic. So I resurrected that old
> logic here.
> 
> Finally, when running tests, I hit failures because Opaque nodes for
> skeleton predicates can now end up above a predicate that is split
> thru phi. That causes the Opaque nodes to be split up and breaks
> pattern matching. I'm actually not sure this issue is specific to the
> change here so I think it's best to treat it as a general issue and
> fix it by cloning the chain of nodes that lead to the Opaque node
> down.

This pull request has now been integrated.

Changeset: 1ef45c5b
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1ef45c5bbdeb4e1ca65c6d8f3ac1568a6951f3a7
Stats:     340 lines in 3 files changed: 314 ins; 21 del; 5 mod

8280799: ?2: assert(false) failed: cyclic dependency prevents range check elimination

Reviewed-by: thartmann, kvn

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

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

From rcastanedalo at openjdk.java.net  Mon Feb 14 08:41:12 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 14 Feb 2022 08:41:12 GMT
Subject: Integrated: 8281539: IGV: schedule approximation computes immediate
 dominators wrongly
In-Reply-To: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
References: <ZArGnO_SdLJdmHrweAusWObh1NGy3LWR74cppJXHXWU=.41df4ab4-c9c5-43ca-b476-a95ceae5dd6b@github.com>
Message-ID: <NN7BNCdlZm5Rm4NJqJx2v6deVUwKTV_x6SE1NnLrPnQ=.86d44631-53a3-402c-ac05-d4af6bf1053a@github.com>

On Wed, 9 Feb 2022 15:16:42 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> The `ServerCompiler` module in IGV computes an approximation of C2's schedule for unscheduled graphs, for clustering and showing control flow information in the "Control Flow" window. This approximation uses domination information to guide the scheduling of nodes into basic blocks. Currently, this information is computed with a custom algorithm implementation that gives wrong results for some graphs, as shown in [the issue report](https://bugs.openjdk.java.net/browse/JDK-8281539).
> 
> This change simply replaces the custom implementation with one from the [T. J. Watson Libraries for Analysis (WALA)](https://github.com/wala/WALA), a popular set of static analysis libraries licensed under the [OSI](http://www.opensource.org/)-approved [Eclipse Public License](http://www.eclipse.org/legal/epl-v10.html). The replacement gives correct domination information for the reported graphs and reduces significantly the complexity of the `ServerCompiler` module.
> 
> #### Testing
> 
> - Tested manually that the dominator tree computed for a few selected graphs (included the reported one) is correct.
> - Tested manually, for large graphs, that the dominator tree computation takes a negligible fraction (around 1%) of the entire graph scheduling time.
> - Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

This pull request has now been integrated.

Changeset: 46f52296
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46f522962f1b2bbb2513823821e332db1093994b
Stats:     166 lines in 3 files changed: 9 ins; 140 del; 17 mod

8281539: IGV: schedule approximation computes immediate dominators wrongly

Replace custom dominator computation with one from the WALA libraries.

Reviewed-by: neliasso, chagedorn

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

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

From aph at openjdk.java.net  Mon Feb 14 09:16:10 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 14 Feb 2022 09:16:10 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <iCaaelBgPdReusZLD-8eM-XDbw_xWsV5mv1vq4umRcg=.58de564c-df8f-4d20-96fd-e64389421cc0@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
 <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
 <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>
 <iCaaelBgPdReusZLD-8eM-XDbw_xWsV5mv1vq4umRcg=.58de564c-df8f-4d20-96fd-e64389421cc0@github.com>
Message-ID: <EKNLSOdo1lrE-PbeZZ9YC9LonG9FhmDitLo_Wa60vYk=.c4324df4-3b7d-4b12-939e-e74de8e6ae76@github.com>

On Sun, 13 Feb 2022 13:12:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.
>> 
>> Hi @merykitty ,  You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects.
>
>> What does this do? Comment, even pseudo code, would be nice.
> 
> Thanks @theRealAph , I shall append the comments over the routine.
> BTW, entire rounding algorithm can also be implemented using  Vector API which can perform if-conversion using masked operations.
> 
> class roundf {
>    public static VectorSpecies ISPECIES = IntVector.SPECIES_512;
>    public static VectorSpecies SPECIES = FloatVector.SPECIES_512;
> 
>    public static int round_vector(float[] a, int[] r, int ctr) {
>       IntVector shiftVBC = (IntVector) ISPECIES.broadcast(24 - 2 + 127);
>       for (int i = 0; i < a.length; i += SPECIES.length()) {
>          FloatVector fv = FloatVector.fromArray(SPECIES, a, i);
>          IntVector iv = fv.reinterpretAsInts();
>          IntVector biasedExpV = iv.lanewise(VectorOperators.AND, 0x7F800000);
>          biasedExpV = biasedExpV.lanewise(VectorOperators.ASHR, 23);
>          IntVector shiftV = shiftVBC.lanewise(VectorOperators.SUB, biasedExpV);
>          VectorMask cond = shiftV.lanewise(VectorOperators.AND, -32)
>                .compare(VectorOperators.EQ, 0);
>          IntVector res = iv.lanewise(VectorOperators.AND, 0x007FFFFF)
>                .lanewise(VectorOperators.OR, 0x007FFFFF + 1);
>          VectorMask cond1 = iv.compare(VectorOperators.LT, 0);
>          VectorMask cond2 = cond1.and(cond);
>          res = res.lanewise(VectorOperators.NEG, cond2);
>          res = res.lanewise(VectorOperators.ASHR, shiftV)
>                .lanewise(VectorOperators.ADD, 1)
>                .lanewise(VectorOperators.ASHR, 1);
>          res = fv.convert(VectorOperators.F2I, 0)
>                .reinterpretAsInts()
>                .blend(res, cond);
>          res.intoArray(r, i);
>       }
>       return r[ctr];
>    }

That pseudocode would make a very useful comment too. This whole patch is very thinly commented.

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

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

From neliasso at openjdk.java.net  Mon Feb 14 09:24:35 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 14 Feb 2022 09:24:35 GMT
Subject: RFR: 8281722: Removal of PrintIdealLevel
Message-ID: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>

The PrintIdealLevel flag was recently introduced to support testing of different phase in the IR-test framework. In practice the fit was bad and lot of excess data was printed. The PrintIdealPhase, that gives exact control of ideal printing, was added as a substitution.

This patch removes the PrintIdealLevel flag since it's no longer needed.

Best regards,
Nils Eliasson

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

Commit messages:
 - Removal of PrintIdealLevel

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

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

From chagedorn at openjdk.java.net  Mon Feb 14 09:58:09 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Feb 2022 09:58:09 GMT
Subject: RFR: 8281722: Removal of PrintIdealLevel
In-Reply-To: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
References: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
Message-ID: <VYIejUmwFnqZMUkT-44O1dWUZGfLIMOkObPUom1sVIE=.75f9b782-3162-4164-b39e-dd0b23f59a45@github.com>

On Mon, 14 Feb 2022 09:14:53 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> The PrintIdealLevel flag was recently introduced to support testing of different phase in the IR-test framework. In practice the fit was bad and lot of excess data was printed. The PrintIdealPhase, that gives exact control of ideal printing, was added as a substitution.
> 
> This patch removes the PrintIdealLevel flag since it's no longer needed.
> 
> Best regards,
> Nils Eliasson

Makes sense to remove this flag again now that we got `PrintIdealPhase`. Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From nils.eliasson at oracle.com  Mon Feb 14 10:11:13 2022
From: nils.eliasson at oracle.com (Nils Eliasson)
Date: Mon, 14 Feb 2022 11:11:13 +0100
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <08ce070f-339d-38b4-7867-d74d4f671dfc@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <4fe4310c-9509-3ab7-fefe-e8e2edffd402@oracle.com>
 <08ce070f-339d-38b4-7867-d74d4f671dfc@oracle.com>
Message-ID: <441fb1a5-60bc-2894-a70a-e80e7bddd116@oracle.com>

The transformation is equal to having multiple return point:

public int ex1(boolean cond, int first, int second) {
 ??? p0 = Allocate(...);
 ??? ...
 ??? p0.x = first;
 ??? p0.y = second;

 ??? if (cond) {
 ??????? p1 = call(...); // or allocate
 ??????? ...
 ??????? p1.x = second;
 ??????? p1.y = first;

 ??????? return p1.x - p1.y;
 ??? }

 ??? return p0.x - p0.y;
}

As long as p1.x and p1.y doesn't float up above any other call or 
synchronization point in the '...' section, there are no point at which 
concurrent field updates can be visible between the threads. The stores 
to p1 can't be elided, but p0 is fair game.

Regards,
Nils

On 2022-02-11 19:01, Vladimir Kozlov wrote:
> We can't do that unless we know that p0 does not escape in call() (we 
> do such analysis in EA code already).
> Otherwise there could be concurrent p0's fields updates.
>
> Thanks,
> Vladimir K
>
> On 2/11/22 1:38 AM, Nils Eliasson wrote:
>> This is also useful if only one of the paths are a local allocation. 
>> We must just be sure that the original phi actually can be removed.
>>
>> public int ex1(boolean cond, int first, int second) {
>>
>> ???? p0 = call(...)
>>
>> ???? if (cond) {
>> ???????? p1 = Allocate(...);
>> ???????? ...
>> ???????? p1.x = second;
>> ???????? p1.y = first;
>> ???? }
>>
>> ???? p = phi(p0, p1) // unused and will be removed
>>
>>
>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>> }
>>
>> Regards,
>> Nils
>>
>> On 2022-02-11 05:07, Vladimir Kozlov wrote:
>>> For this simple case we can teach C2's IGVN to split fields loads 
>>> through Phi so that phi(p0, p1) is not used and allocations as well. 
>>> We can do that because we know that allocations and phi do not escape.
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>> ??? p0 = Allocate(...);
>>> ??? ...
>>> ??? p0.x = first;
>>> ??? p0.y = second;
>>>
>>> ??? if (cond) {
>>> ??????? p1 = Allocate(...);
>>> ??????? ...
>>> ??????? p1.x = second;
>>> ??????? p1.y = first;
>>> ??? }
>>>
>>> ??? p = phi(p0, p1) // unused and will be removed
>>>
>>>
>>> ??? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>> }
>>>
>>> Thanks,
>>> Vladimir K 
>>


From thartmann at openjdk.java.net  Mon Feb 14 10:37:54 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Feb 2022 10:37:54 GMT
Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare
 intrinsic in SVE
Message-ID: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>

We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures.

Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending.

Thanks,
Tobias

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

Commit messages:
 - Revert "8275448: [REDO] AArch64: Implement string_compare intrinsic in SVE"

Changes: https://git.openjdk.java.net/jdk18/pull/116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=116&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281713
  Stats: 423 lines in 9 files changed: 0 ins; 412 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/116/head:pull/116

PR: https://git.openjdk.java.net/jdk18/pull/116

From vlivanov at openjdk.java.net  Mon Feb 14 12:01:13 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 14 Feb 2022 12:01:13 GMT
Subject: Integrated: 8256368: Avoid repeated upcalls into Java to re-resolve
 MH/VH linkers/invokers
In-Reply-To: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
References: <Qc-QF7Gl1XBJ8u2TCy4_BoVvqiSr_F6xcKP_gx6eOzU=.de568bc4-6a53-400d-84af-1a14b3a8fd65@github.com>
Message-ID: <QvuSdTyf5HYXKMD5R9mwn6dHdC-Kmq4UMAT_7fyu4Ws=.3872feb0-270b-4643-9ce4-d23b11b9f6bc@github.com>

On Thu, 10 Feb 2022 16:57:30 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> It's another attempt to fix JDK-8256368 (previous one was #1453). 
> 
> @coleenp raised a question about resolution failure case (`indy_resolution_failed()`) and after a closer look it turned out the logic is broken there. 
> 
> After thinking more about it, I decided to completely drop resolution failure case handling and always perform re-resolution.
> For MethodHandle/VarHandle invokers resolution failure is very uncommon, so going through re-resolution step seems well-justified.
> 
> Original description:
> 
> Method linkage of invokehandle instructions involve an upcall into Java
> (MethodHandleNatives::linkMethod), but the result is not cached. Unless the
> upcall behaves idempotently (which is highly desirable, but not guaranteed),
> repeated invokehandle resolution attempts enter a vicious cycle in tiered mode:
> switching to a higher tier involves call site re-resolution in generated code,
> but re-resolution installs a fresh method which puts execution back into
> interpreter.
> 
> (Another prerequisite is no inlining through a invokehandle which doesn't
> normally happen in practice - relevant methods are marked w/ @ForceInline -
> except some testing modes, -Xcomp in particular.)
> 
> Proposed fix is to inspect ConstantPoolCache first. Previous resolution
> attempts from interpreter and C1 records their results there and it stabilises
> the execution.
> 
> Testing: hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 534e5578
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/534e557874274255c55086b4f6128063cbd9cc58
Stats:     47 lines in 5 files changed: 22 ins; 12 del; 13 mod

8256368: Avoid repeated upcalls into Java to re-resolve MH/VH linkers/invokers

Reviewed-by: dlong, kvn

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

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

From duke at openjdk.java.net  Mon Feb 14 12:23:57 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Mon, 14 Feb 2022 12:23:57 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
Message-ID: <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>

> Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception of `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)

TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
 - Fix TieredStopAtLevel requirements for certain tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7451/files
  - new: https://git.openjdk.java.net/jdk/pull/7451/files/1428c12d..667cd20b

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

  Stats: 1811 lines in 113 files changed: 1020 ins; 467 del; 324 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7451.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7451/head:pull/7451

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

From redestad at openjdk.java.net  Mon Feb 14 13:28:09 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 14 Feb 2022 13:28:09 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <zKDz3xkFEjpbCP_UuX_qhkKHdOD1cT_punkftYt9xlI=.b6cc4b1f-0a86-4875-84a3-1a961e3f3d69@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

Looks great!

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

Marked as reviewed by redestad (Reviewer).

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

From vlivanov at openjdk.java.net  Mon Feb 14 13:51:47 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 14 Feb 2022 13:51:47 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries [v2]
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <WL8TzT6cFJhpAHJzjOepGeD6kwfEeLL7ea2Hk6j7QRk=.a72f6d58-44fc-4c60-a840-cef00e72493f@github.com>

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

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

  Fix minimal build failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7423/files
  - new: https://git.openjdk.java.net/jdk/pull/7423/files/73d5fbde..d29a5c94

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

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

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

From neliasso at openjdk.java.net  Mon Feb 14 14:00:17 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 14 Feb 2022 14:00:17 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries [v2]
In-Reply-To: <WL8TzT6cFJhpAHJzjOepGeD6kwfEeLL7ea2Hk6j7QRk=.a72f6d58-44fc-4c60-a840-cef00e72493f@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
 <WL8TzT6cFJhpAHJzjOepGeD6kwfEeLL7ea2Hk6j7QRk=.a72f6d58-44fc-4c60-a840-cef00e72493f@github.com>
Message-ID: <p1A5OP-l0HiOEpn4D6LNREJiLhDN22fveBJlY2Ce9_k=.7a823c6e-06df-4437-b088-5ac08d6aeaef@github.com>

On Mon, 14 Feb 2022 13:51:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
>> 
>> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
>> 
>> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
>> 
>> Testing: hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minimal build failure

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From duke at openjdk.java.net  Mon Feb 14 15:06:28 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 14 Feb 2022 15:06:28 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out
Message-ID: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>

?_out

unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.

I improved the code by having two functions instead:
unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.

This makes implicit assumptions explicit and also validates them in the future.

I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.

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

Commit messages:
 - 8281732: add assert for non-NULL assumption for return of unique_ctrl_out

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

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

From duke at openjdk.java.net  Mon Feb 14 15:18:52 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 14 Feb 2022 15:18:52 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v2]
In-Reply-To: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
Message-ID: <-UkLBcT3KlfHRB9Sq8Kvpo8GmCUkrL9t9tAeQex_bdM=.2c872645-e5de-44ba-8a35-d50d97272b0b@github.com>

> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
> 
> I improved the code by having two functions instead:
> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
> 
> This makes implicit assumptions explicit and also validates them in the future.
> 
> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright year and minor code style issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7462/files
  - new: https://git.openjdk.java.net/jdk/pull/7462/files/a23b34ad..d2efb501

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

  Stats: 8 lines in 6 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7462.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7462/head:pull/7462

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

From thartmann at openjdk.java.net  Mon Feb 14 16:02:10 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Feb 2022 16:02:10 GMT
Subject: RFR: 8281722: Removal of PrintIdealLevel
In-Reply-To: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
References: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
Message-ID: <ghi3KJc1pGxtVeZCk5Flsa1oMc8UjIfMDVxKiGibFeE=.5d4817eb-eed3-46fb-8a74-e7d1b096c68f@github.com>

On Mon, 14 Feb 2022 09:14:53 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> The PrintIdealLevel flag was recently introduced to support testing of different phase in the IR-test framework. In practice the fit was bad and lot of excess data was printed. The PrintIdealPhase, that gives exact control of ideal printing, was added as a substitution.
> 
> This patch removes the PrintIdealLevel flag since it's no longer needed.
> 
> Best regards,
> Nils Eliasson

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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

From jbhateja at openjdk.java.net  Mon Feb 14 17:18:07 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 14 Feb 2022 17:18:07 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <EKNLSOdo1lrE-PbeZZ9YC9LonG9FhmDitLo_Wa60vYk=.c4324df4-3b7d-4b12-939e-e74de8e6ae76@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
 <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
 <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>
 <iCaaelBgPdReusZLD-8eM-XDbw_xWsV5mv1vq4umRcg=.58de564c-df8f-4d20-96fd-e64389421cc0@github.com>
 <EKNLSOdo1lrE-PbeZZ9YC9LonG9FhmDitLo_Wa60vYk=.c4324df4-3b7d-4b12-939e-e74de8e6ae76@github.com>
Message-ID: <UMm_6uonBzgdEoJzE3zbiZ2MTeBRh8FWEgR1wjk-SMI=.ecc686f6-f233-4335-a810-89f540992f93@github.com>

On Mon, 14 Feb 2022 09:12:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> What does this do? Comment, even pseudo code, would be nice.
>> 
>> Thanks @theRealAph , I shall append the comments over the routine.
>> BTW, entire rounding algorithm can also be implemented using  Vector API which can perform if-conversion using masked operations.
>> 
>> class roundf {
>>    public static VectorSpecies ISPECIES = IntVector.SPECIES_512;
>>    public static VectorSpecies SPECIES = FloatVector.SPECIES_512;
>> 
>>    public static int round_vector(float[] a, int[] r, int ctr) {
>>       IntVector shiftVBC = (IntVector) ISPECIES.broadcast(24 - 2 + 127);
>>       for (int i = 0; i < a.length; i += SPECIES.length()) {
>>          FloatVector fv = FloatVector.fromArray(SPECIES, a, i);
>>          IntVector iv = fv.reinterpretAsInts();
>>          IntVector biasedExpV = iv.lanewise(VectorOperators.AND, 0x7F800000);
>>          biasedExpV = biasedExpV.lanewise(VectorOperators.ASHR, 23);
>>          IntVector shiftV = shiftVBC.lanewise(VectorOperators.SUB, biasedExpV);
>>          VectorMask cond = shiftV.lanewise(VectorOperators.AND, -32)
>>                .compare(VectorOperators.EQ, 0);
>>          IntVector res = iv.lanewise(VectorOperators.AND, 0x007FFFFF)
>>                .lanewise(VectorOperators.OR, 0x007FFFFF + 1);
>>          VectorMask cond1 = iv.compare(VectorOperators.LT, 0);
>>          VectorMask cond2 = cond1.and(cond);
>>          res = res.lanewise(VectorOperators.NEG, cond2);
>>          res = res.lanewise(VectorOperators.ASHR, shiftV)
>>                .lanewise(VectorOperators.ADD, 1)
>>                .lanewise(VectorOperators.ASHR, 1);
>>          res = fv.convert(VectorOperators.F2I, 0)
>>                .reinterpretAsInts()
>>                .blend(res, cond);
>>          res.intoArray(r, i);
>>       }
>>       return r[ctr];
>>    }
>
> That pseudocode would make a very useful comment too. This whole patch is very thinly commented.

> > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.
> 
> Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects.

**Just want to correct above statement, LDMXCSR will not be re-ordered/re-scheduled early OOO backend.**

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

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

From vlivanov at openjdk.java.net  Mon Feb 14 18:50:16 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 14 Feb 2022 18:50:16 GMT
Subject: Integrated: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic
 constant pool entries
In-Reply-To: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
Message-ID: <H-K16tsU-n_rX3U-Tz0DbdiVTKbcFS4SjbA5fMgpBWE=.1909a7e8-adbf-4f27-bccd-1d7c724ad15b@github.com>

On Thu, 10 Feb 2022 11:37:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
> 
> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
> 
> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
> 
> Testing: hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 88fc3bfd
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/88fc3bfdff7f89a02fcfb16909df144e6173c658
Stats:     477 lines in 12 files changed: 375 ins; 60 del; 42 mod

8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant pool entries

Reviewed-by: dlong, redestad, neliasso

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

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

From vlivanov at openjdk.java.net  Mon Feb 14 18:50:15 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 14 Feb 2022 18:50:15 GMT
Subject: RFR: 8280473: CI: Support unresolved JVM_CONSTANT_Dynamic constant
 pool entries [v2]
In-Reply-To: <WL8TzT6cFJhpAHJzjOepGeD6kwfEeLL7ea2Hk6j7QRk=.a72f6d58-44fc-4c60-a840-cef00e72493f@github.com>
References: <YX7gOGspZkgeYDuqG9hv3m5p6UXWgAR7hnfXrGjwsw0=.a08de369-2b4b-4625-a675-26287f345d50@github.com>
 <WL8TzT6cFJhpAHJzjOepGeD6kwfEeLL7ea2Hk6j7QRk=.a72f6d58-44fc-4c60-a840-cef00e72493f@github.com>
Message-ID: <2sA7wA7b8F0_xwKwFBAy3UJVH8F5vOZicb_qkQYDcd8=.0f56c279-517e-48fc-917e-765408ce420a@github.com>

On Mon, 14 Feb 2022 13:51:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Properly support unresolved CONSTANT_Dynamic CP entries in C1/C2.
>> 
>> Right now, both compilers bail out the compilation when they encounter a single unresolved dynamic constant. It forces users to do eager resolution which defeats the whole purpose of using dynamic constants. 
>> 
>> The patch is focused on C1 and enables code patching for dynamic constants, but there are minor C2-specific changes to avoid compilation bailouts there. 
>> 
>> Testing: hs-tier1 - hs-tier4
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minimal build failure

Thanks for the reviews, Dean, Claes, and Nils.

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

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

From neliasso at openjdk.java.net  Mon Feb 14 19:09:34 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 14 Feb 2022 19:09:34 GMT
Subject: RFR: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp
Message-ID: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>

Hi,

The PrintIdealPhaseTest fails with Xcomp - the test method is inlined, and not compiled. Adding a DontInline command to fix this. 

Also excluding this test from Xcomp - the flag it's propagated to the sub tests which spends a lot of time wasting energy compiling nothing of interest.

Please review,
Nils Eliasson

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

Commit messages:
 - 8281741: PrintIdealPhaseTest fails with -Xcomp

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

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

From Divino.Cesar at microsoft.com  Mon Feb 14 19:32:10 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Mon, 14 Feb 2022 19:32:10 +0000
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
Message-ID: <DM6PR21MB1484F4125F3142FEF3DC2C1D9A339@DM6PR21MB1484.namprd21.prod.outlook.com>

Here is my understanding from the discussion so far, please correct me if I'm
wrong: Improving split_unique_types to make it able to handle "clusters" of
allocations will not only make it easier to implement the "split through phi"
transformation but also make it applicable to more complex merge situations. 
Did I get it right?


Regards,
Cesar
________________________________________
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Sent: February 11, 2022 2:22 PM
To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
Cc: Brian Stafford; Martijn Verburg
Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement


>>> For this simple case we can teach C2's IGVN to split fields loads
>>> through Phi so that phi(p0, p1) is not used and allocations as well.
>>> We can do that because we know that allocations and phi do not escape.
>>
>> Seems like split_unique_types() pass is a prerequisite to make such
>> transformations predictable on a larger scale. It simplifies the
>> memory graph and untangles instance-related memory operations from the
>> rest of the graph.
>
> Can you elaborate on your suggestion?
>
> As you correctly pointed in your original post, EA and SR heavily depend
> on _instance_id which is Allocation node's _idx value. And the solution
> for this is either remove reference to merge phi. Or introduce new
> "virtual allocation" which fields are populated by loads - but it is
> again needs to split through phi.

My rough proposal is to group interfering non-escaping allocations into
"clusters" and introduce separate memory slices for such clusters (as
part of split_unique_types()). The clusters should not intersect,
otherwise, the slice won't be unique anymore.

Once memory graph for unique alias is separated, it should be much
simpler to further optimize it. If all memory operations are folded, the
allocation can go away.

Splitting memory operations through phis should help untangle the
allocations. So, even if one allocation can't be fully scalarized, it
shouldn't keep other allocations from being scalarized (unless they alias).

I don't have a good understanding how new logic will interact with
unique instance slices & _instance_id. Maybe a gradual transition from
original graph to clustered slices to unique instance slices.

Best regards,
Vladimir Ivanov

>>
>> Otherwise, I believe wide memory states/merges would pose serious
>> problems. E.g., when a load is split through a phi, you need to pick
>> correct memory states for the new loads above the phi which quickly
>> becomes quite a challenging task.
>
> Especially in loops. Actually I did tried such approach before and I
> agree that it is hard.
>
> Thanks,
> Vladimir K
>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> public int ex1(boolean cond, int first, int second) {
>>>      p0 = Allocate(...);
>>>      ...
>>>      p0.x = first;
>>>      p0.y = second;
>>>
>>>      if (cond) {
>>>          p1 = Allocate(...);
>>>          ...
>>>          p1.x = second;
>>>          p1.y = first;
>>>      }
>>>
>>>      p = phi(p0, p1) // unused and will be removed
>>>
>>>
>>>      return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>> }
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>>>
>>>> Hi Cesar,
>>>>
>>>> Thanks for looking into enhancing EA.
>>>>
>>>> Overall, the proposal looks reasonable.
>>>>
>>>> I suggest to look more closely at split_unique_types().
>>>> It introduces a dedicated class of alias categories for fields of
>>>> the allocation being eliminated and clones memory graph. I don't see
>>>> why it shouldn't work for multiple allocations.
>>>>
>>>> Moreover, split_unique_types() will break if you start optimizing
>>>> multiple allocations at once. The notion of unique alias should be
>>>> adjusted and cover the union of unique aliases for all interacting
>>>> allocations.
>>>>
>>>> Seems like you need to enhance SR to work on non-intersecting
>>>> clusters of allocations.
>>>>
>>>> One thing to take care of: scalar replacement relies on
>>>> TypeOopPtr::instance_id().
>>>>
>>>>    // If not InstanceTop or InstanceBot, indicates that this is
>>>>    // a particular instance of this type which is distinct.
>>>>    // This is the node index of the allocation node creating this
>>>> instance.
>>>>    int           _instance_id;
>>>>
>>>> It'll break when multiple allocations are in play.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>> Hi there again!
>>>>>
>>>>> Can you please give me feedback on the following approach to at
>>>>> least partially
>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>
>>>>> The problem that I am trying to solve arises when allocations are
>>>>> merged after a
>>>>> control flow split. The code below shows _one example_ of such a
>>>>> situation.
>>>>>
>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>      Point p = new Point(x, y);
>>>>>      if (cond)
>>>>>          p = new Point(y, x);
>>>>>      // Allocations for p are merged here.
>>>>>      return p.calc();
>>>>> }
>>>>>
>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>> will not
>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>      p0 = Allocate(...);
>>>>>      ...
>>>>>      p0.x = first;
>>>>>      p0.y = second;
>>>>>
>>>>>      if (cond) {
>>>>>          p1 = Allocate(...);
>>>>>          ...
>>>>>          p1.x = second;
>>>>>          p1.y = first;
>>>>>      }
>>>>>
>>>>>      p = phi(p0, p1)
>>>>>
>>>>>      return p.x - p.y;
>>>>> }
>>>>>
>>>>> However, one of the constraints implemented here [2], specifically
>>>>> the third
>>>>> one, will prevent the objects from being scalar replaced.
>>>>>
>>>>> The approach that I'm considering for solving the problem is to
>>>>> replace the Phi
>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of
>>>>> the objects
>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>> this after the
>>>>> transformation:
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>      p0 = Allocate(...);
>>>>>      ...
>>>>>      p0.x = first;
>>>>>      p0.y = second;
>>>>>
>>>>>      if (cond) {
>>>>>          p1 = Allocate(...);
>>>>>          ...
>>>>>          p1.x = second;
>>>>>          p1.y = first;
>>>>>      }
>>>>>
>>>>>      pX = phi(first, second)
>>>>>      pY = phi(second, first)
>>>>>
>>>>>      return pX - pY;
>>>>> }
>>>>>
>>>>> I understand that this transformation might not be applicable for
>>>>> all cases and
>>>>> that it's not as simple as illustrated above. Also, it seems to me
>>>>> that much of
>>>>> what I'd have to implement is already implemented in other steps of
>>>>> the Scalar
>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>> implementation details I plan to use as much of the existing code
>>>>> as possible.
>>>>> The algorithm for the transformation would be like this:
>>>>>
>>>>> split_phis(phi)
>>>>>      # If output of phi escapes, or something uses its identity, etc
>>>>>      # then we can't remove it. The conditions here might possible
>>>>> be the
>>>>>      # same as the ones implemented in
>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>      if cant_remove_phi_output(phi)
>>>>>          return ;
>>>>>
>>>>>      # Collect a set of tuples(F,U) containing nodes U that uses
>>>>> field F
>>>>>      # member of the object resulting from `phi`.
>>>>>      fields_used = collect_fields_used_after_phi(phi)
>>>>>
>>>>>      foreach field in fields_used
>>>>>          producers = {}
>>>>>
>>>>>          # Create a list with the last Store for each field "field"
>>>>> on the
>>>>>          # scope of each of the Phi input objects.
>>>>>          foreach o in phi.inputs
>>>>>              # The function called below might re-use a lot of the
>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>              producers += last_store_to_o_field(0, field)
>>>>>          # Create a new phi node whose inputs are the Store's to
>>>>> 'field'
>>>>>          field_phi = create_new_phi(producers)
>>>>>
>>>>>          update_consumers(field, field_phi)
>>>>>
>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>> [3] step just
>>>>> after EA but before the constraint checks in
>>>>> `adjust_scalar_replaceable_state`
>>>>> [2]. If we agree that the overall Scalar Replacement implementation
>>>>> goes through
>>>>> the following major phases:
>>>>>
>>>>>      1. Identify the Escape Status of objects.
>>>>>      2. Adjust object Escape and/or Scalar Replacement status based
>>>>> on a set of constraints.
>>>>>      3. Make call to Split_unique_types [4].
>>>>>      4 Iterate over object and array allocations.
>>>>>          4.1 Check if allocation can be eliminated.
>>>>>          4.2 Perform scalar replacement. Replace uses of object in
>>>>> Safepoints.
>>>>>          4.3 Process users of CheckCastPP other than Safepoint:
>>>>> AddP, ArrayCopy and CastP2X.
>>>>>
>>>>> The transformation that I am proposing would change the overall
>>>>> flow to look
>>>>> like this:
>>>>>
>>>>>      1. Identify the Escape Status of objects.
>>>>>      2. ----> New: "Split phi functions" <----
>>>>>      2. Adjust object Escape and/or Scalar Replacement status based
>>>>> on a set of constraints.
>>>>>      3. Make call to Split_unique_types [14].
>>>>>      4 Iterate over object and array allocations.
>>>>>          4.1 ----> Moved to split_phi: "Check if allocation can be
>>>>> eliminated" <----
>>>>>          4.2 Perform scalar replacement. Replace uses of object in
>>>>> Safepoints.
>>>>>          4.3 Process users of CheckCastPP other than Safepoint:
>>>>> AddP, ArrayCopy and CastP2X.
>>>>>
>>>>> Please let me know what you think and thank you for taking the time
>>>>> to review
>>>>> this!
>>>>>
>>>>>
>>>>> Regards,
>>>>> Cesar
>>>>>
>>>>> Notes:
>>>>>
>>>>>      [1] I am not sure yet how this approach will play with the
>>>>> case of a merge
>>>>>          with NULL.
>>>>>      [2]
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fescape.cpp%23L1809&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cb8b9939a638d4382b64208d9edad0a0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637802149742125104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=lP%2BGg%2Fk4LBvQ3lCxYGlseHvOel8E8W2PW3bQNwqg5JQ%3D&amp;reserved=0
>>>>>
>>>>>
>>>>>      [3] Another option would be to "patch" the current
>>>>> implementation to be able
>>>>>          to handle the merges. I am not certain that the "patch"
>>>>> approach would be
>>>>>          better, however, the "pre-process" approach is certainly
>>>>> much easier to test
>>>>>          and more readable.
>>>>>
>>>>>      [4] I cannot say I understand 100% the effects of executing
>>>>>          split_unique_types(). Would the transformation that I am
>>>>> proposing need to
>>>>>          be after the call to split_unique_types?

From psandoz at openjdk.java.net  Mon Feb 14 19:35:10 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 14 Feb 2022 19:35:10 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v3]
In-Reply-To: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>
Message-ID: <BdB8jNfGoM7uzfoD53-axEryX0d0cKvaHUxLtIUVYDE=.c9f59d32-63e8-4d93-9cd3-ea463a7fc77b@github.com>

On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing ForceInline

Marked as reviewed by psandoz (Reviewer).

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

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

From psandoz at openjdk.java.net  Mon Feb 14 19:35:10 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 14 Feb 2022 19:35:10 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v2]
In-Reply-To: <RhoQzZ82rJ1zpohq2Z-8JEuJCA-hM46UXwz5H-GOchU=.d5c06efe-41d1-404d-8a9a-bef65102dd32@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <y5ea-XiYdEiEZ8Nv1TLY-1g22N0ONyfK-7Zdb_U4Alw=.8da05ea8-2f44-4c2a-b601-9c17d5fe6669@github.com>
 <Mw8wnUYFgKMIS124_zvUI4wtV_s7YHydLEwiwkOC0Fw=.72a1e123-3272-40d7-8d95-746fa3da061b@github.com>
 <RhoQzZ82rJ1zpohq2Z-8JEuJCA-hM46UXwz5H-GOchU=.d5c06efe-41d1-404d-8a9a-bef65102dd32@github.com>
Message-ID: <DBc-yBG5N0VyxPLAEXDLvD442bp6YPJ8mGZEw6IA5cI=.b96fc9ad-30c2-4231-88b1-54803b53c73d@github.com>

On Sun, 13 Feb 2022 05:14:47 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Observing the following failures on CPUs with "Intel_R__Xeon_R__Gold_6354_CPU___3.00GHz" with HotSpot flags:
>> 
>> -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation
>> 
>> 
>> TestVectorCastAVX512.java:
>> 
>> Failed IR Rules (1)
>> ------------------
>> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUI256toL512(int[],long[])":
>>   * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastI2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
>>     - counts: Graph contains wrong number of nodes:
>>         Regex 1: (\\d+(\\s){2}(VectorUCastI2X.*)+(\\s){2}===.*)
>>         Expected 1 but found 0 nodes.
>> 
>> 
>> TestVectorCastAVX1.java:
>> 
>> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toS64(byte[],short[])":
>>   * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
>>     - counts: Graph contains wrong number of nodes:
>>         Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*)
>>         Expected 1 but found 0 nodes.
>> 
>> - Method "public static void compiler.vectorapi.reshape.tests.TestVectorCast.testUB64toI128(byte[],int[])":
>>   * @IR rule 1: "@compiler.lib.ir_framework.IR(failOn={}, applyIf={}, applyIfAnd={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(VectorUCastB2X.*)+(\\\\s){2}===.*)", "1"}, applyIfNot={})"
>>     - counts: Graph contains wrong number of nodes:
>>         Regex 1: (\\d+(\\s){2}(VectorUCastB2X.*)+(\\s){2}===.*)
>>         Expected 1 but found 0 nodes.
>
> @PaulSandoz Thanks a lot for your testing, the reason seems to be due to `LaneType::asIntegral` missing `ForceInline` annotation. I have run the reshape test 10 times without getting any failure while with previous patch there is often 1 or 2.
> Thanks.

@merykitty testing now passes. Java bits look good. Needs HotSpot reviewer.

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

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

From vladimir.x.ivanov at oracle.com  Mon Feb 14 19:39:54 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 14 Feb 2022 22:39:54 +0300
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
Message-ID: <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>


> Once memory graph for unique alias is separated, it should be much 
> simpler to further optimize it. If all memory operations are folded, the 
> allocation can go away.
> 
> Splitting memory operations through phis should help untangle the 
> allocations. So, even if one allocation can't be fully scalarized, it 
> shouldn't keep other allocations from being scalarized (unless they alias).
> 
> I don't have a good understanding how new logic will interact with 
> unique instance slices & _instance_id. Maybe a gradual transition from 
> original graph to clustered slices to unique instance slices.

I took a closer look at a slightly more complicated example:

     class A {
         int i;
         A(int i) { this.i = i; }
     }

     static int testPolluted(int r, boolean b) {
         A obj1 = new A(r);
         A obj2 = new A(r);

         A obj = (b ? obj1 : obj2);
         for (int i = 1; i < r; i++) {
             obj.i++;
         }

         return obj1.i + obj2.i;
     }

There are 3 interacting memory slices: obj1.i, obj2.i, and obj.i (which 
alias with obj1.i and obj2.i).

Unless the access inside the loop is eliminated, there's no way to 
untangle the memory graphs for obj1.i and obj2.i and scalarize allocations.

In this particular case, it's quite straightforward to untangle the 
graphs for instance types (and make both obj1 and obj2 scalarizable):

     static int testUnqiue(int r, boolean b) {
         A obj1 = new A(r);
         A obj2 = new A(r);

         for (int i = 1; i < r; i++) {
             if (b) {
                 obj1.i++;
             } else {
                 obj2.i++;
             }
         }
         return obj1.i + obj2.i;
     }

But depending on the actual shape of the base pointer (here it's 
Phi(obj1,obj2)), it may become infeasible (from performance perspective) 
or even impossible (e.g., for complex loop variant conditions) to 
separate instance slices.

So, gradual approach seems the way to go:
   (1) split memory graph for clusters of interacting non-escaping 
allocations;

   (2) perform adhoc transformation targeted at untangling aliasing 
accesses (e.g, split-through-phi);

   (3) extract unique instance types where possible, thus making the 
corresponding allocation scalar replaceable

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

Also, one observation: interacting allocations don't have to be of the 
same class.

     static int testPolluted(int r, boolean b) {
         A obj1 = new B1(r);
         A obj2 = new B2(r);

         A obj = (b ? obj1 : obj2);
         for (int i = 1; i < r; i++) {
             obj.i++;
         }

         return obj1.i + obj2.i;
     }

Requiring unique instance types to perform SR (and not enhancing SR to 
handle aliasing allocations case) helps avoid some challenges in 
instance rematerialization logic at safepoints, because actual shape of 
the scalarized object (its class and exact set of fields) becomes a 
runtime property.

Best regards,
Vladimir Ivanov

>>>
>>> Otherwise, I believe wide memory states/merges would pose serious 
>>> problems. E.g., when a load is split through a phi, you need to pick 
>>> correct memory states for the new loads above the phi which quickly 
>>> becomes quite a challenging task.
>>
>> Especially in loops. Actually I did tried such approach before and I 
>> agree that it is hard.
>>
>> Thanks,
>> Vladimir K
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>> ???? p0 = Allocate(...);
>>>> ???? ...
>>>> ???? p0.x = first;
>>>> ???? p0.y = second;
>>>>
>>>> ???? if (cond) {
>>>> ???????? p1 = Allocate(...);
>>>> ???????? ...
>>>> ???????? p1.x = second;
>>>> ???????? p1.y = first;
>>>> ???? }
>>>>
>>>> ???? p = phi(p0, p1) // unused and will be removed
>>>>
>>>>
>>>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>> }
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>> (BCCing hotspot-dev and moving the discussion to 
>>>>> hotspot-compiler-dev.)
>>>>>
>>>>> Hi Cesar,
>>>>>
>>>>> Thanks for looking into enhancing EA.
>>>>>
>>>>> Overall, the proposal looks reasonable.
>>>>>
>>>>> I suggest to look more closely at split_unique_types().
>>>>> It introduces a dedicated class of alias categories for fields of 
>>>>> the allocation being eliminated and clones memory graph. I don't 
>>>>> see why it shouldn't work for multiple allocations.
>>>>>
>>>>> Moreover, split_unique_types() will break if you start optimizing 
>>>>> multiple allocations at once. The notion of unique alias should be 
>>>>> adjusted and cover the union of unique aliases for all interacting 
>>>>> allocations.
>>>>>
>>>>> Seems like you need to enhance SR to work on non-intersecting 
>>>>> clusters of allocations.
>>>>>
>>>>> One thing to take care of: scalar replacement relies on 
>>>>> TypeOopPtr::instance_id().
>>>>>
>>>>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>>>>> ?? // a particular instance of this type which is distinct.
>>>>> ?? // This is the node index of the allocation node creating this 
>>>>> instance.
>>>>> ?? int?????????? _instance_id;
>>>>>
>>>>> It'll break when multiple allocations are in play.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>> Hi there again!
>>>>>>
>>>>>> Can you please give me feedback on the following approach to at 
>>>>>> least partially
>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>
>>>>>> The problem that I am trying to solve arises when allocations are 
>>>>>> merged after a
>>>>>> control flow split. The code below shows _one example_ of such a 
>>>>>> situation.
>>>>>>
>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>> ?? ? Point p = new Point(x, y);
>>>>>> ?? ? if (cond)
>>>>>> ?? ? ? ? p = new Point(y, x);
>>>>>> ?? ? // Allocations for p are merged here.
>>>>>> ?? ? return p.calc();
>>>>>> }
>>>>>>
>>>>>> Assuming the method calls on "p" are inlined then the allocations 
>>>>>> will not
>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>> ?? ? p0 = Allocate(...);
>>>>>> ?? ? ...
>>>>>> ?? ? p0.x = first;
>>>>>> ?? ? p0.y = second;
>>>>>>
>>>>>> ?? ? if (cond) {
>>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>>> ?? ? ? ? ...
>>>>>> ?? ? ? ? p1.x = second;
>>>>>> ?? ? ? ? p1.y = first;
>>>>>> ?? ? }
>>>>>>
>>>>>> ?? ? p = phi(p0, p1)
>>>>>>
>>>>>> ?? ? return p.x - p.y;
>>>>>> }
>>>>>>
>>>>>> However, one of the constraints implemented here [2], specifically 
>>>>>> the third
>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>
>>>>>> The approach that I'm considering for solving the problem is to 
>>>>>> replace the Phi
>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields 
>>>>>> of the objects
>>>>>> in the original Phi. The IR for `ex1` would look something like 
>>>>>> this after the
>>>>>> transformation:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>> ?? ? p0 = Allocate(...);
>>>>>> ?? ? ...
>>>>>> ?? ? p0.x = first;
>>>>>> ?? ? p0.y = second;
>>>>>>
>>>>>> ?? ? if (cond) {
>>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>>> ?? ? ? ? ...
>>>>>> ?? ? ? ? p1.x = second;
>>>>>> ?? ? ? ? p1.y = first;
>>>>>> ?? ? }
>>>>>>
>>>>>> ?? ? pX = phi(first, second)
>>>>>> ?? ? pY = phi(second, first)
>>>>>>
>>>>>> ?? ? return pX - pY;
>>>>>> }
>>>>>>
>>>>>> I understand that this transformation might not be applicable for 
>>>>>> all cases and
>>>>>> that it's not as simple as illustrated above. Also, it seems to me 
>>>>>> that much of
>>>>>> what I'd have to implement is already implemented in other steps 
>>>>>> of the Scalar
>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>> implementation details I plan to use as much of the existing code 
>>>>>> as possible.
>>>>>> The algorithm for the transformation would be like this:
>>>>>>
>>>>>> split_phis(phi)
>>>>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>>>>> ?? ? # then we can't remove it. The conditions here might possible 
>>>>>> be the
>>>>>> ?? ? # same as the ones implemented in 
>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>> ?? ? if cant_remove_phi_output(phi)
>>>>>> ?? ? ? ? return ;
>>>>>>
>>>>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses 
>>>>>> field F
>>>>>> ?? ? # member of the object resulting from `phi`.
>>>>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>>>>
>>>>>> ?? ? foreach field in fields_used
>>>>>> ?? ? ? ? producers = {}
>>>>>>
>>>>>> ?? ? ? ? # Create a list with the last Store for each field 
>>>>>> "field" on the
>>>>>> ?? ? ? ? # scope of each of the Phi input objects.
>>>>>> ?? ? ? ? foreach o in phi.inputs
>>>>>> ?? ? ? ? ? ? # The function called below might re-use a lot of the 
>>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>>>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 
>>>>>> 'field'
>>>>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>>>>
>>>>>> ?? ? ? ? update_consumers(field, field_phi)
>>>>>>
>>>>>> The implementation that I envisioned would be as a "pre-process" 
>>>>>> [3] step just
>>>>>> after EA but before the constraint checks in 
>>>>>> `adjust_scalar_replaceable_state`
>>>>>> [2]. If we agree that the overall Scalar Replacement 
>>>>>> implementation goes through
>>>>>> the following major phases:
>>>>>>
>>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status 
>>>>>> based on a set of constraints.
>>>>>> ?? ? 3. Make call to Split_unique_types [4].
>>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>>>>> Safepoints.
>>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> The transformation that I am proposing would change the overall 
>>>>>> flow to look
>>>>>> like this:
>>>>>>
>>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>>> ?? ? 2. ----> New: "Split phi functions" <----
>>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status 
>>>>>> based on a set of constraints.
>>>>>> ?? ? 3. Make call to Split_unique_types [14].
>>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can be 
>>>>>> eliminated" <----
>>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object in 
>>>>>> Safepoints.
>>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> Please let me know what you think and thank you for taking the 
>>>>>> time to review
>>>>>> this!
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Cesar
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>> ?? ? [1] I am not sure yet how this approach will play with the 
>>>>>> case of a merge
>>>>>> ?? ? ? ? with NULL.
>>>>>> ?? ? [2] 
>>>>>> https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809 
>>>>>>
>>>>>>
>>>>>> ?? ? [3] Another option would be to "patch" the current 
>>>>>> implementation to be able
>>>>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" 
>>>>>> approach would be
>>>>>> ?? ? ? ? better, however, the "pre-process" approach is certainly 
>>>>>> much easier to test
>>>>>> ?? ? ? ? and more readable.
>>>>>>
>>>>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>>>>> ?? ? ? ? split_unique_types(). Would the transformation that I am 
>>>>>> proposing need to
>>>>>> ?? ? ? ? be after the call to split_unique_types?

From duke at openjdk.java.net  Mon Feb 14 20:45:18 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Mon, 14 Feb 2022 20:45:18 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations
In-Reply-To: <P9_dov7nIOw_jTHibewXYfywOp2fngbKyc7d4TAfbk4=.57e2d7ff-9d07-4290-a1ee-645726faa298@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <P9_dov7nIOw_jTHibewXYfywOp2fngbKyc7d4TAfbk4=.57e2d7ff-9d07-4290-a1ee-645726faa298@github.com>
Message-ID: <EVkIICRW2AKMmf35vhkAST40Oko2KsNRdM-InXyBG8w=.928e94fe-520a-4bc5-b0b2-0aab4fbc972c@github.com>

On Mon, 14 Feb 2022 07:26:47 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
>> 
>> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
>> - Add more default IR regex's to IR-based test framework.
>
> test/hotspot/jtreg/compiler/c2/irTests/AddLNodeIdealizationTests.java line 73:
> 
>> 71:         Asserts.assertEQ((a - b) + (b + c), test6(a, b, c));
>> 72:         Asserts.assertEQ((a - b) + (c + b), test7(a, b, c));
>> 73:         Asserts.assertEQ((a - b) + (c - a), test8(a, b, c));
> 
> `AddI` additionally has 
> 
> Asserts.assertEQ((a - b) + (b - c), test8(a, b, c));
> 
> Was this left out on purpose?

This is another transformation that is missing for "Long". Tracked by this RFE: https://bugs.openjdk.java.net/browse/JDK-8272735

> test/hotspot/jtreg/compiler/c2/irTests/SubLNodeIdealizationTests.java line 79:
> 
>> 77:         Asserts.assertEQ(a*b - b*c        , test16(a, b, c));
>> 78:         Asserts.assertEQ(a*c - b*c        , test17(a, b, c));
>> 79:         Asserts.assertEQ(a*b - c*a        , test18(a, b, c));
> 
> Some cases are missing compared to `SubI`. Did you omit them on purpose?

Yes, this transformation is actually missing for Long. I had created this RFE to fix that: https://bugs.openjdk.java.net/browse/JDK-8272735

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

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

From kvn at openjdk.java.net  Mon Feb 14 20:56:25 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 14 Feb 2022 20:56:25 GMT
Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare
 intrinsic in SVE
In-Reply-To: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
References: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
Message-ID: <fwtVKRwyzSv8qiWddWa8hIREjEs7SGKdueGbZxRkcXY=.8be2002d-e672-4a53-91c2-cdaa582fe0f6@github.com>

On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures.
> 
> Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending.
> 
> Thanks,
> Tobias

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/116

From kvn at openjdk.java.net  Mon Feb 14 21:17:10 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 14 Feb 2022 21:17:10 GMT
Subject: RFR: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp
In-Reply-To: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
References: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
Message-ID: <GKeKJ9LFKFG9FI6ZrUJKPmaNO6P1a0NYndYtW5uYO8I=.b540ece9-1e65-45fa-9caa-b6a0f38b03a6@github.com>

On Mon, 14 Feb 2022 19:02:10 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> The PrintIdealPhaseTest fails with Xcomp - the test method is inlined, and not compiled. Adding a DontInline command to fix this. 
> 
> Also excluding this test from Xcomp - the flag it's propagated to the sub tests which spends a lot of time wasting energy compiling nothing of interest.
> 
> Please review,
> Nils Eliasson

Marked as reviewed by kvn (Reviewer).

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

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

From duke at openjdk.java.net  Mon Feb 14 22:02:15 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Mon, 14 Feb 2022 22:02:15 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v2]
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <aVRFllALTBXjDqBCO1P6j_E2Rw29F5qlo47S9_teiOs=.bc603e9b-98bd-43b4-ad3f-6debd040d795@github.com>

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:

  Fixing typos & compilation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7434/files
  - new: https://git.openjdk.java.net/jdk/pull/7434/files/88bfba36..8c66e0e5

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

  Stats: 45 lines in 4 files changed: 15 ins; 0 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7434/head:pull/7434

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

From neliasso at openjdk.java.net  Mon Feb 14 22:38:09 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 14 Feb 2022 22:38:09 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
 <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
Message-ID: <AvdG9ERhZ7Ql2V546nPs2P8LTOuirew5CVd4Z5slxA8=.01b5f16e-bbea-4a92-a80f-87c1ff543476@github.com>

On Mon, 14 Feb 2022 12:23:57 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception of `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)
>
> TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
>  - Fix TieredStopAtLevel requirements for certain tests

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From dlong at openjdk.java.net  Mon Feb 14 22:42:15 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Mon, 14 Feb 2022 22:42:15 GMT
Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare
 intrinsic in SVE
In-Reply-To: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
References: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
Message-ID: <NggiBvRTves2neD5niJ81xCMwOw8vmKkQVyryn-277Y=.60a36612-9f95-4cab-abc5-d39c73017178@github.com>

On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures.
> 
> Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending.
> 
> Thanks,
> Tobias

Marked as reviewed by dlong (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/116

From sviswanathan at openjdk.java.net  Tue Feb 15 02:14:14 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 15 Feb 2022 02:14:14 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v3]
In-Reply-To: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>
Message-ID: <jKQnKU6fY0r2kOLCfj3lTUnmi9tpAR0JvZeDL3_zoB0=.3233faa1-5575-44bf-97d4-0d361c9b5837@github.com>

On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing ForceInline

Marked as reviewed by sviswanathan (Reviewer).

Hotspot changes look good to me.

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

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

From duke at openjdk.java.net  Tue Feb 15 02:18:12 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Tue, 15 Feb 2022 02:18:12 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
 <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
Message-ID: <3gaV0iO4xnXpzHHEcbdvU9PfSd8ORZ0tA_sbVq95ZYY=.60fc94a0-c4cb-4764-99a6-6b7c0cd0776d@github.com>

On Mon, 14 Feb 2022 12:23:57 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception of `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)
>
> TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
>  - Fix TieredStopAtLevel requirements for certain tests

Thanks! Gonna integrate shortly

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

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

From duke at openjdk.java.net  Tue Feb 15 02:18:12 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Tue, 15 Feb 2022 02:18:12 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <AvdG9ERhZ7Ql2V546nPs2P8LTOuirew5CVd4Z5slxA8=.01b5f16e-bbea-4a92-a80f-87c1ff543476@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
 <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
 <AvdG9ERhZ7Ql2V546nPs2P8LTOuirew5CVd4Z5slxA8=.01b5f16e-bbea-4a92-a80f-87c1ff543476@github.com>
Message-ID: <MbIbsolNfXj1B5-eVUElbEHKP4xmnVb3-TUhej-lRxE=.bdd6437e-e82c-4825-baa1-c87b9f8f180a@github.com>

On Mon, 14 Feb 2022 22:34:49 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
>>  - Fix TieredStopAtLevel requirements for certain tests
>
> Looks good!

@neliasso I almost forgot, does `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` need any updating for it's TieredStopAtLevel requirements or is it good to remain as is?

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

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

From duke at openjdk.java.net  Tue Feb 15 05:41:13 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 15 Feb 2022 05:41:13 GMT
Subject: RFR: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts [v3]
In-Reply-To: <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
 <9geCUxBmjKm5HoVrV2HTlD5DSFkJX-GdvlZbPPnzIcM=.ed8260f3-eed5-4f18-9e37-c12a304e9b4e@github.com>
Message-ID: <NZaiplpKulLJ_F6BvvUxKzo6KNpu4ZHEutX4oM_1Gy0=.962e7c28-fec1-4988-babe-78c3afd7705b@github.com>

On Sun, 13 Feb 2022 05:18:34 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing ForceInline

Thanks a lot for your reviews.

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

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

From fgao at openjdk.java.net  Tue Feb 15 06:54:32 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Tue, 15 Feb 2022 06:54:32 GMT
Subject: RFR: 8280511: AArch64: Combine shift and negate to a single
 instruction
Message-ID: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>

Hi,

In AArch64,

asr     x10, x1, #31
neg     x0, x10

can be optimized to:
`neg    x0, x1, asr #31`

To implement the instruction combining, we add matching rules in the backend.

Thanks.

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

Commit messages:
 - 8280511: AArch64: Combine shift and negate to a single instruction

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

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

From thartmann at openjdk.java.net  Tue Feb 15 07:10:22 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Feb 2022 07:10:22 GMT
Subject: [jdk18] Integrated: 8281713: [BACKOUT] AArch64: Implement
 string_compare intrinsic in SVE
In-Reply-To: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
References: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
Message-ID: <1D6SYN3fdj71U0GtxJE-_cLjtGOksVPyILjctK05mjw=.c4c8ec5f-728a-4f72-9095-40ed3f89dda2@github.com>

On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures.
> 
> Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 2be2a298
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/2be2a298f13c3a38d9518ccfea11dfd8a736d56c
Stats:     423 lines in 9 files changed: 0 ins; 412 del; 11 mod

8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE

Reviewed-by: kvn, dlong

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

PR: https://git.openjdk.java.net/jdk18/pull/116

From thartmann at openjdk.java.net  Tue Feb 15 07:10:21 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Feb 2022 07:10:21 GMT
Subject: [jdk18] RFR: 8281713: [BACKOUT] AArch64: Implement string_compare
 intrinsic in SVE
In-Reply-To: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
References: <BNTGEkOhv2lW2yQXoeBrmoXAGwKElL4_UjwEnBrkthw=.e4068026-58af-4dc3-a17d-a70c3cd6435d@github.com>
Message-ID: <lzcfkrcU5xguBZ-IqkAF4s6sT0Qwe7060x2Nr5kALSs=.be2a6e3e-d92a-4097-b174-8ce8b2bd1560@github.com>

On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We observed several failures on macosx aarch64 after integration of [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could reliably reproduce [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18 b25-1665 (the first build with [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) containing no other changes) but **not** with JDK 18 b25-1664 (the build just before integration). Also, I could reliably reproduce the issue with mainline but **not** with the string compare intrinsic disabled. I think this is enough evidence to prove that [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448) is the root cause of the failures.
> 
> Given that we don't fully understand which part of this fix is causing the issue and how (it might be a side effect that triggers a bug in the build toolchain or adlc), I propose to backout the change. The backout applies cleanly, approval is pending.
> 
> Thanks,
> Tobias

Vladimir, Dean, thanks for the reviews.

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

PR: https://git.openjdk.java.net/jdk18/pull/116

From duke at openjdk.java.net  Tue Feb 15 07:29:47 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 15 Feb 2022 07:29:47 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v3]
In-Reply-To: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
Message-ID: <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>

> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
> 
> I improved the code by having two functions instead:
> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
> 
> This makes implicit assumptions explicit and also validates them in the future.
> 
> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
> 
> Ran tests to verify that the assert never triggers.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  Require non-Null in some more cases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7462/files
  - new: https://git.openjdk.java.net/jdk/pull/7462/files/d2efb501..3beb58ce

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

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

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

From thartmann at openjdk.java.net  Tue Feb 15 07:41:09 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Feb 2022 07:41:09 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <1w5KxUL_ofPv7CWaH9Q_kStOhQ1pq5d0igJGNZYu0k4=.4ed4f8bb-5cb6-4645-ae23-1918f52ca3e4@github.com>

On Thu, 10 Feb 2022 16:41:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

Nice improvement!

src/hotspot/share/opto/escape.cpp line 230:

> 228:       ptn->dump();
> 229:     }
> 230:     tty->print_cr("+++++ Calculating escapse states and scalar replaceability");

Suggestion:

    tty->print_cr("+++++ Calculating escape states and scalar replaceability");

src/hotspot/share/opto/escape.hpp line 434:

> 432:   // Set the escape state of an object and its fields.
> 433:   void set_escape_state(PointsToNode* ptn, PointsToNode::EscapeState esc
> 434:                         DEBUG_ONLY(COMMA const char* reason="reason unknown")) {

Wouldn't it be better to not have a default argument for `reason` to enforce a unique message (even if it's `"reason unknown (42)"`) being set by the caller?

Same for `set_fields_escape_state` and `set_not_scalar_replaceable`.

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

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

From neliasso at openjdk.java.net  Tue Feb 15 08:24:10 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 08:24:10 GMT
Subject: RFR: 8281722: Removal of PrintIdealLevel
In-Reply-To: <ghi3KJc1pGxtVeZCk5Flsa1oMc8UjIfMDVxKiGibFeE=.5d4817eb-eed3-46fb-8a74-e7d1b096c68f@github.com>
References: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
 <ghi3KJc1pGxtVeZCk5Flsa1oMc8UjIfMDVxKiGibFeE=.5d4817eb-eed3-46fb-8a74-e7d1b096c68f@github.com>
Message-ID: <-f8GnbiE5bvWY8Gow5s6zLqoTjwHHL2hHHK07seXNN8=.4ba8597f-9a71-4ba5-977b-4bb95b84ff1f@github.com>

On Mon, 14 Feb 2022 15:58:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The PrintIdealLevel flag was recently introduced to support testing of different phase in the IR-test framework. In practice the fit was bad and lot of excess data was printed. The PrintIdealPhase, that gives exact control of ideal printing, was added as a substitution.
>> 
>> This patch removes the PrintIdealLevel flag since it's no longer needed.
>> 
>> Best regards,
>> Nils Eliasson
>
> Looks good to me.

@TobiHartmann @chhagedorn Thanks for the review!

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

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

From neliasso at openjdk.java.net  Tue Feb 15 08:24:10 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 08:24:10 GMT
Subject: Integrated: 8281722: Removal of PrintIdealLevel
In-Reply-To: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
References: <m3foNekiQ-4h4EfWPJRsPfl7dDFMqiv9os53yHiKf3k=.3a094df9-6bdf-4d57-ba94-7e3dcf2c0724@github.com>
Message-ID: <lO6xXT9oTBZK6NVPZj8gM9Ni4AWRlku3-bLB1lgwG8c=.b7bfc6d9-d7e4-42ec-b316-91dd3c7b1455@github.com>

On Mon, 14 Feb 2022 09:14:53 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> The PrintIdealLevel flag was recently introduced to support testing of different phase in the IR-test framework. In practice the fit was bad and lot of excess data was printed. The PrintIdealPhase, that gives exact control of ideal printing, was added as a substitution.
> 
> This patch removes the PrintIdealLevel flag since it's no longer needed.
> 
> Best regards,
> Nils Eliasson

This pull request has now been integrated.

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

8281722: Removal of PrintIdealLevel

Reviewed-by: chagedorn, thartmann

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

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

From chagedorn at openjdk.java.net  Tue Feb 15 08:30:14 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 15 Feb 2022 08:30:14 GMT
Subject: RFR: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp
In-Reply-To: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
References: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
Message-ID: <AXbNdN-sB-JJbJXQSJQ16v6BeNy0N_omzYjE2Aww3h4=.0049d49e-eff9-4662-b75b-02ec2dee0e0b@github.com>

On Mon, 14 Feb 2022 19:02:10 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> The PrintIdealPhaseTest fails with Xcomp - the test method is inlined, and not compiled. Adding a DontInline command to fix this. 
> 
> Also excluding this test from Xcomp - the flag it's propagated to the sub tests which spends a lot of time wasting energy compiling nothing of interest.
> 
> Please review,
> Nils Eliasson

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Feb 15 08:42:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 15 Feb 2022 08:42:10 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v2]
In-Reply-To: <P9_dov7nIOw_jTHibewXYfywOp2fngbKyc7d4TAfbk4=.57e2d7ff-9d07-4290-a1ee-645726faa298@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <P9_dov7nIOw_jTHibewXYfywOp2fngbKyc7d4TAfbk4=.57e2d7ff-9d07-4290-a1ee-645726faa298@github.com>
Message-ID: <hXxVCInQsY4rm14KinNSVcIvvF8LO5ZJvzZvK1iEyfs=.ef8fcfae-2d8f-477d-aae7-305a01998f22@github.com>

On Mon, 14 Feb 2022 07:53:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing typos & compilation
>
> test/hotspot/jtreg/compiler/c2/irTests/DivINodeIdealizationTests.java line 149:
> 
>> 147:                  })
>> 148:     // Checks (x & -(2^c0)) / 2^c1 => (x >> c1) & (2^c0 >> c1) => (x >> c1) & c3 where 2^c0 > |2^c1| and c3 = 2^c0 >> c1
>> 149:     // Having a large enough and in the dividend removes the need to account for rounding when converting to shifts and multiplies as in divByPow2()
> 
> Maybe you capitalize `and` -> `AND`, same further down. I first read it as a normal word "and" which was confusing :-)

I've actually meant the comments themselves but it's just a minor thing.

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

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

From chagedorn at openjdk.java.net  Tue Feb 15 08:42:09 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 15 Feb 2022 08:42:09 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v2]
In-Reply-To: <EVkIICRW2AKMmf35vhkAST40Oko2KsNRdM-InXyBG8w=.928e94fe-520a-4bc5-b0b2-0aab4fbc972c@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <P9_dov7nIOw_jTHibewXYfywOp2fngbKyc7d4TAfbk4=.57e2d7ff-9d07-4290-a1ee-645726faa298@github.com>
 <EVkIICRW2AKMmf35vhkAST40Oko2KsNRdM-InXyBG8w=.928e94fe-520a-4bc5-b0b2-0aab4fbc972c@github.com>
Message-ID: <dEhn8HxZITsvfC2T7UxjYAMebRtT45ljl8FloBbjtoM=.ef81c318-3d66-4a5c-ba85-4124524d2901@github.com>

On Mon, 14 Feb 2022 20:43:12 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/AddLNodeIdealizationTests.java line 73:
>> 
>>> 71:         Asserts.assertEQ((a - b) + (b + c), test6(a, b, c));
>>> 72:         Asserts.assertEQ((a - b) + (c + b), test7(a, b, c));
>>> 73:         Asserts.assertEQ((a - b) + (c - a), test8(a, b, c));
>> 
>> `AddI` additionally has 
>> 
>> Asserts.assertEQ((a - b) + (b - c), test8(a, b, c));
>> 
>> Was this left out on purpose?
>
> This is another transformation that is missing for "Long". Tracked by this RFE: https://bugs.openjdk.java.net/browse/JDK-8272735

Great! Thanks for the explanation.

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

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

From chagedorn at openjdk.java.net  Tue Feb 15 08:42:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 15 Feb 2022 08:42:10 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v2]
In-Reply-To: <aVRFllALTBXjDqBCO1P6j_E2Rw29F5qlo47S9_teiOs=.bc603e9b-98bd-43b4-ad3f-6debd040d795@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <aVRFllALTBXjDqBCO1P6j_E2Rw29F5qlo47S9_teiOs=.bc603e9b-98bd-43b4-ad3f-6debd040d795@github.com>
Message-ID: <tYNfDW1QW-ihysGkQedlJnAdmrH-zSO7fhkwBUlQvvs=.683781fe-7600-4311-be82-750dda039cfa@github.com>

On Mon, 14 Feb 2022 22:02:15 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

>> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
>> 
>> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
>> - Add more default IR regex's to IR-based test framework.
>
> Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing typos & compilation

test/hotspot/jtreg/compiler/c2/irTests/loopOpts/LoopIdealizationTests.java line 87:

> 85:     public void oneIterForLoop2() {
> 86:         for (int i = 0; i < 500; i++) {
> 87: 			this.blackhole();

Should be whitespaces instead of tabs.

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

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

From shade at openjdk.java.net  Tue Feb 15 09:04:25 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 09:04:25 GMT
Subject: RFR: 8281812: x86: Use short jumps in TemplateTable::condy_helper
Message-ID: <3MiEBHNxoNrUP6is6sp2lphlGeih6T6LLpntln-RMNU=.cc9dde10-40c1-495a-868a-1f01ac6dca03@github.com>

Similar to [JDK-8281744](https://bugs.openjdk.java.net/browse/JDK-8281744), this change improves TemplateTable::condy_helper, for the same reason: there are only a few pushes between the jumps, and we can tell MacroAssembler those can be short. There is no significant code that uses condy yet (I think), so the performance improvement for condy is only theoretical. This makes interpreter code a bit more compact, though.

Additional testing:
 - [x] Linux x86_64 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`
 - [x] Linux x86_32 `fastdebug`, `java/lang/invoke/condy`, `runtime/condy`

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

Commit messages:
 - Fix

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

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

From jiefu at openjdk.java.net  Tue Feb 15 09:16:15 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 15 Feb 2022 09:16:15 GMT
Subject: RFR: 8280799: =?UTF-8?B?0KEyOg==?= assert(false) failed: cyclic
 dependency prevents range check elimination [v2]
In-Reply-To: <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
References: <Rep9M3aEDDodap-GUI8EzGGjgIN8H1HEOPCFat9ZxHE=.a2cd0ec6-3f9d-4e51-a516-3ea4dc6afd4a@github.com>
 <7bCWIJSd7xqxzbvOEdqGt0IU7FuUHxErnKth3_vv9ec=.fea52c84-d619-41f8-8fae-5b5e3a48055b@github.com>
Message-ID: <jgGDr8uPSmLJ3AAJNseIUUf81r5yWvBLyjuq4wdDAzI=.30873553-cd8a-479f-aabd-dc45e8e2074e@github.com>

On Wed, 9 Feb 2022 12:55:39 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The loop exit condition of the test method:
>> 
>> if (i == stop) {
>>     break;
>> }
>> 
>> requires insertion of a loop limit predicate when the loop is turned
>> into a counted loop. stop is a LoadI. Next:
>> 
>> array[stop - i + j] = 0;
>> 
>> is transformed to:
>> 
>> array[stop - i] = 0;
>> 
>> and the range check for that array access becomes candidate for
>> predication in a subsequent loop opts pass. stop has control just
>> above the loop limit check when that happens (because it is assigned
>> control as late as possible). But the loop predicate for the bound
>> check needs to be above the loop limit check and that causes the
>> assert failure.
>> 
>> There's already logic in PhaseIdealLoop::build_loop_late_post_work()
>> to assign control to nodes above predicates so this sort of issues
>> doesn't occur. But it only applies to node initially on the entry
>> projection right above the loop head. The fix I propose is to remove
>> that restriction.
>> 
>> That logic was added by JDK-8203197 and looking back at this change I
>> noticed I replaced some existing logic with the current logic but,
>> while the 2 overlap, the current logic is not guaranteed to always
>> cover some cases handled by the old logic. So I resurrected that old
>> logic here.
>> 
>> Finally, when running tests, I hit failures because Opaque nodes for
>> skeleton predicates can now end up above a predicate that is split
>> thru phi. That causes the Opaque nodes to be split up and breaks
>> pattern matching. I'm actually not sure this issue is specific to the
>> change here so I think it's best to treat it as a general issue and
>> fix it by cloning the chain of nodes that lead to the Opaque node
>> down.
>
> 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 three additional commits since the last revision:
> 
>  - fix
>  - Merge branch 'master' into JDK-8280799
>  - fix & test

Regression: https://bugs.openjdk.java.net/browse/JDK-8281811
Please have a look. @rwestrel

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

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

From thartmann at openjdk.java.net  Tue Feb 15 09:40:09 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Feb 2022 09:40:09 GMT
Subject: RFR: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp
In-Reply-To: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
References: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
Message-ID: <x7MwAQ_1iSE8LTdNGBUqDI2HIQhIJs9OPq0Hguw-w5s=.bdbe1b59-504d-4e07-b3b5-1baafe8a8e3d@github.com>

On Mon, 14 Feb 2022 19:02:10 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> The PrintIdealPhaseTest fails with Xcomp - the test method is inlined, and not compiled. Adding a DontInline command to fix this. 
> 
> Also excluding this test from Xcomp - the flag it's propagated to the sub tests which spends a lot of time wasting energy compiling nothing of interest.
> 
> Please review,
> Nils Eliasson

Marked as reviewed by thartmann (Reviewer).

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

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

From neliasso at openjdk.java.net  Tue Feb 15 09:53:08 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 09:53:08 GMT
Subject: RFR: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp
In-Reply-To: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
References: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
Message-ID: <UNsVsbnPbZWbzF7sUrYFPBHjU5qJuKGeH8ae1VOmcM8=.a632e556-69dc-4ac3-bef7-571a00f87461@github.com>

On Mon, 14 Feb 2022 19:02:10 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> The PrintIdealPhaseTest fails with Xcomp - the test method is inlined, and not compiled. Adding a DontInline command to fix this. 
> 
> Also excluding this test from Xcomp - the flag it's propagated to the sub tests which spends a lot of time wasting energy compiling nothing of interest.
> 
> Please review,
> Nils Eliasson

Thanks for the reviews!

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

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

From neliasso at openjdk.java.net  Tue Feb 15 09:53:09 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 09:53:09 GMT
Subject: Integrated: 8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp
In-Reply-To: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
References: <Ao6_ztABkSM56Wx-rjwZjXQvd72vs9hqfnvq_8wsHgk=.8109aa42-0f92-4847-b5c2-bb4d25001bbc@github.com>
Message-ID: <BSQyFoXOdZ2kyRdzeDh6kh1rLJHLugzpJsVvMAMe_go=.dcfc4ef9-3427-4224-9d65-93cf17e819d2@github.com>

On Mon, 14 Feb 2022 19:02:10 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> The PrintIdealPhaseTest fails with Xcomp - the test method is inlined, and not compiled. Adding a DontInline command to fix this. 
> 
> Also excluding this test from Xcomp - the flag it's propagated to the sub tests which spends a lot of time wasting energy compiling nothing of interest.
> 
> Please review,
> Nils Eliasson

This pull request has now been integrated.

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

8281741: [testbug] PrintIdealPhaseTest fails with -Xcomp

Reviewed-by: kvn, chagedorn, thartmann

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

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

From jvernee at openjdk.java.net  Tue Feb 15 12:11:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 12:11:57 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v2]
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <rW-U5IcEpcSU5-Axj8kGSDNuKJ6xbjrKNz7Q0x0vRBU=.c749e40c-3f88-4d91-bd2a-d904677f120d@github.com>

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Typo
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7428/files
  - new: https://git.openjdk.java.net/jdk/pull/7428/files/4eb650d9..d903aeb7

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

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

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

From jvernee at openjdk.java.net  Tue Feb 15 12:16:29 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 12:16:29 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v3]
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <NIdoywHnnlaU3Qd7UjwhDjNaA6OCpKG7kkP4Z3oo4RA=.14af5ff5-3981-4c70-b20d-c7c031a704fd@github.com>

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a nodes escape is update, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4 (in progress).
> 
> Thanks,
> Jorn

Jorn Vernee 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 TraceEA
 - Typo
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Add missing newlines
 - Pass outputStream to dump_header
 - Remove redundant resource mark
 - Rewrite with reason string
 - format string warning
 - Add TraceEscapeAnalysis flag

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

Changes: https://git.openjdk.java.net/jdk/pull/7428/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7428&range=02
  Stats: 129 lines in 6 files changed: 86 ins; 0 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7428/head:pull/7428

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

From jvernee at openjdk.java.net  Tue Feb 15 12:19:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 12:19:11 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v3]
In-Reply-To: <1w5KxUL_ofPv7CWaH9Q_kStOhQ1pq5d0igJGNZYu0k4=.4ed4f8bb-5cb6-4645-ae23-1918f52ca3e4@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <1w5KxUL_ofPv7CWaH9Q_kStOhQ1pq5d0igJGNZYu0k4=.4ed4f8bb-5cb6-4645-ae23-1918f52ca3e4@github.com>
Message-ID: <epYLpY-8u2U0WTQ2451lcLeXi6nwIqkhRYuj3lURIDA=.ec2e7abe-1fc9-4fee-8544-60c089a25ee5@github.com>

On Tue, 15 Feb 2022 07:37:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jorn Vernee 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 TraceEA
>>  - Typo
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Add missing newlines
>>  - Pass outputStream to dump_header
>>  - Remove redundant resource mark
>>  - Rewrite with reason string
>>  - format string warning
>>  - Add TraceEscapeAnalysis flag
>
> src/hotspot/share/opto/escape.hpp line 434:
> 
>> 432:   // Set the escape state of an object and its fields.
>> 433:   void set_escape_state(PointsToNode* ptn, PointsToNode::EscapeState esc
>> 434:                         DEBUG_ONLY(COMMA const char* reason="reason unknown")) {
> 
> Wouldn't it be better to not have a default argument for `reason` to enforce a unique message (even if it's `"reason unknown (42)"`) being set by the caller?
> 
> Same for `set_fields_escape_state` and `set_not_scalar_replaceable`.

Yeah, that seems better. (didn't want to push that onto others initially). I'll drop the default reason string

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

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

From jvernee at openjdk.java.net  Tue Feb 15 12:50:54 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 12:50:54 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v3]
In-Reply-To: <NIdoywHnnlaU3Qd7UjwhDjNaA6OCpKG7kkP4Z3oo4RA=.14af5ff5-3981-4c70-b20d-c7c031a704fd@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <NIdoywHnnlaU3Qd7UjwhDjNaA6OCpKG7kkP4Z3oo4RA=.14af5ff5-3981-4c70-b20d-c7c031a704fd@github.com>
Message-ID: <6G25QMTI_-LAds9c5p_Jv7HB0oYG_NKJmjSMNdThRp0=.19187d33-cd0a-4b17-89ea-f6afc097232a@github.com>

On Tue, 15 Feb 2022 12:16:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee 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 TraceEA
>  - Typo
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Add missing newlines
>  - Pass outputStream to dump_header
>  - Remove redundant resource mark
>  - Rewrite with reason string
>  - format string warning
>  - Add TraceEscapeAnalysis flag

I've integrated review comments in the latest version. Please have another look.

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

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

From jvernee at openjdk.java.net  Tue Feb 15 12:50:50 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 12:50:50 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7428/files
  - new: https://git.openjdk.java.net/jdk/pull/7428/files/0eb45e67..df1bc990

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

  Stats: 44 lines in 4 files changed: 0 ins; 6 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7428/head:pull/7428

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

From jbhateja at openjdk.java.net  Tue Feb 15 14:36:06 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 15 Feb 2022 14:36:06 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v3]
In-Reply-To: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
Message-ID: <-kIOnLUNf7JhtmqCjTPVwr941e67kVbiCorya3x9CnM=.2580f30b-adff-48e6-bee2-73944a7224e3@github.com>

On Tue, 8 Feb 2022 09:01:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resoultion.
>
> Hi Jatin, nice work!
> 
> One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.
> 
> Best regards,
> Nils

Hi @neliasso , your comments have been addressed.

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

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

From jiefu at openjdk.java.net  Tue Feb 15 14:59:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 15 Feb 2022 14:59:30 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
Message-ID: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>

Hi all,

runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.

This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.

 824   address generate_fp_mask(const char *stub_name, int64_t mask) {
 825     __ align(CodeEntryAlignment);
 826     StubCodeMark mark(this, "StubRoutines", stub_name);
 827     address start = __ pc();
 828
 829     __ emit_data64( mask, relocInfo::none );
 830     __ emit_data64( mask, relocInfo::none );
 831
 832     return start;
 833   }


Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.

1184 void MacroAssembler::align(int modulus) {
1185   // 8273459: Ensure alignment is possible with current segment alignment
1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
1187   align(modulus, offset());
1188 }
1189
1190 void MacroAssembler::align(int modulus, int target) {
1191   if (target % modulus != 0) {
1192     nop(modulus - (target % modulus));
1193   }
1194 }


The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.

This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467

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

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

From neliasso at openjdk.java.net  Tue Feb 15 15:09:09 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 15:09:09 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <AvdG9ERhZ7Ql2V546nPs2P8LTOuirew5CVd4Z5slxA8=.01b5f16e-bbea-4a92-a80f-87c1ff543476@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
 <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
 <AvdG9ERhZ7Ql2V546nPs2P8LTOuirew5CVd4Z5slxA8=.01b5f16e-bbea-4a92-a80f-87c1ff543476@github.com>
Message-ID: <8ytR9Ai5o1S7Dyqat97vO2GF5FFLxSmMOcrFUC-cDYU=.df32bf72-5513-44dc-b60f-b09dcbf75ebb@github.com>

On Mon, 14 Feb 2022 22:34:49 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
>>  - Fix TieredStopAtLevel requirements for certain tests
>
> Looks good!

> @neliasso I almost forgot, does `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` need any updating for it's TieredStopAtLevel requirements or is it good to remain as is?

It should be good as it is. It already requires that TieredStopAtLevel is not set. When used, Jvmci is level 4, so there is no reason to run with that flag.

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

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

From ihse at openjdk.java.net  Tue Feb 15 15:18:35 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:18:35 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v2]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <E1FBhnWLLdl1EhzQaqkB4PimaCpzBgw3FXp4fTc1FLc=.2aef9632-7a90-4f6f-b94f-0fbccd2edb9f@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

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 two commits:

 - Merge branch 'master' into hsdis-backend-llvm
 - Create hsdis backend using LLVM

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

Changes: https://git.openjdk.java.net/jdk/pull/5920/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5920&range=01
  Stats: 406 lines in 6 files changed: 398 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5920/head:pull/5920

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

From ihse at openjdk.java.net  Tue Feb 15 15:23:58 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:23:58 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v3]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <8Dp9ejGHYpmoUjoR2-nw2Ewxaugs4icy65v62S7yhMM=.295c27a9-b3d2-4879-9f78-a9b62d422f02@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Find llvm-config on mac-aarch64 homebrew as well

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/c16dcb21..9f2ab6d9

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

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

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

From ihse at openjdk.java.net  Tue Feb 15 15:34:52 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:34:52 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v4]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <m6Ej95nyzpN2hObs_tq6mwwstAi-xTqZxB2IV43ZdQw=.69f12fab-83b1-4628-b281-2c8a9a0629a8@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Handle unknown instructions from LLVM. Solution suggested by ngasson.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/9f2ab6d9..7d866725

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

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

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

From ihse at openjdk.java.net  Tue Feb 15 15:48:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 15:48:43 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v5]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <E7Al6P0s8iYPkuLPR-2Vs30gvSC7wwddLfbQU3yzKyI=.44e5e9e7-db07-458e-97be-35febe8c0df2@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix install-hsdis warning

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/7d866725..a4d9896e

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

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

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

From vladimir.kozlov at oracle.com  Tue Feb 15 16:14:49 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 15 Feb 2022 08:14:49 -0800
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <DM6PR21MB1484F4125F3142FEF3DC2C1D9A339@DM6PR21MB1484.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <DM6PR21MB1484F4125F3142FEF3DC2C1D9A339@DM6PR21MB1484.namprd21.prod.outlook.com>
Message-ID: <c2d3ab9f-6282-32f4-ae1b-7e19164fdda2@oracle.com>

On 2/14/22 11:32 AM, Cesar Soares Lucas wrote:
> Here is my understanding from the discussion so far, please correct me if I'm
> wrong: Improving split_unique_types to make it able to handle "clusters" of
> allocations will not only make it easier to implement the "split through phi"
> transformation but also make it applicable to more complex merge situations.
> Did I get it right?

Yes. Please, see the last response from Vladimir I.

Thanks,
Vladimir K

> 
> 
> Regards,
> Cesar
> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 11, 2022 2:22 PM
> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> 
> 
>>>> For this simple case we can teach C2's IGVN to split fields loads
>>>> through Phi so that phi(p0, p1) is not used and allocations as well.
>>>> We can do that because we know that allocations and phi do not escape.
>>>
>>> Seems like split_unique_types() pass is a prerequisite to make such
>>> transformations predictable on a larger scale. It simplifies the
>>> memory graph and untangles instance-related memory operations from the
>>> rest of the graph.
>>
>> Can you elaborate on your suggestion?
>>
>> As you correctly pointed in your original post, EA and SR heavily depend
>> on _instance_id which is Allocation node's _idx value. And the solution
>> for this is either remove reference to merge phi. Or introduce new
>> "virtual allocation" which fields are populated by loads - but it is
>> again needs to split through phi.
> 
> My rough proposal is to group interfering non-escaping allocations into
> "clusters" and introduce separate memory slices for such clusters (as
> part of split_unique_types()). The clusters should not intersect,
> otherwise, the slice won't be unique anymore.
> 
> Once memory graph for unique alias is separated, it should be much
> simpler to further optimize it. If all memory operations are folded, the
> allocation can go away.
> 
> Splitting memory operations through phis should help untangle the
> allocations. So, even if one allocation can't be fully scalarized, it
> shouldn't keep other allocations from being scalarized (unless they alias).
> 
> I don't have a good understanding how new logic will interact with
> unique instance slices & _instance_id. Maybe a gradual transition from
> original graph to clustered slices to unique instance slices.
> 
> Best regards,
> Vladimir Ivanov
> 
>>>
>>> Otherwise, I believe wide memory states/merges would pose serious
>>> problems. E.g., when a load is split through a phi, you need to pick
>>> correct memory states for the new loads above the phi which quickly
>>> becomes quite a challenging task.
>>
>> Especially in loops. Actually I did tried such approach before and I
>> agree that it is hard.
>>
>> Thanks,
>> Vladimir K
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>>       p0 = Allocate(...);
>>>>       ...
>>>>       p0.x = first;
>>>>       p0.y = second;
>>>>
>>>>       if (cond) {
>>>>           p1 = Allocate(...);
>>>>           ...
>>>>           p1.x = second;
>>>>           p1.y = first;
>>>>       }
>>>>
>>>>       p = phi(p0, p1) // unused and will be removed
>>>>
>>>>
>>>>       return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>> }
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>> (BCCing hotspot-dev and moving the discussion to hotspot-compiler-dev.)
>>>>>
>>>>> Hi Cesar,
>>>>>
>>>>> Thanks for looking into enhancing EA.
>>>>>
>>>>> Overall, the proposal looks reasonable.
>>>>>
>>>>> I suggest to look more closely at split_unique_types().
>>>>> It introduces a dedicated class of alias categories for fields of
>>>>> the allocation being eliminated and clones memory graph. I don't see
>>>>> why it shouldn't work for multiple allocations.
>>>>>
>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>> multiple allocations at once. The notion of unique alias should be
>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>> allocations.
>>>>>
>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>> clusters of allocations.
>>>>>
>>>>> One thing to take care of: scalar replacement relies on
>>>>> TypeOopPtr::instance_id().
>>>>>
>>>>>     // If not InstanceTop or InstanceBot, indicates that this is
>>>>>     // a particular instance of this type which is distinct.
>>>>>     // This is the node index of the allocation node creating this
>>>>> instance.
>>>>>     int           _instance_id;
>>>>>
>>>>> It'll break when multiple allocations are in play.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>> Hi there again!
>>>>>>
>>>>>> Can you please give me feedback on the following approach to at
>>>>>> least partially
>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>
>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>> merged after a
>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>> situation.
>>>>>>
>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>       Point p = new Point(x, y);
>>>>>>       if (cond)
>>>>>>           p = new Point(y, x);
>>>>>>       // Allocations for p are merged here.
>>>>>>       return p.calc();
>>>>>> }
>>>>>>
>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>> will not
>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>       p0 = Allocate(...);
>>>>>>       ...
>>>>>>       p0.x = first;
>>>>>>       p0.y = second;
>>>>>>
>>>>>>       if (cond) {
>>>>>>           p1 = Allocate(...);
>>>>>>           ...
>>>>>>           p1.x = second;
>>>>>>           p1.y = first;
>>>>>>       }
>>>>>>
>>>>>>       p = phi(p0, p1)
>>>>>>
>>>>>>       return p.x - p.y;
>>>>>> }
>>>>>>
>>>>>> However, one of the constraints implemented here [2], specifically
>>>>>> the third
>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>
>>>>>> The approach that I'm considering for solving the problem is to
>>>>>> replace the Phi
>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields of
>>>>>> the objects
>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>> this after the
>>>>>> transformation:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>       p0 = Allocate(...);
>>>>>>       ...
>>>>>>       p0.x = first;
>>>>>>       p0.y = second;
>>>>>>
>>>>>>       if (cond) {
>>>>>>           p1 = Allocate(...);
>>>>>>           ...
>>>>>>           p1.x = second;
>>>>>>           p1.y = first;
>>>>>>       }
>>>>>>
>>>>>>       pX = phi(first, second)
>>>>>>       pY = phi(second, first)
>>>>>>
>>>>>>       return pX - pY;
>>>>>> }
>>>>>>
>>>>>> I understand that this transformation might not be applicable for
>>>>>> all cases and
>>>>>> that it's not as simple as illustrated above. Also, it seems to me
>>>>>> that much of
>>>>>> what I'd have to implement is already implemented in other steps of
>>>>>> the Scalar
>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>> implementation details I plan to use as much of the existing code
>>>>>> as possible.
>>>>>> The algorithm for the transformation would be like this:
>>>>>>
>>>>>> split_phis(phi)
>>>>>>       # If output of phi escapes, or something uses its identity, etc
>>>>>>       # then we can't remove it. The conditions here might possible
>>>>>> be the
>>>>>>       # same as the ones implemented in
>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>       if cant_remove_phi_output(phi)
>>>>>>           return ;
>>>>>>
>>>>>>       # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>> field F
>>>>>>       # member of the object resulting from `phi`.
>>>>>>       fields_used = collect_fields_used_after_phi(phi)
>>>>>>
>>>>>>       foreach field in fields_used
>>>>>>           producers = {}
>>>>>>
>>>>>>           # Create a list with the last Store for each field "field"
>>>>>> on the
>>>>>>           # scope of each of the Phi input objects.
>>>>>>           foreach o in phi.inputs
>>>>>>               # The function called below might re-use a lot of the
>>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>               producers += last_store_to_o_field(0, field)
>>>>>>           # Create a new phi node whose inputs are the Store's to
>>>>>> 'field'
>>>>>>           field_phi = create_new_phi(producers)
>>>>>>
>>>>>>           update_consumers(field, field_phi)
>>>>>>
>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>> [3] step just
>>>>>> after EA but before the constraint checks in
>>>>>> `adjust_scalar_replaceable_state`
>>>>>> [2]. If we agree that the overall Scalar Replacement implementation
>>>>>> goes through
>>>>>> the following major phases:
>>>>>>
>>>>>>       1. Identify the Escape Status of objects.
>>>>>>       2. Adjust object Escape and/or Scalar Replacement status based
>>>>>> on a set of constraints.
>>>>>>       3. Make call to Split_unique_types [4].
>>>>>>       4 Iterate over object and array allocations.
>>>>>>           4.1 Check if allocation can be eliminated.
>>>>>>           4.2 Perform scalar replacement. Replace uses of object in
>>>>>> Safepoints.
>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> The transformation that I am proposing would change the overall
>>>>>> flow to look
>>>>>> like this:
>>>>>>
>>>>>>       1. Identify the Escape Status of objects.
>>>>>>       2. ----> New: "Split phi functions" <----
>>>>>>       2. Adjust object Escape and/or Scalar Replacement status based
>>>>>> on a set of constraints.
>>>>>>       3. Make call to Split_unique_types [14].
>>>>>>       4 Iterate over object and array allocations.
>>>>>>           4.1 ----> Moved to split_phi: "Check if allocation can be
>>>>>> eliminated" <----
>>>>>>           4.2 Perform scalar replacement. Replace uses of object in
>>>>>> Safepoints.
>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> Please let me know what you think and thank you for taking the time
>>>>>> to review
>>>>>> this!
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Cesar
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>>       [1] I am not sure yet how this approach will play with the
>>>>>> case of a merge
>>>>>>           with NULL.
>>>>>>       [2]
>>>>>> https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cb8b9939a638d4382b64208d9edad0a0f*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637802149742125104*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=lP*2BGg*2Fk4LBvQ3lCxYGlseHvOel8E8W2PW3bQNwqg5JQ*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!ACWV5N9M2RV99hQ!flGO3Lw7WYjGc9E5njiYUEspjG1XnYdeTgiXRpXIbsMuMdMbvoMbWHOzTOfrZbYRaPqLSg$
>>>>>>
>>>>>>
>>>>>>       [3] Another option would be to "patch" the current
>>>>>> implementation to be able
>>>>>>           to handle the merges. I am not certain that the "patch"
>>>>>> approach would be
>>>>>>           better, however, the "pre-process" approach is certainly
>>>>>> much easier to test
>>>>>>           and more readable.
>>>>>>
>>>>>>       [4] I cannot say I understand 100% the effects of executing
>>>>>>           split_unique_types(). Would the transformation that I am
>>>>>> proposing need to
>>>>>>           be after the call to split_unique_types?

From ihse at openjdk.java.net  Tue Feb 15 16:19:32 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Feb 2022 16:19:32 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v6]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <hCnUcZ4GEnRRmKXv9Xii_H1ZYjMpnUUL7E3WFN9g5vQ=.7fd67df0-32c0-458f-ac1e-0f968baceeaf@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restructure README to prepare for section on LLVM

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/a4d9896e..47cf9a1b

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

  Stats: 58 lines in 1 file changed: 30 ins; 22 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5920/head:pull/5920

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

From kvn at openjdk.java.net  Tue Feb 15 16:22:03 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 15 Feb 2022 16:22:03 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
 <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
Message-ID: <G0CVSDZ9Bjc_nfRt4B2lDWdL2JyizzgdPNq1iP2ToCg=.c76023f0-e897-4e97-874f-72a3558394a3@github.com>

On Mon, 14 Feb 2022 12:23:57 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception of `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)
>
> TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
>  - Fix TieredStopAtLevel requirements for certain tests

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Tue Feb 15 16:33:09 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 15 Feb 2022 16:33:09 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <1Gt0BWpEFapG1PrGP08TdHo-cfINrj1bvEwBEZJIURk=.eff3dbf1-cb92-4465-9e49-b8fb0394b670@github.com>

On Tue, 15 Feb 2022 14:51:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Tue Feb 15 16:47:07 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 15 Feb 2022 16:47:07 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v3]
In-Reply-To: <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
 <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
Message-ID: <Fjji9d7sCXerpO4OQhXXQMQUcC11UUGauiN3mRvagXc=.305b7cf7-e75d-4a01-bba1-91a1f2dfaa36@github.com>

On Tue, 15 Feb 2022 07:29:47 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
>> 
>> I improved the code by having two functions instead:
>> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
>> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
>> 
>> This makes implicit assumptions explicit and also validates them in the future.
>> 
>> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
>> 
>> Ran tests to verify that the assert never triggers.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require non-Null in some more cases

Looks good.

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

Marked as reviewed by kvn (Reviewer).

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

From chagedorn at openjdk.java.net  Tue Feb 15 17:04:03 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 15 Feb 2022 17:04:03 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v3]
In-Reply-To: <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
 <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
Message-ID: <H0mm1vOkRfPuwWYuuKH3_TgoGb89H8F90N__9ZLe_jg=.c78125e8-eab1-4af0-97ae-844f2f6cc2d7@github.com>

On Tue, 15 Feb 2022 07:29:47 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
>> 
>> I improved the code by having two functions instead:
>> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
>> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
>> 
>> This makes implicit assumptions explicit and also validates them in the future.
>> 
>> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
>> 
>> Ran tests to verify that the assert never triggers.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require non-Null in some more cases

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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

From duke at openjdk.java.net  Tue Feb 15 19:01:08 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 15 Feb 2022 19:01:08 GMT
Subject: Integrated: 8278173: [vectorapi] Add x64 intrinsics for unsigned (zero
 extended) casts
In-Reply-To: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
References: <wY-To-VJCIYtJkAgG1u5ePqJeABUxs5yx9oF4fL8_Zc=.1682c95f-3d45-460b-90d4-2d3b194617af@github.com>
Message-ID: <w3klZDCKfttVgyY0RxMoYGDO_rp7PSJpIhNolFi8Egw=.5c620e28-6bd0-4dd1-a2c9-a56cb8f6aff3@github.com>

On Sat, 5 Feb 2022 15:34:08 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements the unsigned upcast intrinsics in x86, which are used in vector lane-wise reinterpreting operations.
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: 0af356bb
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0af356bb4bfee99223d4bd4f8b0001c5f362c150
Stats:     490 lines in 19 files changed: 428 ins; 24 del; 38 mod

8278173: [vectorapi] Add x64 intrinsics for unsigned (zero extended) casts

Reviewed-by: psandoz, sviswanathan

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

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

From xliu at openjdk.java.net  Tue Feb 15 21:03:07 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 15 Feb 2022 21:03:07 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

I think this is very useful feature. thanks.

src/hotspot/share/opto/escape.cpp line 882:

> 880:     PointsToNode* ptn = ptnode_adr(val->_idx);
> 881:     assert(ptn != NULL, "node should be registered");
> 882:     set_escape_state(ptn, PointsToNode::GlobalEscape NOT_PRODUCT(COMMA "stored at raw address"));

In a nutshell, this PR annotates a node why it escapes or is NSR.  I believe the code would be much cleaner if you just add a field of "reason" to `PointsToNode`.  One field is enough because scalar replacement candidates is subset of NoEscape Java nodes.  There's no overlap between escape reason and NSR reason.  extra bonus is that we can access the reason field in debugger later on.

src/hotspot/share/opto/escape.cpp line 3764:

> 3762:     ss.print("escapes as arg to:");
> 3763:     call->dump("", false, &ss);
> 3764:     return ss.as_string();

stringStream::as_string will allocate a new string on resource arena. 
I think  you should place "ResourceMark rm;" to reclaim that space. 
ps: I don't quite understand why not all code of share/opto follow this idiom. maybe it's not an issue.

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

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

From jvernee at openjdk.java.net  Tue Feb 15 21:14:13 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 21:14:13 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
Message-ID: <OeCzvNklGZQfBVfHs6VfplPCN2MNHqKQzXl9DPu_WM0=.5dc31d80-6c30-4303-a40d-63f255a886d8@github.com>

On Tue, 15 Feb 2022 20:59:22 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/share/opto/escape.cpp line 3764:
> 
>> 3762:     ss.print("escapes as arg to:");
>> 3763:     call->dump("", false, &ss);
>> 3764:     return ss.as_string();
> 
> stringStream::as_string will allocate a new string on resource arena. 
> I think  you should place "ResourceMark rm;" to reclaim that space. 
> ps: I don't quite understand why not all code of share/opto follow this idiom. maybe it's not an issue.

There is already a `ResourceMark` in [`ConnectionGraph::do_analysis`](1) that catches these strings. FWIW adding another more nested `ResourceMark` is not possible since some of the GrowableArrays might then be resized in the nested mark which is a bug [(See)](2).

[1]: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/escape.cpp#L96
[2]: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/growableArray.cpp#L64-L71

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

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

From jvernee at openjdk.java.net  Tue Feb 15 21:23:10 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 15 Feb 2022 21:23:10 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
Message-ID: <Tb1iWHUmKRd87LOvrcr79uMC8DgEpOrTgk7-2HTzqHE=.335f5a26-bc1b-4c08-aee4-305cff3490ce@github.com>

On Tue, 15 Feb 2022 20:48:33 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/share/opto/escape.cpp line 882:
> 
>> 880:     PointsToNode* ptn = ptnode_adr(val->_idx);
>> 881:     assert(ptn != NULL, "node should be registered");
>> 882:     set_escape_state(ptn, PointsToNode::GlobalEscape NOT_PRODUCT(COMMA "stored at raw address"));
> 
> In a nutshell, this PR annotates a node why it escapes or is NSR.  I believe the code would be much cleaner if you just add a field of "reason" to `PointsToNode`.  One field is enough because scalar replacement candidates is subset of NoEscape Java nodes.  There's no overlap between escape reason and NSR reason.  extra bonus is that we can access the reason field in debugger later on.

I can get the debugger argument, but I'm not sure how doing this would make the code cleaner...

Instead of printing out the reason message directly in set_(fields_)escape_state/set_not_scalar_replaceable we would set it in `PointsToNode.reason`, and then afterwards walk the graph to print out all messages?

One potential problem with that approach is that if a node is first updated to ArgEscape, and then later to GlobalEscape, the first state transition would not be visible. (i.e. the PR is not just annotating nodes, it's annotating state transitions, and there can be multiple state transitions per node)

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

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

From neliasso at openjdk.java.net  Tue Feb 15 21:53:11 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 15 Feb 2022 21:53:11 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v3]
In-Reply-To: <giQvPrCTzkj6LpFpTkrFzqFGCj5rAuAiR_rI0yWyHY0=.466d1488-4455-4dfa-9b41-bd8a495dfe13@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <giQvPrCTzkj6LpFpTkrFzqFGCj5rAuAiR_rI0yWyHY0=.466d1488-4455-4dfa-9b41-bd8a495dfe13@github.com>
Message-ID: <vrMLiAJq4z50BJQynjid5x-xyk32W6XcLnSJZVjSfb0=.ff4e002b-dd0d-4ada-a5d7-7b71ef692b51@github.com>

On Sat, 12 Feb 2022 15:14:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resoultion.

src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 4031:

> 4029:     StubRoutines::x86::_vector_iota_indices = generate_iota_indices("iota_indices");
> 4030: 
> 4031:     if (VM_Version::supports_avx2() && UsePopCountInstruction) {

Do we need it if VM_Version::supports_avx512_vpopcntdq()?

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

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

From xliu at openjdk.java.net  Wed Feb 16 01:58:08 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Feb 2022 01:58:08 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <Tb1iWHUmKRd87LOvrcr79uMC8DgEpOrTgk7-2HTzqHE=.335f5a26-bc1b-4c08-aee4-305cff3490ce@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
 <Tb1iWHUmKRd87LOvrcr79uMC8DgEpOrTgk7-2HTzqHE=.335f5a26-bc1b-4c08-aee4-305cff3490ce@github.com>
Message-ID: <ci6JmwsAjg3sy3ZsUv-kGRukBtfWcHQpTlUsQaUTHno=.1953c363-2f87-4cf7-9c6a-07d0281b1914@github.com>

On Tue, 15 Feb 2022 21:18:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/opto/escape.cpp line 882:
>> 
>>> 880:     PointsToNode* ptn = ptnode_adr(val->_idx);
>>> 881:     assert(ptn != NULL, "node should be registered");
>>> 882:     set_escape_state(ptn, PointsToNode::GlobalEscape NOT_PRODUCT(COMMA "stored at raw address"));
>> 
>> In a nutshell, this PR annotates a node why it escapes or is NSR.  I believe the code would be much cleaner if you just add a field of "reason" to `PointsToNode`.  One field is enough because scalar replacement candidates is subset of NoEscape Java nodes.  There's no overlap between escape reason and NSR reason.  extra bonus is that we can access the reason field in debugger later on.
>
> I can get the debugger argument, but I'm not sure I see how doing this would make the code cleaner...
> 
> Instead of printing out the reason message directly in set_(fields_)escape_state/set_not_scalar_replaceable we would set it in `PointsToNode.reason`, and then afterwards walk the graph to print out all messages?
> 
> One potential problem with that approach is that if a node is first updated to ArgEscape, and then later to GlobalEscape, the first state transition would not be visible. (i.e. the PR is not just annotating nodes, it's annotating state transitions, and there can be multiple state transitions per node)

C/C++ macro is very powerful. however, it may scramble code.  If we refrain abusing, I think C++ can achieve cleaner code like Java. 

> Instead of printing out the reason message directly in set_(fields_)escape_state/set_not_scalar_replaceable we would set it in PointsToNode.reason, and then afterwards walk the graph to print out all messages?

I mean we can do thing like this: 
```ptn->reason = "stored at raw address";```

and then 

void ConnectionGraph::trace_es_update_helper(PointsToNode* ptn, PointsToNode::EscapeState es, bool fields) const {
  if (_compile->directive()->TraceEscapeAnalysisOption) {
    assert(ptn != nullptr, "should not be null");
    assert(ptn->reason != nullptr, "should not be null");
    ptn->dump_header(true);
    PointsToNode::EscapeState new_es = fields ? ptn->escape_state() : es;
    PointsToNode::EscapeState new_fields_es = fields ? es : ptn->fields_escape_state();
    tty->print_cr("-> %s(%s) %s", esc_names[(int)new_es], esc_names[(int)new_fields_es], ptn->reason);
  }
}


PointsToNode::reason is just a global variable. it can prevent you from passing the argument under macro expansion. 
if inliner and scalar replacement of gcc is at work, this field can be removed. Since we only use PointsToNode::reason in debug build, it doesn't matter if gcc misses that.

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

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

From xliu at openjdk.java.net  Wed Feb 16 02:02:03 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Feb 2022 02:02:03 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <OeCzvNklGZQfBVfHs6VfplPCN2MNHqKQzXl9DPu_WM0=.5dc31d80-6c30-4303-a40d-63f255a886d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
 <OeCzvNklGZQfBVfHs6VfplPCN2MNHqKQzXl9DPu_WM0=.5dc31d80-6c30-4303-a40d-63f255a886d8@github.com>
Message-ID: <tbpaFt3viQ1cE0cjvibShGOj3H7UsaMcBwhJKuJES7Y=.919156a0-0dff-4ec5-b92b-661ad4321551@github.com>

On Tue, 15 Feb 2022 21:11:25 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/opto/escape.cpp line 3764:
>> 
>>> 3762:     ss.print("escapes as arg to:");
>>> 3763:     call->dump("", false, &ss);
>>> 3764:     return ss.as_string();
>> 
>> stringStream::as_string will allocate a new string on resource arena. 
>> I think  you should place "ResourceMark rm;" to reclaim that space. 
>> ps: I don't quite understand why not all code of share/opto follow this idiom. maybe it's not an issue.
>
> There is already a `ResourceMark` in [`ConnectionGraph::do_analysis`](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/escape.cpp#L96) that catches these strings. FWIW, I tried adding another more nested `ResourceMark`, but ran into trouble since some of the GrowableArrays might then be resized in the nested mark which is a bug [(See)](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/growableArray.cpp#L64-L71).

I miss that. you are right!

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

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

From jiefu at openjdk.java.net  Wed Feb 16 02:19:31 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 02:19:31 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on
 AVX512 machines
Message-ID: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>

Hi all, 

compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
The fix just increasing the stub size for AVX512 platforms.

Testing:
  - tier1~3 on Linux/x64 with AVX512, no regression

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines

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

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

From xgong at openjdk.java.net  Wed Feb 16 02:29:25 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 16 Feb 2022 02:29:25 GMT
Subject: RFR: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
Message-ID: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>

Currently the vector lanewise `NOT` is implemented with `"v.xor(-1)"` and `AND_NOT ` is implemented with `"v1.and(v2.xor(-1))"`. With SVE they can be respectively implemented with `"not/bic"` instructions, and we have already optimized the non-masked operations before (see [1]).

Consider the SVE also supports the `predicated` `"not/bic"`, we can apply the same optimizations for the masked `NOT/AND_NOT` by adding match rules. So this patch adds the rules for the following optimizations:

For `NOT `with int type:

  mov z16.s, #-1
  eor z18.s, p0/m, z18.s, z16.s  ==>  not z18.s, p0/m, z18.s

For `AND_NOT `with int type:

  not z16.d, p7/m, z16.d
  and z17.s, p0/m, z17.s, z16.s  ==>  bic z17.s, p0/m, z16.s

Here is the performance gain for the `"NOT/AND_NOT"` benchmarks (see [2][3] for byte type) with SVE 512-bit:

Benchmark                    Gain
LongMaxVector.NOTMasked      1.005
ShortMaxVector.NOTMasked     1.017
IntMaxVector.NOTMasked       1.022
ByteMaxVector.NOTMasked      1.023
LongMaxVector.AND_NOTMasked  1.063
IntMaxVector.AND_NOTMasked   1.047
ShortMaxVector.AND_NOTMasked 1.059
ByteMaxVector.AND_NOTMasked  1.030

[1] https://github.com/openjdk/jdk/pull/3370
[2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L1963
[3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L362

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

Commit messages:
 - 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE

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

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

From xliu at openjdk.java.net  Wed Feb 16 04:46:05 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Feb 2022 04:46:05 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <TzemfXSgKXJd1fQfF6wgg_d08te0H9zD5Y5HnHRfFM0=.7085736c-69f6-45ce-98c5-b40a3a1ba51a@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

src/hotspot/share/opto/escape.cpp line 1832:

> 1830:         // Mark all objects.
> 1831:         set_not_scalar_replaceable(jobj NOT_PRODUCT(COMMA "is merged with other object"));
> 1832:         set_not_scalar_replaceable(ptn NOT_PRODUCT(COMMA "is merged with other object"));

how about we also dump Java Object(x) here? eg. 

JavaObject(8) NoEscape(NoEscape) is NSR. is merged with other java object(4)
JavaObject(4) GlobalEscape(GlobalEscape) NSR is NSR. is merged with other java object(8)

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

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

From duke at openjdk.java.net  Wed Feb 16 07:15:20 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Wed, 16 Feb 2022 07:15:20 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data
Message-ID: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>

8005885: enhance PrintCodeCache to print more data

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

Commit messages:
 - Simplify
 - Report code cache in tiers
 - temp
 - Merge branch 'master' of https://github.com/yftsai/jdk into cclogs
 - Improve CodeCache logs

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

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

From xliu at openjdk.java.net  Wed Feb 16 07:15:22 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 16 Feb 2022 07:15:22 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <fztgDWH-BBYiSj_yakYIZrrT42HEw5t16r39z8H7-tA=.6fb49c6f-28c6-4d9a-9c62-bb1e7a5191ba@github.com>

On Tue, 8 Feb 2022 19:17:32 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8005885: enhance PrintCodeCache to print more data

src/hotspot/share/code/codeCache.cpp line 1445:

> 1443:     FOR_ALL_BLOBS(cb, *heap) {
> 1444:       if (cb->is_nmethod()) {
> 1445:         const int level = cb->as_nmethod_or_null()->comp_level();

is cb->as_nmethod() better?

src/hotspot/share/code/codeCache.cpp line 1470:

> 1468:   for (int i = CompLevel_simple; i <= CompLevel_full_optimization; i++) {
> 1469:     tty->print_cr("Tier %d:", i);
> 1470:     if (!live[i - 1].is_empty()) {

your policy is to skip empty entries. I suggest you move is_empty() logic to CodeBlob_sizes::print(). 
one side, it would print out "#0 live: empty"  instead of skipping it. that's informative. 
secondly, it should simplify your code here.

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

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

From thartmann at openjdk.java.net  Wed Feb 16 07:53:07 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Feb 2022 07:53:07 GMT
Subject: RFR: 8236136: tests which use CompilationMode shouldn't be run w/
 TieredStopAtLevel [v2]
In-Reply-To: <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
 <hfnCNaTUD6e7BI91P47DjLz_unZVZRAREclI-WawWvk=.c543c1b3-efcf-4366-92fc-f3aca40b51b6@github.com>
Message-ID: <ote6i3xEMrscu7JcQGT2q_wBgPWq0rezxlrm96ObQhA=.db59350f-45fa-41fd-ae3e-7afe949ad86f@github.com>

On Mon, 14 Feb 2022 12:23:57 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

>> Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception of `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)
>
> TheShermanTanker 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 remote-tracking branch 'upstream/master' into fixtests
>  - Fix TieredStopAtLevel requirements for certain tests

Looks good to me too.

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

Marked as reviewed by thartmann (Reviewer).

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

From duke at openjdk.java.net  Wed Feb 16 07:53:07 2022
From: duke at openjdk.java.net (TheShermanTanker)
Date: Wed, 16 Feb 2022 07:53:07 GMT
Subject: Integrated: 8236136: tests which use CompilationMode shouldn't be run
 w/ TieredStopAtLevel
In-Reply-To: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
References: <-MIAujPxksnOjVG0oR0GB9cNG_n5e07ifRuwuoVH5NE=.e401f889-7af1-477a-85da-74ecf3712740@github.com>
Message-ID: <YTwukLx2e27Y6Z6kg7IGAVmv9VGaivXw-zOm2_9ta0E=.40c95b79-e05a-44e3-94af-4accea6d849b@github.com>

On Sat, 12 Feb 2022 07:07:57 GMT, TheShermanTanker <duke at openjdk.java.net> wrote:

> Prevents the tests from JDK-8236136 from running when the required `TieredStopAtLevel` is not met, with the exception of `compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest` as it seems to already have the requirement set, and I'm not sure what (or whether) to update it's required `TieredStopAtLevel` to should the existing one be outdated (Would appreciate any feedback on this part)

This pull request has now been integrated.

Changeset: a86cab8d
Author:    TheShermanTanker <josephtay19 at gmail.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a86cab8d4259f29af86aa6063b721e47827fb949
Stats:     3 lines in 3 files changed: 1 ins; 0 del; 2 mod

8236136: tests which use CompilationMode shouldn't be run w/ TieredStopAtLevel

Reviewed-by: neliasso, kvn, thartmann

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

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

From thartmann at openjdk.java.net  Wed Feb 16 07:55:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Feb 2022 07:55:05 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <eY0HhKN0ldOiqauto4LzmXYF8IumQFtp5WZkTPHzJ18=.39666ebe-ff05-4765-8c8d-782681e3c9c3@github.com>

On Tue, 15 Feb 2022 14:51:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

Looks good to me otherwise.

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

> 231:   if ((uintx)CodeEntryAlignment > CodeCacheSegmentSize) {
> 232:     JVMFlag::printError(verbose,
> 233:                         "CodeEntryAlignment  (" INTX_FORMAT ") must be "

Suggestion:

                        "CodeEntryAlignment (" INTX_FORMAT ") must be "

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

Marked as reviewed by thartmann (Reviewer).

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

From thartmann at openjdk.java.net  Wed Feb 16 07:56:11 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Feb 2022 07:56:11 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v3]
In-Reply-To: <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
 <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
Message-ID: <pV-mNlU9EuVAa5vRYNQfkjRDSOrCkYl9kgs5ujucAkw=.b683f9f8-f144-48eb-9794-655fd0815593@github.com>

On Tue, 15 Feb 2022 07:29:47 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
>> 
>> I improved the code by having two functions instead:
>> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
>> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
>> 
>> This makes implicit assumptions explicit and also validates them in the future.
>> 
>> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
>> 
>> Ran tests to verify that the assert never triggers.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Require non-Null in some more cases

Looks good to me otherwise.

src/hotspot/share/opto/node.cpp line 2411:

> 2409:     Node* ctrl = unique_ctrl_out_or_null();
> 2410:     assert(ctrl != NULL, "control out is assumed to be unique");
> 2411:     return ctrl;

Suggestion:

  Node* ctrl = unique_ctrl_out_or_null();
  assert(ctrl != NULL, "control out is assumed to be unique");
  return ctrl;

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

Marked as reviewed by thartmann (Reviewer).

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

From duke at openjdk.java.net  Wed Feb 16 08:01:49 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 16 Feb 2022 08:01:49 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v4]
In-Reply-To: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
Message-ID: <n17GwVZWRsso2PIIRrJ2m7D43u4mprkYpqCj54-W7wM=.d4d0be6f-d24f-4c76-abc6-1452b234ff09@github.com>

> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
> 
> I improved the code by having two functions instead:
> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
> 
> This makes implicit assumptions explicit and also validates them in the future.
> 
> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
> 
> Ran tests to verify that the assert never triggers.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation in src/hotspot/share/opto/node.cpp
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7462/files
  - new: https://git.openjdk.java.net/jdk/pull/7462/files/3beb58ce..20798305

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

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

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

From jiefu at openjdk.java.net  Wed Feb 16 08:14:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 08:14:39 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467 [v2]
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <Fum6-ZtJBwH895FEGEMadk3A02LdwS0gX2gELZqIofM=.770853fd-2e46-4c5d-bb70-c6078ff95e40@github.com>

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7480/files
  - new: https://git.openjdk.java.net/jdk/pull/7480/files/b39bc8f3..5c274548

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

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

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

From jiefu at openjdk.java.net  Wed Feb 16 08:14:40 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 08:14:40 GMT
Subject: RFR: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467 [v2]
In-Reply-To: <eY0HhKN0ldOiqauto4LzmXYF8IumQFtp5WZkTPHzJ18=.39666ebe-ff05-4765-8c8d-782681e3c9c3@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
 <eY0HhKN0ldOiqauto4LzmXYF8IumQFtp5WZkTPHzJ18=.39666ebe-ff05-4765-8c8d-782681e3c9c3@github.com>
Message-ID: <MPVm9m4ho5b6nqd5KpV5pQ02izsl32C9wG73HyFFdeI=.5db34bbb-b26b-44e5-ba28-7b4382ed2ff6@github.com>

On Wed, 16 Feb 2022 07:51:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment
>
> src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp line 233:
> 
>> 231:   if ((uintx)CodeEntryAlignment > CodeCacheSegmentSize) {
>> 232:     JVMFlag::printError(verbose,
>> 233:                         "CodeEntryAlignment  (" INTX_FORMAT ") must be "
> 
> Suggestion:
> 
>                         "CodeEntryAlignment (" INTX_FORMAT ") must be "

Fixed.

Thanks @vnkozlov and @TobiHartmann for your review.

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

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

From pli at openjdk.java.net  Wed Feb 16 08:32:32 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Wed, 16 Feb 2022 08:32:32 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable
Message-ID: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>

AArch64 has SVE instruction of populating incrementing indices into an
SVE vector register. With this we can vectorize some operations in loop
with the induction variable operand, such as below.

  for (int i = 0; i < count; i++) {
    b[i] = a[i] * i;
  }

This patch enables the vectorization of operations with loop induction
variable by extending current scope of C2 superword vectorizable packs.
Before this patch, any scalar input node in a vectorizable pack must be
an out-of-loop invariant. This patch takes the induction variable input
as consideration. It allows the input to be the iv phi node or phi plus
its index offset, and creates a `PopulateIndexNode` to generate a vector
filled with incrementing indices. On AArch64 SVE, final generated code
for above loop expression is like below.

  add     x12, x16, x10
  add     x12, x12, #0x10
  ld1w    {z16.s}, p7/z, [x12]
  index   z17.s, w1, #1
  mul     z17.s, p7/m, z17.s, z16.s
  add     x10, x17, x10
  add     x10, x10, #0x10
  st1w    {z17.s}, p7, [x10]

As there is no populating index instruction on AArch64 NEON or other
platforms like x86, a function named `is_populate_index_supported()` is
created in the VectorNode class for the backend support check.

Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
are tested and no issue is found. Hotspot jtreg has existing tests in
`compiler/c2/cr7192963/Test*Vect.java` covering this kind of use cases so
no new jtreg is created within this patch. A new JMH is created in this
patch and tested on a 512-bit SVE machine. Below test result shows the
performance can be significantly improved in some cases.

  Benchmark                       Performance
  IndexVector.exprWithIndex1            ~7.7x
  IndexVector.exprWithIndex2           ~13.3x
  IndexVector.indexArrayFill            ~5.7x

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

Commit messages:
 - 8280510: AArch64: Vectorize operations with loop induction variable

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

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

From aph at openjdk.java.net  Wed Feb 16 09:24:08 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 16 Feb 2022 09:24:08 GMT
Subject: RFR: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
In-Reply-To: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
References: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
Message-ID: <MEzHoq7tiXr4UKU_9IdrK1QfEu-wfgKn_UO1l2x6GmA=.29038fe0-047c-4747-bdee-615397a8c028@github.com>

On Wed, 16 Feb 2022 02:21:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector lanewise `NOT` is implemented with `"v.xor(-1)"` and `AND_NOT ` is implemented with `"v1.and(v2.xor(-1))"`. With SVE they can be respectively implemented with `"not/bic"` instructions, and we have already optimized the non-masked operations before (see [1]).
> 
> Consider the SVE also supports the `predicated` `"not/bic"`, we can apply the same optimizations for the masked `NOT/AND_NOT` by adding match rules. So this patch adds the rules for the following optimizations:
> 
> For `NOT `with int type:
> 
>   mov z16.s, #-1
>   eor z18.s, p0/m, z18.s, z16.s  ==>  not z18.s, p0/m, z18.s
> 
> For `AND_NOT `with int type:
> 
>   not z16.d, p7/m, z16.d
>   and z17.s, p0/m, z17.s, z16.s  ==>  bic z17.s, p0/m, z16.s
> 
> Here is the performance gain for the `"NOT/AND_NOT"` benchmarks (see [2][3] for byte type) with SVE 512-bit:
> 
> Benchmark                    Gain
> LongMaxVector.NOTMasked      1.005
> ShortMaxVector.NOTMasked     1.017
> IntMaxVector.NOTMasked       1.022
> ByteMaxVector.NOTMasked      1.023
> LongMaxVector.AND_NOTMasked  1.063
> IntMaxVector.AND_NOTMasked   1.047
> ShortMaxVector.AND_NOTMasked 1.059
> ByteMaxVector.AND_NOTMasked  1.030
> 
> [1] https://github.com/openjdk/jdk/pull/3370
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L1963
> [3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L362

Marked as reviewed by aph (Reviewer).

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

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

From jbhateja at openjdk.java.net  Wed Feb 16 11:05:07 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Feb 2022 11:05:07 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v4]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <1dqqh2KXNKFtAUuCMwvI9mLA0jFw--Bqz-AEfrxq_NM=.1b9f677e-3798-4877-9b58-8afdc8ed64ac@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Replacing by efficient instruction sequence based on MXCSR.RC mode.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/2dc364fa..1c9ff777

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

  Stats: 143 lines in 4 files changed: 4 ins; 82 del; 57 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

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

From jbhateja at openjdk.java.net  Wed Feb 16 12:30:28 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Feb 2022 12:30:28 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <UMm_6uonBzgdEoJzE3zbiZ2MTeBRh8FWEgR1wjk-SMI=.ecc686f6-f233-4335-a810-89f540992f93@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
 <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
 <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>
 <iCaaelBgPdReusZLD-8eM-XDbw_xWsV5mv1vq4umRcg=.58de564c-df8f-4d20-96fd-e64389421cc0@github.com>
 <EKNLSOdo1lrE-PbeZZ9YC9LonG9FhmDitLo_Wa60vYk=.c4324df4-3b7d-4b12-939e-e74de8e6ae76@github.com>
 <UMm_6uonBzgdEoJzE3zbiZ2MTeBRh8FWEgR1wjk-SMI=.ecc686f6-f233-4335-a810-89f540992f93@github.com>
Message-ID: <CMP5v8fC8SRtISzzTncUyG7OU58s0kdrEIQZaX_-oUw=.88fdebd3-5f12-47fd-a5c0-7690175c1f93@github.com>

On Mon, 14 Feb 2022 17:14:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> That pseudocode would make a very useful comment too. This whole patch is very thinly commented.
>
>> > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.
>> 
>> Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects.
> 
> **Just want to correct above statement, LDMXCSR will not be re-ordered/re-scheduled early OOO backend.**

> That pseudocode would make a very useful comment too. This whole patch is very thinly commented.

I have replaced earlier bulky sequence, new sequence is having similar performance but reduction in code may improve inlining behavior.  Added descriptive comments around the special cases.

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

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

From jbhateja at openjdk.java.net  Wed Feb 16 12:30:27 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Feb 2022 12:30:27 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v5]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <-NfiIwcnrf7TRNxA9x1d9itPvKYgeCYogpjSZgGYtvc=.15346702-2db7-4295-8e5a-a4864f3bbdbd@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - 8279508: Adding few descriptive comments.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - 8279508: Replacing by efficient instruction sequence based on MXCSR.RC mode.
 - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - 8279508: Adding a test for scalar intrinsification.
 - 8279508: Auto-vectorize Math.round API

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

Changes: https://git.openjdk.java.net/jdk/pull/7094/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=04
  Stats: 739 lines in 23 files changed: 648 ins; 29 del; 62 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

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

From ihse at openjdk.java.net  Wed Feb 16 12:33:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 12:33:43 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v7]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <xOiKVqPpqz6jsGFAHsDxcgAJB_XttiFWiS57vKKRVpo=.7262f97f-12f6-490a-bd51-a66593c15f0a@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Make sure install-hsdis also copies to image

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/47cf9a1b..467e1bb1

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

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

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

From jbhateja at openjdk.java.net  Wed Feb 16 12:40:10 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Feb 2022 12:40:10 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v3]
In-Reply-To: <CMP5v8fC8SRtISzzTncUyG7OU58s0kdrEIQZaX_-oUw=.88fdebd3-5f12-47fd-a5c0-7690175c1f93@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <O1e2e74ohmj0q0nxd1YuInGsZWrlDpXGetUqwXRZES0=.eb3c1352-d840-4d05-ad22-b68a4da187db@github.com>
 <aQmrSiY4J2-diiRGJKRM26RnaCAF93rsaoyvzQyVOSM=.852e8450-c25b-4e1a-b3e1-4f71a1e16977@github.com>
 <j-EwZ27qdjOya-YG0gRFgQ-ekCoEEr5A10YqHtGOh1k=.83e47518-ee9b-44d1-8652-e5f84c59d539@github.com>
 <iCaaelBgPdReusZLD-8eM-XDbw_xWsV5mv1vq4umRcg=.58de564c-df8f-4d20-96fd-e64389421cc0@github.com>
 <EKNLSOdo1lrE-PbeZZ9YC9LonG9FhmDitLo_Wa60vYk=.c4324df4-3b7d-4b12-939e-e74de8e6ae76@github.com>
 <UMm_6uonBzgdEoJzE3zbiZ2MTeBRh8FWEgR1wjk-SMI=.ecc686f6-f233-4335-a810-89f540992f93@github.com>
 <CMP5v8fC8SRtISzzTncUyG7OU58s0kdrEIQZaX_-oUw=.88fdebd3-5f12-47fd-a5c0-7690175c1f93@github.com>
Message-ID: <UdQYwLX0ky_klc-PLJxzAAyEeFLeYVJYHH9BRD5exR8=.5e45de8c-46a1-4f79-8c05-172a7257d1e4@github.com>

On Wed, 16 Feb 2022 12:26:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Hi, IIRC for evex encoding you can embed the RC control bit directly in the evex prefix, removing the need to rely on global MXCSR register. Thanks.
>>> 
>>> Hi @merykitty , You are correct, we can embed RC mode in instruction encoding of round instruction (towards -inf,+inf, zero). But to match the semantics of Math.round API one needs to add 0.5[f] to input value and then perform rounding over resultant value, which is why @sviswa7 suggested to use a global rounding mode driven by MXCSR.RC so that intermediate floating inexact values are resolved as desired, but OOO execution may misplace LDMXCSR and hence may have undesired side effects.
>> 
>> **Just want to correct above statement, LDMXCSR will not be re-ordered/re-scheduled early OOO backend.**
>
>> That pseudocode would make a very useful comment too. This whole patch is very thinly commented.
> 
> I have replaced earlier bulky sequence, new sequence is having similar performance but reduction in code may improve inlining behavior.  Added descriptive comments around the special cases.

> There are already `RoundFloat`, `RoundDouble`, and `RoundDoubleMode` nodes defined.
> 
> Though `RoundFloat` and `RoundDouble` are legacy nodes used only on x86-32, `RoundDoubleMode` supports multiple rounding modes and is amenable to auto-vectorization.
> 
> What do you think about the following alternative?
> 
> Reuse `RoundDoubleMode` (with a new rounding mode) and introduce `RoundFloatMode`.
> 
> Special rounding rules is not the only peculiarity of `Math.round()`. It also converts the result to an integral type. It can be represented as `ConvF2I (RoundFloatMode f #rmode)` / `ConvD2L (RoundDoubleMode d #rmode)`. In scalar case, it can be matched as a single AD instruction.
> 
> Auto-vectorizer can then convert it to `VectorCastF2X (RoundFloatModeV vf #rmode)` / `VectorCastD2X (RoundDoubleModeV vd #rmode)` and match it in a similar manner.

Adding new rounding mode to RoundDoubleMode may disturb other targets. match_rule_supported routine operates over Opcodes and currently any target supporting RoundDoubleMode generates code for all the rounding modes. Your solution is anyways based on creating new scalar and vector IR node for floating point rounding operation, which is what patch is doing currently.

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

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

From roland at openjdk.java.net  Wed Feb 16 13:35:40 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 16 Feb 2022 13:35:40 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799
Message-ID: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>

The crash occurs because a Shenandoah barrier is expanded between the
Start node and its control projection. One of the test cases I added
also shows the same failure with a barrier expansion between a MemBar
and its control projection. The barrier is expanded at the control
that PhaseIdealLoop assigns to it.

This code:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
I added back with JDK-8280799 is what's causing the incorrect
placement of the barrier.

The fix I propose is to skip that logic if the loop opts pass is for
barrier expansion as there's no range check elimination then.

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

Commit messages:
 - test
 - fix

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

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

From jiefu at openjdk.java.net  Wed Feb 16 13:50:12 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 13:50:12 GMT
Subject: Integrated: 8281829:
 runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after
 JDK-8281467
In-Reply-To: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
References: <cKzvspH4qwy7522BGoU4TVagXfSn51B63VBfDFFOH04=.30ef9543-8f48-42e6-b749-d5756ef0d2fc@github.com>
Message-ID: <eF8OVIOvNLGYV7Z0XcBNFhbgeMZ8v0-s4Igr6GquHrA=.371c9e7d-b6a3-41a4-85cf-cffbebdf667d@github.com>

On Tue, 15 Feb 2022 14:51:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails due to SIGFPE after JDK-8281467 with release VMs.
> It can be reproduced by running `java -XX:+UnlockExperimentalVMOptions -XX:CodeEntryAlignment=4294967296` with release VMs.
> 
> This is because `CodeEntryAlignment` would be converted from `intx` to `int` at line 825.
> 
>  824   address generate_fp_mask(const char *stub_name, int64_t mask) {
>  825     __ align(CodeEntryAlignment);
>  826     StubCodeMark mark(this, "StubRoutines", stub_name);
>  827     address start = __ pc();
>  828
>  829     __ emit_data64( mask, relocInfo::none );
>  830     __ emit_data64( mask, relocInfo::none );
>  831
>  832     return start;
>  833   }
> 
> 
> Then at line 1187, `modulus` would become 0 after the conversion of `CodeEntryAlignment`, which leads to SIGFPE at line 1191.
> 
> 1184 void MacroAssembler::align(int modulus) {
> 1185   // 8273459: Ensure alignment is possible with current segment alignment
> 1186   assert(modulus <= CodeEntryAlignment, "Alignment must be <= CodeEntryAlignment");
> 1187   align(modulus, offset());
> 1188 }
> 1189
> 1190 void MacroAssembler::align(int modulus, int target) {
> 1191   if (target % modulus != 0) {
> 1192     nop(modulus - (target % modulus));
> 1193   }
> 1194 }
> 
> 
> The fix just adding a rule (`CodeEntryAlignment <= CodeCacheSegmentSize`) in `CodeEntryAlignmentConstraintFunc`.
> 
> This is fine because we already has that rule in `CodeCacheSegmentSizeConstraintFunc`.
> And this is necessary since `CodeCacheSegmentSizeConstraintFunc` won't be called in release VMs.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

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

8281829: runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java fails after JDK-8281467

Reviewed-by: kvn, thartmann

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

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

From ihse at openjdk.java.net  Wed Feb 16 14:39:49 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 14:39:49 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v8]
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <0tGSY9Iutr4jkP2idAqvi3yM3Qon120-JCD6fGxZobg=.fb6e4549-44e1-42eb-a51b-166c3912c37b@github.com>

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Add section on using LLVM
 - Allow override of LLVM location using --with-llvm

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5920/files
  - new: https://git.openjdk.java.net/jdk/pull/5920/files/467e1bb1..5ea9bc0d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5920&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5920&range=06-07

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

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

From rcastanedalo at openjdk.java.net  Wed Feb 16 14:43:49 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 16 Feb 2022 14:43:49 GMT
Subject: RFR: 8279068: IGV: Update to work with JDK 16 and 17
Message-ID: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>

This change upgrades the NetBeans Platform on which IGV is based to its latest version ([12.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.

#### Testing

Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):

- 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
- export graph as PDF
- 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)

Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".

Thanks to Jesper Wilhelmsson for helping with testing on macOS.

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

Commit messages:
 - Pass all JVM options in a single line for Windows compatibility
 - Enforce JDK version
 - Update copyright years
 - Allow Netbeans Platform to break encapsulation (needed for correct behavior)
 - Simplify instructions
 - Update to latest Nashorn for compatibility with JDK 17
 - Update instructions
 - Update to latest NetBeans Platform version

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

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

From duke at openjdk.java.net  Wed Feb 16 15:01:07 2022
From: duke at openjdk.java.net (Tom Shull)
Date: Wed, 16 Feb 2022 15:01:07 GMT
Subject: RFR: 8262901: [macos_aarch64] NativeCallTest
 expected:<-3.8194101E18> but was:<3.02668882E10>
In-Reply-To: <gojGfhJBtojityWDOFmQu84LHMdnXjE3CdUGpDUROVU=.06b1fc3f-291a-43c9-a0b7-6fd971257c10@github.com>
References: <EKai9u5Kli5AfxN5AukPhdxVqAZAABnnJfmTwDRnj_A=.940a8b14-8822-4911-b3e0-8ba7ddcc2f35@github.com>
 <-Wzb3RXPFeEY0E7HDT-7lWw1_2mxReE-J8FPeI3UKl8=.4211598e-f032-46b8-8aa4-6f5254785193@github.com>
 <gojGfhJBtojityWDOFmQu84LHMdnXjE3CdUGpDUROVU=.06b1fc3f-291a-43c9-a0b7-6fd971257c10@github.com>
Message-ID: <mhWMN5IFAhNAswg9JEvgIcnyA_u99uvY0w0SqW5KMGs=.25fb8e2c-a01e-491d-837d-ac3d80bfe9a5@github.com>

On Mon, 20 Dec 2021 07:49:51 GMT, Danil Bubnov <duke at openjdk.java.net> wrote:

>> Please add some test with an odd number of arguments.
>
> @theRealAph Can you review changes?

@KaperD are you planning to update this PR?

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

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

From duke at openjdk.java.net  Wed Feb 16 16:00:11 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 16 Feb 2022 16:00:11 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v3]
In-Reply-To: <Fjji9d7sCXerpO4OQhXXQMQUcC11UUGauiN3mRvagXc=.305b7cf7-e75d-4a01-bba1-91a1f2dfaa36@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
 <qxGS5_1OOT7UPCdrNEq9p58TeuThz65vCTVWb1G515w=.7cd155dc-03dc-48cb-b90b-02afc9e11741@github.com>
 <Fjji9d7sCXerpO4OQhXXQMQUcC11UUGauiN3mRvagXc=.305b7cf7-e75d-4a01-bba1-91a1f2dfaa36@github.com>
Message-ID: <6qzd26fbY6f40V-DnAXhSyOfKcK01fH5hEw_OqVfAL8=.104eb634-25be-44aa-9974-d427271728f1@github.com>

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

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Require non-Null in some more cases
>
> Looks good.

@vnkozlov  @chhagedorn @TobiHartmann thank you for the reviews!
@TobiHartmann I applied your indentation suggestion, thanks for catching it!

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

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

From denghui.ddh at alibaba-inc.com  Wed Feb 16 16:10:18 2022
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Thu, 17 Feb 2022 00:10:18 +0800
Subject: =?UTF-8?B?QSBxdWVzdGlvbiBhYm91dCB0aGUgcGF0Y2hpbmcgaW5zdHJ1Y3Rpb24gb3JkZXIgb2YgQ29t?=
 =?UTF-8?B?cGlsZWRJQzo6aW50ZXJuYWxfc2V0X2ljX2Rlc3RpbmF0aW9u?=
Message-ID: <5722aef9-b62e-4f3c-add3-5d7feafa4d1d.denghui.ddh@alibaba-inc.com>

Hello team,

I have a question about the patching order in CompiledIC::internal_set_ic_destination.

If I understand correctly, the current implementation patches the CALL instruction first and then the MOV instruction.

My question is why don't patch the MOV instruction first?

Suppose an inline cache is in the transition from Clean to Monomorphic state, and the CALL instruction is patched already, but
the MOV instruction is not. If another thread executes to this call site, the guard of the callee UEP will be failed and forward to _ic_miss_blob.

Any input is appreciated:-)

Thanks,
Denghui

From chagedorn at openjdk.java.net  Wed Feb 16 16:20:06 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 16 Feb 2022 16:20:06 GMT
Subject: RFR: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out [v4]
In-Reply-To: <n17GwVZWRsso2PIIRrJ2m7D43u4mprkYpqCj54-W7wM=.d4d0be6f-d24f-4c76-abc6-1452b234ff09@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
 <n17GwVZWRsso2PIIRrJ2m7D43u4mprkYpqCj54-W7wM=.d4d0be6f-d24f-4c76-abc6-1452b234ff09@github.com>
Message-ID: <X0xwy27Qkv0ShjoE4Ks__RR9NlGvkJpTadaK-n9900s=.bc2f9418-2bde-4c1d-947e-27c7acf8f349@github.com>

On Wed, 16 Feb 2022 08:01:49 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
>> 
>> I improved the code by having two functions instead:
>> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
>> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
>> 
>> This makes implicit assumptions explicit and also validates them in the future.
>> 
>> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
>> 
>> Ran tests to verify that the assert never triggers.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation in src/hotspot/share/opto/node.cpp
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Marked as reviewed by chagedorn (Reviewer).

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

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

From duke at openjdk.java.net  Wed Feb 16 16:23:11 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 16 Feb 2022 16:23:11 GMT
Subject: Integrated: 8281732: add assert for non-NULL assumption for return of
 unique_ctrl_out
In-Reply-To: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
References: <z2dQN0hZ0LgJ5JFd5Lpm4bza2iMD-yvOWFW9WFJ5uvg=.25f0c7a3-8b81-41ce-9f4d-ec7d9c5d0298@github.com>
Message-ID: <Ropygc7O4XY-_6Ysoqn2nqiH5BjtvfAxvDoArkAjGFo=.366306be-d834-4694-b948-ba5f9dc62c96@github.com>

On Mon, 14 Feb 2022 14:58:11 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> unique_ctrl_out was used in contexts where NULL may be a valid return, and is also used in contexts where NULL is not expected.
> 
> I improved the code by having two functions instead:
> unique_ctrl_out_or_null: return the unique control out, or NULL if there is no or more than one control out.
> unique_ctrl_out: return the unique control out, assert if there is no or more than one control out.
> 
> This makes implicit assumptions explicit and also validates them in the future.
> 
> I changed the usage to unique_ctrl_out_or_null where NULL is among the expected return values.
> 
> Ran tests to verify that the assert never triggers.

This pull request has now been integrated.

Changeset: 395bc141
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/395bc141f22f59aea4f5b8ee7bca0f691b2c8733
Stats:     30 lines in 8 files changed: 10 ins; 0 del; 20 mod

8281732: add assert for non-NULL assumption for return of unique_ctrl_out

Reviewed-by: kvn, chagedorn, thartmann

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

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

From kvn at openjdk.java.net  Wed Feb 16 17:11:06 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 17:11:06 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <n374rjzLGd7TUXimH0mFSP9qOEGwpuafjmLERJdSXJI=.c7b86e5e-5c03-40a9-8d33-8d73be452a3b@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Change to `NOT_PRODUCT` macro is good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Wed Feb 16 18:14:14 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 18:14:14 GMT
Subject: RFR: 8279068: IGV: Update to work with JDK 16 and 17
In-Reply-To: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
References: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
Message-ID: <F9cgnCn_ptSrWwPzmngFaBArorZEW3WJif2fLdWrXEg=.9d28f4a1-7b46-41a0-a696-8343e2c6d4a3@github.com>

On Fri, 4 Feb 2022 12:30:52 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.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.
> 
> #### Testing
> 
> Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):
> 
> - 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
> - export graph as PDF
> - 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)
> 
> Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".
> 
> Thanks to Jesper Wilhelmsson for helping with testing on macOS.

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From neliasso at openjdk.java.net  Wed Feb 16 18:52:10 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 16 Feb 2022 18:52:10 GMT
Subject: RFR: 8279068: IGV: Update to work with JDK 16 and 17
In-Reply-To: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
References: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
Message-ID: <rLddIKOvyW9vOv5mmPmMFHXaPU1tZ-ztc0sMmoXsccA=.8d755cc3-9335-48c0-a163-312ac8dcec19@github.com>

On Fri, 4 Feb 2022 12:30:52 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.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.
> 
> #### Testing
> 
> Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):
> 
> - 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
> - export graph as PDF
> - 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)
> 
> Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".
> 
> Thanks to Jesper Wilhelmsson for helping with testing on macOS.

Looks good!

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

Marked as reviewed by neliasso (Reviewer).

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

From kvn at openjdk.java.net  Wed Feb 16 19:06:18 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 19:06:18 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799
In-Reply-To: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
Message-ID: <QKkbEhXwBUMsTFn7_6TDTaxrIcQBvRorT_cAldHNcZM=.25bd636d-ee98-414f-a603-61a17ae52b01@github.com>

On Wed, 16 Feb 2022 13:28:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The crash occurs because a Shenandoah barrier is expanded between the
> Start node and its control projection. One of the test cases I added
> also shows the same failure with a barrier expansion between a MemBar
> and its control projection. The barrier is expanded at the control
> that PhaseIdealLoop assigns to it.
> 
> This code:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
> I added back with JDK-8280799 is what's causing the incorrect
> placement of the barrier.
> 
> The fix I propose is to skip that logic if the loop opts pass is for
> barrier expansion as there's no range check elimination then.

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From kvn at openjdk.java.net  Wed Feb 16 19:41:10 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 19:41:10 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <VKjppXYqpX0GKITWWRtxwtoyaTGoVJxIZOiyNCGqDfo=.1a8abd3a-46d0-46ee-9d2c-0ec6b2297bd9@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

I tried it with SubstringNSR.java from JDK-8261531 and have comments.

src/hotspot/share/opto/escape.cpp line 918:

> 916:           // Not scalar replaceable if the length is not constant or too big.
> 917:           scalar_replaceable = false;
> 918:           NOT_PRODUCT(nsr_reason = "has a non-constant or too big length");

Can you separate these two cases: `non-constant` and `too big`? You can split the above check.

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

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

From kvn at openjdk.java.net  Wed Feb 16 19:47:10 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 19:47:10 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <PhBZL3WujLY1Y_Apw1dRciibcARI3cJFc5t0zKSJ8rA=.e32e7a7b-a05c-4dd2-b527-772a870b0a23@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

src/hotspot/share/opto/escape.cpp line 1148:

> 1146:             }
> 1147:           }
> 1148:           set_escape_state(arg_ptn, es NOT_PRODUCT(COMMA "reason unknown (1)"));

Transition here is `NoEscape` -> `ArgEscape`. So the reason could be "is argument".

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

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

From kvn at openjdk.java.net  Wed Feb 16 19:54:07 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 19:54:07 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <T8pDFigYsYc9paeB1iO71fSWHGcQz5ods1b14p722LM=.4c5a7fc9-8954-4fec-a3eb-d6cdf0be6590@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

src/hotspot/share/opto/escape.cpp line 3169:

> 3167:         alloc->as_Allocate()->_is_scalar_replaceable = true;
> 3168:       }
> 3169:       set_escape_state(ptnode_adr(n->_idx), es NOT_PRODUCT(COMMA "reason unknown (2)")); // CheckCastPP escape state

Escape state of allocation is assigned to CheckCastPP node. `es` value should be `NoEscape` - see line 3109.
May be reason should be "assign state of related Allocation".

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

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

From Divino.Cesar at microsoft.com  Wed Feb 16 21:03:16 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Wed, 16 Feb 2022 21:03:16 +0000
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
Message-ID: <DM6PR21MB14843A95A8E3B021634214789A359@DM6PR21MB1484.namprd21.prod.outlook.com>

Thank you Vladimir I., for sharing this. I think I got the overall idea but
there are a few things that aren't quite clear to me still. I'm going to use your
code example to help clarify my questions.

We start of with this:

static int testPolluted(int r, boolean b) {
    A obj1 = new A(r);
    A obj2 = new A(r);

    A obj = (b ? obj1 : obj2);
    for (int i = 1; i < r; i++) {
        obj.i++;
    }

    return obj1.i + obj2.i;
}

And then we cluster interfering allocations together in disjoint clusters. Two
questions on this point: 

1) What exactly grouping the allocations in clusters helps? I believe when you
say it'll help, I'm just trying to understand what exactly how.

2) To create the allocation clusters is it sufficient to simply put together
allocations that merge at Phi's (including transitive merges) or we'll need
something more complex?

After we create the clusters we'll then run a few transformations, including
splitting memory accesses through Phis. This would transform the example above
into something like this:

static int testUnqiue(int r, boolean b) {
    A obj1 = new A(r);
    A obj2 = new A(r);

    for (int i = 1; i < r; i++) {
        if (b) {
            obj1.i++;
        } else {
            obj2.i++;
        }
    }
    return obj1.i + obj2.i;
}

Next we'll run "split_unique_types" and do scalar replacement as we do today and
eventually we should have something like this:

static int testUnqiue(int r, boolean b) {
    int i1 = r;
    int i2 = r;

    for (int i = 1; i < r; i++) {
        if (b) {
            i1++;
        } else {
            i2++;
        }
    }

    return i1 + i2;
}


Thanks,
Cesar


________________________________________
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Sent: February 14, 2022 11:39 AM
To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
Cc: Brian Stafford; Martijn Verburg
Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement


> Once memory graph for unique alias is separated, it should be much
> simpler to further optimize it. If all memory operations are folded, the
> allocation can go away.
>
> Splitting memory operations through phis should help untangle the
> allocations. So, even if one allocation can't be fully scalarized, it
> shouldn't keep other allocations from being scalarized (unless they alias).
>
> I don't have a good understanding how new logic will interact with
> unique instance slices & _instance_id. Maybe a gradual transition from
> original graph to clustered slices to unique instance slices.

I took a closer look at a slightly more complicated example:

     class A {
         int i;
         A(int i) { this.i = i; }
     }

     static int testPolluted(int r, boolean b) {
         A obj1 = new A(r);
         A obj2 = new A(r);

         A obj = (b ? obj1 : obj2);
         for (int i = 1; i < r; i++) {
             obj.i++;
         }

         return obj1.i + obj2.i;
     }

There are 3 interacting memory slices: obj1.i, obj2.i, and obj.i (which
alias with obj1.i and obj2.i).

Unless the access inside the loop is eliminated, there's no way to
untangle the memory graphs for obj1.i and obj2.i and scalarize allocations.

In this particular case, it's quite straightforward to untangle the
graphs for instance types (and make both obj1 and obj2 scalarizable):

     static int testUnqiue(int r, boolean b) {
         A obj1 = new A(r);
         A obj2 = new A(r);

         for (int i = 1; i < r; i++) {
             if (b) {
                 obj1.i++;
             } else {
                 obj2.i++;
             }
         }
         return obj1.i + obj2.i;
     }

But depending on the actual shape of the base pointer (here it's
Phi(obj1,obj2)), it may become infeasible (from performance perspective)
or even impossible (e.g., for complex loop variant conditions) to
separate instance slices.

So, gradual approach seems the way to go:
   (1) split memory graph for clusters of interacting non-escaping
allocations;

   (2) perform adhoc transformation targeted at untangling aliasing
accesses (e.g, split-through-phi);

   (3) extract unique instance types where possible, thus making the
corresponding allocation scalar replaceable

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

Also, one observation: interacting allocations don't have to be of the
same class.

     static int testPolluted(int r, boolean b) {
         A obj1 = new B1(r);
         A obj2 = new B2(r);

         A obj = (b ? obj1 : obj2);
         for (int i = 1; i < r; i++) {
             obj.i++;
         }

         return obj1.i + obj2.i;
     }

Requiring unique instance types to perform SR (and not enhancing SR to
handle aliasing allocations case) helps avoid some challenges in
instance rematerialization logic at safepoints, because actual shape of
the scalarized object (its class and exact set of fields) becomes a
runtime property.

Best regards,
Vladimir Ivanov

>>>
>>> Otherwise, I believe wide memory states/merges would pose serious
>>> problems. E.g., when a load is split through a phi, you need to pick
>>> correct memory states for the new loads above the phi which quickly
>>> becomes quite a challenging task.
>>
>> Especially in loops. Actually I did tried such approach before and I
>> agree that it is hard.
>>
>> Thanks,
>> Vladimir K
>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> public int ex1(boolean cond, int first, int second) {
>>>>      p0 = Allocate(...);
>>>>      ...
>>>>      p0.x = first;
>>>>      p0.y = second;
>>>>
>>>>      if (cond) {
>>>>          p1 = Allocate(...);
>>>>          ...
>>>>          p1.x = second;
>>>>          p1.y = first;
>>>>      }
>>>>
>>>>      p = phi(p0, p1) // unused and will be removed
>>>>
>>>>
>>>>      return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>> }
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>> hotspot-compiler-dev.)
>>>>>
>>>>> Hi Cesar,
>>>>>
>>>>> Thanks for looking into enhancing EA.
>>>>>
>>>>> Overall, the proposal looks reasonable.
>>>>>
>>>>> I suggest to look more closely at split_unique_types().
>>>>> It introduces a dedicated class of alias categories for fields of
>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>> see why it shouldn't work for multiple allocations.
>>>>>
>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>> multiple allocations at once. The notion of unique alias should be
>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>> allocations.
>>>>>
>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>> clusters of allocations.
>>>>>
>>>>> One thing to take care of: scalar replacement relies on
>>>>> TypeOopPtr::instance_id().
>>>>>
>>>>>    // If not InstanceTop or InstanceBot, indicates that this is
>>>>>    // a particular instance of this type which is distinct.
>>>>>    // This is the node index of the allocation node creating this
>>>>> instance.
>>>>>    int           _instance_id;
>>>>>
>>>>> It'll break when multiple allocations are in play.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>> Hi there again!
>>>>>>
>>>>>> Can you please give me feedback on the following approach to at
>>>>>> least partially
>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>
>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>> merged after a
>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>> situation.
>>>>>>
>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>      Point p = new Point(x, y);
>>>>>>      if (cond)
>>>>>>          p = new Point(y, x);
>>>>>>      // Allocations for p are merged here.
>>>>>>      return p.calc();
>>>>>> }
>>>>>>
>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>> will not
>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>      p0 = Allocate(...);
>>>>>>      ...
>>>>>>      p0.x = first;
>>>>>>      p0.y = second;
>>>>>>
>>>>>>      if (cond) {
>>>>>>          p1 = Allocate(...);
>>>>>>          ...
>>>>>>          p1.x = second;
>>>>>>          p1.y = first;
>>>>>>      }
>>>>>>
>>>>>>      p = phi(p0, p1)
>>>>>>
>>>>>>      return p.x - p.y;
>>>>>> }
>>>>>>
>>>>>> However, one of the constraints implemented here [2], specifically
>>>>>> the third
>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>
>>>>>> The approach that I'm considering for solving the problem is to
>>>>>> replace the Phi
>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>> of the objects
>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>> this after the
>>>>>> transformation:
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>      p0 = Allocate(...);
>>>>>>      ...
>>>>>>      p0.x = first;
>>>>>>      p0.y = second;
>>>>>>
>>>>>>      if (cond) {
>>>>>>          p1 = Allocate(...);
>>>>>>          ...
>>>>>>          p1.x = second;
>>>>>>          p1.y = first;
>>>>>>      }
>>>>>>
>>>>>>      pX = phi(first, second)
>>>>>>      pY = phi(second, first)
>>>>>>
>>>>>>      return pX - pY;
>>>>>> }
>>>>>>
>>>>>> I understand that this transformation might not be applicable for
>>>>>> all cases and
>>>>>> that it's not as simple as illustrated above. Also, it seems to me
>>>>>> that much of
>>>>>> what I'd have to implement is already implemented in other steps
>>>>>> of the Scalar
>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>> implementation details I plan to use as much of the existing code
>>>>>> as possible.
>>>>>> The algorithm for the transformation would be like this:
>>>>>>
>>>>>> split_phis(phi)
>>>>>>      # If output of phi escapes, or something uses its identity, etc
>>>>>>      # then we can't remove it. The conditions here might possible
>>>>>> be the
>>>>>>      # same as the ones implemented in
>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>      if cant_remove_phi_output(phi)
>>>>>>          return ;
>>>>>>
>>>>>>      # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>> field F
>>>>>>      # member of the object resulting from `phi`.
>>>>>>      fields_used = collect_fields_used_after_phi(phi)
>>>>>>
>>>>>>      foreach field in fields_used
>>>>>>          producers = {}
>>>>>>
>>>>>>          # Create a list with the last Store for each field
>>>>>> "field" on the
>>>>>>          # scope of each of the Phi input objects.
>>>>>>          foreach o in phi.inputs
>>>>>>              # The function called below might re-use a lot of the
>>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>              producers += last_store_to_o_field(0, field)
>>>>>>          # Create a new phi node whose inputs are the Store's to
>>>>>> 'field'
>>>>>>          field_phi = create_new_phi(producers)
>>>>>>
>>>>>>          update_consumers(field, field_phi)
>>>>>>
>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>> [3] step just
>>>>>> after EA but before the constraint checks in
>>>>>> `adjust_scalar_replaceable_state`
>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>> implementation goes through
>>>>>> the following major phases:
>>>>>>
>>>>>>      1. Identify the Escape Status of objects.
>>>>>>      2. Adjust object Escape and/or Scalar Replacement status
>>>>>> based on a set of constraints.
>>>>>>      3. Make call to Split_unique_types [4].
>>>>>>      4 Iterate over object and array allocations.
>>>>>>          4.1 Check if allocation can be eliminated.
>>>>>>          4.2 Perform scalar replacement. Replace uses of object in
>>>>>> Safepoints.
>>>>>>          4.3 Process users of CheckCastPP other than Safepoint:
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> The transformation that I am proposing would change the overall
>>>>>> flow to look
>>>>>> like this:
>>>>>>
>>>>>>      1. Identify the Escape Status of objects.
>>>>>>      2. ----> New: "Split phi functions" <----
>>>>>>      2. Adjust object Escape and/or Scalar Replacement status
>>>>>> based on a set of constraints.
>>>>>>      3. Make call to Split_unique_types [14].
>>>>>>      4 Iterate over object and array allocations.
>>>>>>          4.1 ----> Moved to split_phi: "Check if allocation can be
>>>>>> eliminated" <----
>>>>>>          4.2 Perform scalar replacement. Replace uses of object in
>>>>>> Safepoints.
>>>>>>          4.3 Process users of CheckCastPP other than Safepoint:
>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>
>>>>>> Please let me know what you think and thank you for taking the
>>>>>> time to review
>>>>>> this!
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Cesar
>>>>>>
>>>>>> Notes:
>>>>>>
>>>>>>      [1] I am not sure yet how this approach will play with the
>>>>>> case of a merge
>>>>>>          with NULL.
>>>>>>      [2]
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fescape.cpp%23L1809&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cf6f03bf26b724150d0e508d9eff1d0bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637804644159660386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=j5KJXWywNe6eNmgD8vDXyhJTPhugsUFvivvocbiwnrE%3D&amp;reserved=0
>>>>>>
>>>>>>
>>>>>>      [3] Another option would be to "patch" the current
>>>>>> implementation to be able
>>>>>>          to handle the merges. I am not certain that the "patch"
>>>>>> approach would be
>>>>>>          better, however, the "pre-process" approach is certainly
>>>>>> much easier to test
>>>>>>          and more readable.
>>>>>>
>>>>>>      [4] I cannot say I understand 100% the effects of executing
>>>>>>          split_unique_types(). Would the transformation that I am
>>>>>> proposing need to
>>>>>>          be after the call to split_unique_types?

From ihse at openjdk.java.net  Wed Feb 16 21:54:09 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 21:54:09 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis [v8]
In-Reply-To: <0tGSY9Iutr4jkP2idAqvi3yM3Qon120-JCD6fGxZobg=.fb6e4549-44e1-42eb-a51b-166c3912c37b@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
 <0tGSY9Iutr4jkP2idAqvi3yM3Qon120-JCD6fGxZobg=.fb6e4549-44e1-42eb-a51b-166c3912c37b@github.com>
Message-ID: <G6ygxtT-4QTB-Yv2fRy7MMkjr483M_8SaRrj8h4yQks=.be0bd661-5e00-4cf1-a376-319f0bbb8e09@github.com>

On Wed, 16 Feb 2022 14:39:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This patch expands the newly added system for hsdis backends to include LLVM.
>> 
>> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
>> 
>> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
>> 
>> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add section on using LLVM
>  - Allow override of LLVM location using --with-llvm

This PR has just gotten too messy. :-( I'll close this one for now, focus on getting the (much simpler) Capstone backend integrated, and then I can come back and revisit this functionality, but in a fresh new PR.

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

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

From ihse at openjdk.java.net  Wed Feb 16 21:54:10 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 21:54:10 GMT
Subject: Withdrawn: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
References: <b3kDRHR4jQJpxNrOl60Y5tZFAXHRoakqwZr75XfLOVc=.1b9be882-f3f5-46ec-99c1-19f801083ca6@github.com>
Message-ID: <h8xE-snG3LGVVsswWAN5NdmArFbB2QRnLCclK6Cz4vA=.9298fe8d-2907-4ef2-abb8-dff18a87c8a5@github.com>

On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This patch expands the newly added system for hsdis backends to include LLVM.
> 
> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.)
> 
> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows.
> 
> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work.

This pull request has been closed without being integrated.

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

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

From joe.darcy at oracle.com  Wed Feb 16 22:20:20 2022
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 16 Feb 2022 14:20:20 -0800
Subject: RFR: 8279508: Auto-vectorize Math.round API [v2]
In-Reply-To: <SKEroM6QsoBV4Btj6kAemSCqqRfHT4mm33Avdy1L8l4=.fcd38193-3821-4573-8bca-300e22f875fe@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <LQMZEAy-QU55kNt5fwFQSI8JPGuYz-nRWhuWVkKMt5c=.e5245c2f-c111-4c3d-829c-db44bca43e47@github.com>
 <2TVKx_BFFyAK2ooOWKpdsEIMFzJngYxlWjbgeZ2y4Mc=.5deb2173-8107-476d-92ca-1835d69ce336@github.com>
 <SKEroM6QsoBV4Btj6kAemSCqqRfHT4mm33Avdy1L8l4=.fcd38193-3821-4573-8bca-300e22f875fe@github.com>
Message-ID: <6e3a21d8-fc16-24b3-ead1-fefb52db9684@oracle.com>


On 2/12/2022 6:55 PM, Jatin Bhateja wrote:
> On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
>
>> The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4
>>
>> The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80).
> Hi @sviswa7 ,
> As per JLS 17 section 15.4 Java follows round to nearest rounding policy for all floating point operations except conversion to integer and remainder where it uses round toward zero.


That is a true background condition, but I will note that the Math.round 
method does independently define the semantics of its operation and 
rounding behavior, which has changed (slightly) over the lifetime of the 
platform.

-Joe



From ihse at openjdk.java.net  Wed Feb 16 22:20:33 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Feb 2022 22:20:33 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis
Message-ID: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>

The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 

This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).

The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

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

Commit messages:
 - Fix whitespace error (thanks, jcheck!)
 - Minor fixes
 - The pandoc-style copyright header looks bad on Github...
 - Turn the README into markdown format. Add documentation on building Capstone.
 - Fix capstone on Windows
 - Add capstone as hsdis backend

Changes: https://git.openjdk.java.net/jdk/pull/7506/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7506&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8188073
  Stats: 517 lines in 9 files changed: 346 ins; 136 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7506.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7506/head:pull/7506

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

From jiefu at openjdk.java.net  Wed Feb 16 23:17:17 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 23:17:17 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is assumed to
 be unique after JDK-8281732
Message-ID: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>

Hi all,

The following tests fail after JDK-8281732.

compiler/gcbarriers/UnsafeIntrinsicsTest.java
gc/metaspace/TestMetaspacePerfCounters.java
gc/shenandoah/TestEvilSyncBug.java
gc/stringdedup/TestStringDeduplicationFullGC.java
gc/stringdedup/TestStringDeduplicationTableResize.java
gc/stringdedup/TestStringDeduplicationYoungGC.java
serviceability/dcmd/gc/HeapDumpCompressedTest.java
jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
jdk/jfr/event/oldobject/TestShenandoah.java
sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
sun/tools/jmap/BasicJMapTest.java
``` 

The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.

Testing:
 - All failing tests passed after this patch

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732

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

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

From kvn at openjdk.java.net  Wed Feb 16 23:26:04 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 23:26:04 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <Mo41yYEMxSLQvLlgNaKQ24v8qKaZdOIVBB-DxNpqkwI=.74364577-e684-4936-adf2-5dd7242d5383@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From jwilhelm at openjdk.java.net  Thu Feb 17 00:23:36 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Feb 2022 00:23:36 GMT
Subject: RFR: Merge jdk18
Message-ID: <Lj5IsZwUEYWGfcfs79ODYaS2VXJTu_wD6XiZGFT4n98=.08904812-c9be-4f98-b893-5b7a33dd8da7@github.com>

Forwardport JDK 18 -> JDK 19

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

Commit messages:
 - Merge
 - 8280415: Remove EA from JDK 18 version string starting with Initial RC promotion B35 on February 10, 2022
 - 8281713: [BACKOUT] AArch64: Implement string_compare intrinsic in SVE

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=7509&range=00.0
 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk&pr=7509&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/7509/files
  Stats: 423 lines in 9 files changed: 0 ins; 412 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7509.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7509/head:pull/7509

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

From jwilhelm at openjdk.java.net  Thu Feb 17 01:17:06 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Feb 2022 01:17:06 GMT
Subject: Integrated: Merge jdk18
In-Reply-To: <Lj5IsZwUEYWGfcfs79ODYaS2VXJTu_wD6XiZGFT4n98=.08904812-c9be-4f98-b893-5b7a33dd8da7@github.com>
References: <Lj5IsZwUEYWGfcfs79ODYaS2VXJTu_wD6XiZGFT4n98=.08904812-c9be-4f98-b893-5b7a33dd8da7@github.com>
Message-ID: <awCe-hAfHidV0mWBaLDzqkDmau_b68GYrr1NrKkxSx4=.15508c8d-76ea-432f-be6d-96a801ff8bdf@github.com>

On Thu, 17 Feb 2022 00:16:02 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 18 -> JDK 19

This pull request has now been integrated.

Changeset: b6e48e67
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6e48e678244481dd45d38bc3ddc325fccda2acc
Stats:     423 lines in 9 files changed: 0 ins; 412 del; 11 mod

Merge

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

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

From xgong at openjdk.java.net  Thu Feb 17 01:46:05 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 17 Feb 2022 01:46:05 GMT
Subject: RFR: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
In-Reply-To: <MEzHoq7tiXr4UKU_9IdrK1QfEu-wfgKn_UO1l2x6GmA=.29038fe0-047c-4747-bdee-615397a8c028@github.com>
References: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
 <MEzHoq7tiXr4UKU_9IdrK1QfEu-wfgKn_UO1l2x6GmA=.29038fe0-047c-4747-bdee-615397a8c028@github.com>
Message-ID: <ooqqZlICynP_7QHin0ATr9CLB7QEeid_C_CV4J-lgRg=.ee3c4c79-bf88-4bfe-abb4-233acb1a978a@github.com>

On Wed, 16 Feb 2022 09:20:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Currently the vector lanewise `NOT` is implemented with `"v.xor(-1)"` and `AND_NOT ` is implemented with `"v1.and(v2.xor(-1))"`. With SVE they can be respectively implemented with `"not/bic"` instructions, and we have already optimized the non-masked operations before (see [1]).
>> 
>> Consider the SVE also supports the `predicated` `"not/bic"`, we can apply the same optimizations for the masked `NOT/AND_NOT` by adding match rules. So this patch adds the rules for the following optimizations:
>> 
>> For `NOT `with int type:
>> 
>>   mov z16.s, #-1
>>   eor z18.s, p0/m, z18.s, z16.s  ==>  not z18.s, p0/m, z18.s
>> 
>> For `AND_NOT `with int type:
>> 
>>   not z16.d, p7/m, z16.d
>>   and z17.s, p0/m, z17.s, z16.s  ==>  bic z17.s, p0/m, z16.s
>> 
>> Here is the performance gain for the `"NOT/AND_NOT"` benchmarks (see [2][3] for byte type) with SVE 512-bit:
>> 
>> Benchmark                    Gain
>> LongMaxVector.NOTMasked      1.005
>> ShortMaxVector.NOTMasked     1.017
>> IntMaxVector.NOTMasked       1.022
>> ByteMaxVector.NOTMasked      1.023
>> LongMaxVector.AND_NOTMasked  1.063
>> IntMaxVector.AND_NOTMasked   1.047
>> ShortMaxVector.AND_NOTMasked 1.059
>> ByteMaxVector.AND_NOTMasked  1.030
>> 
>> [1] https://github.com/openjdk/jdk/pull/3370
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L1963
>> [3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L362
>
> Marked as reviewed by aph (Reviewer).

Thanks for the review @theRealAph !

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

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

From xgong at openjdk.java.net  Thu Feb 17 01:54:41 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 17 Feb 2022 01:54:41 GMT
Subject: RFR: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
 [v2]
In-Reply-To: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
References: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
Message-ID: <cIOv-SwYA9XIQZztJeyGTsB2ZDhX1QSyUMZvpl77OHQ=.76995536-4116-4e8f-af99-4c7e877d31b9@github.com>

> Currently the vector lanewise `NOT` is implemented with `"v.xor(-1)"` and `AND_NOT ` is implemented with `"v1.and(v2.xor(-1))"`. With SVE they can be respectively implemented with `"not/bic"` instructions, and we have already optimized the non-masked operations before (see [1]).
> 
> Consider the SVE also supports the `predicated` `"not/bic"`, we can apply the same optimizations for the masked `NOT/AND_NOT` by adding match rules. So this patch adds the rules for the following optimizations:
> 
> For `NOT `with int type:
> 
>   mov z16.s, #-1
>   eor z18.s, p0/m, z18.s, z16.s  ==>  not z18.s, p0/m, z18.s
> 
> For `AND_NOT `with int type:
> 
>   not z16.d, p7/m, z16.d
>   and z17.s, p0/m, z17.s, z16.s  ==>  bic z17.s, p0/m, z16.s
> 
> Here is the performance gain for the `"NOT/AND_NOT"` benchmarks (see [2][3] for byte type) with SVE 512-bit:
> 
> Benchmark                    Gain
> LongMaxVector.NOTMasked      1.005
> ShortMaxVector.NOTMasked     1.017
> IntMaxVector.NOTMasked       1.022
> ByteMaxVector.NOTMasked      1.023
> LongMaxVector.AND_NOTMasked  1.063
> IntMaxVector.AND_NOTMasked   1.047
> ShortMaxVector.AND_NOTMasked 1.059
> ByteMaxVector.AND_NOTMasked  1.030
> 
> [1] https://github.com/openjdk/jdk/pull/3370
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L1963
> [3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L362

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 two additional commits since the last revision:

 - Merge branch 'jdk:master' into JDK-8281803
 - 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7486/files
  - new: https://git.openjdk.java.net/jdk/pull/7486/files/5475d8f8..ed8a3ccb

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

  Stats: 3109 lines in 69 files changed: 2744 ins; 131 del; 234 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7486.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7486/head:pull/7486

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

From njian at openjdk.java.net  Thu Feb 17 02:23:04 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 17 Feb 2022 02:23:04 GMT
Subject: RFR: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
 [v2]
In-Reply-To: <cIOv-SwYA9XIQZztJeyGTsB2ZDhX1QSyUMZvpl77OHQ=.76995536-4116-4e8f-af99-4c7e877d31b9@github.com>
References: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
 <cIOv-SwYA9XIQZztJeyGTsB2ZDhX1QSyUMZvpl77OHQ=.76995536-4116-4e8f-af99-4c7e877d31b9@github.com>
Message-ID: <OWIGRTIrSSoRJWlGOb2cDQDxFWZDMYUxJS0zIIn3pno=.4c4a921e-0b05-4939-80f0-bd80f12a9e35@github.com>

On Thu, 17 Feb 2022 01:54:41 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Currently the vector lanewise `NOT` is implemented with `"v.xor(-1)"` and `AND_NOT ` is implemented with `"v1.and(v2.xor(-1))"`. With SVE they can be respectively implemented with `"not/bic"` instructions, and we have already optimized the non-masked operations before (see [1]).
>> 
>> Consider the SVE also supports the `predicated` `"not/bic"`, we can apply the same optimizations for the masked `NOT/AND_NOT` by adding match rules. So this patch adds the rules for the following optimizations:
>> 
>> For `NOT `with int type:
>> 
>>   mov z16.s, #-1
>>   eor z18.s, p0/m, z18.s, z16.s  ==>  not z18.s, p0/m, z18.s
>> 
>> For `AND_NOT `with int type:
>> 
>>   not z16.d, p7/m, z16.d
>>   and z17.s, p0/m, z17.s, z16.s  ==>  bic z17.s, p0/m, z16.s
>> 
>> Here is the performance gain for the `"NOT/AND_NOT"` benchmarks (see [2][3] for byte type) with SVE 512-bit:
>> 
>> Benchmark                    Gain
>> LongMaxVector.NOTMasked      1.005
>> ShortMaxVector.NOTMasked     1.017
>> IntMaxVector.NOTMasked       1.022
>> ByteMaxVector.NOTMasked      1.023
>> LongMaxVector.AND_NOTMasked  1.063
>> IntMaxVector.AND_NOTMasked   1.047
>> ShortMaxVector.AND_NOTMasked 1.059
>> ByteMaxVector.AND_NOTMasked  1.030
>> 
>> [1] https://github.com/openjdk/jdk/pull/3370
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L1963
>> [3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L362
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'jdk:master' into JDK-8281803
>  - 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE

Marked as reviewed by njian (Committer).

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

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

From jbhateja at openjdk.java.net  Thu Feb 17 03:44:02 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 17 Feb 2022 03:44:02 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v5]
In-Reply-To: <-NfiIwcnrf7TRNxA9x1d9itPvKYgeCYogpjSZgGYtvc=.15346702-2db7-4295-8e5a-a4864f3bbdbd@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <-NfiIwcnrf7TRNxA9x1d9itPvKYgeCYogpjSZgGYtvc=.15346702-2db7-4295-8e5a-a4864f3bbdbd@github.com>
Message-ID: <U34qdWMWGuoYbavOIDlL5aJQhEnWyp8PKTcMPJ-bGmY=.6e12fd50-0b81-4b22-8e65-ccc065bfe6ee@github.com>

On Wed, 16 Feb 2022 12:30:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 584.99 | 1870.70 | 3.20 | 510.35 | 548.60 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 257.17 | 965.33 | 3.75 | 293.60 | 273.15 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.69 | 3592.54 | 4.35 | 825.32 | 1836.42 | 2.23
>> FpRoundingBenchmark.test_round_float | 2048.00 | 388.55 | 1895.77 | 4.88 | 412.31 | 945.82 | 2.29
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8279508: Adding few descriptive comments.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Replacing by efficient instruction sequence based on MXCSR.RC mode.
>  - 8279508: Adding vectorized algorithms to match the semantics of rounding operations.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Adding a test for scalar intrinsification.
>  - 8279508: Auto-vectorize Math.round API

> _Mailing list message from [Joseph D. Darcy](mailto:joe.darcy at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_
> 
> On 2/12/2022 6:55 PM, Jatin Bhateja wrote:
> 
> > On Fri, 21 Jan 2022 00:49:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
> > > The JVM currently initializes the x86 mxcsr to round to nearest even, see below in stubGenerator_x86_64.cpp: // Round to nearest (even), 64-bit mode, exceptions masked StubRoutines::x86::_mxcsr_std = 0x1F80; The above works for Math.rint which is specified to be round to nearest even. Please see: https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html : section 4.8.4
> > > The rounding mode needed for Math.round is round to positive infinity which needs a different x86 mxcsr initialization(0x5F80).
> > > Hi @sviswa7 ,
> > > As per JLS 17 section 15.4 Java follows round to nearest rounding policy for all floating point operations except conversion to integer and remainder where it uses round toward zero.
> 
> That is a true background condition, but I will note that the Math.round method does independently define the semantics of its operation and rounding behavior, which has changed (slightly) over the lifetime of the platform.
> 
> -Joe

Hi @jddarcy , Thanks for your comments, patch has been updated to follow the prescribed semantics  of Math.round API.

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

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

From xgong at openjdk.java.net  Thu Feb 17 05:09:04 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 17 Feb 2022 05:09:04 GMT
Subject: RFR: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
 [v2]
In-Reply-To: <OWIGRTIrSSoRJWlGOb2cDQDxFWZDMYUxJS0zIIn3pno=.4c4a921e-0b05-4939-80f0-bd80f12a9e35@github.com>
References: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
 <cIOv-SwYA9XIQZztJeyGTsB2ZDhX1QSyUMZvpl77OHQ=.76995536-4116-4e8f-af99-4c7e877d31b9@github.com>
 <OWIGRTIrSSoRJWlGOb2cDQDxFWZDMYUxJS0zIIn3pno=.4c4a921e-0b05-4939-80f0-bd80f12a9e35@github.com>
Message-ID: <0LHbIY5j7D7-b3Plmas24dhhT0gZVG5i8r3Qy3RnaN8=.b33b5ebc-334b-404a-aa3c-d03c62b280b7@github.com>

On Thu, 17 Feb 2022 02:19:32 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'jdk:master' into JDK-8281803
>>  - 8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE
>
> Marked as reviewed by njian (Committer).

Thanks for the review @nsjian !

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

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

From xgong at openjdk.java.net  Thu Feb 17 05:48:06 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 17 Feb 2022 05:48:06 GMT
Subject: Integrated: 8281803: AArch64: Optimize masked vector NOT/AND_NOT for
 SVE
In-Reply-To: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
References: <qzes-kbZSAHwtmaaOnTOovxI9AXxwRJjpKeiG9si1iQ=.9f8b51fb-ff29-4ed1-9ecc-de6e67f91106@github.com>
Message-ID: <bHQL7lMu1ovD1X2YB7xpRfJESryrgMZLGaXPMw-V24k=.0557805a-5e75-4674-b735-6e01a01d5341@github.com>

On Wed, 16 Feb 2022 02:21:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently the vector lanewise `NOT` is implemented with `"v.xor(-1)"` and `AND_NOT ` is implemented with `"v1.and(v2.xor(-1))"`. With SVE they can be respectively implemented with `"not/bic"` instructions, and we have already optimized the non-masked operations before (see [1]).
> 
> Consider the SVE also supports the `predicated` `"not/bic"`, we can apply the same optimizations for the masked `NOT/AND_NOT` by adding match rules. So this patch adds the rules for the following optimizations:
> 
> For `NOT `with int type:
> 
>   mov z16.s, #-1
>   eor z18.s, p0/m, z18.s, z16.s  ==>  not z18.s, p0/m, z18.s
> 
> For `AND_NOT `with int type:
> 
>   not z16.d, p7/m, z16.d
>   and z17.s, p0/m, z17.s, z16.s  ==>  bic z17.s, p0/m, z16.s
> 
> Here is the performance gain for the `"NOT/AND_NOT"` benchmarks (see [2][3] for byte type) with SVE 512-bit:
> 
> Benchmark                    Gain
> LongMaxVector.NOTMasked      1.005
> ShortMaxVector.NOTMasked     1.017
> IntMaxVector.NOTMasked       1.022
> ByteMaxVector.NOTMasked      1.023
> LongMaxVector.AND_NOTMasked  1.063
> IntMaxVector.AND_NOTMasked   1.047
> ShortMaxVector.AND_NOTMasked 1.059
> ByteMaxVector.AND_NOTMasked  1.030
> 
> [1] https://github.com/openjdk/jdk/pull/3370
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L1963
> [3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/ByteMaxVector.java#L362

This pull request has now been integrated.

Changeset: 1eec16b4
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1eec16b47be300e1462528bddf5d0686df3f042c
Stats:     198 lines in 5 files changed: 116 ins; 0 del; 82 mod

8281803: AArch64: Optimize masked vector NOT/AND_NOT for SVE

Reviewed-by: aph, njian

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

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

From jbhateja at openjdk.java.net  Thu Feb 17 07:19:46 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 17 Feb 2022 07:19:46 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v4]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <TpD60Im1RuB2ZOu0jbFUASIIyRe0-0B5wYUXmuvlWqo=.b9f958b1-0298-42e0-a40c-0bfbdae5af2e@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8281375: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/6f390f61..b4257341

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

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

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

From jbhateja at openjdk.java.net  Thu Feb 17 07:19:48 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 17 Feb 2022 07:19:48 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v3]
In-Reply-To: <vrMLiAJq4z50BJQynjid5x-xyk32W6XcLnSJZVjSfb0=.ff4e002b-dd0d-4ada-a5d7-7b71ef692b51@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <giQvPrCTzkj6LpFpTkrFzqFGCj5rAuAiR_rI0yWyHY0=.466d1488-4455-4dfa-9b41-bd8a495dfe13@github.com>
 <vrMLiAJq4z50BJQynjid5x-xyk32W6XcLnSJZVjSfb0=.ff4e002b-dd0d-4ada-a5d7-7b71ef692b51@github.com>
Message-ID: <n_sdJMfZETENpNDub_cLQ0quq0cqjLfqOtbWIWAl3-0=.49464701-0214-4fb5-a285-1c7cbde92ba4@github.com>

On Tue, 15 Feb 2022 21:49:54 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resoultion.
>
> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 4031:
> 
>> 4029:     StubRoutines::x86::_vector_iota_indices = generate_iota_indices("iota_indices");
>> 4030: 
>> 4031:     if (VM_Version::supports_avx2() && UsePopCountInstruction) {
> 
> Do we need it if VM_Version::supports_avx512_vpopcntdq()?

DONE

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

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

From shade at openjdk.java.net  Thu Feb 17 07:21:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 17 Feb 2022 07:21:08 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines
In-Reply-To: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
Message-ID: <wgKYZ7TLHJTpT9crOfaQ6N4x5_Ku0esmhpVFqYxugas=.9ee78dbe-42a8-4c2f-8c1c-7c7f9b880c7c@github.com>

On Wed, 16 Feb 2022 02:13:03 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all, 
> 
> compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
> The fix just increasing the stub size for AVX512 platforms.
> 
> Testing:
>   - tier1~3 on Linux/x64 with AVX512, no regression
> 
> Thanks.
> Best regards,
> Jie

As far as I can see, `RuntimeStub::new_runtime_stub` copies the `CodeBuffer` up to the actual size. So, there is no actual need to make the increase from `1000` to `1200` optional, as it would be cut down to size on `UseAVX <= 2` case anyway? We can just bump it to `1200`. @vnkozlov might have an opinion here.

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

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

From thartmann at openjdk.java.net  Thu Feb 17 07:35:13 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 17 Feb 2022 07:35:13 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <b-lB7PP0iFWpWhmIdglFuT3XbB0QVSCXxZohcgWdTJw=.743071de-8886-41cf-b299-1e3052552d0d@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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

From shade at openjdk.java.net  Thu Feb 17 07:44:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 17 Feb 2022 07:44:10 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines
In-Reply-To: <mNtxLHObz2Lzv7n3woe8Mz-ZkySl9Cj8ZoXDC0-_Wxc=.f7137650-6278-4f49-ad4c-4bbb9a794bf1@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <wgKYZ7TLHJTpT9crOfaQ6N4x5_Ku0esmhpVFqYxugas=.9ee78dbe-42a8-4c2f-8c1c-7c7f9b880c7c@github.com>
 <mNtxLHObz2Lzv7n3woe8Mz-ZkySl9Cj8ZoXDC0-_Wxc=.f7137650-6278-4f49-ad4c-4bbb9a794bf1@github.com>
Message-ID: <h9BaN_McUvaBX84EGHm6ou0ZZiAMyKrjGsaN5GV23Vk=.bc5eb305-acc3-4e26-9088-0d58c122255c@github.com>

On Thu, 17 Feb 2022 07:40:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > So, there is no actual need to make the increase from `1000` to `1200` optional, as it would be cut down to size on `UseAVX <= 2` case anyway?
> 
> More code buffer is required for AVX3 since we have more registers (e.g., 512-bit registers) to be stored/restored.

Yes, I understand. I am saying that we probably don't need to protect it with `UseAVX`, and can just bump to `1200` unconditionally, seeing how the stub would be copied out of the buffer anyway.

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

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

From jiefu at openjdk.java.net  Thu Feb 17 07:44:10 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 07:44:10 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines
In-Reply-To: <wgKYZ7TLHJTpT9crOfaQ6N4x5_Ku0esmhpVFqYxugas=.9ee78dbe-42a8-4c2f-8c1c-7c7f9b880c7c@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <wgKYZ7TLHJTpT9crOfaQ6N4x5_Ku0esmhpVFqYxugas=.9ee78dbe-42a8-4c2f-8c1c-7c7f9b880c7c@github.com>
Message-ID: <mNtxLHObz2Lzv7n3woe8Mz-ZkySl9Cj8ZoXDC0-_Wxc=.f7137650-6278-4f49-ad4c-4bbb9a794bf1@github.com>

On Thu, 17 Feb 2022 07:18:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> So, there is no actual need to make the increase from `1000` to `1200` optional, as it would be cut down to size on `UseAVX <= 2` case anyway?

More code buffer is required for AVX3 since we have more registers (e.g., 512-bit registers) to be stored/restored.

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

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

From chagedorn at openjdk.java.net  Thu Feb 17 07:51:12 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 17 Feb 2022 07:51:12 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <0wCWILIHTgSlt6XRlmnB17FA8kikE_CT8lkRe-YaFOQ=.0c69c785-588e-466f-84d4-5024a24f13d5@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7508

From jiefu at openjdk.java.net  Thu Feb 17 08:16:38 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 08:16:38 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
Message-ID: <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>

> Hi all, 
> 
> compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
> The fix just increasing the stub size for AVX512 platforms.
> 
> Testing:
>   - tier1~3 on Linux/x64 with AVX512, no regression
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7485/files
  - new: https://git.openjdk.java.net/jdk/pull/7485/files/03cd0459..b876cb99

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7485&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7485&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7485.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7485/head:pull/7485

PR: https://git.openjdk.java.net/jdk/pull/7485

From jiefu at openjdk.java.net  Thu Feb 17 08:16:39 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 08:16:39 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <h9BaN_McUvaBX84EGHm6ou0ZZiAMyKrjGsaN5GV23Vk=.bc5eb305-acc3-4e26-9088-0d58c122255c@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <wgKYZ7TLHJTpT9crOfaQ6N4x5_Ku0esmhpVFqYxugas=.9ee78dbe-42a8-4c2f-8c1c-7c7f9b880c7c@github.com>
 <mNtxLHObz2Lzv7n3woe8Mz-ZkySl9Cj8ZoXDC0-_Wxc=.f7137650-6278-4f49-ad4c-4bbb9a794bf1@github.com>
 <h9BaN_McUvaBX84EGHm6ou0ZZiAMyKrjGsaN5GV23Vk=.bc5eb305-acc3-4e26-9088-0d58c122255c@github.com>
Message-ID: <WQSUm3s52asTDb2gdD_DZVusP2XeKYQX5dSlE_68UmI=.00b6ed26-f96b-4576-8de0-151a5908802a@github.com>

On Thu, 17 Feb 2022 07:42:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am saying that we probably don't need to protect it with `UseAVX`, and can just bump to `1200` unconditionally, seeing how the stub would be copied out of the buffer anyway.

You're right.
Got it and updated.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7485

From rcastanedalo at openjdk.java.net  Thu Feb 17 08:32:05 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 17 Feb 2022 08:32:05 GMT
Subject: RFR: 8279068: IGV: Update to work with JDK 16 and 17
In-Reply-To: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
References: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
Message-ID: <dKwa5ElrY8LE3yVli-RSaM1lb5I5fPsXX9H_iHXtTC0=.3628dcb5-9802-435f-98ce-2cab13fab5ed@github.com>

On Fri, 4 Feb 2022 12:30:52 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.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.
> 
> #### Testing
> 
> Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):
> 
> - 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
> - export graph as PDF
> - 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)
> 
> Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".
> 
> Thanks to Jesper Wilhelmsson for helping with testing on macOS.

Thanks for reviewing, Vladimir and Nils!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7347

From rwestrel at redhat.com  Thu Feb 17 08:43:47 2022
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 17 Feb 2022 09:43:47 +0100
Subject: A question about the patching instruction order of
 CompiledIC::internal_set_ic_destination
In-Reply-To: <5722aef9-b62e-4f3c-add3-5d7feafa4d1d.denghui.ddh@alibaba-inc.com>
References: <5722aef9-b62e-4f3c-add3-5d7feafa4d1d.denghui.ddh@alibaba-inc.com>
Message-ID: <87r181dgsc.fsf@redhat.com>


> I have a question about the patching order in CompiledIC::internal_set_ic_destination.
>
> If I understand correctly, the current implementation patches the CALL instruction first and then the MOV instruction.
>
> My question is why don't patch the MOV instruction first?
>
> Suppose an inline cache is in the transition from Clean to Monomorphic state, and the CALL instruction is patched already, but
> the MOV instruction is not. If another thread executes to this call site, the guard of the callee UEP will be failed and forward to _ic_miss_blob.

My recollection of this (but I haven't looked in a while) is that when
the call site requires the mov and the call to be patched, which as
you're saying can't be done atomically, a new out of line buffer is
created (an icstub I think it's called) where the mov, call sequence is
inserted. Then the call in the nmethod is patched to jump to the
stub. This way there's no atomicity issue. Then on a safepoint, when
there's a guarantee that no thread executes the call site, the call site
in the nmethod is patched again but this time it's the ic stub content
that's moved into the nmethod. Then the icstub can be discarded and
there's no extra jump from the call site to the callee.

Roland.


From chagedorn at openjdk.java.net  Thu Feb 17 08:47:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 17 Feb 2022 08:47:10 GMT
Subject: RFR: 8279068: IGV: Update to work with JDK 16 and 17
In-Reply-To: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
References: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
Message-ID: <3PJAU7QQPfeThjlgTXkGAurezc9wMyOobhBisMxsrgM=.a614dd5f-9134-4db6-b549-0051bace6e76@github.com>

On Fri, 4 Feb 2022 12:30:52 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.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.
> 
> #### Testing
> 
> Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):
> 
> - 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
> - export graph as PDF
> - 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)
> 
> Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".
> 
> Thanks to Jesper Wilhelmsson for helping with testing on macOS.

Nice update!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7347

From shade at openjdk.java.net  Thu Feb 17 09:00:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 17 Feb 2022 09:00:10 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
Message-ID: <O8DxAqgc-5wqxdbnvlDUPJvXOiQp6uZGBf6e_MTGwBA=.b905ff07-9289-47c1-9c98-994cb414c8d4@github.com>

On Thu, 17 Feb 2022 08:16:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all, 
>> 
>> compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
>> The fix just increasing the stub size for AVX512 platforms.
>> 
>> Testing:
>>   - tier1~3 on Linux/x64 with AVX512, no regression
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

This looks good to me. Let @vnkozlov ack this too.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7485

From rcastanedalo at openjdk.java.net  Thu Feb 17 09:26:03 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 17 Feb 2022 09:26:03 GMT
Subject: RFR: 8279068: IGV: Update to work with JDK 16 and 17
In-Reply-To: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
References: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
Message-ID: <v3RykWdWZONiUTg_UrLWAUkzSRbJdGzlmwZVSrQiqig=.9c7c8944-414c-446a-8316-986b5121f851@github.com>

On Fri, 4 Feb 2022 12:30:52 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.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.
> 
> #### Testing
> 
> Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):
> 
> - 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
> - export graph as PDF
> - 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)
> 
> Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".
> 
> Thanks to Jesper Wilhelmsson for helping with testing on macOS.

Thanks, Christian!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7347

From yzheng at openjdk.java.net  Thu Feb 17 09:55:21 2022
From: yzheng at openjdk.java.net (Yudi Zheng)
Date: Thu, 17 Feb 2022 09:55:21 GMT
Subject: RFR: 8282044: [JVMCI] Export _sha3_implCompress,
 _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.
Message-ID: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>

This PR allows JVMCI compiler to reuse _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs.

-------------

Commit messages:
 - Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI.

Changes: https://git.openjdk.java.net/jdk/pull/7511/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7511&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282044
  Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7511.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7511/head:pull/7511

PR: https://git.openjdk.java.net/jdk/pull/7511

From roland at openjdk.java.net  Thu Feb 17 10:08:42 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 17 Feb 2022 10:08:42 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway
Message-ID: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>

I noticed that if loop strip mining fails because a safepoint is not
found right above the exit test (following partial peel for instance),
all safepoints are removed from the loop anyway. That's fixed by the
change in IdealLoopTree::counted_loop() where rather than test if loop
strip mining is enabled, the check now verifies that loop strip mining
was successful.

With that change,
compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
is not converted into a strip mined loop because there's no safepoint
above the exit test after partial peeling. The loop strip mining logic
is too strict when it comes to the safepoint location. Any safepoint
that dominates the exit and is in the loop as long as there's no side
effect between the safepoint and the exit can be used. The patch
implements that change as well. TestAutoVectorization2DArray.java
passes as a result.

The existing requirement to have no safepoint on the backedge is too
strict as well. If the loop has another safepoint that can be used for
strip mining, then the safepoint on the backedge can safely be
dropped. That's also implemented by the patch.

-------------

Commit messages:
 - whitespaces
 - fix & test

Changes: https://git.openjdk.java.net/jdk/pull/7513/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7513&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282045
  Stats: 193 lines in 3 files changed: 166 ins; 24 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7513/head:pull/7513

PR: https://git.openjdk.java.net/jdk/pull/7513

From yzheng at openjdk.java.net  Thu Feb 17 10:42:41 2022
From: yzheng at openjdk.java.net (Yudi Zheng)
Date: Thu, 17 Feb 2022 10:42:41 GMT
Subject: RFR: 8282044: [JVMCI] Export _sha3_implCompress,
 _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. [v2]
In-Reply-To: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
References: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
Message-ID: <0nhaF5NyQvt_EQ_TToc9jEpoe1e2MUO9DRSwZdFS-I8=.83647ae4-a06e-4e1e-93ae-2fa54f358b97@github.com>

> This PR allows JVMCI compiler to reuse _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs.

Yudi Zheng 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:

  Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7511/files
  - new: https://git.openjdk.java.net/jdk/pull/7511/files/e4fffaee..f5381932

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7511&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7511&range=00-01

  Stats: 8 lines in 1 file changed: 3 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7511.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7511/head:pull/7511

PR: https://git.openjdk.java.net/jdk/pull/7511

From denghui.ddh at alibaba-inc.com  Thu Feb 17 11:19:16 2022
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Thu, 17 Feb 2022 19:19:16 +0800
Subject: =?UTF-8?B?UmU6IEEgcXVlc3Rpb24gYWJvdXQgdGhlIHBhdGNoaW5nIGluc3RydWN0aW9uIG9yZGVyIG9m?=
 =?UTF-8?B?IENvbXBpbGVkSUM6OmludGVybmFsX3NldF9pY19kZXN0aW5hdGlvbg==?=
In-Reply-To: <87r181dgsc.fsf@redhat.com>
References: <5722aef9-b62e-4f3c-add3-5d7feafa4d1d.denghui.ddh@alibaba-inc.com>,
 <87r181dgsc.fsf@redhat.com>
Message-ID: <4257cb43-2a00-4304-a426-a0b7c815d38a.denghui.ddh@alibaba-inc.com>

Hi Roland,

Thanks for your explanation.

For CompiledIC::set_to_monomorphic and the callee is a compiled code, icstub is created when the context is not safe.

```
    bool safe = SafepointSynchronize::is_at_safepoint() ||
                (!is_in_transition_state() && (info.is_optimized() || static_bound || is_clean()));

```

If the call site is clean, the patching action directly occurs without creating an icstub. In this case, if we patch the call instruction first, it could cause the cache mismatched situation I mentioned in the first email



Thanks,
Denghui
------------------------------------------------------------------
From:Roland Westrelin <rwestrel at redhat.com>
Send Time:2022?2?17?(???) 16:43
To:???(??) <denghui.ddh at alibaba-inc.com>; hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>
Subject:Re: A question about the patching instruction order of CompiledIC::internal_set_ic_destination


> I have a question about the patching order in CompiledIC::internal_set_ic_destination.
>
> If I understand correctly, the current implementation patches the CALL instruction first and then the MOV instruction.
>
> My question is why don't patch the MOV instruction first?
>
> Suppose an inline cache is in the transition from Clean to Monomorphic state, and the CALL instruction is patched already, but
> the MOV instruction is not. If another thread executes to this call site, the guard of the callee UEP will be failed and forward to _ic_miss_blob.

My recollection of this (but I haven't looked in a while) is that when
the call site requires the mov and the call to be patched, which as
you're saying can't be done atomically, a new out of line buffer is
created (an icstub I think it's called) where the mov, call sequence is
inserted. Then the call in the nmethod is patched to jump to the
stub. This way there's no atomicity issue. Then on a safepoint, when
there's a guarantee that no thread executes the call site, the call site
in the nmethod is patched again but this time it's the ic stub content
that's moved into the nmethod. Then the icstub can be discarded and
there's no extra jump from the call site to the callee.

Roland.

From rwestrel at redhat.com  Thu Feb 17 12:09:40 2022
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 17 Feb 2022 13:09:40 +0100
Subject: A question about the patching instruction order of
 CompiledIC::internal_set_ic_destination
In-Reply-To: <4257cb43-2a00-4304-a426-a0b7c815d38a.denghui.ddh@alibaba-inc.com>
References: <5722aef9-b62e-4f3c-add3-5d7feafa4d1d.denghui.ddh@alibaba-inc.com>
 <87r181dgsc.fsf@redhat.com>
 <4257cb43-2a00-4304-a426-a0b7c815d38a.denghui.ddh@alibaba-inc.com>
Message-ID: <87iltdd797.fsf@redhat.com>


> For CompiledIC::set_to_monomorphic and the callee is a compiled code, icstub is created when the context is not safe.
>
> ```
>     bool safe = SafepointSynchronize::is_at_safepoint() ||
>                 (!is_in_transition_state() && (info.is_optimized() || static_bound || is_clean()));
>
> ```
>
> If the call site is clean, the patching action directly occurs without creating an icstub. In this case, if we patch the call instruction first, it could cause the cache mismatched situation I mentioned in the first email

MAybe the call to SharedRuntime::handle_wrong_method_ic_miss() that
could happen in this case is harmless (that is it detects that there's
nothing to do).

Roland.


From dchuyko at openjdk.java.net  Thu Feb 17 14:05:19 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Thu, 17 Feb 2022 14:05:19 GMT
Subject: RFR: 8282049: AArch64: Use ZR for integer zero immediate volatile
 stores
Message-ID: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>

Rules and encodings for volatile stores of immediate zero byte, char, int, long and pointers were added in aarch64.ad. E.g. storeimmN0_volatile() and aarch64_enc_stlrw0(). They use stlr instructions with ZR similar to what is already done for non-volatile zero stores and str instructions.

So for example

mov x13, xzr
stlr x13, [x11]

turns into

stlr xzr [x11]

There's no direct effect in dedicated micro-benchmarks on N1 but 1 register and 1 instruction are saved.

Testing: jtreg tier1, tier2, applications/jcstress on bare metal Graviton 2.

-------------

Commit messages:
 - Added rules for stlr zr, mem

Changes: https://git.openjdk.java.net/jdk/pull/7515/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7515&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282049
  Stats: 91 lines in 1 file changed: 91 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7515.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7515/head:pull/7515

PR: https://git.openjdk.java.net/jdk/pull/7515

From rcastanedalo at openjdk.java.net  Thu Feb 17 14:17:33 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 17 Feb 2022 14:17:33 GMT
Subject: RFR: 8280568: IGV: Phi inputs and pinned nodes are not scheduled
 correctly
Message-ID: <-iYiPRIR5iUEQyHWbTW0j2wwWjPS7YSfsp_ikHPAW54=.fa427507-e74d-4cfa-bd49-8dc7c935346c@github.com>

This change improves the accuracy of IGV's schedule approximation algorithm w.r.t. C2 in two ways:

1. Scheduling each node N pinned to a control node R in:

   1a. the same block as R, if R is a "regular" control node such as `Region` or `Proj`. For example (N = `168 LoadP`, R = `75 Proj`):

   <p align="center">
   <img src="https://user-images.githubusercontent.com/8792647/154474596-ad326ad0-e127-4529-9837-6427c0a17314.png" width="50%">
   </p>

   or

   1b. R's successor block S, if R is a block projection node (such as `IfTrue` or `CatchProj`). For example (N = `92 LoadN`, R = `29 IfTrue`, S = `B4`):

   <p align="center">
   <img src="https://user-images.githubusercontent.com/8792647/154476147-4d53e2d9-db19-4449-bd79-053e6380cf4d.png" width="45%">
   </p>

   In the special case S has multiple predecessors (i.e. (R, S) form a critical edge), N is scheduled into a critical-edge-splitting block between R and S. For example (N = `135 ClearArray`, R = `151 IfTrue`, S=`B5` in _(before)_ and `B8` in _(after)_, and `B5` is the new critical-edge-splitting block in _(after)_):

   <p align="center">
   <img src="https://user-images.githubusercontent.com/8792647/154487037-24d3f147-b592-484a-bdf2-e93c3bec053c.png" width="90%">
   </p>

   Note that in _(after)_, B5 is a predecessor of B8. This can be seen in the CFG view, but is not obvious in the sea-of-nodes graph view, due to the lack of control nodes in the blocks such as B5 created by critical-edge splitting.

2. Scheduling each node N that is input to a `Phi` node P in a block that dominates P's corresponding predecessor block B. For example (N = `36 ConvI2L`, P = `33 Phi`, B = `B2`):

   <p align="center">
   <img src="https://user-images.githubusercontent.com/8792647/154479876-1e2ae61a-a9a9-453f-b031-55d5dce17ce7.png" width="55%">
   </p>

The combined effect of these scheduling improvements can be seen in the subgraph below, that illustrates cases 1b (where a critical edge must be split) and 2. In _(before)_, `135 ClearArray` is both input to a phi node `91 Phi` and pinned to a block projection `151 IfTrue` on a critical edge (B7, B5), hence (_after_) a new critical-edge-splitting block B5 is created in which `135 ClearArray` and the rest of nodes pinned to `151 IfTrue` are scheduled:
 
   <img src="https://user-images.githubusercontent.com/8792647/154481964-37d5c8a1-4243-49eb-a127-5a53f5ef0abb.png" width="95%">

Additionally, the change introduces checks on graph invariants that are assumed by scheduling approximation (e.g. each block projection has a single control successor), warning the IGV user about possible issues in the schedule if these invariants are broken. Emitting warnings and gracefully degrading the approximated schedule is preferred to just failing since one of IGV's main use cases is debugging graphs which might be ill-formed.

These changes increase the overhead of scheduling large graphs by about 10-20%, however there are opportunities for speeding up scheduling by about an order of magnitude (see [JDK-8282043](https://bugs.openjdk.java.net/browse/JDK-8282043)) that would more than compensate for this overhead.

#### Testing

- Tested manually that the phi inputs and pinned nodes are scheduled correctly for a few selected graphs (included the reported one).
- Tested automatically that scheduling tens of thousands of graphs does not trigger any assertion failure (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`) and does not warn with the message "inaccurate schedule: (...) are phi inputs but do not dominate the phi's input block.".

-------------

Commit messages:
 - Structure error reporting
 - Recompute dominator info for final checks, as this is invalidated by block renaming
 - Rename all blocks as a last step, to accomodate new blocks
 - Schedule nodes pinned to critical-edge projections in edge-splitting blocks
 - Make scheduling warning messages more readable
 - Sink nodes pinned to block projections when possible
 - Fix warning message
 - Schedule reachable pinned nodes before general scheduling
 - Move phi inputs above their source blocks and check schedule consistency

Changes: https://git.openjdk.java.net/jdk/pull/7493/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7493&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280568
  Stats: 402 lines in 3 files changed: 361 ins; 27 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7493/head:pull/7493

PR: https://git.openjdk.java.net/jdk/pull/7493

From erikj at openjdk.java.net  Thu Feb 17 14:19:06 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 17 Feb 2022 14:19:06 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis
In-Reply-To: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
Message-ID: <X-c1F8n3rLyKzCQ9ydgOI-PjonSQ-DirPAmZXFSMCU4=.e816cdad-7b93-4484-bc1b-8bd0f0e50f12@github.com>

On Wed, 16 Feb 2022 21:55:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
> 
> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
> 
> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

One style nit.

make/Hsdis.gmk line 157:

> 155: 
> 156: $(INSTALLED_HSDIS): $(BUILD_HSDIS_TARGET)
> 157: ifeq ($(HSDIS_BACKEND), binutils)

Don't we usually indent conditionals to the recipe level using spaces?

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7506

From vladimir.x.ivanov at oracle.com  Thu Feb 17 15:00:45 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 17 Feb 2022 18:00:45 +0300
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <DM6PR21MB14843A95A8E3B021634214789A359@DM6PR21MB1484.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <DM6PR21MB14843A95A8E3B021634214789A359@DM6PR21MB1484.namprd21.prod.outlook.com>
Message-ID: <97d84b3f-a3e0-ee9b-8d09-9972f0715e2a@oracle.com>

Hi Cesar,

> We start of with this:
> 
> static int testPolluted(int r, boolean b) {
>      A obj1 = new A(r);
>      A obj2 = new A(r);
> 
>      A obj = (b ? obj1 : obj2);
>      for (int i = 1; i < r; i++) {
>          obj.i++;
>      }
> 
>      return obj1.i + obj2.i;
> }
> 
> And then we cluster interfering allocations together in disjoint clusters. Two
> questions on this point:
> 
> 1) What exactly grouping the allocations in clusters helps? I believe when you
> say it'll help, I'm just trying to understand what exactly how.

It enables split_unique_types() to introduce dedicated memory slices for 
fields of allocated objects (a pre-requisite for scalarization step). 
When there are memory accesses with indeterminate base, it's illegal to 
introduce memory slices for a particular allocation, because they will 
interfere with existing slices.

But when you process the whole interfering cluster of allocations at 
once, then it's correct to introduce new slices for the whole cluster.
You know all the interactions happen between allocations inside the 
cluster and associate new slices with them.

> 2) To create the allocation clusters is it sufficient to simply put together
> allocations that merge at Phi's (including transitive merges) or we'll need
> something more complex?

Yes, you need to enumerate all possible base values for all accesses 
operating on bases from the cluster (construct a transitive closure).

> 
> After we create the clusters we'll then run a few transformations, including
> splitting memory accesses through Phis. This would transform the example above
> into something like this:

I think the order should be reversed. Do split_unique_types() first to 
get rid of any non-essential interference from unrelated memory 
operations. Then optimize constructed memory graph trying to untangle 
individual allocations from each other.

Best regards,
Vladimir Ivanov

> static int testUnqiue(int r, boolean b) {
>      A obj1 = new A(r);
>      A obj2 = new A(r);
> 
>      for (int i = 1; i < r; i++) {
>          if (b) {
>              obj1.i++;
>          } else {
>              obj2.i++;
>          }
>      }
>      return obj1.i + obj2.i;
> }
> 
> Next we'll run "split_unique_types" and do scalar replacement as we do today and
> eventually we should have something like this:
> 
> static int testUnqiue(int r, boolean b) {
>      int i1 = r;
>      int i2 = r;
> 
>      for (int i = 1; i < r; i++) {
>          if (b) {
>              i1++;
>          } else {
>              i2++;
>          }
>      }
> 
>      return i1 + i2;
> }
> 
> 
> Thanks,
> Cesar
> 
> 
> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 14, 2022 11:39 AM
> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> 
> 
>> Once memory graph for unique alias is separated, it should be much
>> simpler to further optimize it. If all memory operations are folded, the
>> allocation can go away.
>>
>> Splitting memory operations through phis should help untangle the
>> allocations. So, even if one allocation can't be fully scalarized, it
>> shouldn't keep other allocations from being scalarized (unless they alias).
>>
>> I don't have a good understanding how new logic will interact with
>> unique instance slices & _instance_id. Maybe a gradual transition from
>> original graph to clustered slices to unique instance slices.
> 
> I took a closer look at a slightly more complicated example:
> 
>       class A {
>           int i;
>           A(int i) { this.i = i; }
>       }
> 
>       static int testPolluted(int r, boolean b) {
>           A obj1 = new A(r);
>           A obj2 = new A(r);
> 
>           A obj = (b ? obj1 : obj2);
>           for (int i = 1; i < r; i++) {
>               obj.i++;
>           }
> 
>           return obj1.i + obj2.i;
>       }
> 
> There are 3 interacting memory slices: obj1.i, obj2.i, and obj.i (which
> alias with obj1.i and obj2.i).
> 
> Unless the access inside the loop is eliminated, there's no way to
> untangle the memory graphs for obj1.i and obj2.i and scalarize allocations.
> 
> In this particular case, it's quite straightforward to untangle the
> graphs for instance types (and make both obj1 and obj2 scalarizable):
> 
>       static int testUnqiue(int r, boolean b) {
>           A obj1 = new A(r);
>           A obj2 = new A(r);
> 
>           for (int i = 1; i < r; i++) {
>               if (b) {
>                   obj1.i++;
>               } else {
>                   obj2.i++;
>               }
>           }
>           return obj1.i + obj2.i;
>       }
> 
> But depending on the actual shape of the base pointer (here it's
> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
> or even impossible (e.g., for complex loop variant conditions) to
> separate instance slices.
> 
> So, gradual approach seems the way to go:
>     (1) split memory graph for clusters of interacting non-escaping
> allocations;
> 
>     (2) perform adhoc transformation targeted at untangling aliasing
> accesses (e.g, split-through-phi);
> 
>     (3) extract unique instance types where possible, thus making the
> corresponding allocation scalar replaceable
> 
> =====================================================================
> 
> Also, one observation: interacting allocations don't have to be of the
> same class.
> 
>       static int testPolluted(int r, boolean b) {
>           A obj1 = new B1(r);
>           A obj2 = new B2(r);
> 
>           A obj = (b ? obj1 : obj2);
>           for (int i = 1; i < r; i++) {
>               obj.i++;
>           }
> 
>           return obj1.i + obj2.i;
>       }
> 
> Requiring unique instance types to perform SR (and not enhancing SR to
> handle aliasing allocations case) helps avoid some challenges in
> instance rematerialization logic at safepoints, because actual shape of
> the scalarized object (its class and exact set of fields) becomes a
> runtime property.
> 
> Best regards,
> Vladimir Ivanov
> 
>>>>
>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>> correct memory states for the new loads above the phi which quickly
>>>> becomes quite a challenging task.
>>>
>>> Especially in loops. Actually I did tried such approach before and I
>>> agree that it is hard.
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>       p0 = Allocate(...);
>>>>>       ...
>>>>>       p0.x = first;
>>>>>       p0.y = second;
>>>>>
>>>>>       if (cond) {
>>>>>           p1 = Allocate(...);
>>>>>           ...
>>>>>           p1.x = second;
>>>>>           p1.y = first;
>>>>>       }
>>>>>
>>>>>       p = phi(p0, p1) // unused and will be removed
>>>>>
>>>>>
>>>>>       return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>> }
>>>>>
>>>>> Thanks,
>>>>> Vladimir K
>>>>>
>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>> hotspot-compiler-dev.)
>>>>>>
>>>>>> Hi Cesar,
>>>>>>
>>>>>> Thanks for looking into enhancing EA.
>>>>>>
>>>>>> Overall, the proposal looks reasonable.
>>>>>>
>>>>>> I suggest to look more closely at split_unique_types().
>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>
>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>> allocations.
>>>>>>
>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>> clusters of allocations.
>>>>>>
>>>>>> One thing to take care of: scalar replacement relies on
>>>>>> TypeOopPtr::instance_id().
>>>>>>
>>>>>>     // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>     // a particular instance of this type which is distinct.
>>>>>>     // This is the node index of the allocation node creating this
>>>>>> instance.
>>>>>>     int           _instance_id;
>>>>>>
>>>>>> It'll break when multiple allocations are in play.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>> Hi there again!
>>>>>>>
>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>> least partially
>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>
>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>> merged after a
>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>> situation.
>>>>>>>
>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>       Point p = new Point(x, y);
>>>>>>>       if (cond)
>>>>>>>           p = new Point(y, x);
>>>>>>>       // Allocations for p are merged here.
>>>>>>>       return p.calc();
>>>>>>> }
>>>>>>>
>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>> will not
>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>       p0 = Allocate(...);
>>>>>>>       ...
>>>>>>>       p0.x = first;
>>>>>>>       p0.y = second;
>>>>>>>
>>>>>>>       if (cond) {
>>>>>>>           p1 = Allocate(...);
>>>>>>>           ...
>>>>>>>           p1.x = second;
>>>>>>>           p1.y = first;
>>>>>>>       }
>>>>>>>
>>>>>>>       p = phi(p0, p1)
>>>>>>>
>>>>>>>       return p.x - p.y;
>>>>>>> }
>>>>>>>
>>>>>>> However, one of the constraints implemented here [2], specifically
>>>>>>> the third
>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>
>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>> replace the Phi
>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>> of the objects
>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>> this after the
>>>>>>> transformation:
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>       p0 = Allocate(...);
>>>>>>>       ...
>>>>>>>       p0.x = first;
>>>>>>>       p0.y = second;
>>>>>>>
>>>>>>>       if (cond) {
>>>>>>>           p1 = Allocate(...);
>>>>>>>           ...
>>>>>>>           p1.x = second;
>>>>>>>           p1.y = first;
>>>>>>>       }
>>>>>>>
>>>>>>>       pX = phi(first, second)
>>>>>>>       pY = phi(second, first)
>>>>>>>
>>>>>>>       return pX - pY;
>>>>>>> }
>>>>>>>
>>>>>>> I understand that this transformation might not be applicable for
>>>>>>> all cases and
>>>>>>> that it's not as simple as illustrated above. Also, it seems to me
>>>>>>> that much of
>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>> of the Scalar
>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>> as possible.
>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>
>>>>>>> split_phis(phi)
>>>>>>>       # If output of phi escapes, or something uses its identity, etc
>>>>>>>       # then we can't remove it. The conditions here might possible
>>>>>>> be the
>>>>>>>       # same as the ones implemented in
>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>       if cant_remove_phi_output(phi)
>>>>>>>           return ;
>>>>>>>
>>>>>>>       # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>> field F
>>>>>>>       # member of the object resulting from `phi`.
>>>>>>>       fields_used = collect_fields_used_after_phi(phi)
>>>>>>>
>>>>>>>       foreach field in fields_used
>>>>>>>           producers = {}
>>>>>>>
>>>>>>>           # Create a list with the last Store for each field
>>>>>>> "field" on the
>>>>>>>           # scope of each of the Phi input objects.
>>>>>>>           foreach o in phi.inputs
>>>>>>>               # The function called below might re-use a lot of the
>>>>>>> code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>               producers += last_store_to_o_field(0, field)
>>>>>>>           # Create a new phi node whose inputs are the Store's to
>>>>>>> 'field'
>>>>>>>           field_phi = create_new_phi(producers)
>>>>>>>
>>>>>>>           update_consumers(field, field_phi)
>>>>>>>
>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>> [3] step just
>>>>>>> after EA but before the constraint checks in
>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>> implementation goes through
>>>>>>> the following major phases:
>>>>>>>
>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>> based on a set of constraints.
>>>>>>>       3. Make call to Split_unique_types [4].
>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>           4.1 Check if allocation can be eliminated.
>>>>>>>           4.2 Perform scalar replacement. Replace uses of object in
>>>>>>> Safepoints.
>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>
>>>>>>> The transformation that I am proposing would change the overall
>>>>>>> flow to look
>>>>>>> like this:
>>>>>>>
>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>       2. ----> New: "Split phi functions" <----
>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>> based on a set of constraints.
>>>>>>>       3. Make call to Split_unique_types [14].
>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>           4.1 ----> Moved to split_phi: "Check if allocation can be
>>>>>>> eliminated" <----
>>>>>>>           4.2 Perform scalar replacement. Replace uses of object in
>>>>>>> Safepoints.
>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>
>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>> time to review
>>>>>>> this!
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Cesar
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>>       [1] I am not sure yet how this approach will play with the
>>>>>>> case of a merge
>>>>>>>           with NULL.
>>>>>>>       [2]
>>>>>>> https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cf6f03bf26b724150d0e508d9eff1d0bf*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637804644159660386*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=j5KJXWywNe6eNmgD8vDXyhJTPhugsUFvivvocbiwnrE*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!dCjbOcNY-TmA_XDaROQVmVTuzAFxM73migoYdKW9Qle3xgFD7PANME_5LXeGQ0ldiqERUSk$
>>>>>>>
>>>>>>>
>>>>>>>       [3] Another option would be to "patch" the current
>>>>>>> implementation to be able
>>>>>>>           to handle the merges. I am not certain that the "patch"
>>>>>>> approach would be
>>>>>>>           better, however, the "pre-process" approach is certainly
>>>>>>> much easier to test
>>>>>>>           and more readable.
>>>>>>>
>>>>>>>       [4] I cannot say I understand 100% the effects of executing
>>>>>>>           split_unique_types(). Would the transformation that I am
>>>>>>> proposing need to
>>>>>>>           be after the call to split_unique_types?

From dchuyko at openjdk.java.net  Thu Feb 17 15:10:49 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Thu, 17 Feb 2022 15:10:49 GMT
Subject: RFR: 8282049: AArch64: Use ZR for integer zero immediate volatile
 stores [v2]
In-Reply-To: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
References: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
Message-ID: <-wIRPn9UFinHvPnnuRGZkS8wfVXBo4HQcPl0kZ3lrq4=.c35e77ab-9197-4230-bc36-ba492a1179b0@github.com>

> Rules and encodings for volatile stores of immediate zero byte, char, int, long and pointers were added in aarch64.ad. E.g. storeimmN0_volatile() and aarch64_enc_stlrw0(). They use stlr instructions with ZR similar to what is already done for non-volatile zero stores and str instructions.
> 
> So for example
> 
> mov x13, xzr
> stlr x13, [x11]
> 
> turns into
> 
> stlr xzr [x11]
> 
> There's no direct effect in dedicated micro-benchmarks on N1 but 1 register and 1 instruction are saved.
> 
> Testing: jtreg tier1, tier2, applications/jcstress on bare metal Graviton 2.

Dmitry Chuyko 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 'openjdk:master' into JDK-8282049
 - Added rules for stlr zr, mem

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7515/files
  - new: https://git.openjdk.java.net/jdk/pull/7515/files/b3e488ae..3a7d3dd4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7515&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7515&range=00-01

  Stats: 3144 lines in 57 files changed: 1493 ins; 1120 del; 531 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7515.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7515/head:pull/7515

PR: https://git.openjdk.java.net/jdk/pull/7515

From ihse at openjdk.java.net  Thu Feb 17 15:16:41 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Feb 2022 15:16:41 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis [v2]
In-Reply-To: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
Message-ID: <9WqRK6V2GVcRAXUWYNa9irzLZ_0xxTyuv0WzDNZBXg0=.509d399d-fc43-40e9-8a20-12a0f9ffe9d2@github.com>

> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
> 
> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
> 
> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7506/files
  - new: https://git.openjdk.java.net/jdk/pull/7506/files/03974854..05c19820

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7506&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7506&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7506.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7506/head:pull/7506

PR: https://git.openjdk.java.net/jdk/pull/7506

From ihse at openjdk.java.net  Thu Feb 17 15:16:43 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Feb 2022 15:16:43 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis [v2]
In-Reply-To: <X-c1F8n3rLyKzCQ9ydgOI-PjonSQ-DirPAmZXFSMCU4=.e816cdad-7b93-4484-bc1b-8bd0f0e50f12@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
 <X-c1F8n3rLyKzCQ9ydgOI-PjonSQ-DirPAmZXFSMCU4=.e816cdad-7b93-4484-bc1b-8bd0f0e50f12@github.com>
Message-ID: <sbK6NxgYkbpbGfDVIBqzEL27vk6vz4Mu_pPRw2mybvQ=.db340a61-2235-4c7c-9e1d-ee21dc2a8813@github.com>

On Thu, 17 Feb 2022 14:11:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> make/Hsdis.gmk line 157:
> 
>> 155: 
>> 156: $(INSTALLED_HSDIS): $(BUILD_HSDIS_TARGET)
>> 157: ifeq ($(HSDIS_BACKEND), binutils)
> 
> Don't we usually indent conditionals to the recipe level using spaces?

Yes we do. Embarrassing. ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/7506

From yzheng at openjdk.java.net  Thu Feb 17 15:30:44 2022
From: yzheng at openjdk.java.net (Yudi Zheng)
Date: Thu, 17 Feb 2022 15:30:44 GMT
Subject: RFR: 8282044: [JVMCI] Export _sha3_implCompress,
 _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. [v3]
In-Reply-To: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
References: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
Message-ID: <M3x341x1oe1N8H8flbYWlZxpRzv7XPBj1qNw19oIt3s=.f54a6e74-5664-4823-a825-60718fe195f4@github.com>

> This PR allows JVMCI compiler to reuse _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs.

Yudi Zheng 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:

  Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7511/files
  - new: https://git.openjdk.java.net/jdk/pull/7511/files/f5381932..0d8da9e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7511&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7511&range=01-02

  Stats: 6 lines in 1 file changed: 4 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7511.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7511/head:pull/7511

PR: https://git.openjdk.java.net/jdk/pull/7511

From vladimir.x.ivanov at oracle.com  Thu Feb 17 15:37:04 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 17 Feb 2022 18:37:04 +0300
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
Message-ID: <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>


> But depending on the actual shape of the base pointer (here it's 
> Phi(obj1,obj2)), it may become infeasible (from performance perspective) 
> or even impossible (e.g., for complex loop variant conditions) to 
> separate instance slices.

I'd like to correct myself. After thinking more about the problem, I see 
a universal way to scalarize clusters of interfering non-escaping 
allocations even in presence of accesses with indeterminate base.

The crucial property for such cluster of interacting non-escaping 
allocations is for any memory access its base is either part of the 
cluster or not (it's a static property for every access). Then, when it 
is part of the cluster, then the number of possible base values at 
runtime is finite and is a subset of the cluster.

So, memory graph for the cluster can be scalarized as follows:

   (1) separate memory graph for the cluster

   (2) on the newly constructed graph:

      (a) replace every base pointer with an ID ("selector id") and 
recreate data graph for selector IDs from base pointers graph;

      (b) for accesses with indeterminate base pointer, replace them 
with a merge of states from relevant allocations selected by "selector id"

      (c) after 2b, all memory accesses from the cluster memory graph 
should have fixed base pointing at a particular allocation

   (3) scalarize individual allocations from the cluster one by one 
(since they are independent now)

      - additional transformation (like, split-through-phi) should 
simplify the graph by reducing the number of cases at merge points to 
care about (ideally, leaving only a single one);



As an illustration:

   val = Load (AddP (Phi R base1 base2) offset) mem # load A.i

==(pseudo-code)==>

   selector = (Phi R #base1 #base2)

   if (selector == #base1) {
     val1 = Load (base1 + offset) mem
   } else if (selector == #base2) {
     val2 = Load (base2 + offset) mem
   } else {
     halt(); // impossible
   }

   val = Phi(R1, val1, val2)

======

   Store (AddP (Phi R base1 base2) offset) mem v # store A.i v

==(pseudo-code)==>

   selector = (Phi R #base1 #base2)

   if (selector == #base1) {
     Store base1 mem v ==> mem1
   } else if (selector == #base2) {
     Store base2 mem v ==> mem2
   } else {
     halt(); // impossible
   }

   mem = Phi(R1, mem1, mem2);


Best regards,
Vladimir Ivanov

> 
> So, gradual approach seems the way to go:
>  ? (1) split memory graph for clusters of interacting non-escaping 
> allocations;
> 
>  ? (2) perform adhoc transformation targeted at untangling aliasing 
> accesses (e.g, split-through-phi);
> 
>  ? (3) extract unique instance types where possible, thus making the 
> corresponding allocation scalar replaceable
> 
> =====================================================================
> 
> Also, one observation: interacting allocations don't have to be of the 
> same class.
> 
>  ??? static int testPolluted(int r, boolean b) {
>  ??????? A obj1 = new B1(r);
>  ??????? A obj2 = new B2(r);
> 
>  ??????? A obj = (b ? obj1 : obj2);
>  ??????? for (int i = 1; i < r; i++) {
>  ??????????? obj.i++;
>  ??????? }
> 
>  ??????? return obj1.i + obj2.i;
>  ??? }
> 
> Requiring unique instance types to perform SR (and not enhancing SR to 
> handle aliasing allocations case) helps avoid some challenges in 
> instance rematerialization logic at safepoints, because actual shape of 
> the scalarized object (its class and exact set of fields) becomes a 
> runtime property.
> 
> Best regards,
> Vladimir Ivanov
> 
>>>>
>>>> Otherwise, I believe wide memory states/merges would pose serious 
>>>> problems. E.g., when a load is split through a phi, you need to pick 
>>>> correct memory states for the new loads above the phi which quickly 
>>>> becomes quite a challenging task.
>>>
>>> Especially in loops. Actually I did tried such approach before and I 
>>> agree that it is hard.
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>> ???? p0 = Allocate(...);
>>>>> ???? ...
>>>>> ???? p0.x = first;
>>>>> ???? p0.y = second;
>>>>>
>>>>> ???? if (cond) {
>>>>> ???????? p1 = Allocate(...);
>>>>> ???????? ...
>>>>> ???????? p1.x = second;
>>>>> ???????? p1.y = first;
>>>>> ???? }
>>>>>
>>>>> ???? p = phi(p0, p1) // unused and will be removed
>>>>>
>>>>>
>>>>> ???? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>> }
>>>>>
>>>>> Thanks,
>>>>> Vladimir K
>>>>>
>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>> (BCCing hotspot-dev and moving the discussion to 
>>>>>> hotspot-compiler-dev.)
>>>>>>
>>>>>> Hi Cesar,
>>>>>>
>>>>>> Thanks for looking into enhancing EA.
>>>>>>
>>>>>> Overall, the proposal looks reasonable.
>>>>>>
>>>>>> I suggest to look more closely at split_unique_types().
>>>>>> It introduces a dedicated class of alias categories for fields of 
>>>>>> the allocation being eliminated and clones memory graph. I don't 
>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>
>>>>>> Moreover, split_unique_types() will break if you start optimizing 
>>>>>> multiple allocations at once. The notion of unique alias should be 
>>>>>> adjusted and cover the union of unique aliases for all interacting 
>>>>>> allocations.
>>>>>>
>>>>>> Seems like you need to enhance SR to work on non-intersecting 
>>>>>> clusters of allocations.
>>>>>>
>>>>>> One thing to take care of: scalar replacement relies on 
>>>>>> TypeOopPtr::instance_id().
>>>>>>
>>>>>> ?? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>> ?? // a particular instance of this type which is distinct.
>>>>>> ?? // This is the node index of the allocation node creating this 
>>>>>> instance.
>>>>>> ?? int?????????? _instance_id;
>>>>>>
>>>>>> It'll break when multiple allocations are in play.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>> Hi there again!
>>>>>>>
>>>>>>> Can you please give me feedback on the following approach to at 
>>>>>>> least partially
>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>
>>>>>>> The problem that I am trying to solve arises when allocations are 
>>>>>>> merged after a
>>>>>>> control flow split. The code below shows _one example_ of such a 
>>>>>>> situation.
>>>>>>>
>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>> ?? ? Point p = new Point(x, y);
>>>>>>> ?? ? if (cond)
>>>>>>> ?? ? ? ? p = new Point(y, x);
>>>>>>> ?? ? // Allocations for p are merged here.
>>>>>>> ?? ? return p.calc();
>>>>>>> }
>>>>>>>
>>>>>>> Assuming the method calls on "p" are inlined then the allocations 
>>>>>>> will not
>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>> ?? ? p0 = Allocate(...);
>>>>>>> ?? ? ...
>>>>>>> ?? ? p0.x = first;
>>>>>>> ?? ? p0.y = second;
>>>>>>>
>>>>>>> ?? ? if (cond) {
>>>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>>>> ?? ? ? ? ...
>>>>>>> ?? ? ? ? p1.x = second;
>>>>>>> ?? ? ? ? p1.y = first;
>>>>>>> ?? ? }
>>>>>>>
>>>>>>> ?? ? p = phi(p0, p1)
>>>>>>>
>>>>>>> ?? ? return p.x - p.y;
>>>>>>> }
>>>>>>>
>>>>>>> However, one of the constraints implemented here [2], 
>>>>>>> specifically the third
>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>
>>>>>>> The approach that I'm considering for solving the problem is to 
>>>>>>> replace the Phi
>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields 
>>>>>>> of the objects
>>>>>>> in the original Phi. The IR for `ex1` would look something like 
>>>>>>> this after the
>>>>>>> transformation:
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>> ?? ? p0 = Allocate(...);
>>>>>>> ?? ? ...
>>>>>>> ?? ? p0.x = first;
>>>>>>> ?? ? p0.y = second;
>>>>>>>
>>>>>>> ?? ? if (cond) {
>>>>>>> ?? ? ? ? p1 = Allocate(...);
>>>>>>> ?? ? ? ? ...
>>>>>>> ?? ? ? ? p1.x = second;
>>>>>>> ?? ? ? ? p1.y = first;
>>>>>>> ?? ? }
>>>>>>>
>>>>>>> ?? ? pX = phi(first, second)
>>>>>>> ?? ? pY = phi(second, first)
>>>>>>>
>>>>>>> ?? ? return pX - pY;
>>>>>>> }
>>>>>>>
>>>>>>> I understand that this transformation might not be applicable for 
>>>>>>> all cases and
>>>>>>> that it's not as simple as illustrated above. Also, it seems to 
>>>>>>> me that much of
>>>>>>> what I'd have to implement is already implemented in other steps 
>>>>>>> of the Scalar
>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>> implementation details I plan to use as much of the existing code 
>>>>>>> as possible.
>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>
>>>>>>> split_phis(phi)
>>>>>>> ?? ? # If output of phi escapes, or something uses its identity, etc
>>>>>>> ?? ? # then we can't remove it. The conditions here might 
>>>>>>> possible be the
>>>>>>> ?? ? # same as the ones implemented in 
>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>> ?? ? if cant_remove_phi_output(phi)
>>>>>>> ?? ? ? ? return ;
>>>>>>>
>>>>>>> ?? ? # Collect a set of tuples(F,U) containing nodes U that uses 
>>>>>>> field F
>>>>>>> ?? ? # member of the object resulting from `phi`.
>>>>>>> ?? ? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>
>>>>>>> ?? ? foreach field in fields_used
>>>>>>> ?? ? ? ? producers = {}
>>>>>>>
>>>>>>> ?? ? ? ? # Create a list with the last Store for each field 
>>>>>>> "field" on the
>>>>>>> ?? ? ? ? # scope of each of the Phi input objects.
>>>>>>> ?? ? ? ? foreach o in phi.inputs
>>>>>>> ?? ? ? ? ? ? # The function called below might re-use a lot of 
>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>> ?? ? ? ? ? ? producers += last_store_to_o_field(0, field)
>>>>>>> ?? ? ? ? # Create a new phi node whose inputs are the Store's to 
>>>>>>> 'field'
>>>>>>> ?? ? ? ? field_phi = create_new_phi(producers)
>>>>>>>
>>>>>>> ?? ? ? ? update_consumers(field, field_phi)
>>>>>>>
>>>>>>> The implementation that I envisioned would be as a "pre-process" 
>>>>>>> [3] step just
>>>>>>> after EA but before the constraint checks in 
>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>> [2]. If we agree that the overall Scalar Replacement 
>>>>>>> implementation goes through
>>>>>>> the following major phases:
>>>>>>>
>>>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status 
>>>>>>> based on a set of constraints.
>>>>>>> ?? ? 3. Make call to Split_unique_types [4].
>>>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>>>> ?? ? ? ? 4.1 Check if allocation can be eliminated.
>>>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object 
>>>>>>> in Safepoints.
>>>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>
>>>>>>> The transformation that I am proposing would change the overall 
>>>>>>> flow to look
>>>>>>> like this:
>>>>>>>
>>>>>>> ?? ? 1. Identify the Escape Status of objects.
>>>>>>> ?? ? 2. ----> New: "Split phi functions" <----
>>>>>>> ?? ? 2. Adjust object Escape and/or Scalar Replacement status 
>>>>>>> based on a set of constraints.
>>>>>>> ?? ? 3. Make call to Split_unique_types [14].
>>>>>>> ?? ? 4 Iterate over object and array allocations.
>>>>>>> ?? ? ? ? 4.1 ----> Moved to split_phi: "Check if allocation can 
>>>>>>> be eliminated" <----
>>>>>>> ?? ? ? ? 4.2 Perform scalar replacement. Replace uses of object 
>>>>>>> in Safepoints.
>>>>>>> ?? ? ? ? 4.3 Process users of CheckCastPP other than Safepoint: 
>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>
>>>>>>> Please let me know what you think and thank you for taking the 
>>>>>>> time to review
>>>>>>> this!
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Cesar
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>> ?? ? [1] I am not sure yet how this approach will play with the 
>>>>>>> case of a merge
>>>>>>> ?? ? ? ? with NULL.
>>>>>>> ?? ? [2] 
>>>>>>> https://github.com/openjdk/jdk/blob/2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff/src/hotspot/share/opto/escape.cpp#L1809 
>>>>>>>
>>>>>>>
>>>>>>> ?? ? [3] Another option would be to "patch" the current 
>>>>>>> implementation to be able
>>>>>>> ?? ? ? ? to handle the merges. I am not certain that the "patch" 
>>>>>>> approach would be
>>>>>>> ?? ? ? ? better, however, the "pre-process" approach is certainly 
>>>>>>> much easier to test
>>>>>>> ?? ? ? ? and more readable.
>>>>>>>
>>>>>>> ?? ? [4] I cannot say I understand 100% the effects of executing
>>>>>>> ?? ? ? ? split_unique_types(). Would the transformation that I am 
>>>>>>> proposing need to
>>>>>>> ?? ? ? ? be after the call to split_unique_types?

From adinn at openjdk.java.net  Thu Feb 17 15:52:16 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Thu, 17 Feb 2022 15:52:16 GMT
Subject: RFR: 8282049: AArch64: Use ZR for integer zero immediate volatile
 stores [v2]
In-Reply-To: <-wIRPn9UFinHvPnnuRGZkS8wfVXBo4HQcPl0kZ3lrq4=.c35e77ab-9197-4230-bc36-ba492a1179b0@github.com>
References: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
 <-wIRPn9UFinHvPnnuRGZkS8wfVXBo4HQcPl0kZ3lrq4=.c35e77ab-9197-4230-bc36-ba492a1179b0@github.com>
Message-ID: <ECywufeWhzm0-fPCs1e55L9T_NlXlHsrK79Q3dBgFsw=.3c44af7d-ee8d-456c-b6d2-2f6fe0023616@github.com>

On Thu, 17 Feb 2022 15:10:49 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> Rules and encodings for volatile stores of immediate zero byte, char, int, long and pointers were added in aarch64.ad. E.g. storeimmN0_volatile() and aarch64_enc_stlrw0(). They use stlr instructions with ZR similar to what is already done for non-volatile zero stores and str instructions.
>> 
>> So for example
>> 
>> mov x13, xzr
>> stlr x13, [x11]
>> 
>> turns into
>> 
>> stlr xzr [x11]
>> 
>> There's no direct effect in dedicated micro-benchmarks on N1 but 1 register and 1 instruction are saved.
>> 
>> Testing: jtreg tier1, tier2, applications/jcstress on bare metal Graviton 2.
>
> Dmitry Chuyko 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 'openjdk:master' into JDK-8282049
>  - Added rules for stlr zr, mem

Looks good.

-------------

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7515

From erikj at openjdk.java.net  Thu Feb 17 17:13:13 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 17 Feb 2022 17:13:13 GMT
Subject: RFR: 8188073: Add Capstone as backend for hsdis [v2]
In-Reply-To: <9WqRK6V2GVcRAXUWYNa9irzLZ_0xxTyuv0WzDNZBXg0=.509d399d-fc43-40e9-8a20-12a0f9ffe9d2@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
 <9WqRK6V2GVcRAXUWYNa9irzLZ_0xxTyuv0WzDNZBXg0=.509d399d-fc43-40e9-8a20-12a0f9ffe9d2@github.com>
Message-ID: <TYi6jfqo8VI56YWmTU-y0nI_FrUR4WbIxCCRLHnUGAc=.0f999038-58b0-4fdc-8701-2f9a3d9dc44e@github.com>

On Thu, 17 Feb 2022 15:16:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
>> 
>> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
>> 
>> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7506

From duke at openjdk.java.net  Thu Feb 17 17:27:12 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Thu, 17 Feb 2022 17:27:12 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v3]
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <enxdYe9Ror3TBnLI3yetuoOQJGpdi0xs5UFlkbylE08=.d3a93e8c-c13a-4d16-8f8d-d72e80cfcaf9@github.com>

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7434/files
  - new: https://git.openjdk.java.net/jdk/pull/7434/files/8c66e0e5..61d0a1a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7434&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7434&range=01-02

  Stats: 21 lines in 3 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7434.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7434/head:pull/7434

PR: https://git.openjdk.java.net/jdk/pull/7434

From jbhateja at openjdk.java.net  Thu Feb 17 17:43:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 17 Feb 2022 17:43:43 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v6]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <oMnlIO5l_pU71SvWpOFppQ-7882cq32UOjKqWZckxM0=.0efd7853-b30d-488b-92c4-4a8ad0412fda@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | --
> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Fixing for windows failure.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/73674fe4..f35ed9cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=04-05

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From phh at openjdk.java.net  Thu Feb 17 18:33:17 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 17 Feb 2022 18:33:17 GMT
Subject: RFR: 8282049: AArch64: Use ZR for integer zero immediate volatile
 stores [v2]
In-Reply-To: <-wIRPn9UFinHvPnnuRGZkS8wfVXBo4HQcPl0kZ3lrq4=.c35e77ab-9197-4230-bc36-ba492a1179b0@github.com>
References: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
 <-wIRPn9UFinHvPnnuRGZkS8wfVXBo4HQcPl0kZ3lrq4=.c35e77ab-9197-4230-bc36-ba492a1179b0@github.com>
Message-ID: <wb-Jyqf_Bpk5qNw06ukF5bzT_jmkxuK2epQBHWbdKN8=.f0671742-3261-46a0-9b39-9afc9ab31b93@github.com>

On Thu, 17 Feb 2022 15:10:49 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

>> Rules and encodings for volatile stores of immediate zero byte, char, int, long and pointers were added in aarch64.ad. E.g. storeimmN0_volatile() and aarch64_enc_stlrw0(). They use stlr instructions with ZR similar to what is already done for non-volatile zero stores and str instructions.
>> 
>> So for example
>> 
>> mov x13, xzr
>> stlr x13, [x11]
>> 
>> turns into
>> 
>> stlr xzr [x11]
>> 
>> There's no direct effect in dedicated micro-benchmarks on N1 but 1 register and 1 instruction are saved.
>> 
>> Testing: jtreg tier1, tier2, applications/jcstress on bare metal Graviton 2.
>
> Dmitry Chuyko 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 'openjdk:master' into JDK-8282049
>  - Added rules for stlr zr, mem

Lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7515

From xliu at openjdk.java.net  Thu Feb 17 18:38:12 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 17 Feb 2022 18:38:12 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <hitDGzN5p271cIfeeLRpXnjZpo4QMmCCL2hnplFjXTI=.fea3e433-2b8f-4db4-b4cd-d85e6ebf61ef@github.com>

On Tue, 8 Feb 2022 19:17:32 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8005885: enhance PrintCodeCache to print more data

My comments are nits. Generally, this PR looks good to me. 
I am not a reviewer. We still need other reviewers to approve it.

src/hotspot/share/code/codeCache.cpp line 109:

> 107:   void print(const char* title) const {
> 108:     if (is_empty())
> 109:     {

better stick with the existing codestyle.  they always use if (cond) { and else {

src/hotspot/share/code/codeCache.cpp line 1497:

> 1495:   };
> 1496:   tty->print_cr("Stubs:");
> 1497:   for (auto &stub: stubs) {

current code style prefer auto& stub.  same as 1486 1487 lines, asterisk associates with type.

-------------

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Thu Feb 17 19:07:56 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Thu, 17 Feb 2022 19:07:56 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v2]
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <br7XMosl4RWjrKmPHLfxQQ8y94pNZWBAja3xB7BTT_w=.e369cf03-3f85-419c-8368-9634b7f83581@github.com>

> An example of the modified data.
> 
> java -XX:+TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCodeCache -XX:+Verbose
> 
> Tier 0:
>  #45 live = 38K (hdr 16K, loc 4K, code 18K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #0 dead = 0K
> Tier 1:
>  #56 live = 43K (hdr 20K, loc 3K, code 9K, stub 4K, [oops 0K, metadata 0K, data 0K, pcs 3K])
>  #0 dead = 0K
> Tier 2:
>  #0 live = 0K
>  #0 dead = 0K
> Tier 3:
>  #306 live = 773K (hdr 109K, loc 61K, code 354K, stub 37K, [oops 0K, metadata 6K, data 67K, pcs 122K])
>  #0 dead = 0K
> Tier 4:
>  #37 live = 110K (hdr 13K, loc 6K, code 43K, stub 1K, [oops 0K, metadata 1K, data 13K, pcs 28K])
>  #0 dead = 0K
> Stubs:
>  #60 runtime = 34K (hdr 7K, loc 1K, code 24K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #1 uncommon trap = 0K (hdr 0K, loc 0K, code 0K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #1 deoptimization = 1K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #667 adapter = 512K (hdr 78K, loc 45K, code 376K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #17 buffer blob = 3163K (hdr 1K, loc 0K, code 3161K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #4 other = 2K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Fix code style

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7389/files
  - new: https://git.openjdk.java.net/jdk/pull/7389/files/6ea57a49..2afb2938

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7389/head:pull/7389

PR: https://git.openjdk.java.net/jdk/pull/7389

From kvn at openjdk.java.net  Thu Feb 17 19:49:10 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 17 Feb 2022 19:49:10 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
Message-ID: <SlrlaxGuhjM9a8V4JBKxZKU-kSSb5-mdCRAhLW3yG7s=.849dcd31-fbb2-4179-bec1-f1fdef987acd@github.com>

On Thu, 17 Feb 2022 08:16:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all, 
>> 
>> compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
>> The fix just increasing the stub size for AVX512 platforms.
>> 
>> Testing:
>>   - tier1~3 on Linux/x64 with AVX512, no regression
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

I would like to hear explanation why the test failed with `-XX:CodeEntryAlignment=16` on avx512 when it passed with bigger default value 32 (or other bigger values): 
https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/globals_x86.hpp#L47

It looks like somewhere we use CodeEntryAlignment to calculate some buffer size. It seems we need to fix that place instead of just bumping this CodeBuffer size.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7485

From kvn at openjdk.java.net  Thu Feb 17 20:07:14 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 17 Feb 2022 20:07:14 GMT
Subject: RFR: 8281544: assert(VM_Version::supports_avx512bw()) failed for
 Tests jdk/incubator/vector/ [v2]
In-Reply-To: <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
References: <NuMg_3wZ7GTF1QIuTBDb0t0NJ1YlzWn795AtnDEdNbs=.20bb8fe7-b5ec-4246-a236-5653e0d2d546@github.com>
 <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
Message-ID: <Vrh8Sk9NGYP8YnH9Dv4cOwG5qU0u93_A3NK_D4ieK2Q=.28f12483-fb57-4ddc-9342-31abcba4374f@github.com>

On Thu, 17 Feb 2022 12:01:56 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> `ZSaveLiveRegisters::ZSaveLiveRegisters` stores live registers, and later they are loaded again.
>> This includes opmask registers, which are part of AVX512. However, not all platforms have all of the AVX512 instructions.
>> For example Knights Landing has general AVX512 support and makes use of optmask registers, but does not support the AVX512 BW subset of instructions, specifically it does not support the `kmovql` instruction. Platforms like Cannon Landing have support for AVX512 BW.
>> 
>> Solution: in analogy to `RegisterSaver::save_live_registers`, which seems to perform a very similar task, use `MacroAssembler::kmov` instead of `kmovql` directly. Internally, `kmov` choses either `kmovql` if avx512bw is available, else it takes `kmovwl`.
>> 
>> As a regression test, I took one of the tests that failed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`, and added an additional `@run` statement with those flags. I simulated this test locally with Intel Software Development Emulator:
>> `sde -knl`: Knights Landing, AVX512 but not BW, fails without change to `kmov`, passes with it.
>> `sde -cnl`: Cannon Landing, has AVX512 BW, passes before and after code change.
>> 
>> Ran additional tests to verify that the test triggers before code change, and that with the code change nothing broke.
>> 
>> @neliasso Thanks for the help!
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7510

From neliasso at openjdk.java.net  Thu Feb 17 20:07:14 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 17 Feb 2022 20:07:14 GMT
Subject: RFR: 8281544: assert(VM_Version::supports_avx512bw()) failed for
 Tests jdk/incubator/vector/ [v2]
In-Reply-To: <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
References: <NuMg_3wZ7GTF1QIuTBDb0t0NJ1YlzWn795AtnDEdNbs=.20bb8fe7-b5ec-4246-a236-5653e0d2d546@github.com>
 <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
Message-ID: <Q5adA1YTFVDGwhi19AK6KGxB4OW-dqjmIgXRlL9vA2Y=.5a649118-ceab-4f0e-ad4b-a7d051c50e63@github.com>

On Thu, 17 Feb 2022 12:01:56 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> `ZSaveLiveRegisters::ZSaveLiveRegisters` stores live registers, and later they are loaded again.
>> This includes opmask registers, which are part of AVX512. However, not all platforms have all of the AVX512 instructions.
>> For example Knights Landing has general AVX512 support and makes use of optmask registers, but does not support the AVX512 BW subset of instructions, specifically it does not support the `kmovql` instruction. Platforms like Cannon Landing have support for AVX512 BW.
>> 
>> Solution: in analogy to `RegisterSaver::save_live_registers`, which seems to perform a very similar task, use `MacroAssembler::kmov` instead of `kmovql` directly. Internally, `kmov` choses either `kmovql` if avx512bw is available, else it takes `kmovwl`.
>> 
>> As a regression test, I took one of the tests that failed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`, and added an additional `@run` statement with those flags. I simulated this test locally with Intel Software Development Emulator:
>> `sde -knl`: Knights Landing, AVX512 but not BW, fails without change to `kmov`, passes with it.
>> `sde -cnl`: Cannon Landing, has AVX512 BW, passes before and after code change.
>> 
>> Ran additional tests to verify that the test triggers before code change, and that with the code change nothing broke.
>> 
>> @neliasso Thanks for the help!
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

Looks good!

-------------

Marked as reviewed by neliasso (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7510

From kvn at openjdk.java.net  Thu Feb 17 20:10:11 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 17 Feb 2022 20:10:11 GMT
Subject: RFR: 8282044: [JVMCI] Export _sha3_implCompress,
 _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. [v3]
In-Reply-To: <M3x341x1oe1N8H8flbYWlZxpRzv7XPBj1qNw19oIt3s=.f54a6e74-5664-4823-a825-60718fe195f4@github.com>
References: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
 <M3x341x1oe1N8H8flbYWlZxpRzv7XPBj1qNw19oIt3s=.f54a6e74-5664-4823-a825-60718fe195f4@github.com>
Message-ID: <DmiEmPpyc7Y7QIyl_VimaaW_rTuczh7qqAizUujaLCM=.1cd4dad0-51a4-4ef1-b633-a1ab2a47f753@github.com>

On Thu, 17 Feb 2022 15:30:44 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR allows JVMCI compiler to reuse _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs.
>
> Yudi Zheng 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:
> 
>   Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7511

From dcubed at openjdk.java.net  Thu Feb 17 21:00:35 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Feb 2022 21:00:35 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
Message-ID: <0zZ2TNpyG-ptBmfEMte_L-Tmz1mHJUtOt0Yg3PeLOZs=.addb23a7-09a8-4931-a663-433960848051@github.com>

On Thu, 17 Feb 2022 20:48:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

This pull request has now been integrated.

Changeset: 69fc273f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69fc273f202352f74a313c37db0198be2be08616
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8282075: ProblemList 3 compiler/whitebox tests on macosx-x64

Reviewed-by: mikael, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/7523

From mikael at openjdk.java.net  Thu Feb 17 21:00:32 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 17 Feb 2022 21:00:32 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
Message-ID: <l5vU7OEUgw05O-gc1BYsZYU8PH8JVCgqdes6HaZTGY4=.7602026f-031f-4464-9ebb-26d54cd5c06b@github.com>

On Thu, 17 Feb 2022 20:48:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7523

From dcubed at openjdk.java.net  Thu Feb 17 21:00:31 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Feb 2022 21:00:31 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
Message-ID: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>

A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

-------------

Commit messages:
 - 8282075: ProblemList 3 compiler/whitebox tests on macosx-x64

Changes: https://git.openjdk.java.net/jdk/pull/7523/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7523&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282075
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7523.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7523/head:pull/7523

PR: https://git.openjdk.java.net/jdk/pull/7523

From bpb at openjdk.java.net  Thu Feb 17 21:00:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 17 Feb 2022 21:00:33 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
Message-ID: <EcCo2yia0RFEdBcGpJ5BoZpiMtgnqKqDREyOlSSKpwQ=.2056510a-89ed-4a8b-9912-06c40f19b59a@github.com>

On Thu, 17 Feb 2022 20:48:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7523

From dcubed at openjdk.java.net  Thu Feb 17 21:00:33 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 17 Feb 2022 21:00:33 GMT
Subject: Integrated: 8282075: ProblemList 3 compiler/whitebox tests on
 macosx-x64
In-Reply-To: <l5vU7OEUgw05O-gc1BYsZYU8PH8JVCgqdes6HaZTGY4=.7602026f-031f-4464-9ebb-26d54cd5c06b@github.com>
References: <FMt90ZJIfTz5ntUHmxd_dSzp252JaXMtPy6FVKDi90U=.e8a7b133-e740-4338-8165-ab9a4d27e793@github.com>
 <l5vU7OEUgw05O-gc1BYsZYU8PH8JVCgqdes6HaZTGY4=.7602026f-031f-4464-9ebb-26d54cd5c06b@github.com>
Message-ID: <r_0Dg2_m8dSu2FGjRLoRSL-Xoc2Eiz-NS4Ne78tQ6b4=.37f2603c-f52a-465d-838d-72ddc7dabe5b@github.com>

On Thu, 17 Feb 2022 20:53:45 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A trivial fix to ProblemList 3 compiler/whitebox tests on macosx-x64.
>
> Marked as reviewed by mikael (Reviewer).

@vidmik and @bplb - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7523

From ihse at openjdk.java.net  Thu Feb 17 21:22:15 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 17 Feb 2022 21:22:15 GMT
Subject: Integrated: 8188073: Add Capstone as backend for hsdis
In-Reply-To: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
References: <xEZE2wBWffXwaOYrQbRF0DIlrboDXe-0deAR6Ktc1y4=.5a3393b1-6fb3-44b1-adde-4c08bee3330f@github.com>
Message-ID: <wtMdLcHOKBaOPWL5UfdBdv10t-EbRj2oJUFzjNVE2Yw=.c64dc810-42d5-421d-8b14-a7cb04a9f5b4@github.com>

On Wed, 16 Feb 2022 21:55:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The Capstone library is a simple to use, efficient disassembly library, distributed under the MIT license. 
> 
> This PR implements an hsdis backend using Capstone. It has been tested on Linux, macOS and Windows (x64).
> 
> The actual C implementation of the backend was done by @JornVernee. I assume there are plenty of room for enhancing this implementation, with options like in the binutils backend. Such improvements can be done later, by teams more familiar with the requirements of hsdis.

This pull request has now been integrated.

Changeset: f830cbec
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f830cbec909b91ad0f00f46a3496d83ecb5912ed
Stats:     499 lines in 9 files changed: 328 ins; 118 del; 53 mod

8188073: Add Capstone as backend for hsdis

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/7506

From redestad at openjdk.java.net  Thu Feb 17 21:31:21 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 17 Feb 2022 21:31:21 GMT
Subject: RFR: 8282044: [JVMCI] Export _sha3_implCompress,
 _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler. [v3]
In-Reply-To: <M3x341x1oe1N8H8flbYWlZxpRzv7XPBj1qNw19oIt3s=.f54a6e74-5664-4823-a825-60718fe195f4@github.com>
References: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
 <M3x341x1oe1N8H8flbYWlZxpRzv7XPBj1qNw19oIt3s=.f54a6e74-5664-4823-a825-60718fe195f4@github.com>
Message-ID: <0SnUVoXYTsMw5b_i9o6FcYwRB3RgAp3WkxF0PXpEdT8=.94e8a6c6-2cae-46fe-a117-94511c494edd@github.com>

On Thu, 17 Feb 2022 15:30:44 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This PR allows JVMCI compiler to reuse _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs.
>
> Yudi Zheng 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:
> 
>   Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.

For awareness in #7231 I'm reworking the `_has_negatives` stub into `_count_positibes`, with slightly different semantics.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7511

From jiefu at openjdk.java.net  Thu Feb 17 22:55:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 22:55:06 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <c1yE7XU9inJfcYqG5Wny5QR7py5KdQ32IIxufH0Se-I=.f6b52576-3dac-4661-9703-504ee5a6152d@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Thank you all for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7508

From jiefu at openjdk.java.net  Thu Feb 17 23:00:02 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 23:00:02 GMT
Subject: Integrated: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <OJIk7dxbKtf_LXPdqkciNhgNE7H6JrARxofxi1a1pdw=.eed26895-3d1b-4cea-bda9-373090947673@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: fdce35f3
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fdce35f3a1c12a64238d0c76c02451a25b0b4abb
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732

Reviewed-by: kvn, thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7508

From jiefu at openjdk.java.net  Fri Feb 18 03:41:53 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Feb 2022 03:41:53 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <SlrlaxGuhjM9a8V4JBKxZKU-kSSb5-mdCRAhLW3yG7s=.849dcd31-fbb2-4179-bec1-f1fdef987acd@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
 <SlrlaxGuhjM9a8V4JBKxZKU-kSSb5-mdCRAhLW3yG7s=.849dcd31-fbb2-4179-bec1-f1fdef987acd@github.com>
Message-ID: <lmW5b5wfjRo8kX1s835go7N1qh5mOM11N4lA6jkoOSI=.72db41f6-4e4f-4d9a-9141-215b7e1d3727@github.com>

On Thu, 17 Feb 2022 19:46:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I would like to hear explanation why the test failed with `-XX:CodeEntryAlignment=16` on avx512 when it passed with bigger default value 32 (or other bigger values):
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/globals_x86.hpp#L47

Let's see the code buffer size after line 3005 with CodeEntryAlignment={16, 32, 64}

2999 RuntimeStub* SharedRuntime::generate_resolve_blob(address destination, const char* name) {
3000   assert (StubRoutines::forward_exception_entry() != NULL, "must be generated before");
3001
3002   // allocate space for the code
3003   ResourceMark rm;
3004
3005   CodeBuffer buffer(name, 1000, 512);
3006   MacroAssembler* masm                = new MacroAssembler(&buffer);
3007
3008   int frame_size_in_words;


The `insts.code` is only 1128 for `CodeEntryAlignment=16` which is not enough on AVX512.

CodeEntryAlignment=16

CodeBuffer:
  consts.code = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0)
  consts.locs = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0) point=0
   insts.code = 0x00007fffd90adc90 : 0x00007fffd90adc90 : 0x00007fffd90ae0f8 (0 of 1128)
   insts.locs = 0x00007ffff0027098 : 0x00007ffff0027098 : 0x00007ffff0027298 (0 of 256) point=0
   stubs.code = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0)
   stubs.locs = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0) point=0


CodeEntryAlignment=32

CodeBuffer:
  consts.code = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0)
  consts.locs = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0) point=0
   insts.code = 0x00007fffd90add20 : 0x00007fffd90add20 : 0x00007fffd90ae208 (0 of 1256)
   insts.locs = 0x00007ffff0027098 : 0x00007ffff0027098 : 0x00007ffff0027298 (0 of 256) point=0
   stubs.code = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0)
   stubs.locs = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0) point=0


CodeEntryAlignment=64

CodeBuffer:
  consts.code = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0)
  consts.locs = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0) point=0
   insts.code = 0x00007fffd90adec0 : 0x00007fffd90adec0 : 0x00007fffd90ae4a8 (0 of 1512)
   insts.locs = 0x00007ffff0027098 : 0x00007ffff0027098 : 0x00007ffff0027298 (0 of 256) point=0
   stubs.code = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0)
   stubs.locs = 0x0000000000000000 : 0x0000000000000000 : 0x0000000000000000 (0 of 0) point=0



The related code logic at line 100 & 105, which shows larger `insts.code` with higher `CodeEntryAlignment`.

  98 void CodeBuffer::initialize(csize_t code_size, csize_t locs_size) {
  99   // Compute maximal alignment.
 100   int align = _insts.alignment();                     // <--- will return CodeEntryAlignment
 101   // Always allow for empty slop around each section.
 102   int slop = (int) CodeSection::end_slop();
 103
 104   assert(blob() == NULL, "only once");
 105   set_blob(BufferBlob::create(_name, code_size + (align+slop) * (SECT_LIMIT+1)));

-------------

PR: https://git.openjdk.java.net/jdk/pull/7485

From kvn at openjdk.java.net  Fri Feb 18 04:33:53 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 18 Feb 2022 04:33:53 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <vqXCNBRcM6GmtzM7rLTdIHkecNC4GBPPkkWfWAOoMyA=.d9845421-b15f-4434-9c6e-aedafb948f2c@github.com>
Message-ID: <KMuSXilI8b04vSj4kjRPUZOpISuWoyd2f60qZgFixFU=.59a87ab3-03fe-4a85-880d-877496e2069e@github.com>

On Thu, 17 Feb 2022 08:16:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all, 
>> 
>> compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
>> The fix just increasing the stub size for AVX512 platforms.
>> 
>> Testing:
>>   - tier1~3 on Linux/x64 with AVX512, no regression
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

@DamonFool Thank you for explaining. So we were lucky that previous size was enough for default sizze.

Your fix is good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7485

From jiefu at openjdk.java.net  Fri Feb 18 05:06:53 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Feb 2022 05:06:53 GMT
Subject: RFR: 8281936: compiler/arguments/TestCodeEntryAlignment.java fails
 on AVX512 machines [v2]
In-Reply-To: <h9BaN_McUvaBX84EGHm6ou0ZZiAMyKrjGsaN5GV23Vk=.bc5eb305-acc3-4e26-9088-0d58c122255c@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
 <wgKYZ7TLHJTpT9crOfaQ6N4x5_Ku0esmhpVFqYxugas=.9ee78dbe-42a8-4c2f-8c1c-7c7f9b880c7c@github.com>
 <mNtxLHObz2Lzv7n3woe8Mz-ZkySl9Cj8ZoXDC0-_Wxc=.f7137650-6278-4f49-ad4c-4bbb9a794bf1@github.com>
 <h9BaN_McUvaBX84EGHm6ou0ZZiAMyKrjGsaN5GV23Vk=.bc5eb305-acc3-4e26-9088-0d58c122255c@github.com>
Message-ID: <de_Q-U5FFBZYSmGzx70oN-lqAN97vyQBw6rcU46zQEM=.cca93711-51d9-4f75-8831-c91c1796c763@github.com>

On Thu, 17 Feb 2022 07:42:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> So, there is no actual need to make the increase from `1000` to `1200` optional, as it would be cut down to size on `UseAVX <= 2` case anyway?
>> 
>> More code buffer is required for AVX3 since we have more registers (e.g., 512-bit registers) to be stored/restored.
>
>> > So, there is no actual need to make the increase from `1000` to `1200` optional, as it would be cut down to size on `UseAVX <= 2` case anyway?
>> 
>> More code buffer is required for AVX3 since we have more registers (e.g., 512-bit registers) to be stored/restored.
> 
> Yes, I understand. I am saying that we probably don't need to protect it with `UseAVX`, and can just bump to `1200` unconditionally, seeing how the stub would be copied out of the buffer anyway.

Thanks @shipilev and @vnkozlov for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7485

From jiefu at openjdk.java.net  Fri Feb 18 05:06:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Feb 2022 05:06:54 GMT
Subject: Integrated: 8281936: compiler/arguments/TestCodeEntryAlignment.java
 fails on AVX512 machines
In-Reply-To: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
References: <DbZypy7yfwgGlZlRsT-fYn4C2tK05UmOq7agRdEVgRI=.a6a94696-8123-4d5e-97cc-c48ef035c9bb@github.com>
Message-ID: <LcjedEQGqNiMX0Lc-I7QmSCWEW44J4-50MfyahtcEaQ=.2eb1306c-c7c3-445b-af52-954ab9776fbe@github.com>

On Wed, 16 Feb 2022 02:13:03 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all, 
> 
> compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines due to stub size is not big enough.
> The fix just increasing the stub size for AVX512 platforms.
> 
> Testing:
>   - tier1~3 on Linux/x64 with AVX512, no regression
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: c9289583
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c9289583eb6919ced3b4115cf981180f6a957fbf
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8281936: compiler/arguments/TestCodeEntryAlignment.java fails on AVX512 machines

Reviewed-by: shade, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7485

From thartmann at openjdk.java.net  Fri Feb 18 08:13:53 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 18 Feb 2022 08:13:53 GMT
Subject: RFR: 8281544: assert(VM_Version::supports_avx512bw()) failed for
 Tests jdk/incubator/vector/ [v2]
In-Reply-To: <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
References: <NuMg_3wZ7GTF1QIuTBDb0t0NJ1YlzWn795AtnDEdNbs=.20bb8fe7-b5ec-4246-a236-5653e0d2d546@github.com>
 <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
Message-ID: <C8qTYm47Gm8Yt3STYwG88cYo9XvfCrH3jSpkiGJGAts=.dd893456-6c60-4405-bc88-690c1fab1209@github.com>

On Thu, 17 Feb 2022 12:01:56 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> `ZSaveLiveRegisters::ZSaveLiveRegisters` stores live registers, and later they are loaded again.
>> This includes opmask registers, which are part of AVX512. However, not all platforms have all of the AVX512 instructions.
>> For example Knights Landing has general AVX512 support and makes use of optmask registers, but does not support the AVX512 BW subset of instructions, specifically it does not support the `kmovql` instruction. Platforms like Cannon Landing have support for AVX512 BW.
>> 
>> Solution: in analogy to `RegisterSaver::save_live_registers`, which seems to perform a very similar task, use `MacroAssembler::kmov` instead of `kmovql` directly. Internally, `kmov` choses either `kmovql` if avx512bw is available, else it takes `kmovwl`.
>> 
>> As a regression test, I took one of the tests that failed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`, and added an additional `@run` statement with those flags. I simulated this test locally with Intel Software Development Emulator:
>> `sde -knl`: Knights Landing, AVX512 but not BW, fails without change to `kmov`, passes with it.
>> `sde -cnl`: Cannon Landing, has AVX512 BW, passes before and after code change.
>> 
>> Ran additional tests to verify that the test triggers before code change, and that with the code change nothing broke.
>> 
>> @neliasso Thanks for the help!
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7510

From dchuyko at openjdk.java.net  Fri Feb 18 08:31:36 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Fri, 18 Feb 2022 08:31:36 GMT
Subject: RFR: 8282049: AArch64: Use ZR for integer zero immediate volatile
 stores [v3]
In-Reply-To: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
References: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
Message-ID: <ndWna0Wt4X19R4UOFEvoXTfM2Miiuy5LbtORGJ6wd0U=.9426c0d7-8cba-49d3-aed3-21e3c8322e71@github.com>

> Rules and encodings for volatile stores of immediate zero byte, char, int, long and pointers were added in aarch64.ad. E.g. storeimmN0_volatile() and aarch64_enc_stlrw0(). They use stlr instructions with ZR similar to what is already done for non-volatile zero stores and str instructions.
> 
> So for example
> 
> mov x13, xzr
> stlr x13, [x11]
> 
> turns into
> 
> stlr xzr [x11]
> 
> There's no direct effect in dedicated micro-benchmarks on N1 but 1 register and 1 instruction are saved.
> 
> Testing: jtreg tier1, tier2, applications/jcstress on bare metal Graviton 2.

Dmitry Chuyko 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:

 - Merge branch 'openjdk:master' into JDK-8282049
 - Merge branch 'openjdk:master' into JDK-8282049
 - Added rules for stlr zr, mem

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7515/files
  - new: https://git.openjdk.java.net/jdk/pull/7515/files/3a7d3dd4..179c0fe1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7515&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7515&range=01-02

  Stats: 828 lines in 24 files changed: 634 ins; 120 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7515.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7515/head:pull/7515

PR: https://git.openjdk.java.net/jdk/pull/7515

From rcastanedalo at openjdk.java.net  Fri Feb 18 08:36:20 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 18 Feb 2022 08:36:20 GMT
Subject: RFR: 8280568: IGV: Phi inputs and pinned nodes are not scheduled
 correctly [v2]
In-Reply-To: <-iYiPRIR5iUEQyHWbTW0j2wwWjPS7YSfsp_ikHPAW54=.fa427507-e74d-4cfa-bd49-8dc7c935346c@github.com>
References: <-iYiPRIR5iUEQyHWbTW0j2wwWjPS7YSfsp_ikHPAW54=.fa427507-e74d-4cfa-bd49-8dc7c935346c@github.com>
Message-ID: <l6dih5wDNham2kBk3LOD1fkRHrSvacuw7fzAJ2Y9RSQ=.87f0fef7-b478-4f0a-b15f-2df7fa4dca89@github.com>

> This change improves the accuracy of IGV's schedule approximation algorithm w.r.t. C2 in two ways:
> 
> 1. Schedule each node N pinned to a control node R in:
> 
>    1a. the same block as R, if R is a "regular" control node such as `Region` or `Proj`. For example (N = `168 LoadP`, R = `75 Proj`):
> 
>    <p align="center">
>    <img src="https://user-images.githubusercontent.com/8792647/154474596-ad326ad0-e127-4529-9837-6427c0a17314.png" width="50%">
>    </p>
> 
>    or
> 
>    1b. R's successor block S, if R is a block projection node (such as `IfTrue` or `CatchProj`). For example (N = `92 LoadN`, R = `29 IfTrue`, S = `B4`):
> 
>    <p align="center">
>    <img src="https://user-images.githubusercontent.com/8792647/154476147-4d53e2d9-db19-4449-bd79-053e6380cf4d.png" width="45%">
>    </p>
> 
>    In case S has multiple predecessors (i.e. (R, S) form a critical edge), N is scheduled in a critical-edge-splitting block between R and S. For example (N = `135 ClearArray`, R = `151 IfTrue`, S=`B5` in _(before)_ and `B8` in _(after)_, and `B5` is the new critical-edge-splitting block in _(after)_):
> 
>    <p align="center">
>    <img src="https://user-images.githubusercontent.com/8792647/154487037-24d3f147-b592-484a-bdf2-e93c3bec053c.png" width="90%">
>    </p>
> 
>    Note that in _(after)_, B5 is a predecessor of B8. This can be seen in the CFG view, but is not visible in the sea-of-nodes graph view, due to the lack of control nodes in the blocks such as B5 created by critical-edge splitting.
> 
> 2. Schedule each node N that is input to a `Phi` node P in a block that dominates P's corresponding predecessor block B. For example (N = `36 ConvI2L`, P = `33 Phi`, B = `B2`):
> 
>    <p align="center">
>    <img src="https://user-images.githubusercontent.com/8792647/154479876-1e2ae61a-a9a9-453f-b031-55d5dce17ce7.png" width="55%">
>    </p>
> 
> The combined effect of these scheduling improvements can be seen in the subgraph below, that illustrates cases 1b (where a critical edge must be split) and 2. In _(before)_, `135 ClearArray` is both input to a phi node `91 Phi` and pinned to a block projection `151 IfTrue` on a critical edge (B7, B5), hence (_after_) a new critical-edge-splitting block B5 is created in which `135 ClearArray` and the rest of nodes pinned to `151 IfTrue` are scheduled:
> <p align="center"> 
> <img src="https://user-images.githubusercontent.com/8792647/154481964-37d5c8a1-4243-49eb-a127-5a53f5ef0abb.png" width="95%">
> </p>
> 
> Additionally, the change introduces checks on graph invariants that are assumed by scheduling approximation (e.g. each block projection has a single control successor), warning the IGV user about possible issues in the schedule if these invariants are broken. Emitting warnings and gracefully degrading the approximated schedule is preferred to just failing since one of IGV's main use cases is debugging graphs which might be ill-formed.
> 
> These changes increase the overhead of scheduling large graphs by about 10-20%, however there are opportunities for speeding up scheduling by about an order of magnitude (see [JDK-8282043](https://bugs.openjdk.java.net/browse/JDK-8282043)) that would more than compensate for this overhead.
> 
> #### Testing
> 
> - Tested manually that the phi inputs and pinned nodes are scheduled correctly for a few selected graphs (included the reported one).
> - Tested automatically that scheduling tens of thousands of graphs (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`) does not trigger any assertion failure and does not warn with the message "inaccurate schedule: (...) are phi inputs but do not dominate the phi's input block.".

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7493/files
  - new: https://git.openjdk.java.net/jdk/pull/7493/files/45d60d10..d2e3b0ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7493&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7493&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7493.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7493/head:pull/7493

PR: https://git.openjdk.java.net/jdk/pull/7493

From rcastanedalo at openjdk.java.net  Fri Feb 18 08:39:55 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 18 Feb 2022 08:39:55 GMT
Subject: Integrated: 8279068: IGV: Update to work with JDK 16 and 17
In-Reply-To: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
References: <ZC_hzpwNN6TZRdumiRdtfyKEgnO_MwrBzb2bs8L5exg=.2fae9d30-c229-465e-9e06-e98880297b0a@github.com>
Message-ID: <6p_r011Z61oWtprwu5sWPFLbA9MwpJPIdlUz_Y3RduU=.b895b0f7-99cc-4d49-8599-1894d8672f17@github.com>

On Fri, 4 Feb 2022 12:30:52 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.6](https://netbeans.apache.org/download/nb126/index.html)). The upgrade introduces support for JDK versions 16 and 17, and drops support for versions earlier than 11. The change adds a check to enforce that a supported JDK version is used when building IGV, emitting an informative error message otherwise.
> 
> #### Testing
> 
> Tested the following use cases manually on all combinations of (Linux, Windows, macOS) and (JDK 11, JDK 16, JDK 17):
> 
> - 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
> - export graph as PDF
> - 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)
> 
> Also tested that building IGV on JDK 8 and 18 (EA) fails with the error message "IGV requires a JDK version between 11 and 17".
> 
> Thanks to Jesper Wilhelmsson for helping with testing on macOS.

This pull request has now been integrated.

Changeset: 7bcca769
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7bcca7692b62a37f70c757694f6acff0295371cc
Stats:     142 lines in 22 files changed: 121 ins; 0 del; 21 mod

8279068: IGV: Update to work with JDK 16 and 17

Reviewed-by: kvn, neliasso, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7347

From thartmann at openjdk.java.net  Fri Feb 18 08:57:13 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 18 Feb 2022 08:57:13 GMT
Subject: RFR: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
Message-ID: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>

After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.

Thanks,
Tobias

-------------

Commit messages:
 - 8282085: The REGISTER_DEFINITION macro is useless after JDK-8269122

Changes: https://git.openjdk.java.net/jdk/pull/7528/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7528&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282085
  Stats: 531 lines in 6 files changed: 0 ins; 529 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7528/head:pull/7528

PR: https://git.openjdk.java.net/jdk/pull/7528

From jiefu at openjdk.java.net  Fri Feb 18 09:10:51 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Feb 2022 09:10:51 GMT
Subject: RFR: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
In-Reply-To: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
References: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
Message-ID: <j5t70jp3nSf2Yr1Vis-F9gDiOk3fvalM82U6QKO5KcA=.017bf229-246d-470a-9dce-ae719ad2bcaa@github.com>

On Fri, 18 Feb 2022 08:49:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.
> 
> Thanks,
> Tobias

Looks good to me.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7528

From vlivanov at openjdk.java.net  Fri Feb 18 10:38:46 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 18 Feb 2022 10:38:46 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses
In-Reply-To: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
Message-ID: <Xj1ZSqzxXLh1b4yK2HrzPFAU50508YTmxnU0EYUHxqA=.766f1807-ba79-40ed-9f63-21f453bf2a01@github.com>

On Mon, 6 Dec 2021 09:59:44 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Outside the type system code itself, c2 usually assumes that a
> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
> klass(). To have proper support for interfaces, that can't be true as
> a type needs to be represented by an instance class and a set of
> interfaces. This patch hides the klass() accessor of
> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
> that makes that code suitable for proper interface support in a
> subsequent change. This patch doesn't add proper interface support yet
> and is mostly refactoring. "Mostly" because there are cases where the
> previous logic would use a ciKlass but the new one works with a
> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
> klass is exact or not. That extra bit of information can sometimes
> help and so could result in slightly different decisions.
> 
> To remove the klass() accessors, the new logic either relies on:
> 
> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
> toop->klass()->is_subtype_of(other_toop->klass())
> the new code is:
> toop->is_java_subtype_of(other_toop)
> 
> - variants of the klass() accessors for narrower cases like
>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>   interface in which case it returns Object),
>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>   the type is exact).
> 
> When I tested this patch, for most changes in this patch, I had the
> previous logic, the new logic and a check that verified that they
> return the same result. I ran as much testing as I could that way.

Nice work, Roland! Looks good.

Except IGP-related crashes, all tests passed (hs-tier1 - hs-tier9).

Also, you need to merge it with #6952.

Some minor cleanup suggestions follow.

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 800:

> 798:   } else if (src_type->isa_aryptr()) {
> 799:     BasicType src_elem = src_type->isa_aryptr()->elem()->array_element_basic_type();
> 800:     if (is_reference_type(src_elem) || src_elem == T_NARROWOOP) {

I find numerous new `T_NARROWOOP` checks distracting. Is it possible to get rid of them?
E.g., either normalize it to `T_OBJECT` in `array_element_basic_type()` or enhance `is_reference_type()`.

src/hotspot/share/opto/idealGraphPrinter.cpp line 490:

> 488:       const TypeInstPtr  *toop = t->isa_instptr();
> 489:       const TypeInstKlassPtr *tkls = t->isa_instklassptr();
> 490:       if (toop->is_interface() || tkls->is_interface()) {

Missing NULL checks on `toop` and `tkls`. It causes crashes when IGP is enabled.

src/hotspot/share/opto/macro.cpp line 685:

> 683:   int element_size = 0;
> 684:   BasicType basic_elem_type = T_ILLEGAL;
> 685:   const Type *field_type = NULL;

Typo: should be `const Type* field_type`.

src/hotspot/share/opto/macro.cpp line 744:

> 742:             field_type = TypeInstPtr::BOTTOM;
> 743:           } else if (field != NULL && field->is_static_constant()) {
> 744:             // This can happen if the constant oop is non-perm.

Seems like the comment is outdated. What is 'non-perm'? Out of PermGen?

src/hotspot/share/opto/type.hpp line 1198:

> 1196:   // Instance klass, ignoring any interface
> 1197:   ciInstanceKlass* instance_klass() const {
> 1198:     if (klass()->is_loaded() && klass()->is_interface()) {

Does it make sense to normalize `_klass` during construction instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6717

From thartmann at openjdk.java.net  Fri Feb 18 11:12:42 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 18 Feb 2022 11:12:42 GMT
Subject: RFR: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
In-Reply-To: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
References: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
Message-ID: <-5k5w85CpqRuGN4J1ZWzkyz1P7oBtmiB8a_XcgbbORc=.ad2b1995-2300-43ac-8e64-ce993f0bafa9@github.com>

On Fri, 18 Feb 2022 08:49:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.
> 
> Thanks,
> Tobias

Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7528

From ihse at openjdk.java.net  Fri Feb 18 11:51:30 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 18 Feb 2022 11:51:30 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
Message-ID: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>

Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)

This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.

Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).

Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)

I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.

Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

-------------

Commit messages:
 - Update description on runtime requirements for LLVM
 - Fix warning on Windows (as opposed to hiding it)
 - Add LLVM backend to hsdis. Portions of this patch contributed by luhenry, jvernee and ngasson.

Changes: https://git.openjdk.java.net/jdk/pull/7531/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7531&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253757
  Stats: 495 lines in 4 files changed: 490 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7531/head:pull/7531

PR: https://git.openjdk.java.net/jdk/pull/7531

From chagedorn at openjdk.java.net  Fri Feb 18 13:40:53 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 18 Feb 2022 13:40:53 GMT
Subject: RFR: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
In-Reply-To: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
References: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
Message-ID: <RLVz5pNyEdrOnQRzR_mIQTtWnHd72JufQO2t2NI34Lk=.a5155d57-7986-486f-9f7b-48b530d33a57@github.com>

On Fri, 18 Feb 2022 08:49:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.
> 
> Thanks,
> Tobias

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7528

From erikj at openjdk.java.net  Fri Feb 18 13:46:46 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 18 Feb 2022 13:46:46 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
References: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
Message-ID: <5pnm3YtLsoPyrNQgaN_CWS5w4g-namVs355AygUSReI=.802a2f65-8962-4166-b3f9-94b97b0ce407@github.com>

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

Build changes look good. I can't comment on the hsdis implementation.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7531

From chagedorn at openjdk.java.net  Fri Feb 18 13:47:45 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 18 Feb 2022 13:47:45 GMT
Subject: RFR: 8281122: [IR Framework] Cleanup IR matching code in preparation
 for JDK-8280378
Message-ID: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>

This patch does some restructurings and refactorings of the `IRMatcher.java` class in preparation for adding IR matching support on different compile phases with [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). There are no semantic changes of how IR matching is eventually done on regexes and how the results are checked with the `failOn` and `counts` constraints provided by the user. The only user-visible change is an improved output format of matching failures.

The old format also did not report a `counts` constraint failure correctly. It wrongly used the format of `failOn` failures which was misleading. This is also fixed by this patch.

**Example:**

@Test
@IR(counts = {IRNode.STORE_F, "!= 1"}) // fails
@IR(counts = {IRNode.STORE_F, "2", IRNode.LOAD_F, "> 1"}) // both constraints fail
public void test1() {
    fFld = 4.2f;
}

@Test
@IR(failOn = IRNode.ALLOC, counts = {IRNode.STORE_F, ">= 2"}) // failOn and counts fail
public void test2() {
    fFld = 4.2f;
    o = new Object();
}

_Failure outputs:_
<details>
  <summary>Old format</summary>


Failed IR Rules (3)
------------------
- Method "public void ir_framework.tests.Testi.test1()":
  * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
    - counts: Graph contains wrong number of nodes:
        Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
        Expected 1 but found 1 node:
          25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
  * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
    - counts: Graph contains wrong number of nodes:
        Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
        Expected 2 but found 1 node:
          25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
        Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
        Expected 1 but found 0 nodes.

- Method "public void ir_framework.tests.Testi.test2()":
  * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
    - failOn: Graph contains forbidden nodes:
        Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
        Matched forbidden node:
          1a5     movq    RSI, precise java/lang/Object: 0x00007fb188007318:Constant:exact *	# ptr
    1af     call,static  wrapper for: _new_instance_Java
    - counts: Graph contains wrong number of nodes:
        Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
        Expected 2 but found 1 node:
          25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)

</details>
<details>
  <summary>New format</summary>


Failed IR Rules (3) of Methods (2)
----------------------------------
1) Method "public void ir_framework.tests.Testi.test1()" - [Failed IR rules: 2]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
     - counts: Graph contains wrong number of nodes:
       * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
         - Failed comparison: [found] 1 != 1 [given]
         - Matched node:
           * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
   * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
     - counts: Graph contains wrong number of nodes:
       * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
         - Failed comparison: [found] 1 = 2 [given]
         - Matched node:
           * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
       * Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
         - Failed comparison: [found] 0 > 1 [given]
         - No nodes matched!

2) Method "public void ir_framework.tests.Testi.test2()" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
     - failOn: Graph contains forbidden nodes:
       * Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
         - Matched forbidden node:
           * 1a5     movq    RSI, precise java/lang/Object: 0x00007fd3c4007318:Constant:exact *	# ptr
             1af     call,static  wrapper for: _new_instance_Java
     - counts: Graph contains wrong number of nodes:
       * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
         - Failed comparison: [found] 1 >= 2 [given]
         - Matched node:
           * 25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)

</details>

**New class structure:**

The old `IRMatcher` class mixed different tasks such as parsing, IR annotation verification, IR matching and failure reporting together. This made it difficult to extend the existing code to add IR matching support on different compile phases. Therefore, the class was split to separate the different tasks:
- parser classes (`IREncodingParser`, `HotSpotPidFileParser`, `IRMethodParser` etc.)
- entity classes for the different parts of an `@IR` annotation (`IRMethod`, `IRRule`, `Counts`, `FailOn` etc.)
- match result classes for each entity class to provide a formatted failure message (`IRMethodMatchResult`, `IRRuleMatchResult` etc.)

The main structure of the new classes will be kept in JDK-8280378 but will be further improved to match the new needs.

**Testing:**
- Normal tier testing including tier5 and 6 where the IR framework tests are executed.
- Testing of this patch in Valhalla with tier1-3 + some Valhalla-specific stress testing


Thanks,
Christian

-------------

Commit messages:
 - Improve format of reported nodes and IR method line with failure counts
 - Fix report compilation output if no match with counts
 - Add separate classes for handling empty compilation outputs
 - More cleanups
 - Update copyrights and minor things
 - Some renaming and formatting cleanups
 - Splitting HotSpotPidFileParser into separate classes
 - Move IR matching classes into separate packages
 - Fix TestIRMatching test
 - Split List of Failures into FailOn and Counts MatchResult classes and rename Failure into RegexFailure + improve IR failure messages
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/a4d20190...873a8282

Changes: https://git.openjdk.java.net/jdk/pull/7533/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7533&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281122
  Stats: 3592 lines in 57 files changed: 2756 ins; 769 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7533.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7533/head:pull/7533

PR: https://git.openjdk.java.net/jdk/pull/7533

From chagedorn at openjdk.java.net  Fri Feb 18 14:01:54 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 18 Feb 2022 14:01:54 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v3]
In-Reply-To: <enxdYe9Ror3TBnLI3yetuoOQJGpdi0xs5UFlkbylE08=.d3a93e8c-c13a-4d16-8f8d-d72e80cfcaf9@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <enxdYe9Ror3TBnLI3yetuoOQJGpdi0xs5UFlkbylE08=.d3a93e8c-c13a-4d16-8f8d-d72e80cfcaf9@github.com>
Message-ID: <NXUVRzSSFvE3c6yd-I78IlivH7g1F8bP4ovMHcQJ0pA=.68f82ed3-0ed5-49bd-8fa0-2f9af61257f1@github.com>

On Thu, 17 Feb 2022 17:27:12 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

>> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
>> 
>> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
>> - Add more default IR regex's to IR-based test framework.
>
> Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Looks good, thanks for doing the updates!

I'll submit another round of testing over the weekend.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7434

From luhenry at openjdk.java.net  Fri Feb 18 14:18:59 2022
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Fri, 18 Feb 2022 14:18:59 GMT
Subject: RFR: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
References: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
Message-ID: <t8aDmngJN57Y9RpCbGGSiRiQDGqCvpncuZoiEsDaL1M=.7046707e-eff6-4672-8ddc-99d1b744e540@github.com>

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

Marked as reviewed by luhenry (Author).

Thanks again for pushing that forward! It's always good to have an alternative especially for porting to new platforms and architectures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7531

From dchuyko at openjdk.java.net  Fri Feb 18 16:06:14 2022
From: dchuyko at openjdk.java.net (Dmitry Chuyko)
Date: Fri, 18 Feb 2022 16:06:14 GMT
Subject: Integrated: 8282049: AArch64: Use ZR for integer zero immediate
 volatile stores
In-Reply-To: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
References: <YACetrbX_Zl3yrRo5X_JVUITwv9LMMLQR-oE8glCxiQ=.8f02284a-d828-4054-b4b2-5c4c8e6c9797@github.com>
Message-ID: <8YTM-JMzJpSePM87x2KBuez39KSlxUpQtgoeRt3401s=.69cd864c-05ce-49c9-b682-6cd9c0804c48@github.com>

On Thu, 17 Feb 2022 13:55:53 GMT, Dmitry Chuyko <dchuyko at openjdk.org> wrote:

> Rules and encodings for volatile stores of immediate zero byte, char, int, long and pointers were added in aarch64.ad. E.g. storeimmN0_volatile() and aarch64_enc_stlrw0(). They use stlr instructions with ZR similar to what is already done for non-volatile zero stores and str instructions.
> 
> So for example
> 
> mov x13, xzr
> stlr x13, [x11]
> 
> turns into
> 
> stlr xzr [x11]
> 
> There's no direct effect in dedicated micro-benchmarks on N1 but 1 register and 1 instruction are saved.
> 
> Testing: jtreg tier1, tier2, applications/jcstress on bare metal Graviton 2.

This pull request has now been integrated.

Changeset: 413bef68
Author:    Dmitry Chuyko <dchuyko at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/413bef6890e9ba820590aa48017c4c7b1d691d24
Stats:     91 lines in 1 file changed: 91 ins; 0 del; 0 mod

8282049: AArch64: Use ZR for integer zero immediate volatile stores

Reviewed-by: adinn, phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/7515

From dcubed at openjdk.java.net  Fri Feb 18 16:28:19 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Feb 2022 16:28:19 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
Message-ID: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>

A trivial change to fix macosx-generic typo in ProblemList.

-------------

Commit messages:
 - 8282103: fix macosx-generic typo in ProblemList

Changes: https://git.openjdk.java.net/jdk/pull/7535/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7535&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282103
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7535.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7535/head:pull/7535

PR: https://git.openjdk.java.net/jdk/pull/7535

From rriggs at openjdk.java.net  Fri Feb 18 16:28:20 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 18 Feb 2022 16:28:20 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
In-Reply-To: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
References: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
Message-ID: <GWrp0T3ZfFsutekSemTuxGzt1DPXPuNquQN62-lNAIE=.569df68e-c01a-4201-b9fb-d3aca08881d3@github.com>

On Fri, 18 Feb 2022 16:19:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial change to fix macosx-generic typo in ProblemList.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7535

From dcubed at openjdk.java.net  Fri Feb 18 16:28:21 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Feb 2022 16:28:21 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
In-Reply-To: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
References: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
Message-ID: <XHh7hij_vWCAmd2Q5TWTqiG18MmlM1csHiwaKxPm8BI=.fc8110c7-1f3b-42d8-8afb-7e01bc497804@github.com>

On Fri, 18 Feb 2022 16:19:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial change to fix macosx-generic typo in ProblemList.

This pull request has now been integrated.

Changeset: cfbfd9bf
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cfbfd9bf4123452e8bcff0ef7fbc18b14be8638c
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8282103: fix macosx-generic typo in ProblemList

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7535

From dcubed at openjdk.java.net  Fri Feb 18 16:28:20 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 18 Feb 2022 16:28:20 GMT
Subject: Integrated: 8282103: fix macosx-generic typo in ProblemList
In-Reply-To: <GWrp0T3ZfFsutekSemTuxGzt1DPXPuNquQN62-lNAIE=.569df68e-c01a-4201-b9fb-d3aca08881d3@github.com>
References: <IV_IlLRH9Onll65kXrwa40ih-3F3q4WzQp1PBoat_00=.57da9339-3e9e-44cb-b5b8-01eacbe578a6@github.com>
 <GWrp0T3ZfFsutekSemTuxGzt1DPXPuNquQN62-lNAIE=.569df68e-c01a-4201-b9fb-d3aca08881d3@github.com>
Message-ID: <dDNITaCX542-WmSkgpbEU65rpBELot7K4AHHzqEl9nQ=.dd5cc3d1-ab0f-45bd-a56a-c17a47ddae45@github.com>

On Fri, 18 Feb 2022 16:21:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial change to fix macosx-generic typo in ProblemList.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7535

From kvn at openjdk.java.net  Fri Feb 18 17:38:52 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 18 Feb 2022 17:38:52 GMT
Subject: RFR: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
In-Reply-To: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
References: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
Message-ID: <L7ERPq6uxztVhMHvP0S7udrYooX8tiw1EtUZ5_Yh_sI=.c507ce67-9f2a-45be-9081-4e7c0e6ae7b4@github.com>

On Fri, 18 Feb 2022 08:49:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.
> 
> Thanks,
> Tobias

Marked as reviewed by kvn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7528

From Divino.Cesar at microsoft.com  Fri Feb 18 17:53:18 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Fri, 18 Feb 2022 17:53:18 +0000
Subject: RFC : Approach to handle Allocation Merges in C2 Scalar
 Replacement
In-Reply-To: <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
Message-ID: <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi Vladimir, thank you for sharing this idea.

I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating specialized memory operations conditionally using the different bases.


Regards,
Cesar

________________________________________
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Sent: February 17, 2022 7:37 AM
To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
Cc: Brian Stafford; Martijn Verburg
Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement


> But depending on the actual shape of the base pointer (here it's
> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
> or even impossible (e.g., for complex loop variant conditions) to
> separate instance slices.

I'd like to correct myself. After thinking more about the problem, I see
a universal way to scalarize clusters of interfering non-escaping
allocations even in presence of accesses with indeterminate base.

The crucial property for such cluster of interacting non-escaping
allocations is for any memory access its base is either part of the
cluster or not (it's a static property for every access). Then, when it
is part of the cluster, then the number of possible base values at
runtime is finite and is a subset of the cluster.

So, memory graph for the cluster can be scalarized as follows:

   (1) separate memory graph for the cluster

   (2) on the newly constructed graph:

      (a) replace every base pointer with an ID ("selector id") and
recreate data graph for selector IDs from base pointers graph;

      (b) for accesses with indeterminate base pointer, replace them
with a merge of states from relevant allocations selected by "selector id"

      (c) after 2b, all memory accesses from the cluster memory graph
should have fixed base pointing at a particular allocation

   (3) scalarize individual allocations from the cluster one by one
(since they are independent now)

      - additional transformation (like, split-through-phi) should
simplify the graph by reducing the number of cases at merge points to
care about (ideally, leaving only a single one);



As an illustration:

   val = Load (AddP (Phi R base1 base2) offset) mem # load A.i

==(pseudo-code)==>

   selector = (Phi R #base1 #base2)

   if (selector == #base1) {
     val1 = Load (base1 + offset) mem
   } else if (selector == #base2) {
     val2 = Load (base2 + offset) mem
   } else {
     halt(); // impossible
   }

   val = Phi(R1, val1, val2)

======

   Store (AddP (Phi R base1 base2) offset) mem v # store A.i v

==(pseudo-code)==>

   selector = (Phi R #base1 #base2)

   if (selector == #base1) {
     Store base1 mem v ==> mem1
   } else if (selector == #base2) {
     Store base2 mem v ==> mem2
   } else {
     halt(); // impossible
   }

   mem = Phi(R1, mem1, mem2);


Best regards,
Vladimir Ivanov

>
> So, gradual approach seems the way to go:
>    (1) split memory graph for clusters of interacting non-escaping
> allocations;
>
>    (2) perform adhoc transformation targeted at untangling aliasing
> accesses (e.g, split-through-phi);
>
>    (3) extract unique instance types where possible, thus making the
> corresponding allocation scalar replaceable
>
> =====================================================================
>
> Also, one observation: interacting allocations don't have to be of the
> same class.
>
>      static int testPolluted(int r, boolean b) {
>          A obj1 = new B1(r);
>          A obj2 = new B2(r);
>
>          A obj = (b ? obj1 : obj2);
>          for (int i = 1; i < r; i++) {
>              obj.i++;
>          }
>
>          return obj1.i + obj2.i;
>      }
>
> Requiring unique instance types to perform SR (and not enhancing SR to
> handle aliasing allocations case) helps avoid some challenges in
> instance rematerialization logic at safepoints, because actual shape of
> the scalarized object (its class and exact set of fields) becomes a
> runtime property.
>
> Best regards,
> Vladimir Ivanov
>
>>>>
>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>> correct memory states for the new loads above the phi which quickly
>>>> becomes quite a challenging task.
>>>
>>> Especially in loops. Actually I did tried such approach before and I
>>> agree that it is hard.
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>>
>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>      p0 = Allocate(...);
>>>>>      ...
>>>>>      p0.x = first;
>>>>>      p0.y = second;
>>>>>
>>>>>      if (cond) {
>>>>>          p1 = Allocate(...);
>>>>>          ...
>>>>>          p1.x = second;
>>>>>          p1.y = first;
>>>>>      }
>>>>>
>>>>>      p = phi(p0, p1) // unused and will be removed
>>>>>
>>>>>
>>>>>      return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>> }
>>>>>
>>>>> Thanks,
>>>>> Vladimir K
>>>>>
>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>> hotspot-compiler-dev.)
>>>>>>
>>>>>> Hi Cesar,
>>>>>>
>>>>>> Thanks for looking into enhancing EA.
>>>>>>
>>>>>> Overall, the proposal looks reasonable.
>>>>>>
>>>>>> I suggest to look more closely at split_unique_types().
>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>
>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>> allocations.
>>>>>>
>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>> clusters of allocations.
>>>>>>
>>>>>> One thing to take care of: scalar replacement relies on
>>>>>> TypeOopPtr::instance_id().
>>>>>>
>>>>>>    // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>    // a particular instance of this type which is distinct.
>>>>>>    // This is the node index of the allocation node creating this
>>>>>> instance.
>>>>>>    int           _instance_id;
>>>>>>
>>>>>> It'll break when multiple allocations are in play.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>> Hi there again!
>>>>>>>
>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>> least partially
>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>
>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>> merged after a
>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>> situation.
>>>>>>>
>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>      Point p = new Point(x, y);
>>>>>>>      if (cond)
>>>>>>>          p = new Point(y, x);
>>>>>>>      // Allocations for p are merged here.
>>>>>>>      return p.calc();
>>>>>>> }
>>>>>>>
>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>> will not
>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>      p0 = Allocate(...);
>>>>>>>      ...
>>>>>>>      p0.x = first;
>>>>>>>      p0.y = second;
>>>>>>>
>>>>>>>      if (cond) {
>>>>>>>          p1 = Allocate(...);
>>>>>>>          ...
>>>>>>>          p1.x = second;
>>>>>>>          p1.y = first;
>>>>>>>      }
>>>>>>>
>>>>>>>      p = phi(p0, p1)
>>>>>>>
>>>>>>>      return p.x - p.y;
>>>>>>> }
>>>>>>>
>>>>>>> However, one of the constraints implemented here [2],
>>>>>>> specifically the third
>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>
>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>> replace the Phi
>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>> of the objects
>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>> this after the
>>>>>>> transformation:
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>      p0 = Allocate(...);
>>>>>>>      ...
>>>>>>>      p0.x = first;
>>>>>>>      p0.y = second;
>>>>>>>
>>>>>>>      if (cond) {
>>>>>>>          p1 = Allocate(...);
>>>>>>>          ...
>>>>>>>          p1.x = second;
>>>>>>>          p1.y = first;
>>>>>>>      }
>>>>>>>
>>>>>>>      pX = phi(first, second)
>>>>>>>      pY = phi(second, first)
>>>>>>>
>>>>>>>      return pX - pY;
>>>>>>> }
>>>>>>>
>>>>>>> I understand that this transformation might not be applicable for
>>>>>>> all cases and
>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>> me that much of
>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>> of the Scalar
>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>> as possible.
>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>
>>>>>>> split_phis(phi)
>>>>>>>      # If output of phi escapes, or something uses its identity, etc
>>>>>>>      # then we can't remove it. The conditions here might
>>>>>>> possible be the
>>>>>>>      # same as the ones implemented in
>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>      if cant_remove_phi_output(phi)
>>>>>>>          return ;
>>>>>>>
>>>>>>>      # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>> field F
>>>>>>>      # member of the object resulting from `phi`.
>>>>>>>      fields_used = collect_fields_used_after_phi(phi)
>>>>>>>
>>>>>>>      foreach field in fields_used
>>>>>>>          producers = {}
>>>>>>>
>>>>>>>          # Create a list with the last Store for each field
>>>>>>> "field" on the
>>>>>>>          # scope of each of the Phi input objects.
>>>>>>>          foreach o in phi.inputs
>>>>>>>              # The function called below might re-use a lot of
>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>              producers += last_store_to_o_field(0, field)
>>>>>>>          # Create a new phi node whose inputs are the Store's to
>>>>>>> 'field'
>>>>>>>          field_phi = create_new_phi(producers)
>>>>>>>
>>>>>>>          update_consumers(field, field_phi)
>>>>>>>
>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>> [3] step just
>>>>>>> after EA but before the constraint checks in
>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>> implementation goes through
>>>>>>> the following major phases:
>>>>>>>
>>>>>>>      1. Identify the Escape Status of objects.
>>>>>>>      2. Adjust object Escape and/or Scalar Replacement status
>>>>>>> based on a set of constraints.
>>>>>>>      3. Make call to Split_unique_types [4].
>>>>>>>      4 Iterate over object and array allocations.
>>>>>>>          4.1 Check if allocation can be eliminated.
>>>>>>>          4.2 Perform scalar replacement. Replace uses of object
>>>>>>> in Safepoints.
>>>>>>>          4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>
>>>>>>> The transformation that I am proposing would change the overall
>>>>>>> flow to look
>>>>>>> like this:
>>>>>>>
>>>>>>>      1. Identify the Escape Status of objects.
>>>>>>>      2. ----> New: "Split phi functions" <----
>>>>>>>      2. Adjust object Escape and/or Scalar Replacement status
>>>>>>> based on a set of constraints.
>>>>>>>      3. Make call to Split_unique_types [14].
>>>>>>>      4 Iterate over object and array allocations.
>>>>>>>          4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>> be eliminated" <----
>>>>>>>          4.2 Perform scalar replacement. Replace uses of object
>>>>>>> in Safepoints.
>>>>>>>          4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>
>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>> time to review
>>>>>>> this!
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Cesar
>>>>>>>
>>>>>>> Notes:
>>>>>>>
>>>>>>>      [1] I am not sure yet how this approach will play with the
>>>>>>> case of a merge
>>>>>>>          with NULL.
>>>>>>>      [2]
>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fescape.cpp%23L1809&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Ce13b0a3de30e43d7ac4408d9f22b75c5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637807090747649306%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=WruWqIgGVIzIFIG0gD0%2FEIQm40euLx6FZMexotJVrlE%3D&amp;reserved=0
>>>>>>>
>>>>>>>
>>>>>>>      [3] Another option would be to "patch" the current
>>>>>>> implementation to be able
>>>>>>>          to handle the merges. I am not certain that the "patch"
>>>>>>> approach would be
>>>>>>>          better, however, the "pre-process" approach is certainly
>>>>>>> much easier to test
>>>>>>>          and more readable.
>>>>>>>
>>>>>>>      [4] I cannot say I understand 100% the effects of executing
>>>>>>>          split_unique_types(). Would the transformation that I am
>>>>>>> proposing need to
>>>>>>>          be after the call to split_unique_types?

From yzheng at openjdk.java.net  Fri Feb 18 18:03:54 2022
From: yzheng at openjdk.java.net (Yudi Zheng)
Date: Fri, 18 Feb 2022 18:03:54 GMT
Subject: Integrated: 8282044: [JVMCI] Export _sha3_implCompress,
 _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.
In-Reply-To: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
References: <ab-Ck1EHKvB6LZg7Wu64f3btKmwUrctaU8QKSoMMGHk=.58d9c33c-5ff2-48ff-aab7-95c8424aeb88@github.com>
Message-ID: <nvam-FHaQe6E6YcLMZHlfzkfh_W_whrnnAG4bTJxvOk=.a55161ba-9201-4145-a866-df3a1099aca4@github.com>

On Thu, 17 Feb 2022 09:48:42 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

> This PR allows JVMCI compiler to reuse _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs.

This pull request has now been integrated.

Changeset: 3943c89b
Author:    Yudi Zheng <yzheng at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3943c89b9b71d8c1fda3ba88fd833f08723202f0
Stats:     11 lines in 2 files changed: 9 ins; 2 del; 0 mod

8282044: [JVMCI] Export _sha3_implCompress, _md5_implCompress and aarch64::_has_negatives stubs to JVMCI compiler.

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7511

From duke at openjdk.java.net  Fri Feb 18 19:24:28 2022
From: duke at openjdk.java.net (Foivos)
Date: Fri, 18 Feb 2022 19:24:28 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle hidden
 classes correctly
Message-ID: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>

https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`

This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

-------------

Commit messages:
 - Fix handling of hidden classes in MetaUtil
 - Test MetaUtil methods toInternalName & internalNameToJava

Changes: https://git.openjdk.java.net/jdk/pull/7346/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7346&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281266
  Stats: 33 lines in 2 files changed: 8 ins; 5 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7346.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7346/head:pull/7346

PR: https://git.openjdk.java.net/jdk/pull/7346

From sgehwolf at openjdk.java.net  Fri Feb 18 19:24:28 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 18 Feb 2022 19:24:28 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
Message-ID: <x0kNWyYczfJBv0YkIGX_gf8aqxu_QColLEB9g06iZhA=.2201a12f-3770-45b1-8136-8ddf1e4fa8e4@github.com>

On Fri, 4 Feb 2022 12:01:46 GMT, Foivos <duke at openjdk.java.net> wrote:

> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
> 
> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

@zakkak Works for Red Hat is covered by the RH OCA.

I've created a bug for this here: https://bugs.openjdk.java.net/browse/JDK-8281266

@robilad Could someone look at the OCA verification status for @zakkak please?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From sgehwolf at openjdk.java.net  Fri Feb 18 19:24:30 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 18 Feb 2022 19:24:30 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <x0kNWyYczfJBv0YkIGX_gf8aqxu_QColLEB9g06iZhA=.2201a12f-3770-45b1-8136-8ddf1e4fa8e4@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
 <x0kNWyYczfJBv0YkIGX_gf8aqxu_QColLEB9g06iZhA=.2201a12f-3770-45b1-8136-8ddf1e4fa8e4@github.com>
Message-ID: <QNVZHN0DvQqD9aPG1wXoxOkUtDbGcj3jqdVp-qw_e3Y=.f45a5f82-4bf1-45c2-a461-9ed5f66641d7@github.com>

On Fri, 4 Feb 2022 14:03:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> I've created a bug for this here: https://bugs.openjdk.java.net/browse/JDK-8281266

@zakkak If you update the PR title to the bug synopsis the bots should add the issue just fine. I.e. change it to:

8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle hidden classes correctly

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From robilad at openjdk.java.net  Fri Feb 18 19:24:30 2022
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Fri, 18 Feb 2022 19:24:30 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
Message-ID: <UjFt5EZjP9mb4dxe4op35SqMzvHauaa-ZlnVB_Zr3lY=.3c39c8ab-f179-4042-bae7-b167a5d04630@github.com>

On Fri, 4 Feb 2022 12:01:46 GMT, Foivos <duke at openjdk.java.net> wrote:

> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
> 
> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

Done, thanks for the ping!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From coleenp at openjdk.java.net  Fri Feb 18 20:36:19 2022
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 18 Feb 2022 20:36:19 GMT
Subject: RFR: 8271008: appcds/*/MethodHandlesAsCollectorTest.java tests time
 out because of excessive GC (CodeCache GC Threshold) in loom
Message-ID: <kYn3797y65G_uT3f16-_Nfg0HNEHOIEKOs91EUzkOzc=.b3155dcd-d36f-4203-963a-c4ddb2eac9eb@github.com>

In Loom there's a full heap walk when the sweeper is triggered.  Many of the triggers in this test case are for the adapters created by the test, which are not deallocated.  Since there is a fall back to other code cache heap areas for NonNMethod and for NMethodProfiled, made the function CodeCache::reverse_free_ratio() examine the total code cache available rather than the specific area that it is allocating into.  The compilation policy also uses this to increase the C1 compile threshold so also uses the entire free code cache size to calculate new threshold (ask @TobiHartmann about this).  Thanks to Tobias for the discussion for this fix.
Tested with tier1-4.

-------------

Commit messages:
 - 8271008: appcds/*/MethodHandlesAsCollectorTest.java tests time out because of excessive GC (CodeCache GC Threshold) in loom

Changes: https://git.openjdk.java.net/jdk/pull/7514/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7514&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271008
  Stats: 36 lines in 5 files changed: 6 ins; 10 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7514.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7514/head:pull/7514

PR: https://git.openjdk.java.net/jdk/pull/7514

From duke at openjdk.java.net  Sat Feb 19 08:04:52 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Sat, 19 Feb 2022 08:04:52 GMT
Subject: RFR: 8281544: assert(VM_Version::supports_avx512bw()) failed for
 Tests jdk/incubator/vector/ [v2]
In-Reply-To: <Q5adA1YTFVDGwhi19AK6KGxB4OW-dqjmIgXRlL9vA2Y=.5a649118-ceab-4f0e-ad4b-a7d051c50e63@github.com>
References: <NuMg_3wZ7GTF1QIuTBDb0t0NJ1YlzWn795AtnDEdNbs=.20bb8fe7-b5ec-4246-a236-5653e0d2d546@github.com>
 <MkCnJurj0-UxLlqU8dgicJKsvE39hvJl63VHvi_wm8g=.97e9ed92-16a0-4980-948a-524fd8bb05fd@github.com>
 <Q5adA1YTFVDGwhi19AK6KGxB4OW-dqjmIgXRlL9vA2Y=.5a649118-ceab-4f0e-ad4b-a7d051c50e63@github.com>
Message-ID: <lmoGVDdFE-oSMaycj1cZ85s7jP82Z9MDOm56JfzTjDE=.813b01b8-121a-484b-963d-75db4506c57f@github.com>

On Thu, 17 Feb 2022 20:03:38 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix indentation
>
> Looks good!

Thanks @neliasso @TobiHartmann @vnkozlov for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7510

From pli at openjdk.java.net  Mon Feb 21 06:19:26 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 21 Feb 2022 06:19:26 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
Message-ID: <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>

> ### Background
> 
> Post loop vectorization is a C2 compiler optimization in an experimental
> VM feature called PostLoopMultiversioning. It transforms the range-check
> eliminated post loop to a 1-iteration vectorized loop with vector mask.
> This optimization was contributed by Intel in 2016 to support x86 AVX512
> masked vector instructions. However, it was disabled soon after an issue
> was found. Due to insufficient maintenance in these years, multiple bugs
> have been accumulated inside. But we (Arm) still think this is a useful
> framework for vector mask support in C2 auto-vectorized loops, for both
> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
> post loop vectorization.
> 
> ### Changes in this patch
> 
> This patch reworks post loop vectorization. The most significant change
> is removing vector mask support in C2 x86 backend and re-implementing
> it in the mid-end. With this, we can re-enable post loop vectorization
> for platforms other than x86.
> 
> Previous implementation hard-codes x86 k1 register as a reserved AVX512
> opmask register and defines two routines (setvectmask/restorevectmask)
> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
> AVX512 instructions as unmasked by default, generated vector masks are
> no longer used in AVX512 vector instructions. To fix incorrect codegen
> and add vector mask support for more platforms, we turn to add a vector
> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
> to generate a mask and replace all Load/Store nodes in the post loop
> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
> IR form is exactly the same to those which are used in VectorAPI mask
> support. For now, we only add mask inputs for Load/Store nodes because
> we don't have reduction operations supported in post loop vectorization.
> After this change, the x86 k1 register is no longer reserved and can be
> allocated when PostLoopMultiversioning is enabled.
> 
> Besides this change, we have fixed a compiler crash and five incorrect
> result issues with post loop vectorization.
> 
> **I) C2 crashes with segmentation fault in strip-mined loops**
> 
> Previous implementation was done before C2 loop strip-mining was merged
> into JDK master so it didn't take strip-mined loops into consideration.
> In C2's strip mined loops, post loop is not the sibling of the main loop
> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
> post loop from strip-mined main loop.
> 
> **II) Incorrect result issues with post loop vectorization**
> 
> We have also fixed five incorrect vectorization issues. Some of them are
> hidden deep and can only be reproduced with corner cases. These issues
> have a common cause that it assumes the post loop can be vectorized if
> the vectorization in corresponding main loop is successful. But in many
> cases this assumption is wrong. Below are details.
> 
> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
> 
> This issue can be reproduced by below loop where only some operations in
> the loop body are vectorizable.
> 
>   for (int i = 0; i < 10000; i++) {
>     res[i] = a[i] * b[i];
>     k = 3 * k + 1;
>   }
> 
> In the main loop, superword can work well if parts of the operations in
> loop body are not vectorizable since those parts can be unrolled only.
> But for post loops, we don't create vectors through combining scalar IRs
> generated from loop unrolling. Instead, we are doing scalars to vectors
> replacement for all operations in the loop body. Hence, all operations
> should be either vectorized together or not vectorized at all. To fix
> this kind of cases, we add an extra field "_slp_vector_pack_count" in
> CountedLoopNode to record the eventual count of vector packs in the main
> loop. This value is then passed to post loop and compared with post loop
> pack count. Vectorization will be bailed out in post loop if it creates
> more vector packs than in the main loop.
> 
> - **[Issue-2] Incorrect result in loops with growing-down vectors**
> 
> This issue appears with growing-down vectors, that is, vectors that grow
> to smaller memory address as the loop iterates. It can be reproduced by
> below counting-up loop with negative scale value in array index.
> 
>   for (int i = 0; i < 10000; i++) {
>     a[MAX - i] = b[MAX - i];
>   }
> 
> Cause of this issue is that for a growing-down vector, generated vector
> mask value has reversed vector-lane order so it masks incorrect vector
> lanes. Note that if negative scale value appears in counting-down loops,
> the vector will be growing up. With this rule, we fix the issue by only
> allowing positive array index scales in counting-up loops and negative
> array index scales in counting-down loops. This check is done with the
> help of SWPointer by comparing scale values in each memory access in the
> loop with loop stride value.
> 
> - **[Issue-3] Incorrect result in manually unrolled loops**
> 
> This issue can be reproduced by below manually unrolled loop.
> 
>   for (int i = 0; i < 10000; i += 2) {
>     c[i] = a[i] + b[i];
>     c[i + 1] = a[i + 1] * b[i + 1];
>   }
> 
> In this loop, operations in the 2nd statement duplicate those in the 1st
> statement with a small memory address offset. Vectorization in the main
> loop works well in this case because C2 does further unrolling and pack
> combination. But we cannot vectorize the post loop through replacement
> from scalars to vectors because it creates duplicated vector operations.
> To fix this, we restrict post loop vectorization to loops with stride
> values of 1 or -1.
> 
> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
> 
> This issue is found after we enable post loop vectorization for AArch64.
> It's reproducible by multiple array operations with different element
> sizes inside a loop. On x86, there is no issue because the values of x86
> AVX512 opmasks only depend on which vector lanes are active. But AArch64
> is different - the values of SVE predicates also depend on lane size of
> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
> sizes, we should use different vector masks. For now, we just support
> loops with only one vector element size, i.e., "int + float" vectors in
> a single loop is ok but "int + double" vectors in a single loop is not
> vectorizable. This fix also enables subword vectors support to make all
> primitive type array operations vectorizable.
> 
> - **[Issue-5] Incorrect result in loops with potential data dependence**
> 
> This issue can be reproduced by below corner case on AArch64 only.
> 
>   for (int i = 0; i < 10000; i++) {
>     a[i] = x;
>     a[i + OFFSET] = y;
>   }
> 
> In this case, two stores in the loop have data dependence if the OFFSET
> value is smaller than the vector length. So we cannot do vectorization
> through replacing scalars to vectors. But the main loop vectorization
> in this case is successful on AArch64 because AArch64 has partial vector
> load/store support. It splits vector fill with different values in lanes
> to several smaller-sized fills. In this patch, we add additional data
> dependence check for this kind of cases. The check is also done with the
> help of SWPointer class. In this check, we require that every two memory
> accesses (with at least one store) of the same element type (or subword
> size) in the loop has the same array index expression.
> 
> ### Tests
> 
> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
> experimental VM option "PostLoopMultiversioning" turned on. We found no
> issue in all tests. We notice that those existing cases are not enough
> because some of above issues are not spotted by them. We would like to
> add some new cases but we found existing vectorization tests are a bit
> cumbersome - golden results must be pre-calculated and hard-coded in the
> test code for correctness verification. Thus, in this patch, we propose
> a new vectorization testing framework.
> 
> Our new framework brings a simpler way to add new cases. For a new test
> case, we only need to create a new method annotated with "@Test". The
> test runner will invoke each annotated method twice automatically. First
> time it runs in the interpreter and second time it's forced compiled by
> C2. Then the two return results are compared. So in this framework each
> test method should return a primitive value or an array of primitives.
> In this way, no extra verification code for vectorization correctness is
> required. This test runner is still jtreg-based and takes advantages of
> the jtreg WhiteBox API, which enables test methods running at specific
> compilation levels. Each test class inside is also jtreg-based. It just
> need to inherit from the test runner class and run with two additional
> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
> 
> ### Summary & Future work
> 
> In this patch, we reworked post loop vectorization. We made it platform
> independent and fixed several issues inside. We also implemented a new
> vectorization testing framework with many test cases inside. Meanwhile,
> we did some code cleanups.
> 
> This patch only touches C2 code guarded with PostLoopMultiversioning,
> except a few data structure changes. So, there's no behavior change when
> experimental VM option PostLoopMultiversioning is off. Also, to reduce
> risks, we still propose to keep post loop vectorization experimental for
> now. But if it receives positive feedback, we would like to change it to
> non-experimental in the future.

Pengfei Li 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 postloop
   
   Change-Id: I503edb75f0f626569c776416bfef09651935979c
 - Update copyright year and rename a function
   
   Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
 - Merge branch 'master' into postloop
   
   Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
 - Fix issues in newly added test framework
   
   Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
 - Merge branch 'master' into postloop
   
   Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
 - 8183390: Fix and re-enable post loop vectorization
   
   ** Background
   
   Post loop vectorization is a C2 compiler optimization in an experimental
   VM feature called PostLoopMultiversioning. It transforms the range-check
   eliminated post loop to a 1-iteration vectorized loop with vector mask.
   This optimization was contributed by Intel in 2016 to support x86 AVX512
   masked vector instructions. However, it was disabled soon after an issue
   was found. Due to insufficient maintenance in these years, multiple bugs
   have been accumulated inside. But we (Arm) still think this is a useful
   framework for vector mask support in C2 auto-vectorized loops, for both
   x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
   post loop vectorization.
   
   ** Changes in this patch
   
   This patch reworks post loop vectorization. The most significant change
   is removing vector mask support in C2 x86 backend and re-implementing
   it in the mid-end. With this, we can re-enable post loop vectorization
   for platforms other than x86.
   
   Previous implementation hard-codes x86 k1 register as a reserved AVX512
   opmask register and defines two routines (setvectmask/restorevectmask)
   to set and restore the value of k1. But after JDK-8211251 which encodes
   AVX512 instructions as unmasked by default, generated vector masks are
   no longer used in AVX512 vector instructions. To fix incorrect codegen
   and add vector mask support for more platforms, we turn to add a vector
   mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
   to generate a mask and replace all Load/Store nodes in the post loop
   into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
   IR form is exactly the same to those which are used in VectorAPI mask
   support. For now, we only add mask inputs for Load/Store nodes because
   we don't have reduction operations supported in post loop vectorization.
   After this change, the x86 k1 register is no longer reserved and can be
   allocated when PostLoopMultiversioning is enabled.
   
   Besides this change, we have fixed a compiler crash and five incorrect
   result issues with post loop vectorization.
   
   - 1) C2 crashes with segmentation fault in strip-mined loops
   
   Previous implementation was done before C2 loop strip-mining was merged
   into JDK master so it didn't take strip-mined loops into consideration.
   In C2's strip mined loops, post loop is not the sibling of the main loop
   in ideal loop tree. Instead, it's the sibling of the main loop's parent.
   This patch fixed a SIGSEGV issue caused by NULL pointer when locating
   post loop from strip-mined main loop.
   
   - 2) Incorrect result issues with post loop vectorization
   
   We have also fixed five incorrect vectorization issues. Some of them are
   hidden deep and can only be reproduced with corner cases. These issues
   have a common cause that it assumes the post loop can be vectorized if
   the vectorization in corresponding main loop is successful. But in many
   cases this assumption is wrong. Below are details.
   
   [Issue-1] Incorrect vectorization for partial vectorizable loops
   
   This issue can be reproduced by below loop where only some operations in
   the loop body are vectorizable.
   
     for (int i = 0; i < 10000; i++) {
       res[i] = a[i] * b[i];
       k = 3 * k + 1;
     }
   
   In the main loop, superword can work well if parts of the operations in
   loop body are not vectorizable since those parts can be unrolled only.
   But for post loops, we don't create vectors through combining scalar IRs
   generated from loop unrolling. Instead, we are doing scalars to vectors
   replacement for all operations in the loop body. Hence, all operations
   should be either vectorized together or not vectorized at all. To fix
   this kind of cases, we add an extra field "_slp_vector_pack_count" in
   CountedLoopNode to record the eventual count of vector packs in the main
   loop. This value is then passed to post loop and compared with post loop
   pack count. Vectorization will be bailed out in post loop if it creates
   more vector packs than in the main loop.
   
   [Issue-2] Incorrect result in loops with growing-down vectors
   
   This issue appears with growing-down vectors, that is, vectors that grow
   to smaller memory address as the loop iterates. It can be reproduced by
   below counting-up loop with negative scale value in array index.
   
     for (int i = 0; i < 10000; i++) {
       a[MAX - i] = b[MAX - i];
     }
   
   Cause of this issue is that for a growing-down vector, generated vector
   mask value has reversed vector-lane order so it masks incorrect vector
   lanes. Note that if negative scale value appears in counting-down loops,
   the vector will be growing up. With this rule, we fix the issue by only
   allowing positive array index scales in counting-up loops and negative
   array index scales in counting-down loops. This check is done with the
   help of SWPointer by comparing scale values in each memory access in the
   loop with loop stride value.
   
   [Issue-3] Incorrect result in manually unrolled loops
   
   This issue can be reproduced by below manually unrolled loop.
   
     for (int i = 0; i < 10000; i += 2) {
       c[i] = a[i] + b[i];
       c[i + 1] = a[i + 1] * b[i + 1];
     }
   
   In this loop, operations in the 2nd statement duplicate those in the 1st
   statement with a small memory address offset. Vectorization in the main
   loop works well in this case because C2 does further unrolling and pack
   combination. But we cannot vectorize the post loop through replacement
   from scalars to vectors because it creates duplicated vector operations.
   To fix this, we restrict post loop vectorization to loops with stride
   values of 1 or -1.
   
   [Issue-4] Incorrect result in loops with mixed vector element sizes
   
   This issue is found after we enable post loop vectorization for AArch64.
   It's reproducible by multiple array operations with different element
   sizes inside a loop. On x86, there is no issue because the values of x86
   AVX512 opmasks only depend on which vector lanes are active. But AArch64
   is different - the values of SVE predicates also depend on lane size of
   the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
   sizes, we should use different vector masks. For now, we just support
   loops with only one vector element size, i.e., "int + float" vectors in
   a single loop is ok but "int + double" vectors in a single loop is not
   vectorizable. This fix also enables subword vectors support to make all
   primitive type array operations vectorizable.
   
   [Issue-5] Incorrect result in loops with potential data dependence
   
   This issue can be reproduced by below corner case on AArch64 only.
   
     for (int i = 0; i < 10000; i++) {
       a[i] = x;
       a[i + OFFSET] = y;
     }
   
   In this case, two stores in the loop have data dependence if the OFFSET
   value is smaller than the vector length. So we cannot do vectorization
   through replacing scalars to vectors. But the main loop vectorization
   in this case is successful on AArch64 because AArch64 has partial vector
   load/store support. It splits vector fill with different values in lanes
   to several smaller-sized fills. In this patch, we add additional data
   dependence check for this kind of cases. The check is also done with the
   help of SWPointer class. In this check, we require that every two memory
   accesses (with at least one store) of the same element type (or subword
   size) in the loop has the same array index expression.
   
   ** Tests
   
   So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
   experimental VM option "PostLoopMultiversioning" turned on. We found no
   issue in all tests. We notice that those existing cases are not enough
   because some of above issues are not spotted by them. We would like to
   add some new cases but we found existing vectorization tests are a bit
   cumbersome - golden results must be pre-calculated and hard-coded in the
   test code for correctness verification. Thus, in this patch, we propose
   a new vectorization testing framework.
   
   Our new framework brings a simpler way to add new cases. For a new test
   case, we only need to create a new method annotated with "@Test". The
   test runner will invoke each annotated method twice automatically. First
   time it runs in the interpreter and second time it's forced compiled by
   C2. Then the two return results are compared. So in this framework each
   test method should return a primitive value or an array of primitives.
   In this way, no extra verification code for vectorization correctness is
   required. This test runner is still jtreg-based and takes advantages of
   the jtreg WhiteBox API, which enables test methods running at specific
   compilation levels. Each test class inside is also jtreg-based. It just
   need to inherit from the test runner class and run with two additional
   options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
   
   ** Summary & Future work
   
   In this patch, we reworked post loop vectorization. We made it platform
   independent and fixed several issues inside. We also implemented a new
   vectorization testing framework with many test cases inside. Meanwhile,
   we did some code cleanups.
   
   This patch only touches C2 code guarded with PostLoopMultiversioning,
   except a few data structure changes. So, there's no behavior change when
   experimental VM option PostLoopMultiversioning is off. Also, to reduce
   risks, we still propose to keep post loop vectorization experimental for
   now. But if it receives positive feedback, we would like to change it to
   non-experimental in the future.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6828/files
  - new: https://git.openjdk.java.net/jdk/pull/6828/files/56575886..ea0598ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6828&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6828&range=02-03

  Stats: 57104 lines in 1757 files changed: 38847 ins; 10161 del; 8096 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6828.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6828/head:pull/6828

PR: https://git.openjdk.java.net/jdk/pull/6828

From thartmann at openjdk.java.net  Mon Feb 21 07:06:51 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 21 Feb 2022 07:06:51 GMT
Subject: RFR: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
In-Reply-To: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
References: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
Message-ID: <0Rj1VmsPGv8gYuj-k-Z3b5xRfqwP9S15UaxWCe01ArU=.0f082fd3-4205-4483-875b-5fbb352246a9@github.com>

On Fri, 18 Feb 2022 08:49:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.
> 
> Thanks,
> Tobias

Thanks Christian and Vladimir.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7528

From thartmann at openjdk.java.net  Mon Feb 21 07:06:52 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 21 Feb 2022 07:06:52 GMT
Subject: Integrated: 8282085: The REGISTER_DEFINITION macro is useless after
 JDK-8269122
In-Reply-To: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
References: <NqKNhL0JNrV6CqIkFHtepXVU98KlX00hFhYja01N2M0=.8d74b57a-d2c5-488c-99c0-180b65161cfa@github.com>
Message-ID: <gXuYsmiTKEB0sVf4v7mZrcSy1LdaKtd1zTwCX1CUM_Q=.0a8e9d0a-da79-487b-b4c9-b48a960d1365@github.com>

On Fri, 18 Feb 2022 08:49:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After [JDK-8269122](https://bugs.openjdk.java.net/browse/JDK-8269122) (https://github.com/openjdk/jdk/commit/4d2412ef3e1068063acc954a00b4db0fa4b5affb), `REGISTER_DEFINITION` is empty and should be removed together with the files using it.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 8563d86f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8563d86f2cce0dc9d1411bf9276a00bca0515efd
Stats:     531 lines in 6 files changed: 0 ins; 529 del; 2 mod

8282085: The REGISTER_DEFINITION macro is useless after JDK-8269122

Reviewed-by: jiefu, chagedorn, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7528

From duke at openjdk.java.net  Mon Feb 21 07:08:50 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 21 Feb 2022 07:08:50 GMT
Subject: Integrated: 8281544: assert(VM_Version::supports_avx512bw()) failed
 for Tests jdk/incubator/vector/
In-Reply-To: <NuMg_3wZ7GTF1QIuTBDb0t0NJ1YlzWn795AtnDEdNbs=.20bb8fe7-b5ec-4246-a236-5653e0d2d546@github.com>
References: <NuMg_3wZ7GTF1QIuTBDb0t0NJ1YlzWn795AtnDEdNbs=.20bb8fe7-b5ec-4246-a236-5653e0d2d546@github.com>
Message-ID: <8CY3PKUGwuGTB6D-mzhR6218exbBBgA_4xR8n0joyx4=.461f0fd9-a069-4616-9a7e-25d716831d1b@github.com>

On Thu, 17 Feb 2022 07:51:42 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> `ZSaveLiveRegisters::ZSaveLiveRegisters` stores live registers, and later they are loaded again.
> This includes opmask registers, which are part of AVX512. However, not all platforms have all of the AVX512 instructions.
> For example Knights Landing has general AVX512 support and makes use of optmask registers, but does not support the AVX512 BW subset of instructions, specifically it does not support the `kmovql` instruction. Platforms like Cannon Landing have support for AVX512 BW.
> 
> Solution: in analogy to `RegisterSaver::save_live_registers`, which seems to perform a very similar task, use `MacroAssembler::kmov` instead of `kmovql` directly. Internally, `kmov` choses either `kmovql` if avx512bw is available, else it takes `kmovwl`.
> 
> As a regression test, I took one of the tests that failed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZGC`, and added an additional `@run` statement with those flags. I simulated this test locally with Intel Software Development Emulator:
> `sde -knl`: Knights Landing, AVX512 but not BW, fails without change to `kmov`, passes with it.
> `sde -cnl`: Cannon Landing, has AVX512 BW, passes before and after code change.
> 
> Ran additional tests to verify that the test triggers before code change, and that with the code change nothing broke.
> 
> @neliasso Thanks for the help!

This pull request has now been integrated.

Changeset: 4e0b81c5
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4e0b81c596f2a2eae49127b9ee98c80500b4e319
Stats:     14 lines in 2 files changed: 12 ins; 0 del; 2 mod

8281544: assert(VM_Version::supports_avx512bw()) failed for Tests jdk/incubator/vector/

Reviewed-by: kvn, neliasso, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7510

From jbhateja at openjdk.java.net  Mon Feb 21 08:09:52 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 21 Feb 2022 08:09:52 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v4]
In-Reply-To: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
Message-ID: <oHC6dVhxoCR9pJZ2C5jkXUe_2RFS520pGn8ePsvVadU=.7d9cabee-b529-4b27-93fc-218ca4e7ef11@github.com>

On Tue, 8 Feb 2022 09:01:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Hi Jatin, nice work!
> 
> One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.
> 
> Best regards,
> Nils

Hi @neliasso , your comments have been addressed. Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From chagedorn at openjdk.java.net  Mon Feb 21 08:57:49 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 21 Feb 2022 08:57:49 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v3]
In-Reply-To: <NXUVRzSSFvE3c6yd-I78IlivH7g1F8bP4ovMHcQJ0pA=.68f82ed3-0ed5-49bd-8fa0-2f9af61257f1@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <enxdYe9Ror3TBnLI3yetuoOQJGpdi0xs5UFlkbylE08=.d3a93e8c-c13a-4d16-8f8d-d72e80cfcaf9@github.com>
 <NXUVRzSSFvE3c6yd-I78IlivH7g1F8bP4ovMHcQJ0pA=.68f82ed3-0ed5-49bd-8fa0-2f9af61257f1@github.com>
Message-ID: <Me6EQoBBM_XOVo_BPm-2Gm4GFi1uE7lwZn6ZzGvAh7w=.6ef1d37a-ecc6-470c-a9a2-84d2a6add6d9@github.com>

On Fri, 18 Feb 2022 13:58:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I'll submit another round of testing over the weekend.

hs-tier1-3 looked good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7434

From ihse at openjdk.java.net  Mon Feb 21 10:41:59 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 21 Feb 2022 10:41:59 GMT
Subject: Integrated: 8253757: Add LLVM-based backend for hsdis
In-Reply-To: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
References: <0rJJRoOQYtYPrj8JKVRQLaggsk4JWKLTvW1ddiB6Bd8=.c0076efd-822c-4163-b613-e4554fdb0b01@github.com>
Message-ID: <O-41ikmMP5XpbRaSQQvNfmjLqk-5eu2jUDOI0ev_CgA=.27596f74-be1d-4550-b487-cf6afa2592c9@github.com>

On Fri, 18 Feb 2022 11:44:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Third time's a charm! After the two previous closed PRs for this issue, I think this functionality is finally ready to enter mainline. :)
> 
> This code is at it's core the same as the previous PR. The main C++ hsdis implementation is still the one @luhenry wrote, with some changes. As in the previous PR, I extracted the LLVM-specific part into a separate file. In addition to the last PR, I have also fixed a warning, and added a patch inspired by @nick-arm for getting past instructions unknown to LLVM.
> 
> Thanks to the prototype written by @JornVernee (and his graciously providing me with a working version of LLVM build for Windows), this PR now has full support for LLVM on Windows (as well as Linux and macOS).
> 
> Finally, I have cleaned up the integration in autoconf and Hsdis.gmk, and written a thorough guide in the README on how to build witth LLVM, on Windows and on saner platforms. :)
> 
> I'm pretty sure this means that all comments and criticism in the previous PR has been addressed.
> 
> Huge thanks to everyone who has helped me with getting this PR in place. I have a hard time remember a feature that has been so tricky to get in place, for something to seemingly simple...

This pull request has now been integrated.

Changeset: d7a706a5
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7a706a54076109b1a600a4d963df54b6d3f86de
Stats:     495 lines in 4 files changed: 490 ins; 0 del; 5 mod

8253757: Add LLVM-based backend for hsdis

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Nick Gasson <ngasson at openjdk.org>
Reviewed-by: erikj, luhenry

-------------

PR: https://git.openjdk.java.net/jdk/pull/7531

From adinn at openjdk.java.net  Mon Feb 21 10:49:09 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 21 Feb 2022 10:49:09 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands.
Message-ID: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>

This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.

-------------

Commit messages:
 - document algorithm aarch64 immediate encoding

Changes: https://git.openjdk.java.net/jdk/pull/7536/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7536&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282182
  Stats: 81 lines in 1 file changed: 74 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7536/head:pull/7536

PR: https://git.openjdk.java.net/jdk/pull/7536

From adinn at openjdk.java.net  Mon Feb 21 10:49:10 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 21 Feb 2022 10:49:10 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands.
In-Reply-To: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
Message-ID: <MpNdTVL-vTckiGjHCR8mrW5ASwK-vv6RX5-JZLm1gME=.8699161a-78c8-41fc-ab7d-c1db8857479b@github.com>

On Fri, 18 Feb 2022 17:12:08 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.

Document algorithm used to encode aarch64 logical immediate operands.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7536

From shade at openjdk.java.net  Mon Feb 21 11:16:54 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 21 Feb 2022 11:16:54 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands.
In-Reply-To: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
Message-ID: <LELXb2DvUkQCtNk4IecpfDAv-u7hMI8MgMF6WDalHH0=.d3046cef-a1db-4ea9-9d9c-69615c4a10de@github.com>

On Fri, 18 Feb 2022 17:12:08 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.

src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 129:

> 127: // SPEC
> 128: //
> 129: // bits(M*N) Replicate(bits(M) x, integer N);

Suggestion:

// bits(M*N) Replicate(bits(M) B, integer N);

...because the next text references "bit string B"?

src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 216:

> 214: // ensures that an all 0s or all 1s bit pattern is never generated.
> 215: //
> 216: // bit field construction:

The flow in this section is odd. I think the text should flow as: "This is what we intend to do; this is how we construct it is done; this is the example of the generated output; given all above; here are the invariants that are enforced".

src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 226:

> 224: // implementation note:
> 225: //
> 226: // For hysterical reasons the implementation of this function is much

Suggestion:

// For historical reasons the implementation of this function is much

-------------

PR: https://git.openjdk.java.net/jdk/pull/7536

From adinn at openjdk.java.net  Mon Feb 21 11:23:52 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 21 Feb 2022 11:23:52 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands.
In-Reply-To: <LELXb2DvUkQCtNk4IecpfDAv-u7hMI8MgMF6WDalHH0=.d3046cef-a1db-4ea9-9d9c-69615c4a10de@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
 <LELXb2DvUkQCtNk4IecpfDAv-u7hMI8MgMF6WDalHH0=.d3046cef-a1db-4ea9-9d9c-69615c4a10de@github.com>
Message-ID: <aupAXls3FhcK5xK1cSegYxbOtB_HnngnW5yUf7GRgSs=.d6ea636a-4e1d-4961-ba81-781817f64785@github.com>

On Mon, 21 Feb 2022 11:00:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.
>
> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 129:
> 
>> 127: // SPEC
>> 128: //
>> 129: // bits(M*N) Replicate(bits(M) x, integer N);
> 
> Suggestion:
> 
> // bits(M*N) Replicate(bits(M) B, integer N);
> 
> ...because the next text references "bit string B"?

Indeed.

> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 226:
> 
>> 224: // implementation note:
>> 225: //
>> 226: // For hysterical reasons the implementation of this function is much
> 
> Suggestion:
> 
> // For historical reasons the implementation of this function is much

I keep misspelling that ;-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7536

From shade at openjdk.java.net  Mon Feb 21 11:28:14 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 21 Feb 2022 11:28:14 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-compiler threads
Message-ID: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>

In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:


  void log_metaspace_failure(const char* reason) {
    ResourceMark rm;
    StringLogMessage lm;
    lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
    lm.print("\n");
    log(JavaThread::current(), "%s", (const char*)lm);
  }


...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).

It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:


12700 breakpoints set
12800 breakpoints set
12900 breakpoints set
13000 breakpoints set
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
# assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 


Additional testing:
 - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7555/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7555&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282172
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7555/head:pull/7555

PR: https://git.openjdk.java.net/jdk/pull/7555

From adinn at openjdk.java.net  Mon Feb 21 12:08:26 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 21 Feb 2022 12:08:26 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands. [v2]
In-Reply-To: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
Message-ID: <09cn7mLuNyxKgalWLvtJTFuqIf-Eoqvj8Rj1G33Jl9s=.4df90424-597f-4d13-bd4e-2b0f236e410f@github.com>

> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.

Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:

 - more logical flow to explanation
 - address initial reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7536/files
  - new: https://git.openjdk.java.net/jdk/pull/7536/files/d664a793..737c1160

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7536&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7536&range=00-01

  Stats: 29 lines in 1 file changed: 7 ins; 3 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7536/head:pull/7536

PR: https://git.openjdk.java.net/jdk/pull/7536

From adinn at openjdk.java.net  Mon Feb 21 12:08:28 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 21 Feb 2022 12:08:28 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands. [v2]
In-Reply-To: <LELXb2DvUkQCtNk4IecpfDAv-u7hMI8MgMF6WDalHH0=.d3046cef-a1db-4ea9-9d9c-69615c4a10de@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
 <LELXb2DvUkQCtNk4IecpfDAv-u7hMI8MgMF6WDalHH0=.d3046cef-a1db-4ea9-9d9c-69615c4a10de@github.com>
Message-ID: <O8hyyd94b9LDFg0bh3EO8uyXg1j3LTky_XJK6qxczLM=.051bb17b-2ccf-4ed2-81c3-0841518d7ec2@github.com>

On Mon, 21 Feb 2022 11:13:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - more logical flow to explanation
>>  - address initial reviewer feedback
>
> src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 216:
> 
>> 214: // ensures that an all 0s or all 1s bit pattern is never generated.
>> 215: //
>> 216: // bit field construction:
> 
> The flow in this section is odd. I think the text should flow as: "This is what we intend to do; this is how we construct it is done; this is the example of the generated output; given all above; here are the invariants that are enforced".

Yeah, I agree, only I found it tricky to describe the algorithm without describing the constraints that determine how it proceeds. I have pushed a revised version to address that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7536

From adinn at openjdk.java.net  Mon Feb 21 13:15:34 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 21 Feb 2022 13:15:34 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands. [v3]
In-Reply-To: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
Message-ID: <_mcHOjaHB3O6M6B9vFnu6d-SWwTNu14mX2-iVAHYKz4=.2e9b79d3-fe2f-45b0-9942-48eccb1cfa11@github.com>

> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  include unsaved changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7536/files
  - new: https://git.openjdk.java.net/jdk/pull/7536/files/737c1160..777759cf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7536&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7536&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7536.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7536/head:pull/7536

PR: https://git.openjdk.java.net/jdk/pull/7536

From vlivanov at openjdk.java.net  Mon Feb 21 13:35:20 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 21 Feb 2022 13:35:20 GMT
Subject: RFR: 8282194: C1: Missing side effects of dynamic constant linkage
Message-ID: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>

After [JDK-8280473](https://bugs.openjdk.java.net/browse/JDK-8280473), C1 handles unresolved dynamic constants by performing
constant resolution at runtime and then putting the constant value into the
generated code by patching it. But it treats the not-yet-resolved constant as a
pure value, dynamic constants are produced by user-defined bootstrap methods
and there are no guarantees that they don't have any side effects.

Proposed fix conservatively kills the whole memory state after any unresolved
dynamic constant.

Testing:
- [x] jck:vm/constantpool/resolveDynamicConstant w/ -Xcomp
- [x] hs-tier1 - hs-tier4

-------------

Commit messages:
 - 8282194: C1: Missing side effects of dynamic constant linkage

Changes: https://git.openjdk.java.net/jdk/pull/7557/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7557&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282194
  Stats: 35 lines in 5 files changed: 30 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7557.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7557/head:pull/7557

PR: https://git.openjdk.java.net/jdk/pull/7557

From mdoerr at openjdk.java.net  Mon Feb 21 14:16:53 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 21 Feb 2022 14:16:53 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
Message-ID: <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>

On Wed, 2 Feb 2022 14:40:58 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
> 
> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
> 
> As this is a s390x-only change, other platforms are not impacted.

Looks basically good. I have a few minor remarks. Did you test this carefully? I can't guarantee that there's no typo or copy&paste bug.

src/hotspot/cpu/s390/assembler_s390.hpp line 1812:

> 1810:   inline void emit_data(int x);
> 1811: 
> 1812: // private:

Uncommon. Should better get removed.

src/hotspot/cpu/s390/assembler_s390.inline.hpp line 52:

> 50:         *(unsigned short*)(pos)   = (unsigned short)(x>>16);
> 51:         *(unsigned short*)(pos+2) = (unsigned short)x;
> 52:       }

Looks correct, but what is the motivation behind splitting unaligned stores? z can store to unaligned memory.

src/hotspot/cpu/s390/assembler_s390.inline.hpp line 1412:

> 1410:   int len_bits = instr >> (48-2);
> 1411:   if (len_bits == 0) len_bits = instr >> (32-2);
> 1412:   if (len_bits == 0) len_bits = instr >> (16-2);

Tricky, but looks correct.

src/hotspot/cpu/s390/assembler_s390.inline.hpp line 1423:

> 1421:       // The switch expression examines just the leftmost two bytes
> 1422:       // of the main opcode. So the range of values is just [0..3].
> 1423:       // Having a default clause makes the compiler happy.

A bit lengthy for a trivial explanation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From sgehwolf at openjdk.java.net  Mon Feb 21 14:54:49 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 21 Feb 2022 14:54:49 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <UjFt5EZjP9mb4dxe4op35SqMzvHauaa-ZlnVB_Zr3lY=.3c39c8ab-f179-4042-bae7-b167a5d04630@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
 <UjFt5EZjP9mb4dxe4op35SqMzvHauaa-ZlnVB_Zr3lY=.3c39c8ab-f179-4042-bae7-b167a5d04630@github.com>
Message-ID: <1l5zuk4ufNzijoIgs8EBszqReBfwIG5q6hazdioZOII=.1c2b3b38-9630-4325-b9a7-d85a76dff46f@github.com>

On Fri, 18 Feb 2022 19:16:52 GMT, Dalibor Topic <robilad at openjdk.org> wrote:

> Done, thanks for the ping!

Thanks, Dalibor!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From duke at openjdk.java.net  Mon Feb 21 16:01:14 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 21 Feb 2022 16:01:14 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on x86_64
Message-ID: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>

Hi,

This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 

Thank you very much.

-------------

Commit messages:
 - Use lea

Changes: https://git.openjdk.java.net/jdk/pull/7560/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282204
  Stats: 107 lines in 2 files changed: 78 ins; 5 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From vladimir.x.ivanov at oracle.com  Mon Feb 21 18:26:05 2022
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 21 Feb 2022 21:26:05 +0300
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>

Hi Cesar,

> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating specialized memory operations conditionally using the different bases.

Yes, that's a valid simplification. It does sound like introducing 
selector ID doesn't require a separate memory graph (and can be 
performed before split_unique_types()), but I don't have a good 
understanding how complicated simplifying selector-based IR shapes would 
be compared to original (memory op-based) ones. It's definitely worth 
experimenting with.

Best regards,
Vladimir Ivanov

> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 17, 2022 7:37 AM
> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> 
> 
>> But depending on the actual shape of the base pointer (here it's
>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>> or even impossible (e.g., for complex loop variant conditions) to
>> separate instance slices.
> 
> I'd like to correct myself. After thinking more about the problem, I see
> a universal way to scalarize clusters of interfering non-escaping
> allocations even in presence of accesses with indeterminate base.
> 
> The crucial property for such cluster of interacting non-escaping
> allocations is for any memory access its base is either part of the
> cluster or not (it's a static property for every access). Then, when it
> is part of the cluster, then the number of possible base values at
> runtime is finite and is a subset of the cluster.
> 
> So, memory graph for the cluster can be scalarized as follows:
> 
>     (1) separate memory graph for the cluster
> 
>     (2) on the newly constructed graph:
> 
>        (a) replace every base pointer with an ID ("selector id") and
> recreate data graph for selector IDs from base pointers graph;
> 
>        (b) for accesses with indeterminate base pointer, replace them
> with a merge of states from relevant allocations selected by "selector id"
> 
>        (c) after 2b, all memory accesses from the cluster memory graph
> should have fixed base pointing at a particular allocation
> 
>     (3) scalarize individual allocations from the cluster one by one
> (since they are independent now)
> 
>        - additional transformation (like, split-through-phi) should
> simplify the graph by reducing the number of cases at merge points to
> care about (ideally, leaving only a single one);
> 
> 
> 
> As an illustration:
> 
>     val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
> 
> ==(pseudo-code)==>
> 
>     selector = (Phi R #base1 #base2)
> 
>     if (selector == #base1) {
>       val1 = Load (base1 + offset) mem
>     } else if (selector == #base2) {
>       val2 = Load (base2 + offset) mem
>     } else {
>       halt(); // impossible
>     }
> 
>     val = Phi(R1, val1, val2)
> 
> ======
> 
>     Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
> 
> ==(pseudo-code)==>
> 
>     selector = (Phi R #base1 #base2)
> 
>     if (selector == #base1) {
>       Store base1 mem v ==> mem1
>     } else if (selector == #base2) {
>       Store base2 mem v ==> mem2
>     } else {
>       halt(); // impossible
>     }
> 
>     mem = Phi(R1, mem1, mem2);
> 
> 
> Best regards,
> Vladimir Ivanov
> 
>>
>> So, gradual approach seems the way to go:
>>     (1) split memory graph for clusters of interacting non-escaping
>> allocations;
>>
>>     (2) perform adhoc transformation targeted at untangling aliasing
>> accesses (e.g, split-through-phi);
>>
>>     (3) extract unique instance types where possible, thus making the
>> corresponding allocation scalar replaceable
>>
>> =====================================================================
>>
>> Also, one observation: interacting allocations don't have to be of the
>> same class.
>>
>>       static int testPolluted(int r, boolean b) {
>>           A obj1 = new B1(r);
>>           A obj2 = new B2(r);
>>
>>           A obj = (b ? obj1 : obj2);
>>           for (int i = 1; i < r; i++) {
>>               obj.i++;
>>           }
>>
>>           return obj1.i + obj2.i;
>>       }
>>
>> Requiring unique instance types to perform SR (and not enhancing SR to
>> handle aliasing allocations case) helps avoid some challenges in
>> instance rematerialization logic at safepoints, because actual shape of
>> the scalarized object (its class and exact set of fields) becomes a
>> runtime property.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>>>
>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>> correct memory states for the new loads above the phi which quickly
>>>>> becomes quite a challenging task.
>>>>
>>>> Especially in loops. Actually I did tried such approach before and I
>>>> agree that it is hard.
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>       p0 = Allocate(...);
>>>>>>       ...
>>>>>>       p0.x = first;
>>>>>>       p0.y = second;
>>>>>>
>>>>>>       if (cond) {
>>>>>>           p1 = Allocate(...);
>>>>>>           ...
>>>>>>           p1.x = second;
>>>>>>           p1.y = first;
>>>>>>       }
>>>>>>
>>>>>>       p = phi(p0, p1) // unused and will be removed
>>>>>>
>>>>>>
>>>>>>       return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>> }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir K
>>>>>>
>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>> hotspot-compiler-dev.)
>>>>>>>
>>>>>>> Hi Cesar,
>>>>>>>
>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>
>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>
>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>
>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>> allocations.
>>>>>>>
>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>> clusters of allocations.
>>>>>>>
>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>> TypeOopPtr::instance_id().
>>>>>>>
>>>>>>>     // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>     // a particular instance of this type which is distinct.
>>>>>>>     // This is the node index of the allocation node creating this
>>>>>>> instance.
>>>>>>>     int           _instance_id;
>>>>>>>
>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>> Hi there again!
>>>>>>>>
>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>> least partially
>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>
>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>> merged after a
>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>> situation.
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>       Point p = new Point(x, y);
>>>>>>>>       if (cond)
>>>>>>>>           p = new Point(y, x);
>>>>>>>>       // Allocations for p are merged here.
>>>>>>>>       return p.calc();
>>>>>>>> }
>>>>>>>>
>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>> will not
>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>       p0 = Allocate(...);
>>>>>>>>       ...
>>>>>>>>       p0.x = first;
>>>>>>>>       p0.y = second;
>>>>>>>>
>>>>>>>>       if (cond) {
>>>>>>>>           p1 = Allocate(...);
>>>>>>>>           ...
>>>>>>>>           p1.x = second;
>>>>>>>>           p1.y = first;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       p = phi(p0, p1)
>>>>>>>>
>>>>>>>>       return p.x - p.y;
>>>>>>>> }
>>>>>>>>
>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>> specifically the third
>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>
>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>> replace the Phi
>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>> of the objects
>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>> this after the
>>>>>>>> transformation:
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>       p0 = Allocate(...);
>>>>>>>>       ...
>>>>>>>>       p0.x = first;
>>>>>>>>       p0.y = second;
>>>>>>>>
>>>>>>>>       if (cond) {
>>>>>>>>           p1 = Allocate(...);
>>>>>>>>           ...
>>>>>>>>           p1.x = second;
>>>>>>>>           p1.y = first;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       pX = phi(first, second)
>>>>>>>>       pY = phi(second, first)
>>>>>>>>
>>>>>>>>       return pX - pY;
>>>>>>>> }
>>>>>>>>
>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>> all cases and
>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>> me that much of
>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>> of the Scalar
>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>> as possible.
>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>
>>>>>>>> split_phis(phi)
>>>>>>>>       # If output of phi escapes, or something uses its identity, etc
>>>>>>>>       # then we can't remove it. The conditions here might
>>>>>>>> possible be the
>>>>>>>>       # same as the ones implemented in
>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>       if cant_remove_phi_output(phi)
>>>>>>>>           return ;
>>>>>>>>
>>>>>>>>       # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>> field F
>>>>>>>>       # member of the object resulting from `phi`.
>>>>>>>>       fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>
>>>>>>>>       foreach field in fields_used
>>>>>>>>           producers = {}
>>>>>>>>
>>>>>>>>           # Create a list with the last Store for each field
>>>>>>>> "field" on the
>>>>>>>>           # scope of each of the Phi input objects.
>>>>>>>>           foreach o in phi.inputs
>>>>>>>>               # The function called below might re-use a lot of
>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>               producers += last_store_to_o_field(0, field)
>>>>>>>>           # Create a new phi node whose inputs are the Store's to
>>>>>>>> 'field'
>>>>>>>>           field_phi = create_new_phi(producers)
>>>>>>>>
>>>>>>>>           update_consumers(field, field_phi)
>>>>>>>>
>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>> [3] step just
>>>>>>>> after EA but before the constraint checks in
>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>> implementation goes through
>>>>>>>> the following major phases:
>>>>>>>>
>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>> based on a set of constraints.
>>>>>>>>       3. Make call to Split_unique_types [4].
>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>           4.1 Check if allocation can be eliminated.
>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>> in Safepoints.
>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>
>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>> flow to look
>>>>>>>> like this:
>>>>>>>>
>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>       2. ----> New: "Split phi functions" <----
>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>> based on a set of constraints.
>>>>>>>>       3. Make call to Split_unique_types [14].
>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>           4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>> be eliminated" <----
>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>> in Safepoints.
>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>
>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>> time to review
>>>>>>>> this!
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Cesar
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>
>>>>>>>>       [1] I am not sure yet how this approach will play with the
>>>>>>>> case of a merge
>>>>>>>>           with NULL.
>>>>>>>>       [2]
>>>>>>>> https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=WruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc$
>>>>>>>>
>>>>>>>>
>>>>>>>>       [3] Another option would be to "patch" the current
>>>>>>>> implementation to be able
>>>>>>>>           to handle the merges. I am not certain that the "patch"
>>>>>>>> approach would be
>>>>>>>>           better, however, the "pre-process" approach is certainly
>>>>>>>> much easier to test
>>>>>>>>           and more readable.
>>>>>>>>
>>>>>>>>       [4] I cannot say I understand 100% the effects of executing
>>>>>>>>           split_unique_types(). Would the transformation that I am
>>>>>>>> proposing need to
>>>>>>>>           be after the call to split_unique_types?

From neliasso at openjdk.java.net  Mon Feb 21 21:49:02 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Mon, 21 Feb 2022 21:49:02 GMT
Subject: RFR: 8282208: Reduce MachNode size
Message-ID: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>

Hi,

This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.

The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 

Fixes in this patch:

1) Change MachNode::_remove to a Node::flag

2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 

3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.

Please review,
Nils Eliasson

-------------

Commit messages:
 - Move debug_idx
 - 8282208_reduce_machnode

Changes: https://git.openjdk.java.net/jdk/pull/7562/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7562&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282208
  Stats: 15 lines in 2 files changed: 5 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7562/head:pull/7562

PR: https://git.openjdk.java.net/jdk/pull/7562

From vlivanov at openjdk.java.net  Mon Feb 21 22:00:47 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 21 Feb 2022 22:00:47 GMT
Subject: RFR: 8282194: C1: Missing side effects of dynamic constant linkage
In-Reply-To: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
References: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
Message-ID: <UT69VJ8YmwdCiH73SfCSe_d0IYGgxQBiYLhKIDN85A4=.5fbc2d20-9bb5-4738-afe2-0cdd67c3d85a@github.com>

On Mon, 21 Feb 2022 13:20:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> After [JDK-8280473](https://bugs.openjdk.java.net/browse/JDK-8280473), C1 handles unresolved dynamic constants by performing
> constant resolution at runtime and then putting the constant value into the
> generated code by patching it. But it treats the not-yet-resolved constant as a
> pure value, dynamic constants are produced by user-defined bootstrap methods
> and there are no guarantees that they don't have any side effects.
> 
> Proposed fix conservatively kills the whole memory state after any unresolved
> dynamic constant.
> 
> Testing:
> - [x] jck:vm/constantpool/resolveDynamicConstant w/ -Xcomp
> - [x] hs-tier1 - hs-tier4

Forgot to mention that the problem is not specific to dynamic constants. It turns out all non-String constants are affected, because their linkage involves class loading. Custom class loaders may produce (provide no guarantees) side effects which are noticeable by an application, but not necessarily preserved across a patched constant in C1-generated code. Filed [JDK-8282218](https://bugs.openjdk.java.net/browse/JDK-8282218) to cover such cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7557

From yunyao.zxl at alibaba-inc.com  Tue Feb 22 03:28:45 2022
From: yunyao.zxl at alibaba-inc.com (=?UTF-8?B?6YOR5a2d5p6XKOS6keefhSk=?=)
Date: Tue, 22 Feb 2022 11:28:45 +0800
Subject: =?UTF-8?B?RG8gYE5hdGl2ZUluc3RydWN0aW9uOjpzZXRfKl9hdCgpYCBhbmQgYEJhcnJpZXJTZXROTWV0?=
 =?UTF-8?B?aG9kOjpkaXNhcm0oKWAgbWlzcyBpY2FjaGUgaW52YWxpZGF0aW9uIG9wZXJhdGlvbnMgb24g?=
 =?UTF-8?B?QUFyY2g2NCBwbGF0Zm9ybT8=?=
Message-ID: <493b7565-fc09-4b62-bb05-29026b8c4e7b.yunyao.zxl@alibaba-inc.com>


Hi experts on AArch64,

As the topic, I was wondering if these methods lack icache invalidation operations when patching data saved in a code region, though it seems not harmful.
1. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L95-L101
2. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp#L49-L51

When patching a trampoline address, we will go
```
NativeCall::set_destination_mt_safe()
  -> NativeCallTrampolineStub::set_destination()
    -> NativeInstruction::set_ptr_at()
```

bl(1) -> ldr
            br
            <int64: the real call target (2)>

When a call target is getting updated, (1) is flushed but (2) is not on AArch64. So I was wondering if there are more possibilities for other cores to see the new patching behavior with a theoretically longer latency when code is running at full speed on every core? Since when other cores observe (1), they are likely run without observing (2) in theory.

Also `BarrierSetNMethod::disarm()` will patch the guard address as well, without flushing the related icache address on AArch64. 

Maybe something like http://cr.openjdk.java.net/~xlinzheng/1.diff ?

Previously I wanted to send this to the aarch64-port-dev, but seems that list is not so active - I see only Duke's there syncing changesets.
I feel sorry in advance if this isn't worth a discussion, and am very glad to receive any input.

Thanks,Xiaolin

From lucy at openjdk.java.net  Tue Feb 22 07:41:47 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 22 Feb 2022 07:41:47 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
Message-ID: <fWaGUch6kidSB2htgCk0sOx9ys3YyJrOlKXD2ue50zk=.dd49ba01-2ab1-473b-8ac0-76d0c7a67f67@github.com>

On Mon, 21 Feb 2022 13:59:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> src/hotspot/cpu/s390/assembler_s390.hpp line 1812:
> 
>> 1810:   inline void emit_data(int x);
>> 1811: 
>> 1812: // private:
> 
> Uncommon. Should better get removed.

Agreed. Will get removed with next commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From lucy at openjdk.java.net  Tue Feb 22 08:08:51 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 22 Feb 2022 08:08:51 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
Message-ID: <jQ-bX5mMsQAwrPYw5JVvC8ihQr0fFxkY9g7QndP-IOk=.ab040aa2-2751-4b2c-af5a-f073b9c06f7d@github.com>

On Mon, 21 Feb 2022 14:11:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> src/hotspot/cpu/s390/assembler_s390.inline.hpp line 1412:
> 
>> 1410:   int len_bits = instr >> (48-2);
>> 1411:   if (len_bits == 0) len_bits = instr >> (32-2);
>> 1412:   if (len_bits == 0) len_bits = instr >> (16-2);
> 
> Tricky, but looks correct.

Want some detailed comment here?

> src/hotspot/cpu/s390/assembler_s390.inline.hpp line 1423:
> 
>> 1421:       // The switch expression examines just the leftmost two bytes
>> 1422:       // of the main opcode. So the range of values is just [0..3].
>> 1423:       // Having a default clause makes the compiler happy.
> 
> A bit lengthy for a trivial explanation.

You mean I should not explain what's going on?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From mdoerr at openjdk.java.net  Tue Feb 22 08:25:50 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 22 Feb 2022 08:25:50 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <jQ-bX5mMsQAwrPYw5JVvC8ihQr0fFxkY9g7QndP-IOk=.ab040aa2-2751-4b2c-af5a-f073b9c06f7d@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
 <jQ-bX5mMsQAwrPYw5JVvC8ihQr0fFxkY9g7QndP-IOk=.ab040aa2-2751-4b2c-af5a-f073b9c06f7d@github.com>
Message-ID: <btp9nSWFuXfTE6ogy5MynByNQ3NxAXk64meVPDgxS7E=.f237b1ad-1840-407d-94ed-bf1144ae44b4@github.com>

On Tue, 22 Feb 2022 08:05:57 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> src/hotspot/cpu/s390/assembler_s390.inline.hpp line 1412:
>> 
>>> 1410:   int len_bits = instr >> (48-2);
>>> 1411:   if (len_bits == 0) len_bits = instr >> (32-2);
>>> 1412:   if (len_bits == 0) len_bits = instr >> (16-2);
>> 
>> Tricky, but looks correct.
>
> Want some detailed comment here?

I can understand it, but a short comment would be appreciated. E.g. length can only be >2 if first 2 bits are != 0.

>> src/hotspot/cpu/s390/assembler_s390.inline.hpp line 1423:
>> 
>>> 1421:       // The switch expression examines just the leftmost two bytes
>>> 1422:       // of the main opcode. So the range of values is just [0..3].
>>> 1423:       // Having a default clause makes the compiler happy.
>> 
>> A bit lengthy for a trivial explanation.
>
> You mean I should not explain what's going on?

The explanation in the middle is fine. What's the value of the first and last sentence? The first one is already expressed by ShouldNotReachHere, the last one is a general statement which I don't like to be at every switch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From lucy at openjdk.java.net  Tue Feb 22 08:47:49 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 22 Feb 2022 08:47:49 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
Message-ID: <QaNMyE6zUdNxeoK0G8sOKCWZ6dDQp6cngUPoXknH8JQ=.ad8530d5-ae7d-4776-9802-d41480b1f5c0@github.com>

On Mon, 21 Feb 2022 14:02:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> src/hotspot/cpu/s390/assembler_s390.inline.hpp line 52:
> 
>> 50:         *(unsigned short*)(pos)   = (unsigned short)(x>>16);
>> 51:         *(unsigned short*)(pos+2) = (unsigned short)x;
>> 52:       }
> 
> Looks correct, but what is the motivation behind splitting unaligned stores? z can store to unaligned memory.

Will go back to single int store for 4-byte instructions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From mdoerr at openjdk.java.net  Tue Feb 22 08:47:49 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 22 Feb 2022 08:47:49 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <QaNMyE6zUdNxeoK0G8sOKCWZ6dDQp6cngUPoXknH8JQ=.ad8530d5-ae7d-4776-9802-d41480b1f5c0@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
 <QaNMyE6zUdNxeoK0G8sOKCWZ6dDQp6cngUPoXknH8JQ=.ad8530d5-ae7d-4776-9802-d41480b1f5c0@github.com>
Message-ID: <dBSHvFA_EMa-mTM8VD81qhYM2uhBdeADr4zEUAilBwg=.e8e6eaad-9bd2-4a2b-89db-7885c1422065@github.com>

On Tue, 22 Feb 2022 08:42:06 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> src/hotspot/cpu/s390/assembler_s390.inline.hpp line 52:
>> 
>>> 50:         *(unsigned short*)(pos)   = (unsigned short)(x>>16);
>>> 51:         *(unsigned short*)(pos+2) = (unsigned short)x;
>>> 52:       }
>> 
>> Looks correct, but what is the motivation behind splitting unaligned stores? z can store to unaligned memory.
>
> Will go back to single int store for 4-byte instructions.

Ok. I'm fine with either version. Maybe the reason you did it this way was to be more consistent with the 6 Byte version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From lucy at openjdk.java.net  Tue Feb 22 08:47:50 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 22 Feb 2022 08:47:50 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters
In-Reply-To: <btp9nSWFuXfTE6ogy5MynByNQ3NxAXk64meVPDgxS7E=.f237b1ad-1840-407d-94ed-bf1144ae44b4@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <_3CKjUNzs2ZdWbHUaGwR5XHb4gy3OhxOnJfcEHlCaqg=.d4f9ec15-89ef-44fc-9b43-3a072a5cd5af@github.com>
 <jQ-bX5mMsQAwrPYw5JVvC8ihQr0fFxkY9g7QndP-IOk=.ab040aa2-2751-4b2c-af5a-f073b9c06f7d@github.com>
 <btp9nSWFuXfTE6ogy5MynByNQ3NxAXk64meVPDgxS7E=.f237b1ad-1840-407d-94ed-bf1144ae44b4@github.com>
Message-ID: <-uC2FPHrNo9VR-0BQTLh94wF-9RsFvmcgmNObT_FDVI=.82ee06e5-ec33-468c-9071-b1f3147aae48@github.com>

On Tue, 22 Feb 2022 08:22:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Want some detailed comment here?
>
> I can understand it, but a short comment would be appreciated. E.g. length can only be >2 if first 2 bits are != 0.

Will rework with next commit.

>> You mean I should not explain what's going on?
>
> The explanation in the middle is fine. What's the value of the first and last sentence? The first one is already expressed by ShouldNotReachHere, the last one is a general statement which I don't like to be at every switch.

Will rework with next commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From duke at openjdk.java.net  Tue Feb 22 12:01:30 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 22 Feb 2022 12:01:30 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  decoder, format

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/d1a5bbb1..bcaeb3d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=00-01

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From erik.osterlund at oracle.com  Tue Feb 22 12:37:03 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Tue, 22 Feb 2022 12:37:03 +0000
Subject: Do `NativeInstruction::set_*_at()` and
 `BarrierSetNMethod::disarm()` miss icache invalidation operations on AArch64
 platform?
In-Reply-To: <493b7565-fc09-4b62-bb05-29026b8c4e7b.yunyao.zxl@alibaba-inc.com>
References: <493b7565-fc09-4b62-bb05-29026b8c4e7b.yunyao.zxl@alibaba-inc.com>
Message-ID: <BN0PR10MB5176AB978F39881180FEC3ACF43B9@BN0PR10MB5176.namprd10.prod.outlook.com>

Hi Xiaolin,

Note that the guard for nmethod entry barriers is used as data only.
Its address just happens to be in the code cache, but it is never executed.

Thanks,
/Erik

> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> retn at openjdk.java.net> On Behalf Of ???(??)
> Sent: Tuesday, 22 February 2022 04:29
> To: hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>
> Subject: Do `NativeInstruction::set_*_at()` and
> `BarrierSetNMethod::disarm()` miss icache invalidation operations on
> AArch64 platform?
> 
> 
> Hi experts on AArch64,
> 
> As the topic, I was wondering if these methods lack icache invalidation
> operations when patching data saved in a code region, though it seems not
> harmful.
> 1.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/nati
> veInst_aarch64.hpp#L95-L101
> 2.
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/gc/s
> hared/barrierSetNMethod_aarch64.cpp#L49-L51
> 
> When patching a trampoline address, we will go ```
> NativeCall::set_destination_mt_safe()
>   -> NativeCallTrampolineStub::set_destination()
>     -> NativeInstruction::set_ptr_at()
> ```
> 
> bl(1) -> ldr
>             br
>             <int64: the real call target (2)>
> 
> When a call target is getting updated, (1) is flushed but (2) is not on AArch64.
> So I was wondering if there are more possibilities for other cores to see the
> new patching behavior with a theoretically longer latency when code is
> running at full speed on every core? Since when other cores observe (1),
> they are likely run without observing (2) in theory.
> 
> Also `BarrierSetNMethod::disarm()` will patch the guard address as well,
> without flushing the related icache address on AArch64.
> 
> Maybe something like http://cr.openjdk.java.net/~xlinzheng/1.diff ?
> 
> Previously I wanted to send this to the aarch64-port-dev, but seems that list
> is not so active - I see only Duke's there syncing changesets.
> I feel sorry in advance if this isn't worth a discussion, and am very glad to
> receive any input.
> 
> Thanks,Xiaolin

From aph-open at littlepinkcloud.com  Tue Feb 22 13:16:59 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 22 Feb 2022 13:16:59 +0000
Subject: Do `NativeInstruction::set_*_at()` and
 `BarrierSetNMethod::disarm()` miss icache invalidation operations on AArch64
 platform?
In-Reply-To: <493b7565-fc09-4b62-bb05-29026b8c4e7b.yunyao.zxl@alibaba-inc.com>
References: <493b7565-fc09-4b62-bb05-29026b8c4e7b.yunyao.zxl@alibaba-inc.com>
Message-ID: <ed318967-33b2-51fb-5b90-b9c5bc8b26ba@littlepinkcloud.com>

On 2/22/22 03:28, ???(??) wrote:
> 
> Hi experts on AArch64,
> 
> As the topic, I was wondering if these methods lack icache invalidation operations when patching data saved in a code region, though it seems not harmful.
> 1. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L95-L101
> 2. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp#L49-L51
> 
> When patching a trampoline address, we will go
> ```
> NativeCall::set_destination_mt_safe()
>    -> NativeCallTrampolineStub::set_destination()
>      -> NativeInstruction::set_ptr_at()
> ```
> 
> bl(1) -> ldr
>              br
>              <int64: the real call target (2)>
> 
> When a call target is getting updated, (1) is flushed but (2) is not on AArch64. So I was wondering if there are more possibilities for other cores to see the new patching behavior with a theoretically longer latency when code is running at full speed on every core?

That's definitely true, but it doesn't matter because they'll observe
either the old call target in the dcache or the new one: both are still
valid. If the old one is observed, the processor will hit a trap and retry.

> Also `BarrierSetNMethod::disarm()` will patch the guard address as well, without flushing the related icache address on AArch64.

There's no need to touch the icache, and again this is by design.

> Maybe something like http://cr.openjdk.java.net/~xlinzheng/1.diff ?
> 
> Previously I wanted to send this to the aarch64-port-dev, but seems that list is not so active - I see only Duke's there syncing changesets.
> I feel sorry in advance if this isn't worth a discussion, and am very glad to receive any input.

aarch64-port-dev is the right place, but posts by non-members are
rejected. I guess we should start diverting the changeset messages
elsewhere.

-- 
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  Tue Feb 22 13:41:19 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 13:41:19 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers
Message-ID: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>

In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.

This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

-------------

Commit messages:
 - 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts registers
 - Revert effac9b87ecb3cdc8d3d149b9dcd72ee1ea88fec
 - Merge https://github.com/openjdk/jdk into master
 - Merge https://github.com/openjdk/jdk
 - Merge https://github.com/openjdk/jdk
 - Merge branch 'master' of https://github.com/theRealAph/jdk
 - Merge
 - Merge branch 'master' of https://github.com/theRealAph/jdk
 - Merge https://github.com/openjdk/jdk
 - Merge https://github.com/openjdk/jdk
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f34f8d4d...fb02aa59

Changes: https://git.openjdk.java.net/jdk/pull/7575/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282231
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7575/head:pull/7575

PR: https://git.openjdk.java.net/jdk/pull/7575

From shade at openjdk.java.net  Tue Feb 22 14:00:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 22 Feb 2022 14:00:45 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers
In-Reply-To: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
Message-ID: <-nRBTkV85JB_dhVHvegueol5WO3WjZKoin9UJt7PzBM=.15b95702-2e2a-4bcc-9e2d-793f59c6237e@github.com>

On Tue, 22 Feb 2022 13:34:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
> 
> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

Yeah, I did a similar thing here: https://github.com/openjdk/jdk/pull/7498 -- I think we can drop `cr`, `cx`, `bx` from match rule arguments too. Also drop spaces between parentheses, while we are at it. That change passed tier{1,2,3} on x86_32, I am sure this one passes it too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From phh at openjdk.java.net  Tue Feb 22 14:08:44 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Tue, 22 Feb 2022 14:08:44 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v2]
In-Reply-To: <br7XMosl4RWjrKmPHLfxQQ8y94pNZWBAja3xB7BTT_w=.e369cf03-3f85-419c-8368-9634b7f83581@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <br7XMosl4RWjrKmPHLfxQQ8y94pNZWBAja3xB7BTT_w=.e369cf03-3f85-419c-8368-9634b7f83581@github.com>
Message-ID: <I5qFucwPJnDpkYIQTg9fNyG8o_mUlM_kF6KHAQhuMo8=.25410ecc-8ab8-4a34-a613-e807b8d367d0@github.com>

On Thu, 17 Feb 2022 19:07:56 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> An example of the modified data.
>> 
>> java -XX:+TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCodeCache -XX:+Verbose
>> 
>> Tier 0:
>>  #45 live = 38K (hdr 16K, loc 4K, code 18K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #0 dead = 0K
>> Tier 1:
>>  #56 live = 43K (hdr 20K, loc 3K, code 9K, stub 4K, [oops 0K, metadata 0K, data 0K, pcs 3K])
>>  #0 dead = 0K
>> Tier 2:
>>  #0 live = 0K
>>  #0 dead = 0K
>> Tier 3:
>>  #306 live = 773K (hdr 109K, loc 61K, code 354K, stub 37K, [oops 0K, metadata 6K, data 67K, pcs 122K])
>>  #0 dead = 0K
>> Tier 4:
>>  #37 live = 110K (hdr 13K, loc 6K, code 43K, stub 1K, [oops 0K, metadata 1K, data 13K, pcs 28K])
>>  #0 dead = 0K
>> Stubs:
>>  #60 runtime = 34K (hdr 7K, loc 1K, code 24K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #1 uncommon trap = 0K (hdr 0K, loc 0K, code 0K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #1 deoptimization = 1K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #667 adapter = 512K (hdr 78K, loc 45K, code 376K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #17 buffer blob = 3163K (hdr 1K, loc 0K, code 3161K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #4 other = 2K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code style

Why not print both absolute size and percentage? E.g., "24K(10%)".

Could include sample output in a comment please?

-------------

Changes requested by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7389

From yunyao.zxl at alibaba-inc.com  Tue Feb 22 14:16:25 2022
From: yunyao.zxl at alibaba-inc.com (Xiaolin Zheng)
Date: Tue, 22 Feb 2022 22:16:25 +0800
Subject: =?UTF-8?B?UkU6IFJlOiBEbyBgTmF0aXZlSW5zdHJ1Y3Rpb246OnNldF8qX2F0KClgIGFuZCBgQmFycmll?=
 =?UTF-8?B?clNldE5NZXRob2Q6OmRpc2FybSgpYCBtaXNzIGljYWNoZSBpbnZhbGlkYXRpb24gb3BlcmF0?=
 =?UTF-8?B?aW9ucyBvbiBBQXJjaDY0IHBsYXRmb3JtPw==?=
Message-ID: <4dd40f21-ecef-4fa5-8883-477bbc2a032d.yunyao.zxl@alibaba-inc.com>

Hi Erik and Andrew,

Thank you for the detailed explanations that are very reasonable to me - seems they could solve my confusion. The elaborately designed code really has lots of details hidden inside.
Next time I will post it to the aarch64-port-dev :-).

P.S. I have changed my name shown outside to the English one and hope it doesn't make confusions - it is not important though.

Thanks again for taking the time to look into this!

Best Regards,Xiaolin


------------------------------------------------------------------
On Tue, Feb 22, 2022 at 21:18 Andrew Haley <aph-open at littlepinkcloud.com> wrote:
On 2/22/22 03:28, ???(??) wrote:
> 
> Hi experts on AArch64,
> 
> As the topic, I was wondering if these methods lack icache invalidation operations when patching data saved in a code region, though it seems not harmful.
> 1. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L95-L101
> 2. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp#L49-L51
> 
> When patching a trampoline address, we will go
> ```
> NativeCall::set_destination_mt_safe()
>    -> NativeCallTrampolineStub::set_destination()
>      -> NativeInstruction::set_ptr_at()
> ```
> 
> bl(1) -> ldr
>              br
>              <int64: the real call target (2)>
> 
> When a call target is getting updated, (1) is flushed but (2) is not on AArch64. So I was wondering if there are more possibilities for other cores to see the new patching behavior with a theoretically longer latency when code is running at full speed on every core?

That's definitely true, but it doesn't matter because they'll observe
either the old call target in the dcache or the new one: both are still
valid. If the old one is observed, the processor will hit a trap and retry.

> Also `BarrierSetNMethod::disarm()` will patch the guard address as well, without flushing the related icache address on AArch64.

There's no need to touch the icache, and again this is by design.

> Maybe something like http://cr.openjdk.java.net/~xlinzheng/1.diff ?
> 
> Previously I wanted to send this to the aarch64-port-dev, but seems that list is not so active - I see only Duke's there syncing changesets.
> I feel sorry in advance if this isn't worth a discussion, and am very glad to receive any input.

aarch64-port-dev is the right place, but posts by non-members are
rejected. I guess we should start diverting the changeset messages
elsewhere.

-- 
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  Tue Feb 22 14:26:57 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 14:26:57 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers
In-Reply-To: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
Message-ID: <99rPTwaqy4CUJEga_dFPU6HWycMOThTvonqxM9fFz4o=.8378c34c-6551-496e-92c5-cdf916cf2383@github.com>

On Tue, 22 Feb 2022 13:34:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
> 
> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

> Yeah, I did a similar thing here: #7498 -- I think we can drop `cr`, `cx`, `bx` from match rule arguments too. Also drop spaces between parentheses, while we are at it. That change passed tier{1,2,3} on x86_32, I am sure this one passes it too.

Yes, we seem to have collided. Suggest we go ahead with this one, OK? I've put you in as a co-author, so I guess someone else will have to review it. 

`cr`, `cx`, and `bx` are call-clobbered, so we don't need them as an effect, I believe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From aph at openjdk.java.net  Tue Feb 22 14:30:24 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 14:30:24 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v2]
In-Reply-To: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
Message-ID: <H5i0iLx1tjKCplX30xZ9jkQ7s8WcZ7NeTucXgm-uUK8=.da57940f-20f5-4ccb-9038-a82796ac4b7c@github.com>

> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
> 
> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7575/files
  - new: https://git.openjdk.java.net/jdk/pull/7575/files/fb02aa59..d912370c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7575/head:pull/7575

PR: https://git.openjdk.java.net/jdk/pull/7575

From jiefu at openjdk.java.net  Tue Feb 22 14:52:49 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 22 Feb 2022 14:52:49 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v2]
In-Reply-To: <H5i0iLx1tjKCplX30xZ9jkQ7s8WcZ7NeTucXgm-uUK8=.da57940f-20f5-4ccb-9038-a82796ac4b7c@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
 <H5i0iLx1tjKCplX30xZ9jkQ7s8WcZ7NeTucXgm-uUK8=.da57940f-20f5-4ccb-9038-a82796ac4b7c@github.com>
Message-ID: <4WIYkTvPYenKcQlg6-tVzq4CgP8c2AHwKq9gVuXGYfI=.6b17023e-c6fb-4e2a-a7d0-2c64af75a885@github.com>

On Tue, 22 Feb 2022 14:30:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
>> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
>> 
>> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace

So how did you find this bug?
Is it possible to add a jtreg test for this fix?

Please also update the copyright year.
Thanks.

src/hotspot/cpu/x86/x86_32.ad line 7828:

> 7826: 
> 7827: // Divide Register Long
> 7828: instruct divL_eReg( eADXRegL dst, eRegL src1, eRegL src2, eFlagsReg cr, eCXRegI cx, eBXRegI bx ) %{

I agree with @shipilev that we can remove `eFlagsReg cr, eCXRegI cx, eBXRegI bx` here, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From aph at openjdk.java.net  Tue Feb 22 15:13:24 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 15:13:24 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v3]
In-Reply-To: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
Message-ID: <wsufS4r7cmYzgyfKIALpvZjFPKFwRUXTgKA7oiiAibs=.75209e2b-1073-49f1-bc3c-75cd1e5b3015@github.com>

> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
> 
> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Delete unused args

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7575/files
  - new: https://git.openjdk.java.net/jdk/pull/7575/files/d912370c..1382812e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7575/head:pull/7575

PR: https://git.openjdk.java.net/jdk/pull/7575

From aph at openjdk.java.net  Tue Feb 22 15:13:26 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 15:13:26 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v2]
In-Reply-To: <4WIYkTvPYenKcQlg6-tVzq4CgP8c2AHwKq9gVuXGYfI=.6b17023e-c6fb-4e2a-a7d0-2c64af75a885@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
 <H5i0iLx1tjKCplX30xZ9jkQ7s8WcZ7NeTucXgm-uUK8=.da57940f-20f5-4ccb-9038-a82796ac4b7c@github.com>
 <4WIYkTvPYenKcQlg6-tVzq4CgP8c2AHwKq9gVuXGYfI=.6b17023e-c6fb-4e2a-a7d0-2c64af75a885@github.com>
Message-ID: <mcM-xg9_bo6ZS02w5yMArAw4WFOuop5ww96vtcIT5BA=.dd1aa078-3584-4879-81fc-e6c6b60e0a05@github.com>

On Tue, 22 Feb 2022 14:49:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Whitespace
>
> src/hotspot/cpu/x86/x86_32.ad line 7828:
> 
>> 7826: 
>> 7827: // Divide Register Long
>> 7828: instruct divL_eReg( eADXRegL dst, eRegL src1, eRegL src2, eFlagsReg cr, eCXRegI cx, eBXRegI bx ) %{
> 
> I agree with @shipilev that we can remove `eFlagsReg cr, eCXRegI cx, eBXRegI bx` here, right?

Done. I deleted them in the effect list but forgot to delete the corresponding args.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From duke at openjdk.java.net  Tue Feb 22 15:19:56 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 22 Feb 2022 15:19:56 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v2]
In-Reply-To: <br7XMosl4RWjrKmPHLfxQQ8y94pNZWBAja3xB7BTT_w=.e369cf03-3f85-419c-8368-9634b7f83581@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <br7XMosl4RWjrKmPHLfxQQ8y94pNZWBAja3xB7BTT_w=.e369cf03-3f85-419c-8368-9634b7f83581@github.com>
Message-ID: <WzhKgGtDZ_wQDkC4rxqgl6gc02ReJreUTivH-YvnQoU=.33d77f76-abb5-4aa4-b201-6a73162bf894@github.com>

On Thu, 17 Feb 2022 19:07:56 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> An example of the modified data.
>> 
>> java -XX:+TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCodeCache -XX:+Verbose
>> 
>> Tier 0:
>>  #45 live = 38K (hdr 16K, loc 4K, code 18K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #0 dead = 0K
>> Tier 1:
>>  #56 live = 43K (hdr 20K, loc 3K, code 9K, stub 4K, [oops 0K, metadata 0K, data 0K, pcs 3K])
>>  #0 dead = 0K
>> Tier 2:
>>  #0 live = 0K
>>  #0 dead = 0K
>> Tier 3:
>>  #306 live = 773K (hdr 109K, loc 61K, code 354K, stub 37K, [oops 0K, metadata 6K, data 67K, pcs 122K])
>>  #0 dead = 0K
>> Tier 4:
>>  #37 live = 110K (hdr 13K, loc 6K, code 43K, stub 1K, [oops 0K, metadata 1K, data 13K, pcs 28K])
>>  #0 dead = 0K
>> Stubs:
>>  #60 runtime = 34K (hdr 7K, loc 1K, code 24K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #1 uncommon trap = 0K (hdr 0K, loc 0K, code 0K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #1 deoptimization = 1K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #667 adapter = 512K (hdr 78K, loc 45K, code 376K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #17 buffer blob = 3163K (hdr 1K, loc 0K, code 3161K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>>  #4 other = 2K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix code style

Changes requested by eastig at github.com (no known OpenJDK username).

src/hotspot/share/code/codeCache.cpp line 1477:

> 1475:   tty->print_cr("nmethod dependency checking time %fs", dependentCheckTime.seconds());
> 1476:   for (int i = 0; i <= CompLevel_full_optimization; i++) {
> 1477:     tty->print_cr("Tier %d:", i);

What about to do it more informative:


Nmethod blobs per compilation level:
CompLevel_none:
...
CompLevel_simple:
...

src/hotspot/share/code/codeCache.cpp line 1485:

> 1483:     const char* name;
> 1484:     const CodeBlob_sizes* sizes;
> 1485:   } stubs[] = {

As `stub` has a particular meaning and there are non-stubs: adapters buffers and other, I suggest `non_nmethod_blobs` instead of `stubs`.

src/hotspot/share/code/codeCache.cpp line 1493:

> 1491:     { "other",          &other },
> 1492:   };
> 1493:   tty->print_cr("Stubs:");

Non-nmethod blobs:

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From aph at openjdk.java.net  Tue Feb 22 15:37:35 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 15:37:35 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v2]
In-Reply-To: <4WIYkTvPYenKcQlg6-tVzq4CgP8c2AHwKq9gVuXGYfI=.6b17023e-c6fb-4e2a-a7d0-2c64af75a885@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
 <H5i0iLx1tjKCplX30xZ9jkQ7s8WcZ7NeTucXgm-uUK8=.da57940f-20f5-4ccb-9038-a82796ac4b7c@github.com>
 <4WIYkTvPYenKcQlg6-tVzq4CgP8c2AHwKq9gVuXGYfI=.6b17023e-c6fb-4e2a-a7d0-2c64af75a885@github.com>
Message-ID: <4bRJhPcgcxssFS32IZdHFIOoKkyDVfTF--AYPT1vS-g=.64b59ca3-e486-4146-a7de-7cefb4cec3af@github.com>

On Tue, 22 Feb 2022 14:50:05 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> So how did you find this bug? 

Found during testing of a new OS build. Fails bootstrap.

> Is it possible to add a jtreg test for this fix?

No, because it corrupts registers in arbitrary places, causing seemingly-random crashes.
If you're lucky it'll corrupt a pointer value, in which case you're almost guaranteed a crash.
If you're unlucky it'll corrupt some data value somewhere. It's a Heisenbug.

> Please also update the copyright year. Thanks.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From aph at openjdk.java.net  Tue Feb 22 15:37:33 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 22 Feb 2022 15:37:33 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v4]
In-Reply-To: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
Message-ID: <MM86a2q3kB8vcFeV_-PeqdId-vR8_30v0LF8bXM1xWU=.fc0a286c-8728-48f1-bcdd-870a794f4a34@github.com>

> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
> 
> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7575/files
  - new: https://git.openjdk.java.net/jdk/pull/7575/files/1382812e..82423ef4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7575&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7575.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7575/head:pull/7575

PR: https://git.openjdk.java.net/jdk/pull/7575

From kvn at openjdk.java.net  Tue Feb 22 17:02:50 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 22 Feb 2022 17:02:50 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-compiler threads
In-Reply-To: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
Message-ID: <Cb8oZezIC8nqCrLz9gsbEXZjykEwKPh4shjtPqq5frk=.f456728f-5eb9-4fed-8df1-997805a30e92@github.com>

On Mon, 21 Feb 2022 11:22:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
> 
> 
>   void log_metaspace_failure(const char* reason) {
>     ResourceMark rm;
>     StringLogMessage lm;
>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>     lm.print("\n");
>     log(JavaThread::current(), "%s", (const char*)lm);
>   }
> 
> 
> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
> 
> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
> 
> 
> 12700 breakpoints set
> 12800 breakpoints set
> 12900 breakpoints set
> 13000 breakpoints set
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore

No, it could be called from Java execution thread too when profiling is triggered. But yes it was assumed that only Java thread can ask for creation `MethodData`.
On other hand `log()` methods accepts `Thread*` parameter and just record it:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/events.hpp#L183
May be we don't need to cast it to `JavaThread` in this case.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7555

From kvn at openjdk.java.net  Tue Feb 22 17:18:47 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 22 Feb 2022 17:18:47 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
Message-ID: <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>

On Tue, 22 Feb 2022 12:01:30 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   decoder, format

What benefits you have with these changes in real world?
It could be fine to use `lea` for merging several instruction, as you did.
But last time I was told that `lea` instruction has larger latency than shift instruction because it uses addressing module in CPU. I am not sure it is fine to replace it.
Also why you removed match rule which moved result of `Add` to different register?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Tue Feb 22 17:38:17 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 22 Feb 2022 17:38:17 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v3]
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>

> An example of the modified data.
> 
> java -XX:+TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCodeCache -XX:+Verbose
> 
> Tier 0:
>  #45 live = 38K (hdr 16K, loc 4K, code 18K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #0 dead = 0K
> Tier 1:
>  #56 live = 43K (hdr 20K, loc 3K, code 9K, stub 4K, [oops 0K, metadata 0K, data 0K, pcs 3K])
>  #0 dead = 0K
> Tier 2:
>  #0 live = 0K
>  #0 dead = 0K
> Tier 3:
>  #306 live = 773K (hdr 109K, loc 61K, code 354K, stub 37K, [oops 0K, metadata 6K, data 67K, pcs 122K])
>  #0 dead = 0K
> Tier 4:
>  #37 live = 110K (hdr 13K, loc 6K, code 43K, stub 1K, [oops 0K, metadata 1K, data 13K, pcs 28K])
>  #0 dead = 0K
> Stubs:
>  #60 runtime = 34K (hdr 7K, loc 1K, code 24K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #1 uncommon trap = 0K (hdr 0K, loc 0K, code 0K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #1 deoptimization = 1K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #667 adapter = 512K (hdr 78K, loc 45K, code 376K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #17 buffer blob = 3163K (hdr 1K, loc 0K, code 3161K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])
>  #4 other = 2K (hdr 0K, loc 0K, code 1K, stub 0K, [oops 0K, metadata 0K, data 0K, pcs 0K])

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Add back percentage and change descriptions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7389/files
  - new: https://git.openjdk.java.net/jdk/pull/7389/files/2afb2938..09583321

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=01-02

  Stats: 33 lines in 1 file changed: 17 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7389/head:pull/7389

PR: https://git.openjdk.java.net/jdk/pull/7389

From kvn at openjdk.java.net  Tue Feb 22 17:40:52 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 22 Feb 2022 17:40:52 GMT
Subject: RFR: 8282208: Reduce MachNode size
In-Reply-To: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
Message-ID: <4Vo1T4kBzeNNpbk6ThQbEzJ1YQKlrVGv0yGuk5d0SPo=.332d4e99-a7a6-42a2-9948-558c0f7d0fee@github.com>

On Mon, 21 Feb 2022 16:19:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
> 
> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
> 
> Fixes in this patch:
> 
> 1) Change MachNode::_remove to a Node::flag
> 
> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
> 
> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
> 
> Please review,
> Nils Eliasson

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7562

From duke at openjdk.java.net  Tue Feb 22 17:41:55 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 22 Feb 2022 17:41:55 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v3]
In-Reply-To: <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
Message-ID: <chrolEUn8Bv44O2NkML4EEYKomd1yT6247Kn3BqtPR0=.49f4dc61-71f2-49d1-8e20-38218abfcafd@github.com>

On Tue, 22 Feb 2022 17:38:17 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back percentage and change descriptions

A snippet from `java -XX:+TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintCodeCache -XX:+Verbose`


CompLevel_none:
 #45 live = 38K (hdr 16K 41%, loc 4K 10%, code 18K 46%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #0 dead = 0K
CompLevel_simple:
 #56 live = 43K (hdr 20K 46%, loc 3K 6%, code 9K 22%, stub 4K 11%, [oops 0K 0%, metadata 0K 1%, data 0K 1%, pcs 3K 7%])
 #0 dead = 0K
CompLevel_limited_profile:
 #0 live = 0K
 #0 dead = 0K
CompLevel_full_profile:
 #306 live = 777K (hdr 109K 14%, loc 61K 7%, code 356K 45%, stub 38K 4%, [oops 0K 0%, metadata 7K 0%, data 68K 8%, pcs 123K 15%])
 #0 dead = 0K
CompLevel_full_optimization:
 #39 live = 105K (hdr 14K 13%, loc 6K 5%, code 40K 38%, stub 1K 1%, [oops 0K 0%, metadata 1K 1%, data 12K 11%, pcs 26K 25%])
 #0 dead = 0K
Non-nmethod blobs:
 #60 runtime = 34K (hdr 7K 20%, loc 1K 5%, code 24K 72%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 uncommon trap = 0K (hdr 0K 20%, loc 0K 4%, code 0K 76%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #1 deoptimization = 1K (hdr 0K 8%, loc 0K 1%, code 1K 89%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #667 adapter = 512K (hdr 78K 15%, loc 45K 8%, code 376K 73%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #17 buffer blob = 3163K (hdr 1K 0%, loc 0K 0%, code 3161K 99%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])
 #4 other = 2K (hdr 0K 18%, loc 0K 2%, code 1K 77%, stub 0K 0%, [oops 0K 0%, metadata 0K 0%, data 0K 0%, pcs 0K 0%])

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From Divino.Cesar at microsoft.com  Tue Feb 22 17:59:51 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Tue, 22 Feb 2022 17:59:51 +0000
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
Message-ID: <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi Vladimir,

I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your ideas/expertise!


Cheers,
Cesar

________________________________________
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Sent: February 21, 2022 10:26 AM
To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
Cc: Brian Stafford; Martijn Verburg
Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement

Hi Cesar,

> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating specialized memory operations conditionally using the different bases.

Yes, that's a valid simplification. It does sound like introducing
selector ID doesn't require a separate memory graph (and can be
performed before split_unique_types()), but I don't have a good
understanding how complicated simplifying selector-based IR shapes would
be compared to original (memory op-based) ones. It's definitely worth
experimenting with.

Best regards,
Vladimir Ivanov

> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 17, 2022 7:37 AM
> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>
>
>> But depending on the actual shape of the base pointer (here it's
>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>> or even impossible (e.g., for complex loop variant conditions) to
>> separate instance slices.
>
> I'd like to correct myself. After thinking more about the problem, I see
> a universal way to scalarize clusters of interfering non-escaping
> allocations even in presence of accesses with indeterminate base.
>
> The crucial property for such cluster of interacting non-escaping
> allocations is for any memory access its base is either part of the
> cluster or not (it's a static property for every access). Then, when it
> is part of the cluster, then the number of possible base values at
> runtime is finite and is a subset of the cluster.
>
> So, memory graph for the cluster can be scalarized as follows:
>
>     (1) separate memory graph for the cluster
>
>     (2) on the newly constructed graph:
>
>        (a) replace every base pointer with an ID ("selector id") and
> recreate data graph for selector IDs from base pointers graph;
>
>        (b) for accesses with indeterminate base pointer, replace them
> with a merge of states from relevant allocations selected by "selector id"
>
>        (c) after 2b, all memory accesses from the cluster memory graph
> should have fixed base pointing at a particular allocation
>
>     (3) scalarize individual allocations from the cluster one by one
> (since they are independent now)
>
>        - additional transformation (like, split-through-phi) should
> simplify the graph by reducing the number of cases at merge points to
> care about (ideally, leaving only a single one);
>
>
>
> As an illustration:
>
>     val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>
> ==(pseudo-code)==>
>
>     selector = (Phi R #base1 #base2)
>
>     if (selector == #base1) {
>       val1 = Load (base1 + offset) mem
>     } else if (selector == #base2) {
>       val2 = Load (base2 + offset) mem
>     } else {
>       halt(); // impossible
>     }
>
>     val = Phi(R1, val1, val2)
>
> ======
>
>     Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>
> ==(pseudo-code)==>
>
>     selector = (Phi R #base1 #base2)
>
>     if (selector == #base1) {
>       Store base1 mem v ==> mem1
>     } else if (selector == #base2) {
>       Store base2 mem v ==> mem2
>     } else {
>       halt(); // impossible
>     }
>
>     mem = Phi(R1, mem1, mem2);
>
>
> Best regards,
> Vladimir Ivanov
>
>>
>> So, gradual approach seems the way to go:
>>     (1) split memory graph for clusters of interacting non-escaping
>> allocations;
>>
>>     (2) perform adhoc transformation targeted at untangling aliasing
>> accesses (e.g, split-through-phi);
>>
>>     (3) extract unique instance types where possible, thus making the
>> corresponding allocation scalar replaceable
>>
>> =====================================================================
>>
>> Also, one observation: interacting allocations don't have to be of the
>> same class.
>>
>>       static int testPolluted(int r, boolean b) {
>>           A obj1 = new B1(r);
>>           A obj2 = new B2(r);
>>
>>           A obj = (b ? obj1 : obj2);
>>           for (int i = 1; i < r; i++) {
>>               obj.i++;
>>           }
>>
>>           return obj1.i + obj2.i;
>>       }
>>
>> Requiring unique instance types to perform SR (and not enhancing SR to
>> handle aliasing allocations case) helps avoid some challenges in
>> instance rematerialization logic at safepoints, because actual shape of
>> the scalarized object (its class and exact set of fields) becomes a
>> runtime property.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>>>
>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>> correct memory states for the new loads above the phi which quickly
>>>>> becomes quite a challenging task.
>>>>
>>>> Especially in loops. Actually I did tried such approach before and I
>>>> agree that it is hard.
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>       p0 = Allocate(...);
>>>>>>       ...
>>>>>>       p0.x = first;
>>>>>>       p0.y = second;
>>>>>>
>>>>>>       if (cond) {
>>>>>>           p1 = Allocate(...);
>>>>>>           ...
>>>>>>           p1.x = second;
>>>>>>           p1.y = first;
>>>>>>       }
>>>>>>
>>>>>>       p = phi(p0, p1) // unused and will be removed
>>>>>>
>>>>>>
>>>>>>       return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>> }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir K
>>>>>>
>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>> hotspot-compiler-dev.)
>>>>>>>
>>>>>>> Hi Cesar,
>>>>>>>
>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>
>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>
>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>
>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>> allocations.
>>>>>>>
>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>> clusters of allocations.
>>>>>>>
>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>> TypeOopPtr::instance_id().
>>>>>>>
>>>>>>>     // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>     // a particular instance of this type which is distinct.
>>>>>>>     // This is the node index of the allocation node creating this
>>>>>>> instance.
>>>>>>>     int           _instance_id;
>>>>>>>
>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>> Hi there again!
>>>>>>>>
>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>> least partially
>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>
>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>> merged after a
>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>> situation.
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>       Point p = new Point(x, y);
>>>>>>>>       if (cond)
>>>>>>>>           p = new Point(y, x);
>>>>>>>>       // Allocations for p are merged here.
>>>>>>>>       return p.calc();
>>>>>>>> }
>>>>>>>>
>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>> will not
>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>       p0 = Allocate(...);
>>>>>>>>       ...
>>>>>>>>       p0.x = first;
>>>>>>>>       p0.y = second;
>>>>>>>>
>>>>>>>>       if (cond) {
>>>>>>>>           p1 = Allocate(...);
>>>>>>>>           ...
>>>>>>>>           p1.x = second;
>>>>>>>>           p1.y = first;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       p = phi(p0, p1)
>>>>>>>>
>>>>>>>>       return p.x - p.y;
>>>>>>>> }
>>>>>>>>
>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>> specifically the third
>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>
>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>> replace the Phi
>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>> of the objects
>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>> this after the
>>>>>>>> transformation:
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>       p0 = Allocate(...);
>>>>>>>>       ...
>>>>>>>>       p0.x = first;
>>>>>>>>       p0.y = second;
>>>>>>>>
>>>>>>>>       if (cond) {
>>>>>>>>           p1 = Allocate(...);
>>>>>>>>           ...
>>>>>>>>           p1.x = second;
>>>>>>>>           p1.y = first;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       pX = phi(first, second)
>>>>>>>>       pY = phi(second, first)
>>>>>>>>
>>>>>>>>       return pX - pY;
>>>>>>>> }
>>>>>>>>
>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>> all cases and
>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>> me that much of
>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>> of the Scalar
>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>> as possible.
>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>
>>>>>>>> split_phis(phi)
>>>>>>>>       # If output of phi escapes, or something uses its identity, etc
>>>>>>>>       # then we can't remove it. The conditions here might
>>>>>>>> possible be the
>>>>>>>>       # same as the ones implemented in
>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>       if cant_remove_phi_output(phi)
>>>>>>>>           return ;
>>>>>>>>
>>>>>>>>       # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>> field F
>>>>>>>>       # member of the object resulting from `phi`.
>>>>>>>>       fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>
>>>>>>>>       foreach field in fields_used
>>>>>>>>           producers = {}
>>>>>>>>
>>>>>>>>           # Create a list with the last Store for each field
>>>>>>>> "field" on the
>>>>>>>>           # scope of each of the Phi input objects.
>>>>>>>>           foreach o in phi.inputs
>>>>>>>>               # The function called below might re-use a lot of
>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>               producers += last_store_to_o_field(0, field)
>>>>>>>>           # Create a new phi node whose inputs are the Store's to
>>>>>>>> 'field'
>>>>>>>>           field_phi = create_new_phi(producers)
>>>>>>>>
>>>>>>>>           update_consumers(field, field_phi)
>>>>>>>>
>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>> [3] step just
>>>>>>>> after EA but before the constraint checks in
>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>> implementation goes through
>>>>>>>> the following major phases:
>>>>>>>>
>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>> based on a set of constraints.
>>>>>>>>       3. Make call to Split_unique_types [4].
>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>           4.1 Check if allocation can be eliminated.
>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>> in Safepoints.
>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>
>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>> flow to look
>>>>>>>> like this:
>>>>>>>>
>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>       2. ----> New: "Split phi functions" <----
>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>> based on a set of constraints.
>>>>>>>>       3. Make call to Split_unique_types [14].
>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>           4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>> be eliminated" <----
>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>> in Safepoints.
>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>
>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>> time to review
>>>>>>>> this!
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Cesar
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>
>>>>>>>>       [1] I am not sure yet how this approach will play with the
>>>>>>>> case of a merge
>>>>>>>>           with NULL.
>>>>>>>>       [2]
>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Ca6d5d5772dde4200119608d9f567aa3c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637810647855476172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2%2Bkgn5CKitCdFdye5WyCkTut1kdtzld4UwMsTL%2B2yS4%3D&amp;reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>>       [3] Another option would be to "patch" the current
>>>>>>>> implementation to be able
>>>>>>>>           to handle the merges. I am not certain that the "patch"
>>>>>>>> approach would be
>>>>>>>>           better, however, the "pre-process" approach is certainly
>>>>>>>> much easier to test
>>>>>>>>           and more readable.
>>>>>>>>
>>>>>>>>       [4] I cannot say I understand 100% the effects of executing
>>>>>>>>           split_unique_types(). Would the transformation that I am
>>>>>>>> proposing need to
>>>>>>>>           be after the call to split_unique_types?

From duke at openjdk.java.net  Tue Feb 22 18:10:56 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 22 Feb 2022 18:10:56 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v3]
In-Reply-To: <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
Message-ID: <D67LUXHSBFrdmmeWi_nGnxext18BNItsPbjQKKSWfW0=.38b91b6c-d098-4224-8390-dc972a2ed11d@github.com>

On Tue, 22 Feb 2022 17:38:17 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back percentage and change descriptions

Changes requested by eastig at github.com (no known OpenJDK username).

src/hotspot/share/code/codeCache.cpp line 1484:

> 1482: 
> 1483:   tty->print_cr("nmethod dependency checking time %fs", dependentCheckTime.seconds());
> 1484:   for (int i = 0; i <= CompLevel_full_optimization; i++) {

I suggest to add:

tty->print_cr("Nmethod blobs per compilation level:");

before the loop.

src/hotspot/share/code/codeCache.cpp line 1492:

> 1490:     case CompLevel_full_profile: level_name = "CompLevel_full_profile"; break;
> 1491:     case CompLevel_full_optimization: level_name = "CompLevel_full_optimization"; break;
> 1492:     default: assert(false, "invalid compLevel");

Could you please put 'level_name = ; break;' into separate lines? It should improve readability .

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From phh at openjdk.java.net  Tue Feb 22 18:29:55 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Tue, 22 Feb 2022 18:29:55 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v3]
In-Reply-To: <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
Message-ID: <g8ylb9W9dUwRizYIBSRCramGj-JSAwkltPfU8uIDGos=.a5259086-6d07-49fb-a317-49a51b1f91dd@github.com>

On Tue, 22 Feb 2022 17:38:17 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add back percentage and change descriptions

src/hotspot/share/code/codeCache.cpp line 1487:

> 1485:     const char *level_name;
> 1486:     switch (i) {
> 1487:     case CompLevel_none: level_name = "CompLevel_none"; break;

It would be less verbose if you removed the "CompLevel_" prefix and the underscores in the name strings. I.e., "none", "simple", "limited profile", "full profile", "full optimization".

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Tue Feb 22 18:37:18 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 22 Feb 2022 18:37:18 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>

> 8005885: enhance PrintCodeCache to print more data

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Improve formatting

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7389/files
  - new: https://git.openjdk.java.net/jdk/pull/7389/files/09583321..97b579bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=02-03

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7389/head:pull/7389

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Tue Feb 22 18:44:54 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Tue, 22 Feb 2022 18:44:54 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v3]
In-Reply-To: <D67LUXHSBFrdmmeWi_nGnxext18BNItsPbjQKKSWfW0=.38b91b6c-d098-4224-8390-dc972a2ed11d@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <OKmquLHw08Nn82qURGU9TAMFF4e9kz9Pm3E1GzOx2x8=.fae81248-5a47-49a3-b1c6-d3cefe82f803@github.com>
 <D67LUXHSBFrdmmeWi_nGnxext18BNItsPbjQKKSWfW0=.38b91b6c-d098-4224-8390-dc972a2ed11d@github.com>
Message-ID: <hR_8U1vHnclB5qutm28B7XrfyK0wmSK9-77puAtS_Zk=.52f0d725-8e0d-4393-b644-854250881cd5@github.com>

On Tue, 22 Feb 2022 18:05:28 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add back percentage and change descriptions
>
> src/hotspot/share/code/codeCache.cpp line 1492:
> 
>> 1490:     case CompLevel_full_profile: level_name = "CompLevel_full_profile"; break;
>> 1491:     case CompLevel_full_optimization: level_name = "CompLevel_full_optimization"; break;
>> 1492:     default: assert(false, "invalid compLevel");
> 
> Could you please put 'level_name = ; break;' into separate lines? It should improve readability .

They're better aligned now though no separate lines were added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From phh at openjdk.java.net  Tue Feb 22 18:57:50 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Tue, 22 Feb 2022 18:57:50 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
Message-ID: <a270S-v9I2cLsNzIRxmPSCi_tv7NtkuI5aBMZMK4dHg=.14874391-d45a-4e8e-8817-0c5a81c55e68@github.com>

On Tue, 22 Feb 2022 18:37:18 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve formatting

Lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Tue Feb 22 19:04:00 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 22 Feb 2022 19:04:00 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
Message-ID: <0SDZ9i-AOKHSBxIARXYMc5qpl13UaFzoGQXjzBQDF2w=.90467f45-55d2-475a-be2c-38560ea8f4e9@github.com>

On Tue, 22 Feb 2022 18:37:18 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve formatting

lgtm

-------------

Marked as reviewed by eastig at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/7389

From neliasso at openjdk.java.net  Tue Feb 22 19:08:49 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 22 Feb 2022 19:08:49 GMT
Subject: RFR: 8282208: Reduce MachNode size
In-Reply-To: <4Vo1T4kBzeNNpbk6ThQbEzJ1YQKlrVGv0yGuk5d0SPo=.332d4e99-a7a6-42a2-9948-558c0f7d0fee@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
 <4Vo1T4kBzeNNpbk6ThQbEzJ1YQKlrVGv0yGuk5d0SPo=.332d4e99-a7a6-42a2-9948-558c0f7d0fee@github.com>
Message-ID: <ZskCymQqRYWuN1fy7xVSpdh_YmHaZWvFTMxy72Ej02A=.b630a07d-0b32-4078-8080-051b92a02559@github.com>

On Tue, 22 Feb 2022 17:37:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
>> 
>> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
>> 
>> Fixes in this patch:
>> 
>> 1) Change MachNode::_remove to a Node::flag
>> 
>> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
>> 
>> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
>> 
>> Please review,
>> Nils Eliasson
>
> Good.

Thank you @vnkozlov !

I can add that I have listed the node layouts in the bug report for reference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7562

From kvn at openjdk.java.net  Tue Feb 22 19:13:54 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 22 Feb 2022 19:13:54 GMT
Subject: RFR: 8282194: C1: Missing side effects of dynamic constant linkage
In-Reply-To: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
References: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
Message-ID: <uLXUo4CBu6Om3WDAcp2lTO4ewRgV_E5FEfdNr578R_k=.7f4e568e-ba78-4545-b8af-4c1924435c11@github.com>

On Mon, 21 Feb 2022 13:20:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> After [JDK-8280473](https://bugs.openjdk.java.net/browse/JDK-8280473), C1 handles unresolved dynamic constants by performing
> constant resolution at runtime and then putting the constant value into the
> generated code by patching it. But it treats the not-yet-resolved constant as a
> pure value, dynamic constants are produced by user-defined bootstrap methods
> and there are no guarantees that they don't have any side effects.
> 
> Proposed fix conservatively kills the whole memory state after any unresolved
> dynamic constant.
> 
> Testing:
> - [x] jck:vm/constantpool/resolveDynamicConstant w/ -Xcomp
> - [x] hs-tier1 - hs-tier4

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7557

From neliasso at openjdk.java.net  Tue Feb 22 22:00:54 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 22 Feb 2022 22:00:54 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
Message-ID: <sUKWdEOkcDCYcBjcqD93l6NsJ2LPANJwpwAPOlK89Uc=.400a0244-9923-4e93-9ad6-41f9ab3fce17@github.com>

On Tue, 22 Feb 2022 18:37:18 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve formatting

Have you verified that this change doesn't break any tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From jiefu at openjdk.java.net  Tue Feb 22 23:23:53 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 22 Feb 2022 23:23:53 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v4]
In-Reply-To: <MM86a2q3kB8vcFeV_-PeqdId-vR8_30v0LF8bXM1xWU=.fc0a286c-8728-48f1-bcdd-870a794f4a34@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
 <MM86a2q3kB8vcFeV_-PeqdId-vR8_30v0LF8bXM1xWU=.fc0a286c-8728-48f1-bcdd-870a794f4a34@github.com>
Message-ID: <F6FEkWw2wMstUBtOykuKkm5Xt07q7n5gp2eP6WUXrE0=.7e9b4dc6-366c-44f7-ac9b-416a4c3ab109@github.com>

On Tue, 22 Feb 2022 15:37:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
>> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
>> 
>> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Looks good to me.
Thanks for the update.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7575

From jiefu at openjdk.java.net  Wed Feb 23 01:25:50 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Feb 2022 01:25:50 GMT
Subject: RFR: 8282208: Reduce MachNode size
In-Reply-To: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
Message-ID: <2l9-KEEimIMHmShR7XDkps8TaHPwfAyX5Kh8bW99JZk=.fd93b9df-539c-441e-9801-fdd14a5248a7@github.com>

On Mon, 21 Feb 2022 16:19:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
> 
> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
> 
> Fixes in this patch:
> 
> 1) Change MachNode::_remove to a Node::flag
> 
> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
> 
> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
> 
> Please review,
> Nils Eliasson

There are several failures in the github tests.
Did you test the failing cases with your patch?

Also, we'd better update the copyright year.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7562

From sviswanathan at openjdk.java.net  Wed Feb 23 01:34:53 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 23 Feb 2022 01:34:53 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v6]
In-Reply-To: <oMnlIO5l_pU71SvWpOFppQ-7882cq32UOjKqWZckxM0=.0efd7853-b30d-488b-92c4-4a8ad0412fda@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <oMnlIO5l_pU71SvWpOFppQ-7882cq32UOjKqWZckxM0=.0efd7853-b30d-488b-92c4-4a8ad0412fda@github.com>
Message-ID: <U8OHdsrpVYQuacfR2pi_xqdFSb0RxGAszHwa2aJCXho=.323829f3-308c-4a18-ac31-6d03e2a8983f@github.com>

On Thu, 17 Feb 2022 17:43:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | --
>> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
>> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
>> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
>> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Fixing for windows failure.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4146:

> 4144:   vaddpd(xtmp1, src , xtmp1, vec_enc);
> 4145:   vrndscalepd(dst, xtmp1, 0x4, vec_enc);
> 4146:   evcvtpd2qq(dst, dst, vec_enc);

Why do we need vrndscalepd in between, could we not directly use cvtpd2qq after vaddpd?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Wed Feb 23 05:56:52 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 23 Feb 2022 05:56:52 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>

On Tue, 22 Feb 2022 09:24:47 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

src/hotspot/cpu/x86/x86_64.ad line 8602:

> 8600:     __ jmp(done);
> 8601:     __ bind(neg_divisor_fastpath); 
> 8602:     // Fastpath for divisor < 0: 

Move in macro assembly routine.

src/hotspot/cpu/x86/x86_64.ad line 8633:

> 8631:     __ jmp(done);
> 8632:     __ bind(neg_divisor_fastpath);
> 8633:     // Fastpath for divisor < 0: 

Move in macro assembly rountine.

src/hotspot/cpu/x86/x86_64.ad line 8722:

> 8720:     __ shrl(rax, 31); // quotient
> 8721:     __ sarl(tmp, 31);
> 8722:     __ andl(tmp, divisor);

Move in macro assembly routine.

src/hotspot/cpu/x86/x86_64.ad line 8763:

> 8761:     __ andnq(rax, rax, rdx);
> 8762:     __ movq(tmp, rax);
> 8763:     __ shrq(rax, 63); // quotient

Move in macro assembly routine.

src/hotspot/cpu/x86/x86_64.ad line 8902:

> 8900:     __ subl(tmp_rax, divisor);
> 8901:     __ andnl(tmp_rax, tmp_rax, rdx);
> 8902:     __ sarl(tmp_rax, 31);

Please move this into a macro assembly routine.

src/hotspot/cpu/x86/x86_64.ad line 8932:

> 8930:     // Fastpath when divisor < 0: 
> 8931:     // remainder = dividend - (((dividend & ~(dividend - divisor)) >> (Long.SIZE - 1)) & divisor)
> 8932:     // See Hacker's Delight (2nd ed), section 9.3 which is implemented in java.lang.Long.remainderUnsigned()

Please move it into a macro assembly routine.

src/hotspot/share/opto/compile.cpp line 3499:

> 3497:       Node* d = n->find_similar(Op_UDivI);
> 3498:       if (d) {
> 3499:         // Replace them with a fused unsigned divmod if supported

Can you explain a bit here, why can't this transformation be handled earlier ?

src/hotspot/share/opto/divnode.cpp line 1350:

> 1348:     return NULL;
> 1349:   }
> 1350: 

Please remove Value and Ideal routines if no explicit transforms are being done.

src/hotspot/share/opto/divnode.cpp line 1362:

> 1360:   }
> 1361: 
> 1362: //=============================================================================

You can remove Ideal routine is not transformation is being done.

test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 76:

> 74:         return quotients;
> 75:     }
> 76: 

Return seems redundant here.

test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 83:

> 81:         }
> 82:         return remainders;
> 83:     }

Return seems redundant here.

test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 75:

> 73:         }
> 74:         return quotients;
> 75:     }

Do we need to return quotients, since it's a field  being explicitly modified.

test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 82:

> 80:             remainders[i] = Long.remainderUnsigned(dividends[i], divisors[i]);
> 81:         }
> 82:         return remainders;

Same as above

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From shade at openjdk.java.net  Wed Feb 23 07:16:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 07:16:47 GMT
Subject: RFR: 8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts
 registers [v4]
In-Reply-To: <MM86a2q3kB8vcFeV_-PeqdId-vR8_30v0LF8bXM1xWU=.fc0a286c-8728-48f1-bcdd-870a794f4a34@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
 <MM86a2q3kB8vcFeV_-PeqdId-vR8_30v0LF8bXM1xWU=.fc0a286c-8728-48f1-bcdd-870a794f4a34@github.com>
Message-ID: <meEBXNBgWeyuYu3YV8cZVfEQpNxSNGkZVycBI3OuQyc=.157e1499-d59b-4f62-b09b-25d023fe9f98@github.com>

On Tue, 22 Feb 2022 15:37:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
>> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
>> 
>> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From shade at openjdk.java.net  Wed Feb 23 07:40:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 07:40:42 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads
In-Reply-To: <Cb8oZezIC8nqCrLz9gsbEXZjykEwKPh4shjtPqq5frk=.f456728f-5eb9-4fed-8df1-997805a30e92@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <Cb8oZezIC8nqCrLz9gsbEXZjykEwKPh4shjtPqq5frk=.f456728f-5eb9-4fed-8df1-997805a30e92@github.com>
Message-ID: <Z8ICcletqvjh9nm0iwPd4X9hyIsotZ7sxTeQmPXY4Co=.4ef44944-96e8-47f6-8105-eb525fc00c6e@github.com>

On Tue, 22 Feb 2022 16:59:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> No, it could be called from Java execution thread too when profiling is triggered. But yes it was assumed that only Java thread can ask for creation `MethodData`. On other hand `log()` methods accepts `Thread*` parameter and just record it: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/events.hpp#L183 May be we don't need to cast it to `JavaThread` in this case.

Yes, this would also work:


diff --git a/src/hotspot/share/compiler/compileBroker.cpp b/src/hotspot/share/compiler/compileBroker.cpp
index 1c8656044b5..62c45e6adca 100644
--- a/src/hotspot/share/compiler/compileBroker.cpp
+++ b/src/hotspot/share/compiler/compileBroker.cpp
@@ -227,11 +227,11 @@ class CompilationLog : public StringEventLog {
   void log_metaspace_failure(const char* reason) {
     ResourceMark rm;
     StringLogMessage lm;
     lm.print("%4d   COMPILE PROFILING SKIPPED: %s", -1, reason);
     lm.print("\n");
-    log(JavaThread::current(), "%s", (const char*)lm);
+    log(Thread::current(), "%s", (const char*)lm);
   }
 };
 
 static CompilationLog* _compilation_log = NULL;


...but it is odd to: a) have the rest of `CompilationLog` accept `JavaThread` only; b) having `COMPILE SKIPPED` printed when we are not dealing with any compiler/Java thread, for example from VMThread / JVMTI code like on the path in the PR body.


void CompileBroker::log_metaspace_failure() {
  const char* message = "some methods may not be compiled because metaspace "
                        "is out of memory";
  if (_compilation_log != NULL) {
    _compilation_log->log_metaspace_failure(message);
  }
  if (PrintCompilation) {
    tty->print_cr("COMPILE PROFILING SKIPPED: %s", message); // <--- from here
  }
}


So I still believe filtering non-Java/compiler threads at `CompileBroker::log_metaspace_failure()` is the proper fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From thartmann at openjdk.java.net  Wed Feb 23 08:02:48 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 08:02:48 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
Message-ID: <lIaXGW7UJLzPHtatuVsqrHjLIXALS8Xm51izSxIKScI=.f9814d27-5070-4660-9eb8-03270919132e@github.com>

On Tue, 22 Feb 2022 17:15:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> But last time I was told that lea instruction has larger latency than shift instruction because it uses addressing module in CPU. I am not sure it is fine to replace it.

FWIW, other compilers don't seem to do that either and emit shift instructions (you can check via https://godbolt.org/).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From thartmann at openjdk.java.net  Wed Feb 23 08:10:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 08:10:45 GMT
Subject: RFR: 8282208: Reduce MachNode size
In-Reply-To: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
Message-ID: <iQGsGZG3gRA4lNbJXP_B5RaXrjNr1zIix71QbdrObpE=.e9e86532-9ba3-4230-a2fe-21ea0668ecf3@github.com>

On Mon, 21 Feb 2022 16:19:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
> 
> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
> 
> Fixes in this patch:
> 
> 1) Change MachNode::_remove to a Node::flag
> 
> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
> 
> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
> 
> Please review,
> Nils Eliasson

The value of `Node::_last_flag` needs to be updated.

src/hotspot/share/opto/node.hpp line 790:

> 788:     Flag_for_post_loop_opts_igvn     = 1 << 16,
> 789:     Flag_is_removed_by_peephole      = 1 << 17,
> 790:     _last_flag                       = Flag_for_post_loop_opts_igvn

Suggestion:

    Flag_is_removed_by_peephole      = 1 << 17,
    _last_flag                       = Flag_is_removed_by_peephole

-------------

Changes requested by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7562

From thartmann at openjdk.java.net  Wed Feb 23 08:15:48 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 08:15:48 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <sUKWdEOkcDCYcBjcqD93l6NsJ2LPANJwpwAPOlK89Uc=.400a0244-9923-4e93-9ad6-41f9ab3fce17@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
 <sUKWdEOkcDCYcBjcqD93l6NsJ2LPANJwpwAPOlK89Uc=.400a0244-9923-4e93-9ad6-41f9ab3fce17@github.com>
Message-ID: <yshHWgEzVlUla6fA_I8N6vJACqJ2b9YAdGdvnhLoxQM=.4287c90d-80aa-47d6-a5d1-b985edd849d1@github.com>

On Tue, 22 Feb 2022 21:57:15 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Have you verified that this change doesn't break any tests?

Just wanted to mention that there are several tests that match the output of `-XX:+PrintCodeCache`, for example `test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/Test.java`. Please verify that they still work.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From thartmann at openjdk.java.net  Wed Feb 23 08:22:48 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 08:22:48 GMT
Subject: RFR: 8282194: C1: Missing side effects of dynamic constant linkage
In-Reply-To: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
References: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
Message-ID: <48ysPRkPn_S1WLzSfTMOLDITKW7A3_oA6c3NWNcOZnM=.f812df8f-a22e-4bd4-b55a-9981c669d88e@github.com>

On Mon, 21 Feb 2022 13:20:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> After [JDK-8280473](https://bugs.openjdk.java.net/browse/JDK-8280473), C1 handles unresolved dynamic constants by performing
> constant resolution at runtime and then putting the constant value into the
> generated code by patching it. But it treats the not-yet-resolved constant as a
> pure value, dynamic constants are produced by user-defined bootstrap methods
> and there are no guarantees that they don't have any side effects.
> 
> Proposed fix conservatively kills the whole memory state after any unresolved
> dynamic constant.
> 
> Testing:
> - [x] jck:vm/constantpool/resolveDynamicConstant w/ -Xcomp
> - [x] hs-tier1 - hs-tier4

Looks good. Is it worth adding a regression test?

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7557

From thartmann at openjdk.java.net  Wed Feb 23 08:49:50 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 08:49:50 GMT
Subject: RFR: 8281122: [IR Framework] Cleanup IR matching code in
 preparation for JDK-8280378
In-Reply-To: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
References: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
Message-ID: <jCriPC3S7pynWBWoh5SUwGM7Hu5XbIWlJ0yOz3ksCE8=.16cd7e3f-0b50-431b-8c83-018f024fd35f@github.com>

On Fri, 18 Feb 2022 13:36:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch does some restructurings and refactorings of the `IRMatcher.java` class in preparation for adding IR matching support on different compile phases with [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). There are no semantic changes of how IR matching is eventually done on regexes and how the results are checked with the `failOn` and `counts` constraints provided by the user. The only user-visible change is an improved output format of matching failures.
> 
> The old format also did not report a `counts` constraint failure correctly. It wrongly used the format of `failOn` failures which was misleading. This is also fixed by this patch.
> 
> **Example:**
> 
> @Test
> @IR(counts = {IRNode.STORE_F, "!= 1"}) // fails
> @IR(counts = {IRNode.STORE_F, "2", IRNode.LOAD_F, "> 1"}) // both constraints fail
> public void test1() {
>     fFld = 4.2f;
> }
> 
> @Test
> @IR(failOn = IRNode.ALLOC, counts = {IRNode.STORE_F, ">= 2"}) // failOn and counts fail
> public void test2() {
>     fFld = 4.2f;
>     o = new Object();
> }
> 
> _Failure outputs:_
> <details>
>   <summary>Old format</summary>
> 
> 
> Failed IR Rules (3)
> ------------------
> - Method "public void ir_framework.tests.Testi.test1()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 1 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>   * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>         Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> - Method "public void ir_framework.tests.Testi.test2()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>     - failOn: Graph contains forbidden nodes:
>         Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>         Matched forbidden node:
>           1a5     movq    RSI, precise java/lang/Object: 0x00007fb188007318:Constant:exact *	# ptr
>     1af     call,static  wrapper for: _new_instance_Java
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> <details>
>   <summary>New format</summary>
> 
> 
> Failed IR Rules (3) of Methods (2)
> ----------------------------------
> 1) Method "public void ir_framework.tests.Testi.test1()" - [Failed IR rules: 2]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 != 1 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>    * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 = 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>        * Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 0 > 1 [given]
>          - No nodes matched!
> 
> 2) Method "public void ir_framework.tests.Testi.test2()" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>      - failOn: Graph contains forbidden nodes:
>        * Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>          - Matched forbidden node:
>            * 1a5     movq    RSI, precise java/lang/Object: 0x00007fd3c4007318:Constant:exact *	# ptr
>              1af     call,static  wrapper for: _new_instance_Java
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 >= 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> 
> **New class structure:**
> 
> The old `IRMatcher` class mixed different tasks such as parsing, IR annotation verification, IR matching and failure reporting together. This made it difficult to extend the existing code to add IR matching support on different compile phases. Therefore, the class was split to separate the different tasks:
> - parser classes (`IREncodingParser`, `HotSpotPidFileParser`, `IRMethodParser` etc.)
> - entity classes for the different parts of an `@IR` annotation (`IRMethod`, `IRRule`, `Counts`, `FailOn` etc.)
> - match result classes for each entity class to provide a formatted failure message (`IRMethodMatchResult`, `IRRuleMatchResult` etc.)
> 
> The main structure of the new classes will be kept in JDK-8280378 but will be further improved to match the new needs.
> 
> **Testing:**
> - Normal tier testing including tier5 and 6 where the IR framework tests are executed.
> - Testing of this patch in Valhalla with tier1-3 + some Valhalla-specific stress testing
> 
> 
> Thanks,
> Christian

Great work! It's hard to review though so I'm trusting your expertise in this area. Approved.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7533

From neliasso at openjdk.java.net  Wed Feb 23 08:55:27 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 23 Feb 2022 08:55:27 GMT
Subject: RFR: 8282208: Reduce MachNode size [v2]
In-Reply-To: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
Message-ID: <Vd9t1Nx3wzei0-XQv76317NaoOPIGQYrDQXQjumfzSA=.13d94137-5ad4-4557-8450-02ac73752c4c@github.com>

> Hi,
> 
> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
> 
> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
> 
> Fixes in this patch:
> 
> 1) Change MachNode::_remove to a Node::flag
> 
> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
> 
> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
> 
> Please review,
> Nils Eliasson

Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright year
 - Fix typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7562/files
  - new: https://git.openjdk.java.net/jdk/pull/7562/files/88145780..bc96f705

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7562&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7562&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7562/head:pull/7562

PR: https://git.openjdk.java.net/jdk/pull/7562

From neliasso at openjdk.java.net  Wed Feb 23 08:55:29 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 23 Feb 2022 08:55:29 GMT
Subject: RFR: 8282208: Reduce MachNode size [v2]
In-Reply-To: <iQGsGZG3gRA4lNbJXP_B5RaXrjNr1zIix71QbdrObpE=.e9e86532-9ba3-4230-a2fe-21ea0668ecf3@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
 <iQGsGZG3gRA4lNbJXP_B5RaXrjNr1zIix71QbdrObpE=.e9e86532-9ba3-4230-a2fe-21ea0668ecf3@github.com>
Message-ID: <p_6f63uENueNb1FdwInCrUy7aAEZkmFbHmOdJgWRoy4=.d02bcdce-e8ec-4085-a9ae-c5f970848d9f@github.com>

On Wed, 23 Feb 2022 08:06:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update copyright year
>>  - Fix typo
>
> src/hotspot/share/opto/node.hpp line 790:
> 
>> 788:     Flag_for_post_loop_opts_igvn     = 1 << 16,
>> 789:     Flag_is_removed_by_peephole      = 1 << 17,
>> 790:     _last_flag                       = Flag_for_post_loop_opts_igvn
> 
> Suggestion:
> 
>     Flag_is_removed_by_peephole      = 1 << 17,
>     _last_flag                       = Flag_is_removed_by_peephole

Good catch! Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7562

From neliasso at openjdk.java.net  Wed Feb 23 08:57:05 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 23 Feb 2022 08:57:05 GMT
Subject: RFR: 8282208: Reduce MachNode size
In-Reply-To: <2l9-KEEimIMHmShR7XDkps8TaHPwfAyX5Kh8bW99JZk=.fd93b9df-539c-441e-9801-fdd14a5248a7@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
 <2l9-KEEimIMHmShR7XDkps8TaHPwfAyX5Kh8bW99JZk=.fd93b9df-539c-441e-9801-fdd14a5248a7@github.com>
Message-ID: <_1jM3DqW8uM7o_iODtf_GvQXPuKyGbyk0DiYskU8DRk=.a3dc2265-6e75-4dbf-a329-ef17a9bc1034@github.com>

On Wed, 23 Feb 2022 01:22:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> There are several failures in the github tests. Did you test the failing cases with your patch?
> 
> Also, we'd better update the copyright year. Thanks.

I looked at the test failures, and they look unrelated. I've also run separate testing that didn't show these failures.

The github tests will run again now.

Updated copyright year.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7562

From thartmann at openjdk.java.net  Wed Feb 23 09:02:56 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 09:02:56 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799
In-Reply-To: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
Message-ID: <ohl1AItneca2iQDYd-LOySTnCwUZqaCxSFed7GPElx8=.53793042-38f9-4648-a28a-b6d701cca1dd@github.com>

On Wed, 16 Feb 2022 13:28:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The crash occurs because a Shenandoah barrier is expanded between the
> Start node and its control projection. One of the test cases I added
> also shows the same failure with a barrier expansion between a MemBar
> and its control projection. The barrier is expanded at the control
> that PhaseIdealLoop assigns to it.
> 
> This code:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
> I added back with JDK-8280799 is what's causing the incorrect
> placement of the barrier.
> 
> The fix I propose is to skip that logic if the loop opts pass is for
> barrier expansion as there's no range check elimination then.

Could you explain what exactly is different in the GC specific loop opts pass that makes this code incorrect?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7494

From jbhateja at openjdk.java.net  Wed Feb 23 09:03:37 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 23 Feb 2022 09:03:37 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v7]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | --
> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Review comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/f35ed9cf..6c869c76

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=05-06

  Stats: 7 lines in 2 files changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Wed Feb 23 09:03:39 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 23 Feb 2022 09:03:39 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v6]
In-Reply-To: <U8OHdsrpVYQuacfR2pi_xqdFSb0RxGAszHwa2aJCXho=.323829f3-308c-4a18-ac31-6d03e2a8983f@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <oMnlIO5l_pU71SvWpOFppQ-7882cq32UOjKqWZckxM0=.0efd7853-b30d-488b-92c4-4a8ad0412fda@github.com>
 <U8OHdsrpVYQuacfR2pi_xqdFSb0RxGAszHwa2aJCXho=.323829f3-308c-4a18-ac31-6d03e2a8983f@github.com>
Message-ID: <Wg3yyVHD32XFG0yJ_RviZkVClkkthf69po-Qe6yiDxg=.3a508365-c27c-451e-9811-c1f91d1b3162@github.com>

On Wed, 23 Feb 2022 01:31:24 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Fixing for windows failure.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4146:
> 
>> 4144:   vaddpd(xtmp1, src , xtmp1, vec_enc);
>> 4145:   vrndscalepd(dst, xtmp1, 0x4, vec_enc);
>> 4146:   evcvtpd2qq(dst, dst, vec_enc);
> 
> Why do we need vrndscalepd in between, could we not directly use cvtpd2qq after vaddpd?

Thanks @sviswa7 , when a conversion is inexact, the value returned is rounded according to the rounding control bits in the MXCSR register or the embedded rounding control bits. DONE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From thartmann at openjdk.java.net  Wed Feb 23 09:04:44 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 09:04:44 GMT
Subject: RFR: 8282208: Reduce MachNode size [v2]
In-Reply-To: <Vd9t1Nx3wzei0-XQv76317NaoOPIGQYrDQXQjumfzSA=.13d94137-5ad4-4557-8450-02ac73752c4c@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
 <Vd9t1Nx3wzei0-XQv76317NaoOPIGQYrDQXQjumfzSA=.13d94137-5ad4-4557-8450-02ac73752c4c@github.com>
Message-ID: <yt23aETW2TvVpPTDdzJQ2W-qoNfc2QLyx8ur28kGeF4=.3e4aa434-18ac-4aa2-b684-5203daf31d71@github.com>

On Wed, 23 Feb 2022 08:55:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
>> 
>> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
>> 
>> Fixes in this patch:
>> 
>> 1) Change MachNode::_remove to a Node::flag
>> 
>> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
>> 
>> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Fix typo

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7562

From thartmann at openjdk.java.net  Wed Feb 23 09:51:55 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 09:51:55 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway
In-Reply-To: <tBUTDnIQnxkGowunN2yP629eLy485hZxpNjREUA9shE=.cc412199-4de5-4cb6-81ed-ee950a2e3b8c@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
 <tBUTDnIQnxkGowunN2yP629eLy485hZxpNjREUA9shE=.cc412199-4de5-4cb6-81ed-ee950a2e3b8c@github.com>
Message-ID: <ho6YNRDpr3Xp1i7x9mck4FPNrr_QyzDBBnn4R6w-ys8=.58063bf6-b506-4c70-98c1-0222e3c72399@github.com>

On Wed, 23 Feb 2022 09:32:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I noticed that if loop strip mining fails because a safepoint is not
>> found right above the exit test (following partial peel for instance),
>> all safepoints are removed from the loop anyway. That's fixed by the
>> change in IdealLoopTree::counted_loop() where rather than test if loop
>> strip mining is enabled, the check now verifies that loop strip mining
>> was successful.
>> 
>> With that change,
>> compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
>> is not converted into a strip mined loop because there's no safepoint
>> above the exit test after partial peeling. The loop strip mining logic
>> is too strict when it comes to the safepoint location. Any safepoint
>> that dominates the exit and is in the loop as long as there's no side
>> effect between the safepoint and the exit can be used. The patch
>> implements that change as well. TestAutoVectorization2DArray.java
>> passes as a result.
>> 
>> The existing requirement to have no safepoint on the backedge is too
>> strict as well. If the loop has another safepoint that can be used for
>> strip mining, then the safepoint on the backedge can safely be
>> dropped. That's also implemented by the patch.
>
> src/hotspot/share/opto/loopnode.cpp line 1852:
> 
>> 1850:   }
>> 1851: 
>> 1852:   Node *sfpt2 = NULL;
> 
> Suggestion:
> 
>   Node* sfpt2 = NULL;

I would suggest to rename `sfpt2` to `sfpt` and `sfpt` below to `backedge_sfpt`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7513

From thartmann at openjdk.java.net  Wed Feb 23 09:51:55 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 09:51:55 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway
In-Reply-To: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
Message-ID: <tBUTDnIQnxkGowunN2yP629eLy485hZxpNjREUA9shE=.cc412199-4de5-4cb6-81ed-ee950a2e3b8c@github.com>

On Thu, 17 Feb 2022 10:00:32 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I noticed that if loop strip mining fails because a safepoint is not
> found right above the exit test (following partial peel for instance),
> all safepoints are removed from the loop anyway. That's fixed by the
> change in IdealLoopTree::counted_loop() where rather than test if loop
> strip mining is enabled, the check now verifies that loop strip mining
> was successful.
> 
> With that change,
> compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
> is not converted into a strip mined loop because there's no safepoint
> above the exit test after partial peeling. The loop strip mining logic
> is too strict when it comes to the safepoint location. Any safepoint
> that dominates the exit and is in the loop as long as there's no side
> effect between the safepoint and the exit can be used. The patch
> implements that change as well. TestAutoVectorization2DArray.java
> passes as a result.
> 
> The existing requirement to have no safepoint on the backedge is too
> strict as well. If the loop has another safepoint that can be used for
> strip mining, then the safepoint on the backedge can safely be
> dropped. That's also implemented by the patch.

Noticed a typo in `PhaseIdealLoop::find_safepoint` that you might want to fix as well with this patch:
`there's not side effect` -> `there's no side effect`

src/hotspot/share/opto/loopnode.cpp line 1852:

> 1850:   }
> 1851: 
> 1852:   Node *sfpt2 = NULL;

Suggestion:

  Node* sfpt2 = NULL;

src/hotspot/share/opto/loopnode.cpp line 1863:

> 1861: 
> 1862:   if (x->in(LoopNode::LoopBackControl)->Opcode() == Op_SafePoint) {
> 1863:     Node *sfpt = x->in(LoopNode::LoopBackControl);

Suggestion:

    Node* sfpt = x->in(LoopNode::LoopBackControl);

src/hotspot/share/opto/loopnode.cpp line 1874:

> 1872:       return false;
> 1873:     }
> 1874:     if (deleteable) {

Can't you check `is_deleteable_safept` inline here like old code did?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7513

From vlivanov at openjdk.java.net  Wed Feb 23 10:17:53 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 23 Feb 2022 10:17:53 GMT
Subject: RFR: 8282194: C1: Missing side effects of dynamic constant linkage
In-Reply-To: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
References: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
Message-ID: <WSNYpTe_7V8Zu7gqiEwisIa-_Uj7Dg-V5pCjiPKv_P4=.71bd5bc1-eae0-44db-af46-cbc239c1f29e@github.com>

On Mon, 21 Feb 2022 13:20:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> After [JDK-8280473](https://bugs.openjdk.java.net/browse/JDK-8280473), C1 handles unresolved dynamic constants by performing
> constant resolution at runtime and then putting the constant value into the
> generated code by patching it. But it treats the not-yet-resolved constant as a
> pure value, dynamic constants are produced by user-defined bootstrap methods
> and there are no guarantees that they don't have any side effects.
> 
> Proposed fix conservatively kills the whole memory state after any unresolved
> dynamic constant.
> 
> Testing:
> - [x] jck:vm/constantpool/resolveDynamicConstant w/ -Xcomp
> - [x] hs-tier1 - hs-tier4

Thanks for the reviews, Vladimir and Tobias.

> Is it worth adding a regression test?

Strictly speaking, `jck:vm/constantpool/resolveDynamicConstant` tests catch the problem. 
But I plan to add new test as part of [JDK-8282218](https://bugs.openjdk.java.net/browse/JDK-8282218). Will consider adding a case for dynamic constants there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7557

From aph at openjdk.java.net  Wed Feb 23 10:18:52 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 23 Feb 2022 10:18:52 GMT
Subject: Integrated: 8282231: x86-32: runtime call to SharedRuntime::ldiv
 corrupts registers
In-Reply-To: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
References: <V36tj_Y94NwN6g9VgUByDupfAmSdJJwJKKbtomUH9tU=.f648eacd-4fc3-4e06-8895-47d109b822ea@github.com>
Message-ID: <qM5qAkOhNY8botgNuFrzL_jERU-U2RSoHcu9bycN2ZE=.2a94fcc0-316e-4a87-9832-5774e9e77c25@github.com>

On Tue, 22 Feb 2022 13:34:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

> In x86_32.ad, a call to SharedRuntime::ldiv doesn't save all of the call-clobbered registers. Also SharedRuntime::lrem. 
> effect(CALL) is the simplest way to fix this, and AFAIK the most efficient too.
> 
> This is by no means the only bug in this area, but it's trivial to fix and allows a bootcycle build to complete on recent Linuxes.

This pull request has now been integrated.

Changeset: ecd85e6f
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ecd85e6f0f8906ad1e8aa0a53bf499e8c969ba73
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8282231: x86-32: runtime call to SharedRuntime::ldiv corrupts registers

Reviewed-by: shade, jiefu

-------------

PR: https://git.openjdk.java.net/jdk/pull/7575

From vlivanov at openjdk.java.net  Wed Feb 23 10:21:53 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 23 Feb 2022 10:21:53 GMT
Subject: Integrated: 8282194: C1: Missing side effects of dynamic constant
 linkage
In-Reply-To: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
References: <exVRgqOBw0LUJgEfIdTyZwAk_YvIC1IUiFWCwuxvz2Y=.cadd38b0-36d0-40e3-9e5a-6733a3703a5b@github.com>
Message-ID: <A8deoF7HUmAAKRIH5OFGARVxQ_U4o_7BHqIN0xX0NcA=.73ce6029-4eae-41ec-8170-40fce3ecf86a@github.com>

On Mon, 21 Feb 2022 13:20:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> After [JDK-8280473](https://bugs.openjdk.java.net/browse/JDK-8280473), C1 handles unresolved dynamic constants by performing
> constant resolution at runtime and then putting the constant value into the
> generated code by patching it. But it treats the not-yet-resolved constant as a
> pure value, dynamic constants are produced by user-defined bootstrap methods
> and there are no guarantees that they don't have any side effects.
> 
> Proposed fix conservatively kills the whole memory state after any unresolved
> dynamic constant.
> 
> Testing:
> - [x] jck:vm/constantpool/resolveDynamicConstant w/ -Xcomp
> - [x] hs-tier1 - hs-tier4

This pull request has now been integrated.

Changeset: 93320717
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9332071784b7150512f7e27b07c290a356d43c2e
Stats:     35 lines in 5 files changed: 30 ins; 0 del; 5 mod

8282194: C1: Missing side effects of dynamic constant linkage

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7557

From jiefu at openjdk.java.net  Wed Feb 23 11:23:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Feb 2022 11:23:54 GMT
Subject: RFR: 8282208: Reduce MachNode size [v2]
In-Reply-To: <Vd9t1Nx3wzei0-XQv76317NaoOPIGQYrDQXQjumfzSA=.13d94137-5ad4-4557-8450-02ac73752c4c@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
 <Vd9t1Nx3wzei0-XQv76317NaoOPIGQYrDQXQjumfzSA=.13d94137-5ad4-4557-8450-02ac73752c4c@github.com>
Message-ID: <QEUhxZhZyMnWguIx_BjzTYghhlvQlCeL8QnvkXnovbk=.518bc7c1-a336-41f5-9d03-7a274e01ff7f@github.com>

On Wed, 23 Feb 2022 08:55:27 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Hi,
>> 
>> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
>> 
>> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
>> 
>> Fixes in this patch:
>> 
>> 1) Change MachNode::_remove to a Node::flag
>> 
>> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
>> 
>> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
>> 
>> Please review,
>> Nils Eliasson
>
> Nils Eliasson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright year
>  - Fix typo

LGTM

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7562

From duke at openjdk.java.net  Wed Feb 23 12:09:33 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 23 Feb 2022 12:09:33 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v3]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <Je8CmWYb3uyqL-QvbTbGbE3H1TSps1TgTebld_fW8VA=.7b2d4404-fb2b-482c-8596-c16d7b9a1391@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add predicate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/bcaeb3d3..b09260b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=01-02

  Stats: 39 lines in 2 files changed: 25 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Wed Feb 23 12:25:49 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 23 Feb 2022 12:25:49 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
Message-ID: <1k_7qNyAg0M2gcQaAD_lQv-v_pRb7uJ5_GnNYRAvnNU=.7f843bf1-a56d-42cc-8a26-53133ef44fb7@github.com>

On Tue, 22 Feb 2022 17:15:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   decoder, format
>
> What benefits you have with these changes in real world?
> It could be fine to use `lea` for merging several instruction, as you did.
> But last time I was told that `lea` instruction has larger latency than shift instruction because it uses addressing module in CPU. I am not sure it is fine to replace it.
> Also why you removed match rule which moved result of `Add` to different register?

@vnkozlov Given `lea` is a really efficient instruction, merging multiple ones into it offers a lot of benefits and all other compilers do so.
The removed match rule seems to never match and it does not perform better than a `mov` + `add` since a `mov` is often elided and an `add` may be executed on more ports than a `lea`.
I have added predicate conditions to address your concerns regarding different execution unit.
@TobiHartmann Actually they are similar, if you force the `src` and `dst` to be different (by calling convention), other compilers would produce a `lea` on O3. But a base-less `lea` is large in size so I revert that change.
Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From neliasso at openjdk.java.net  Wed Feb 23 12:50:53 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 23 Feb 2022 12:50:53 GMT
Subject: Integrated: 8282208: Reduce MachNode size
In-Reply-To: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
References: <fQIOxjVQsMheeHG8YdnrpDJJn1qdSxyFvFe09ODwkz0=.757cd63b-e3ac-44f9-9b04-31eac9f61741@github.com>
Message-ID: <NsbMYagNCLPVznqkr1w9-X1ZJPm766lN0HRMPDvy1JM=.1c7bd037-cd64-4ba4-859b-4825cbe6da98@github.com>

On Mon, 21 Feb 2022 16:19:01 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch reduces the size of MachNode from 72  to 64 bytes in product builds, and from 120 to 104 bytes in debug builds. In debug builds the size of Node is reduced from 104 to 96 bytes.
> 
> The motivation for this patch is that I needed more bits for the _barrier_data field. (This will happen in another patch.) I noticed that the bool _remove field caused a lot of padding. It's only used by peephole and can as well be modeled as a Node::flag. This change together with a slight rearrangement of fields a lot of unnecessary padding can be eliminated. 
> 
> Fixes in this patch:
> 
> 1) Change MachNode::_remove to a Node::flag
> 
> 2) Changing MachNode::operands to a 16 bit unsigned (Allowing room for 16 bits _barrier_data later) 
> 
> 3) Moving Node::_debug_idx below Node::_debug_orig saves 8 bytes in debug builds. This is achieved by having an even number of 4 bytes fields in a row, eliminating two 4 byte paddings.
> 
> Please review,
> Nils Eliasson

This pull request has now been integrated.

Changeset: 5035bf5e
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5035bf5e6cb0ae2892e128b9a7c4014d01addb26
Stats:     18 lines in 2 files changed: 5 ins; 6 del; 7 mod

8282208: Reduce MachNode size

Reviewed-by: kvn, thartmann, jiefu

-------------

PR: https://git.openjdk.java.net/jdk/pull/7562

From jiefu at openjdk.java.net  Wed Feb 23 13:57:50 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 23 Feb 2022 13:57:50 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
Message-ID: <uuZvaCwbFc7sM44SGzVOTVcUmIHboQSMFr5qmvv23GM=.d08b63a6-a2e6-4c17-a011-cfd8f1921165@github.com>

On Tue, 22 Feb 2022 17:15:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   decoder, format
>
> What benefits you have with these changes in real world?
> It could be fine to use `lea` for merging several instruction, as you did.
> But last time I was told that `lea` instruction has larger latency than shift instruction because it uses addressing module in CPU. I am not sure it is fine to replace it.
> Also why you removed match rule which moved result of `Add` to different register?

> @vnkozlov Given `lea` is a really efficient instruction, merging multiple ones into it offers a lot of benefits and all other compilers do so.

So any benchmark to show the perf improvement?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jvernee at openjdk.java.net  Wed Feb 23 14:04:00 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Feb 2022 14:04:00 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <TzemfXSgKXJd1fQfF6wgg_d08te0H9zD5Y5HnHRfFM0=.7085736c-69f6-45ce-98c5-b40a3a1ba51a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <TzemfXSgKXJd1fQfF6wgg_d08te0H9zD5Y5HnHRfFM0=.7085736c-69f6-45ce-98c5-b40a3a1ba51a@github.com>
Message-ID: <8emJ_fnuLCHAiwNOadci0vANT2udlnGvyaHHTGnGMZE=.af3daa4a-29db-49db-8a59-2d52de87ee11@github.com>

On Wed, 16 Feb 2022 04:41:43 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/share/opto/escape.cpp line 1832:
> 
>> 1830:         // Mark all objects.
>> 1831:         set_not_scalar_replaceable(jobj NOT_PRODUCT(COMMA "is merged with other object"));
>> 1832:         set_not_scalar_replaceable(ptn NOT_PRODUCT(COMMA "is merged with other object"));
> 
> how about we also dump Java Object(x) here? eg. 
> 
> JavaObject(8) NoEscape(NoEscape) is NSR. is merged with other java object(4)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR is NSR. is merged with other java object(8)

That seems like a good idea. Will apply it

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From jvernee at openjdk.java.net  Wed Feb 23 14:20:53 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Feb 2022 14:20:53 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <ci6JmwsAjg3sy3ZsUv-kGRukBtfWcHQpTlUsQaUTHno=.1953c363-2f87-4cf7-9c6a-07d0281b1914@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
 <Tb1iWHUmKRd87LOvrcr79uMC8DgEpOrTgk7-2HTzqHE=.335f5a26-bc1b-4c08-aee4-305cff3490ce@github.com>
 <ci6JmwsAjg3sy3ZsUv-kGRukBtfWcHQpTlUsQaUTHno=.1953c363-2f87-4cf7-9c6a-07d0281b1914@github.com>
Message-ID: <lN04PdbQEB-YE3GfJJesC5ozBKVO_kSmlfo7wjGp6ZY=.7d162ab9-f7da-47b2-819d-ba64d9f195e3@github.com>

On Wed, 16 Feb 2022 01:54:28 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> I can get the debugger argument, but I'm not sure I see how doing this would make the code cleaner...
>> 
>> Instead of printing out the reason message directly in set_(fields_)escape_state/set_not_scalar_replaceable we would set it in `PointsToNode.reason`, and then afterwards walk the graph to print out all messages?
>> 
>> One potential problem with that approach is that if a node is first updated to ArgEscape, and then later to GlobalEscape, the first state transition would not be visible. (i.e. the PR is not just annotating nodes, it's annotating state transitions, and there can be multiple state transitions per node)
>
> C/C++ macro is very powerful. however, it may scramble code.  If we refrain abusing, I think C++ can achieve cleaner code like Java. 
> 
>> Instead of printing out the reason message directly in set_(fields_)escape_state/set_not_scalar_replaceable we would set it in PointsToNode.reason, and then afterwards walk the graph to print out all messages?
> 
> I mean we can do thing like this: 
> ```ptn->reason = "stored at raw address";```
> 
> and then 
> 
> void ConnectionGraph::trace_es_update_helper(PointsToNode* ptn, PointsToNode::EscapeState es, bool fields) const {
>   if (_compile->directive()->TraceEscapeAnalysisOption) {
>     assert(ptn != nullptr, "should not be null");
>     assert(ptn->reason != nullptr, "should not be null");
>     ptn->dump_header(true);
>     PointsToNode::EscapeState new_es = fields ? ptn->escape_state() : es;
>     PointsToNode::EscapeState new_fields_es = fields ? es : ptn->fields_escape_state();
>     tty->print_cr("-> %s(%s) %s", esc_names[(int)new_es], esc_names[(int)new_fields_es], ptn->reason);
>   }
> }
> 
> 
> PointsToNode::reason is just a global variable. it can prevent you from passing the argument under macro expansion. 
> if inliner and scalar replacement of gcc is at work, this field can be removed. Since we only use PointsToNode::reason in debug build, it doesn't matter if gcc misses that.

Ok, so if I understand correctly, the issue is with the `NOT_PRODUCT(COMMA ...)` in the arguments list.

I think it doesn't look great either, but it seems like the best alternative if we want to make sure no code is generated in product builds. I think using macros in this way is the best way of doing that. If we were to depend on compiler optimizations to eliminate bits in product builds, I think we should just make the reason parameter unconditional, rather than piggybacking on a field of PointsToNode. The compiler should see that it is unused on product builds. That seems even cleaner. But I think the intent is much clearer with the NOT_PRODUCT macro, since it's more obvious that this code will not be in product builds from the call site.

I don't like the idea of splitting the reason string out of the parameter list either, since it requires callers to remember to also separately set the reason string. Having it as a parameter forces callers to think about it.

An alternative idea is to declare new macros for setting the escape state and scalar replaceability like so:

    #ifndef PRODUCT
    #define SET_ESCAPE_STATE(node, es, reason) set_escape_sate(node, es, reason)
    #else 
    #define SET_ESCAPE_STATE(node, es, reason) set_escape_sate(node, es)
    #endif

Where the product version drops the reason string. But, I think this is also a bit too magic, and a bit worse than the current solution.

Sorry, but I think I'd rather stick with what I have now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From jvernee at openjdk.java.net  Wed Feb 23 14:47:19 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Feb 2022 14:47:19 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v5]
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <R8tDDk2bdyprRy8D5JHfpmAyhJg1saXW2qhGs_TvHl0=.d876cbd0-e9f0-4af5-a5f4-217413b5dc48@github.com>

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4
> 
> Thanks,
> Jorn

Jorn Vernee 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/7428/files
  - new: https://git.openjdk.java.net/jdk/pull/7428/files/df1bc990..98f0193a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7428&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7428&range=03-04

  Stats: 23 lines in 2 files changed: 16 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7428/head:pull/7428

PR: https://git.openjdk.java.net/jdk/pull/7428

From jvernee at openjdk.java.net  Wed Feb 23 14:47:22 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Feb 2022 14:47:22 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
Message-ID: <OL6eQGPjXmDQv-3F3umVTCUkyowc8XGKxG5bs9gH4aM=.fce53bf8-a642-489f-9936-23d0ae8f7b53@github.com>

On Tue, 15 Feb 2022 12:50:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

I've addressed the open review comments. Please have another look.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From jvernee at openjdk.java.net  Wed Feb 23 14:47:24 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Feb 2022 14:47:24 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <PhBZL3WujLY1Y_Apw1dRciibcARI3cJFc5t0zKSJ8rA=.e32e7a7b-a05c-4dd2-b527-772a870b0a23@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <PhBZL3WujLY1Y_Apw1dRciibcARI3cJFc5t0zKSJ8rA=.e32e7a7b-a05c-4dd2-b527-772a870b0a23@github.com>
Message-ID: <4kyXoF4CrrM22VcSjsMU0hT7REAPjFz6Aqmvx8FSaW8=.bda7909e-5f89-4d01-84a9-f20d737f55c1@github.com>

On Wed, 16 Feb 2022 19:44:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/share/opto/escape.cpp line 1148:
> 
>> 1146:             }
>> 1147:           }
>> 1148:           set_escape_state(arg_ptn, es NOT_PRODUCT(COMMA "reason unknown (1)"));
> 
> Transition here is `NoEscape` -> `ArgEscape`. So the reason could be "is argument".

Thanks for the suggestion. I think we can use `trace_arg_escape_message` here to also print out the relevant call node. The message would then be `escapes as arg to call: [call node]`

> src/hotspot/share/opto/escape.cpp line 3169:
> 
>> 3167:         alloc->as_Allocate()->_is_scalar_replaceable = true;
>> 3168:       }
>> 3169:       set_escape_state(ptnode_adr(n->_idx), es NOT_PRODUCT(COMMA "reason unknown (2)")); // CheckCastPP escape state
> 
> Escape state of allocation is assigned to CheckCastPP node. `es` value should be `NoEscape` - see line 3109.
> May be reason should be "assign state of related Allocation".

Thanks. We can use `trace_propagate_message` to also print out the source allocation node `ptn`. The message would then be `propagated from: [relevant Allocation PointsToNode]`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From kvn at openjdk.java.net  Wed Feb 23 16:58:56 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 23 Feb 2022 16:58:56 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads
In-Reply-To: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
Message-ID: <m8vFNkBeWRfM6lIfc6gLbiDMl0draS47agnsFBlMtl8=.b2433750-40c7-4255-a404-5ff0e9b10f6e@github.com>

On Mon, 21 Feb 2022 11:22:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
> 
> 
>   void log_metaspace_failure(const char* reason) {
>     ResourceMark rm;
>     StringLogMessage lm;
>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>     lm.print("\n");
>     log(JavaThread::current(), "%s", (const char*)lm);
>   }
> 
> 
> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
> 
> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
> 
> 
> 12700 breakpoints set
> 12800 breakpoints set
> 12900 breakpoints set
> 13000 breakpoints set
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore

src/hotspot/share/compiler/compileBroker.cpp line 2038:

> 2036:   const char* message = "some methods may not be compiled because metaspace "
> 2037:                         "is out of memory";
> 2038:   if (_compilation_log != NULL) {

Okay. But  can you add the thread check here so that at least we get message with `PrintCompilation`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From shade at openjdk.java.net  Wed Feb 23 17:08:31 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 17:08:31 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
Message-ID: <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>

> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
> 
> 
>   void log_metaspace_failure(const char* reason) {
>     ResourceMark rm;
>     StringLogMessage lm;
>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>     lm.print("\n");
>     log(JavaThread::current(), "%s", (const char*)lm);
>   }
> 
> 
> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
> 
> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
> 
> 
> 12700 breakpoints set
> 12800 breakpoints set
> 12900 breakpoints set
> 13000 breakpoints set
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore

Aleksey Shipilev 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:

 - Another fix
 - Merge branch 'master' into JDK-8282172-compiler-broker-message
 - Fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7555/files
  - new: https://git.openjdk.java.net/jdk/pull/7555/files/82508eb5..8a91ce8d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7555&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7555&range=00-01

  Stats: 1342 lines in 40 files changed: 686 ins; 576 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7555/head:pull/7555

PR: https://git.openjdk.java.net/jdk/pull/7555

From shade at openjdk.java.net  Wed Feb 23 17:08:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Feb 2022 17:08:33 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <m8vFNkBeWRfM6lIfc6gLbiDMl0draS47agnsFBlMtl8=.b2433750-40c7-4255-a404-5ff0e9b10f6e@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <m8vFNkBeWRfM6lIfc6gLbiDMl0draS47agnsFBlMtl8=.b2433750-40c7-4255-a404-5ff0e9b10f6e@github.com>
Message-ID: <xk1Vimqt1hOzfGKpj3NJj_k4n8y56II2efmGvKHHF30=.072b3939-f8e8-4ace-b56e-b75dbacb60c5@github.com>

On Wed, 23 Feb 2022 16:55:26 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Aleksey Shipilev 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:
>> 
>>  - Another fix
>>  - Merge branch 'master' into JDK-8282172-compiler-broker-message
>>  - Fix
>
> src/hotspot/share/compiler/compileBroker.cpp line 2038:
> 
>> 2036:   const char* message = "some methods may not be compiled because metaspace "
>> 2037:                         "is out of memory";
>> 2038:   if (_compilation_log != NULL) {
> 
> Okay. But  can you add the thread check here so that at least we get message with `PrintCompilation`?

Nevermind, let's do it your way. The over-logging is better than under-logging. See new commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From kvn at openjdk.java.net  Wed Feb 23 17:13:49 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 23 Feb 2022 17:13:49 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
Message-ID: <RVV4IyfUVH7NeIFYlJkHjVteAO0jqoazv8XNpw6nEB0=.1dc78e4e-fbb0-4d3a-ba08-00edd161f020@github.com>

On Wed, 23 Feb 2022 17:08:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
>> 
>> 
>>   void log_metaspace_failure(const char* reason) {
>>     ResourceMark rm;
>>     StringLogMessage lm;
>>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>>     lm.print("\n");
>>     log(JavaThread::current(), "%s", (const char*)lm);
>>   }
>> 
>> 
>> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
>> 
>> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
>> 
>> 
>> 12700 breakpoints set
>> 12800 breakpoints set
>> 12900 breakpoints set
>> 13000 breakpoints set
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
>> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
>> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
>> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
>> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
>> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
>> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
>> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore
>
> Aleksey Shipilev 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:
> 
>  - Another fix
>  - Merge branch 'master' into JDK-8282172-compiler-broker-message
>  - Fix

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7555

From jvernee at openjdk.java.net  Wed Feb 23 17:17:02 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Feb 2022 17:17:02 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <VKjppXYqpX0GKITWWRtxwtoyaTGoVJxIZOiyNCGqDfo=.1a8abd3a-46d0-46ee-9d2c-0ec6b2297bd9@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <VKjppXYqpX0GKITWWRtxwtoyaTGoVJxIZOiyNCGqDfo=.1a8abd3a-46d0-46ee-9d2c-0ec6b2297bd9@github.com>
Message-ID: <aN74IWt01RaRj9LBfaXp0_KwBLi3ynWKY80VY8s2xZU=.1a1a7740-7319-4a0a-9df7-e88665d6bbe6@github.com>

On Wed, 16 Feb 2022 19:18:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/share/opto/escape.cpp line 918:
> 
>> 916:           // Not scalar replaceable if the length is not constant or too big.
>> 917:           scalar_replaceable = false;
>> 918:           NOT_PRODUCT(nsr_reason = "has a non-constant or too big length");
> 
> Can you separate these two cases: `non-constant` and `too big`? You can split the above check.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From duke at openjdk.java.net  Wed Feb 23 18:42:52 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Wed, 23 Feb 2022 18:42:52 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <yshHWgEzVlUla6fA_I8N6vJACqJ2b9YAdGdvnhLoxQM=.4287c90d-80aa-47d6-a5d1-b985edd849d1@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
 <sUKWdEOkcDCYcBjcqD93l6NsJ2LPANJwpwAPOlK89Uc=.400a0244-9923-4e93-9ad6-41f9ab3fce17@github.com>
 <yshHWgEzVlUla6fA_I8N6vJACqJ2b9YAdGdvnhLoxQM=.4287c90d-80aa-47d6-a5d1-b985edd849d1@github.com>
Message-ID: <6uKDEhAtHZtZ818Ku3u1UMIeXt6tABpHlEd8rrsDRvE=.8392211f-b8cb-4203-9c87-4ff9beb4d7a1@github.com>

On Wed, 23 Feb 2022 08:13:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> > Have you verified that this change doesn't break any tests?
> 
> Just wanted to mention that there are several tests that match the output of `-XX:+PrintCodeCache`, for example `test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/Test.java`. Please verify that they still work.

No regression was found in tier 2 and 3 tests, and the following tests all pass. There is no change in the output of `-XX:+PrintCodeCache` if `-XX:+Verbose` is not specified.


jtreg:test/hotspot/jtreg/compiler/codecache/CheckSegmentedCodeCache.java
jtreg:test/hotspot/jtreg/compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java
jtreg:test/hotspot/jtreg/compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java
jtreg:test/hotspot/jtreg/compiler/codecache/cli/TestSegmentedCodeCacheOption.java
jtreg:test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfo/Test.java
jtreg:test/hotspot/jtreg/vmTestbase/vm/compiler/CodeCacheInfoOnCompilation/Test.java
jtreg:test/jdk/com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From thartmann at openjdk.java.net  Wed Feb 23 19:06:54 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Feb 2022 19:06:54 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v4]
In-Reply-To: <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <sDsmMG5S1FRrAj7f6hu-CvcmgNOqwqLf3PL1KSM6dVo=.8ebfa0e9-47c6-48c7-90d1-69d88e21590b@github.com>
Message-ID: <jwVcVtAZcQYmHb66Crz_dm76dZ0ktfXRVfBtERFUPdM=.5495cd0a-bea5-43cb-a12d-2194f6b29b0e@github.com>

On Tue, 22 Feb 2022 18:37:18 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve formatting

Okay, thanks for verifying!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From kvn at openjdk.java.net  Wed Feb 23 19:09:54 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 23 Feb 2022 19:09:54 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <lN04PdbQEB-YE3GfJJesC5ozBKVO_kSmlfo7wjGp6ZY=.7d162ab9-f7da-47b2-819d-ba64d9f195e3@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
 <Tb1iWHUmKRd87LOvrcr79uMC8DgEpOrTgk7-2HTzqHE=.335f5a26-bc1b-4c08-aee4-305cff3490ce@github.com>
 <ci6JmwsAjg3sy3ZsUv-kGRukBtfWcHQpTlUsQaUTHno=.1953c363-2f87-4cf7-9c6a-07d0281b1914@github.com>
 <lN04PdbQEB-YE3GfJJesC5ozBKVO_kSmlfo7wjGp6ZY=.7d162ab9-f7da-47b2-819d-ba64d9f195e3@github.com>
Message-ID: <1nvasKTG9vkr1mmPhqn3-1_JYRqog6Suu9OxxoM-0yk=.a9a6f6ac-be4e-434a-ac40-13093751db33@github.com>

On Wed, 23 Feb 2022 14:17:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> C/C++ macro is very powerful. however, it may scramble code.  If we refrain abusing, I think C++ can achieve cleaner code like Java. 
>> 
>>> Instead of printing out the reason message directly in set_(fields_)escape_state/set_not_scalar_replaceable we would set it in PointsToNode.reason, and then afterwards walk the graph to print out all messages?
>> 
>> I mean we can do thing like this: 
>> ```ptn->reason = "stored at raw address";```
>> 
>> and then 
>> 
>> void ConnectionGraph::trace_es_update_helper(PointsToNode* ptn, PointsToNode::EscapeState es, bool fields) const {
>>   if (_compile->directive()->TraceEscapeAnalysisOption) {
>>     assert(ptn != nullptr, "should not be null");
>>     assert(ptn->reason != nullptr, "should not be null");
>>     ptn->dump_header(true);
>>     PointsToNode::EscapeState new_es = fields ? ptn->escape_state() : es;
>>     PointsToNode::EscapeState new_fields_es = fields ? es : ptn->fields_escape_state();
>>     tty->print_cr("-> %s(%s) %s", esc_names[(int)new_es], esc_names[(int)new_fields_es], ptn->reason);
>>   }
>> }
>> 
>> 
>> PointsToNode::reason is just a global variable. it can prevent you from passing the argument under macro expansion. 
>> if inliner and scalar replacement of gcc is at work, this field can be removed. Since we only use PointsToNode::reason in debug build, it doesn't matter if gcc misses that.
>
> Ok, so if I understand correctly, the issue is with the `NOT_PRODUCT(COMMA ...)` in the arguments list.
> 
> I think it doesn't look great either, but it seems like the best alternative if we want to make sure no code is generated in product builds. I think using macros in this way is the best way of doing that. If we were to depend on compiler optimizations to eliminate bits in product builds, I think we should just make the reason parameter unconditional, rather than piggybacking on a field of PointsToNode. The compiler should see that it is unused on product builds. That seems even cleaner. But I think the intent is much clearer with the NOT_PRODUCT macro, since it's more obvious that this code will not be in product builds from the call site.
> 
> I don't like the idea of splitting the reason string out of the parameter list either, since it requires callers to remember to also separately set the reason string. Having it as a parameter forces callers to think about it.
> 
> An alternative idea is to declare new macros for setting the escape state and scalar replaceability like so:
> 
>     #ifndef PRODUCT
>     #define SET_ESCAPE_STATE(node, es, reason) set_escape_sate(node, es, reason)
>     #else 
>     #define SET_ESCAPE_STATE(node, es, reason) set_escape_sate(node, es)
>     #endif
> 
> Where the product version drops the reason string. But, I think this is also a bit too magic, and a bit worse than the current solution.
> 
> Sorry, but I think I'd rather stick with what I have now.

I agree with @JornVernee  here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From xliu at openjdk.java.net  Wed Feb 23 19:23:52 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Feb 2022 19:23:52 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v4]
In-Reply-To: <1nvasKTG9vkr1mmPhqn3-1_JYRqog6Suu9OxxoM-0yk=.a9a6f6ac-be4e-434a-ac40-13093751db33@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <WgRZc1DRulaxshPQi6pVFYyt7T1L_PuvkuXxqxRCqFk=.baaeac45-baef-489e-a6b2-015a57e3bf3a@github.com>
 <m7AZGaFDXhQJ7R6TIPGgmpVtHhTTI0Iih5L5LAMLV9s=.76cd66a8-4472-4948-910a-b79992ac67fa@github.com>
 <Tb1iWHUmKRd87LOvrcr79uMC8DgEpOrTgk7-2HTzqHE=.335f5a26-bc1b-4c08-aee4-305cff3490ce@github.com>
 <ci6JmwsAjg3sy3ZsUv-kGRukBtfWcHQpTlUsQaUTHno=.1953c363-2f87-4cf7-9c6a-07d0281b1914@github.com>
 <lN04PdbQEB-YE3GfJJesC5ozBKVO_kSmlfo7wjGp6ZY=.7d162ab9-f7da-47b2-819d-ba64d9f195e3@github.com>
 <1nvasKTG9vkr1mmPhqn3-1_JYRqog6Suu9OxxoM-0yk=.a9a6f6ac-be4e-434a-ac40-13093751db33@github.com>
Message-ID: <3B3MHSqhcvHG1bdPspfWYO25b10cjjz7PNIcP7bn2Bg=.9ac4b145-17ed-4bb2-9f26-0268e561e838@github.com>

On Wed, 23 Feb 2022 19:06:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ok, so if I understand correctly, the issue is with the `NOT_PRODUCT(COMMA ...)` in the arguments list.
>> 
>> I think it doesn't look great either, but it seems like the best alternative if we want to make sure no code is generated in product builds. I think using macros in this way is the best way of doing that. If we were to depend on compiler optimizations to eliminate bits in product builds, I think we should just make the reason parameter unconditional, rather than piggybacking on a field of PointsToNode. The compiler should see that it is unused on product builds. That seems even cleaner. But I think the intent is much clearer with the NOT_PRODUCT macro, since it's more obvious that this code will not be in product builds from the call site.
>> 
>> I don't like the idea of splitting the reason string out of the parameter list either, since it requires callers to remember to also separately set the reason string. Having it as a parameter forces callers to think about it.
>> 
>> An alternative idea is to declare new macros for setting the escape state and scalar replaceability like so:
>> 
>>     #ifndef PRODUCT
>>     #define SET_ESCAPE_STATE(node, es, reason) set_escape_sate(node, es, reason)
>>     #else 
>>     #define SET_ESCAPE_STATE(node, es, reason) set_escape_sate(node, es)
>>     #endif
>> 
>> Where the product version drops the reason string. But, I think this is also a bit too magic, and a bit worse than the current solution.
>> 
>> Sorry, but I think I'd rather stick with what I have now.
>
> I agree with @JornVernee  here.

fair enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From xliu at openjdk.java.net  Wed Feb 23 19:44:51 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 23 Feb 2022 19:44:51 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v5]
In-Reply-To: <R8tDDk2bdyprRy8D5JHfpmAyhJg1saXW2qhGs_TvHl0=.d876cbd0-e9f0-4af5-a5f4-217413b5dc48@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <R8tDDk2bdyprRy8D5JHfpmAyhJg1saXW2qhGs_TvHl0=.d876cbd0-e9f0-4af5-a5f4-217413b5dc48@github.com>
Message-ID: <fuPpdXu_yotT6wGcqnljC-GvgaSGPiR3EAE513y5iCU=.035f9d2e-eda2-45da-90b4-958fd868e303@github.com>

On Wed, 23 Feb 2022 14:47:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

LGTM. I am not a reviewer. need another reviewer to approve it.

-------------

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7428

From duke at openjdk.java.net  Wed Feb 23 22:48:07 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 23 Feb 2022 22:48:07 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long
In-Reply-To: <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>
Message-ID: <qOv--w4OsMeaSnbKCztDpy2F3SuwQNhGsnroKJ3CKOU=.5e3097d0-d13e-432b-9e09-65a01db3d445@github.com>

On Wed, 23 Feb 2022 05:43:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> src/hotspot/cpu/x86/x86_64.ad line 8602:
> 
>> 8600:     __ jmp(done);
>> 8601:     __ bind(neg_divisor_fastpath); 
>> 8602:     // Fastpath for divisor < 0: 
> 
> Move in macro assembly routine.

Sure, will move it to a macro assembly routine

> src/hotspot/cpu/x86/x86_64.ad line 8633:
> 
>> 8631:     __ jmp(done);
>> 8632:     __ bind(neg_divisor_fastpath);
>> 8633:     // Fastpath for divisor < 0: 
> 
> Move in macro assembly rountine.

Sure, will move it to a macro assembly routine

> src/hotspot/cpu/x86/x86_64.ad line 8902:
> 
>> 8900:     __ subl(tmp_rax, divisor);
>> 8901:     __ andnl(tmp_rax, tmp_rax, rdx);
>> 8902:     __ sarl(tmp_rax, 31);
> 
> Please move this into a macro assembly routine.

Sure, will move it to a macro assembly routine

> src/hotspot/cpu/x86/x86_64.ad line 8932:
> 
>> 8930:     // Fastpath when divisor < 0: 
>> 8931:     // remainder = dividend - (((dividend & ~(dividend - divisor)) >> (Long.SIZE - 1)) & divisor)
>> 8932:     // See Hacker's Delight (2nd ed), section 9.3 which is implemented in java.lang.Long.remainderUnsigned()
> 
> Please move it into a macro assembly routine.

Sure, will move it to a macro assembly routine

> src/hotspot/share/opto/compile.cpp line 3499:
> 
>> 3497:       Node* d = n->find_similar(Op_UDivI);
>> 3498:       if (d) {
>> 3499:         // Replace them with a fused unsigned divmod if supported
> 
> Can you explain a bit here, why can't this transformation be handled earlier ?

This is following the existing approach being used for signed DivMod

> test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 75:
> 
>> 73:         }
>> 74:         return quotients;
>> 75:     }
> 
> Do we need to return quotients, since it's a field  being explicitly modified.

Will remove it.

> test/micro/org/openjdk/bench/java/lang/LongDivMod.java line 82:
> 
>> 80:             remainders[i] = Long.remainderUnsigned(dividends[i], divisors[i]);
>> 81:         }
>> 82:         return remainders;
> 
> Same as above

Will remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Wed Feb 23 22:55:11 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 23 Feb 2022 22:55:11 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long
In-Reply-To: <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>
Message-ID: <ks-w0w2zABPbboQ-ZS2cr4u0MV2D8Z_ldc5TMnXWNFI=.93d83301-66fc-416c-b5c3-41852b0fcbe7@github.com>

On Wed, 23 Feb 2022 05:52:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 76:
> 
>> 74:         return quotients;
>> 75:     }
>> 76: 
> 
> Return seems redundant here.

Will remove it.

> test/micro/org/openjdk/bench/java/lang/IntegerDivMod.java line 83:
> 
>> 81:         }
>> 82:         return remainders;
>> 83:     }
> 
> Return seems redundant here.

Will remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Wed Feb 23 23:11:03 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 23 Feb 2022 23:11:03 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long
In-Reply-To: <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <oaATLVe4meOXI97Pb3XQn5SehxJaRvS7td7-bMpVT3U=.751ccae1-b992-4d8f-a055-5df021010b08@github.com>
Message-ID: <giWisIfFyQkddFi_9mTGq-iBaIpNAZ2hxhODNW7J0eg=.0e8f46a5-896b-4bb8-9ac7-256a2124aa56@github.com>

On Wed, 23 Feb 2022 05:46:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> src/hotspot/share/opto/divnode.cpp line 1350:
> 
>> 1348:     return NULL;
>> 1349:   }
>> 1350: 
> 
> Please remove Value and Ideal routines if no explicit transforms are being done.

Will remove the unused transformations.

> src/hotspot/share/opto/divnode.cpp line 1362:
> 
>> 1360:   }
>> 1361: 
>> 1362: //=============================================================================
> 
> You can remove Ideal routine is not transformation is being done.

Will remove the unused transformation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Wed Feb 23 23:18:56 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 23 Feb 2022 23:18:56 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v3]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <XDqulKWM-u31jIMiaSbGOB1npSt8gZtks48D3KjcuqU=.7886cd75-0548-43ff-b3d9-b83bfcad8e0b@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Fix line at end of file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/7fc18af3..13549290

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Wed Feb 23 23:15:53 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Wed, 23 Feb 2022 23:15:53 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v2]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <UeDaUp0vHrvBKF-Ob_w1XgGFcdOfY89MaHQJSG7zKrE=.21c2d6af-e1c1-4a80-af67-8d892565549b@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  Move intrinsic code to macro assembly routines; remove unused transformations for div and mod nodes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/fa57175a..7fc18af3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=00-01

  Stats: 326 lines in 7 files changed: 137 ins; 176 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From duke at openjdk.java.net  Thu Feb 24 00:42:59 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Thu, 24 Feb 2022 00:42:59 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v5]
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <d9cUi0w5EDjan5DnzU8byzetTUht3VDwwG-m-YXsxbI=.dcf4ac5d-d41d-42cb-babf-b14d6b1231b3@github.com>

> 8005885: enhance PrintCodeCache to print more data

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Add a test on code cache verbose output

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7389/files
  - new: https://git.openjdk.java.net/jdk/pull/7389/files/97b579bc..b989547c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=03-04

  Stats: 78 lines in 1 file changed: 78 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7389/head:pull/7389

PR: https://git.openjdk.java.net/jdk/pull/7389

From sviswanathan at openjdk.java.net  Thu Feb 24 00:47:06 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 24 Feb 2022 00:47:06 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v7]
In-Reply-To: <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
Message-ID: <kaC15h_DGeCKO-Qni0hfmY_FJ696AfbHdP6rBBdjovA=.b93791a1-74f5-4ca3-abd1-36db73129f4a@github.com>

On Wed, 23 Feb 2022 09:03:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | --
>> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
>> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
>> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
>> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Review comments resolved.

Also curious, how does the performance look with all these changes.

src/hotspot/cpu/x86/assembler_x86.hpp line 2254:

> 2252:   void vroundps(XMMRegister dst, XMMRegister src, int32_t rmode, int vector_len);
> 2253:   void vrndscaleps(XMMRegister dst,  XMMRegister src,  int32_t rmode, int vector_len);
> 2254: 

These instructions are not used anymore and can be removed.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4116:

> 4114:                                             KRegister ktmp1, KRegister ktmp2, AddressLiteral double_sign_flip,
> 4115:                                             Register scratch, int vec_enc) {
> 4116:   evcvttpd2qq(dst, src, vec_enc);

The vcvttpd2qq instruction on overflow sets the result as  2^w -1 where w is 64. Whereas the special case handling is expecting 0x80000.....

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4145:

> 4143:   evpbroadcastq(xtmp1, scratch, vec_enc);
> 4144:   vaddpd(xtmp1, src , xtmp1, vec_enc);
> 4145:   evcvtpd2qq(dst, xtmp1, vec_enc);

The vcvtpd2qq instruction on overflow also sets the result as 2^w -1 where w is 64. Whereas the special case handling is expecting 0x80000.....

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4176:

> 4174:   vpbroadcastd(xtmp1, xtmp1, vec_enc);
> 4175:   vaddps(xtmp1, src , xtmp1, vec_enc);
> 4176:   vcvtps2dq(dst, xtmp1, vec_enc);

The vcvtps2dq returns 0x7FFFFFFF in case of overflow whereas the special case handling expects 0x80000000 incase of overflow. The same question applies to the corresponding vector_round_float_avx() implementation as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From sviswanathan at openjdk.java.net  Thu Feb 24 01:47:07 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 24 Feb 2022 01:47:07 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v7]
In-Reply-To: <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
Message-ID: <ZEUMbHG8f-JNJyvA-VfcVu-cp3iYU7XeqECf_uAeNxQ=.94d44361-b2bd-45e3-9505-379645c559a8@github.com>

On Wed, 23 Feb 2022 09:03:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | --
>> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
>> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
>> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
>> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Review comments resolved.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8984:

> 8982: }
> 8983: 
> 8984: void MacroAssembler::round_double(Register dst, XMMRegister src, Register rtmp, Register rcx) {

Is it possible to implement this using the similar mxcsr change? In any case comments will help to review round_double and round_float code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From sviswanathan at openjdk.java.net  Thu Feb 24 02:00:05 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 24 Feb 2022 02:00:05 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v7]
In-Reply-To: <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
Message-ID: <UwXGPnwms2ydicsnvxdiH8iIhIpEiXn-PEZxA80G5Hs=.48973d74-17e9-46db-b895-039b1c5eac80@github.com>

On Wed, 23 Feb 2022 09:03:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | --
>> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
>> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
>> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
>> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Review comments resolved.

test/hotspot/jtreg/compiler/c2/cr6340864/TestDoubleVect.java line 441:

> 439:       errn += verify("test_round: ", 1, l0[1], Long.MAX_VALUE);
> 440:       errn += verify("test_round: ", 2, l0[2], Long.MIN_VALUE);
> 441:       errn += verify("test_round: ", 3, l0[3], Long.MAX_VALUE);

Good to add additional test cases:
  Case with a1 value >= Long Max and < infinity. 
  Case with a1 value <= Long Min and > -infinity.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Thu Feb 24 02:43:46 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Thu, 24 Feb 2022 02:43:46 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
Message-ID: <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>

> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.

Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:

  fix 32bit build issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7572/files
  - new: https://git.openjdk.java.net/jdk/pull/7572/files/13549290..2915b2e7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7572&range=02-03

  Stats: 91 lines in 2 files changed: 49 ins; 42 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7572.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572

PR: https://git.openjdk.java.net/jdk/pull/7572

From rcastanedalo at openjdk.java.net  Thu Feb 24 08:07:09 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 24 Feb 2022 08:07:09 GMT
Subject: RFR: 8280568: IGV: Phi inputs and pinned nodes are not scheduled
 correctly [v2]
In-Reply-To: <l6dih5wDNham2kBk3LOD1fkRHrSvacuw7fzAJ2Y9RSQ=.87f0fef7-b478-4f0a-b15f-2df7fa4dca89@github.com>
References: <-iYiPRIR5iUEQyHWbTW0j2wwWjPS7YSfsp_ikHPAW54=.fa427507-e74d-4cfa-bd49-8dc7c935346c@github.com>
 <l6dih5wDNham2kBk3LOD1fkRHrSvacuw7fzAJ2Y9RSQ=.87f0fef7-b478-4f0a-b15f-2df7fa4dca89@github.com>
Message-ID: <xl0I5dgzx1o-Ege1XVDYyrrtH6EQBU2POnjhKV-whrk=.fea84e9d-9fb5-4a88-88ef-699724cca94b@github.com>

On Fri, 18 Feb 2022 08:36:20 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change improves the accuracy of IGV's schedule approximation algorithm w.r.t. C2 in two ways:
>> 
>> 1. Schedule each node N pinned to a control node R in:
>> 
>>    1a. the same block as R, if R is a "regular" control node such as `Region` or `Proj`. For example (N = `168 LoadP`, R = `75 Proj`):
>> 
>>    <p align="center">
>>    <img src="https://user-images.githubusercontent.com/8792647/154474596-ad326ad0-e127-4529-9837-6427c0a17314.png" width="50%">
>>    </p>
>> 
>>    or
>> 
>>    1b. R's successor block S, if R is a block projection node (such as `IfTrue` or `CatchProj`). For example (N = `92 LoadN`, R = `29 IfTrue`, S = `B4`):
>> 
>>    <p align="center">
>>    <img src="https://user-images.githubusercontent.com/8792647/154476147-4d53e2d9-db19-4449-bd79-053e6380cf4d.png" width="45%">
>>    </p>
>> 
>>    In case S has multiple predecessors (i.e. (R, S) form a critical edge), N is scheduled in a critical-edge-splitting block between R and S. For example (N = `135 ClearArray`, R = `151 IfTrue`, S=`B5` in _(before)_ and `B8` in _(after)_, and `B5` is the new critical-edge-splitting block in _(after)_):
>> 
>>    <p align="center">
>>    <img src="https://user-images.githubusercontent.com/8792647/154487037-24d3f147-b592-484a-bdf2-e93c3bec053c.png" width="90%">
>>    </p>
>> 
>>    Note that in _(after)_, B5 is a predecessor of B8. This can be seen in the CFG view, but is not visible in the sea-of-nodes graph view, due to the lack of control nodes in the blocks such as B5 created by critical-edge splitting.
>> 
>> 2. Schedule each node N that is input to a `Phi` node P in a block that dominates P's corresponding predecessor block B. For example (N = `36 ConvI2L`, P = `33 Phi`, B = `B2`):
>> 
>>    <p align="center">
>>    <img src="https://user-images.githubusercontent.com/8792647/154479876-1e2ae61a-a9a9-453f-b031-55d5dce17ce7.png" width="55%">
>>    </p>
>> 
>> The combined effect of these scheduling improvements can be seen in the subgraph below, that illustrates cases 1b (where a critical edge must be split) and 2. In _(before)_, `135 ClearArray` is both input to a phi node `91 Phi` and pinned to a block projection `151 IfTrue` on a critical edge (B7, B5), hence (_after_) a new critical-edge-splitting block B5 is created in which `135 ClearArray` and the rest of nodes pinned to `151 IfTrue` are scheduled:
>> <p align="center"> 
>> <img src="https://user-images.githubusercontent.com/8792647/154481964-37d5c8a1-4243-49eb-a127-5a53f5ef0abb.png" width="95%">
>> </p>
>> 
>> Additionally, the change introduces checks on graph invariants that are assumed by scheduling approximation (e.g. each block projection has a single control successor), warning the IGV user about possible issues in the schedule if these invariants are broken. Emitting warnings and gracefully degrading the approximated schedule is preferred to just failing since one of IGV's main use cases is debugging graphs which might be ill-formed.
>> 
>> These changes increase the overhead of scheduling large graphs by about 10-20%, however there are opportunities for speeding up scheduling by about an order of magnitude (see [JDK-8282043](https://bugs.openjdk.java.net/browse/JDK-8282043)) that would more than compensate for this overhead.
>> 
>> #### Testing
>> 
>> - Tested manually that the phi inputs and pinned nodes are scheduled correctly for a few selected graphs (included the reported one).
>> - Tested automatically that scheduling tens of thousands of graphs (by instrumenting IGV to schedule parsed graphs eagerly and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`) does not trigger any assertion failure and does not warn with the message "inaccurate schedule: (...) are phi inputs but do not dominate the phi's input block.".
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

Switching back to draft mode to incorporate some offline feedback about reporting of scheduling warnings, and possibly generalize the scheduling algorithm to cover additional, related cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7493

From fgao at openjdk.java.net  Thu Feb 24 10:45:10 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Thu, 24 Feb 2022 10:45:10 GMT
Subject: RFR: 8280511: AArch64: Combine shift and negate to a single
 instruction
In-Reply-To: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>
References: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>
Message-ID: <ViC6o7-iFfxrCapPf7lHX9E9OZMFviuX72gxPsDVqio=.85852dd5-f15b-4c59-b969-9267dbf16a66@github.com>

On Tue, 15 Feb 2022 06:48:10 GMT, Fei Gao <fgao at openjdk.org> wrote:

> Hi,
> 
> In AArch64,
> 
> asr     x10, x1, #31
> neg     x0, x10
> 
> can be optimized to:
> `neg    x0, x1, asr #31`
> 
> To implement the instruction combining, we add matching rules in the backend.
> 
> Thanks.

Hi @theRealAph , can I have your review :)? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7471

From duke at openjdk.java.net  Thu Feb 24 12:13:07 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 24 Feb 2022 12:13:07 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <uuZvaCwbFc7sM44SGzVOTVcUmIHboQSMFr5qmvv23GM=.d08b63a6-a2e6-4c17-a011-cfd8f1921165@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
 <uuZvaCwbFc7sM44SGzVOTVcUmIHboQSMFr5qmvv23GM=.d08b63a6-a2e6-4c17-a011-cfd8f1921165@github.com>
Message-ID: <E4tj4oQvSPbyeD7SRak_Xc3wXxM9gHByW2NopvGc0Ks=.df42964b-ac36-4bd4-8174-2135a102c7d7@github.com>

On Wed, 23 Feb 2022 13:54:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> What benefits you have with these changes in real world?
>> It could be fine to use `lea` for merging several instruction, as you did.
>> But last time I was told that `lea` instruction has larger latency than shift instruction because it uses addressing module in CPU. I am not sure it is fine to replace it.
>> Also why you removed match rule which moved result of `Add` to different register?
>
>> @vnkozlov Given `lea` is a really efficient instruction, merging multiple ones into it offers a lot of benefits and all other compilers do so.
> 
> So any benchmark to show the perf improvement?

@DamonFool I found benchmarking these single arithmetic-instruction optimizations is hard, especially these rules which contain constant immediates. This is the result from a benchmark I wrote, my machine doesn't match 3-operand rules so the result of `B_I_D_*` is the same, and `B_IS_D_int` seems to suffer from loop alignment which leads to decoder bottleneck trying to read a lot of `nop`.
Thank you very much.

    Before:
    Benchmark                   Mode  Cnt     Score     Error  Units
    LeaInstruction.B_IS_D_int   avgt   10  1171.089 ?  12.051  ns/op
    LeaInstruction.B_IS_D_long  avgt   10  1214.248 ? 164.069  ns/op
    LeaInstruction.B_IS_int     avgt   10   908.979 ?  57.721  ns/op
    LeaInstruction.B_IS_long    avgt   10  1218.707 ?   2.169  ns/op
    LeaInstruction.B_I_D_int    avgt   10   842.187 ?  65.795  ns/op
    LeaInstruction.B_I_D_long   avgt   10  1289.333 ?   9.978  ns/op
    LeaInstruction.IS_D_int     avgt   10   533.597 ?   1.302  ns/op
    LeaInstruction.IS_D_long    avgt   10   533.198 ?   0.559  ns/op

    After:
    Benchmark                   Mode  Cnt     Score    Error  Units
    LeaInstruction.B_IS_D_int   avgt   10  1217.740 ?  4.110  ns/op
    LeaInstruction.B_IS_D_long  avgt   10   809.962 ?  8.156  ns/op
    LeaInstruction.B_IS_int     avgt   10   536.518 ?  5.076  ns/op
    LeaInstruction.B_IS_long    avgt   10   534.041 ?  1.158  ns/op
    LeaInstruction.B_I_D_int    avgt   10   808.131 ?  0.965  ns/op
    LeaInstruction.B_I_D_long   avgt   10  1287.391 ? 10.025  ns/op
    LeaInstruction.IS_D_int     avgt   10   305.940 ?  9.886  ns/op
    LeaInstruction.IS_D_long    avgt   10   308.969 ?  0.844  ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Thu Feb 24 12:16:58 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 24 Feb 2022 12:16:58 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v4]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <kKtETDmXF23qtCVuEeMJrp9iquibiloG5qZjuzWOjhc=.80b0861c-a4b0-4d90-afe7-fc3df1bc9d56@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add benchmark

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/b09260b1..6d2680b5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=02-03

  Stats: 122 lines in 2 files changed: 121 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From jbhateja at openjdk.java.net  Thu Feb 24 13:01:58 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Feb 2022 13:01:58 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v8]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <XcbHyyMss1tlSLZC6uai_VCv0oaWux-uCRtm0eCZZRU=.12733ed3-02eb-4384-b13b-fbb474e099ac@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | --
> 1024.00 | 510.41 | 1811.66 | 3.55 | 510.40 | 502.65 | 0.98
> 2048.00 | 293.52 | 984.37 | 3.35 | 304.96 | 177.88 | 0.58
> 1024.00 | 825.94 | 3387.64 | 4.10 | 750.77 | 1925.15 | 2.56
> 2048.00 | 411.91 | 1942.87 | 4.72 | 412.22 | 1034.13 | 2.51
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Review comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/6c869c76..f7dec3d9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=06-07

  Stats: 35 lines in 5 files changed: 8 ins; 22 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Thu Feb 24 13:01:59 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Feb 2022 13:01:59 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v7]
In-Reply-To: <ZEUMbHG8f-JNJyvA-VfcVu-cp3iYU7XeqECf_uAeNxQ=.94d44361-b2bd-45e3-9505-379645c559a8@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
 <ZEUMbHG8f-JNJyvA-VfcVu-cp3iYU7XeqECf_uAeNxQ=.94d44361-b2bd-45e3-9505-379645c559a8@github.com>
Message-ID: <hNjOWpxq-E6ikq7IZy9sYZXjrOniQcuKP1Hs4N4N1I0=.832230ca-7ca7-4540-84bc-b5e0e62838d9@github.com>

On Thu, 24 Feb 2022 01:43:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Review comments resolved.
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8984:
> 
>> 8982: }
>> 8983: 
>> 8984: void MacroAssembler::round_double(Register dst, XMMRegister src, Register rtmp, Register rcx) {
> 
> Is it possible to implement this using the similar mxcsr change? In any case comments will help to review round_double and round_float code.

LDMXCSR has multi-cycle latency and it will degrade the performance of scalar operation's fast path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Thu Feb 24 13:10:34 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 24 Feb 2022 13:10:34 GMT
Subject: RFR: 8230382: Clean up ConvI2L, CastII and CastLL::Ideal methods
Message-ID: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>

This is a cleanup job: move code from `::Ideal` methods that only change types to `::Value` where the code belongs.

`CastLLNode::Ideal` was introduced in [JDK-8229496](https://bugs.openjdk.java.net/browse/JDK-8229496) and reverted (deleted) in [JDK-8242108](https://bugs.openjdk.java.net/browse/JDK-8242108).
Currently, `CastLLNode` does not have its own `::Ideal` method. Hence, I changed nothing for it.

For `ConvI2LNode` and `CastIINode`, I went through a process of first copying the relevant code to `::Value`, calling it from `::Ideal` and asserting that they deliver equivalent results.
These intermediate code results can be found in the comments of [JDK-8230382](https://bugs.openjdk.java.net/browse/JDK-8230382).
I ran tests: final code and intermediate code versions. Ensures code behaves equivalent and nothing broke.

-------------

Commit messages:
 - 8230382: Clean up ConvI2L, CastII and CastLL::Ideal methods

Changes: https://git.openjdk.java.net/jdk/pull/7609/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7609&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8230382
  Stats: 158 lines in 2 files changed: 78 ins; 72 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7609/head:pull/7609

PR: https://git.openjdk.java.net/jdk/pull/7609

From vlivanov at openjdk.java.net  Thu Feb 24 13:59:37 2022
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 24 Feb 2022 13:59:37 GMT
Subject: RFR: 8282218: C1: Missing side effects of dynamic class loading during
 constant linkage
Message-ID: <QtiGzHnIhiQauS8LKRR-p7FStpCaDg5l3f39W2N1-nQ=.6cc51db4-0bd3-4cb4-b6ab-7a702d832e0c@github.com>

(The problem is similar to JDK-8282194, but with class loading this time.)

C1 handles unresolved constants by performing constant resolution at runtime and then putting the constant value into the generated code by patching it. But it treats the not-yet-resolved value as a pure constant without any side effects.

It's not the case for constants which trigger class loading using custom class loaders. (All non-String constants do that.)

There are no guarantees that there are no side effects during class loading, so C1 has to be conservative.

Proposed fix kills memory after accessing not-yet-loaded constant in the context of any non-trusted class loader.

Testing: hs-tier1 - hs-tier4

-------------

Commit messages:
 - 8282218: C1: Missing side effects of dynamic class loading during constant linkage

Changes: https://git.openjdk.java.net/jdk/pull/7612/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7612&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282218
  Stats: 128 lines in 5 files changed: 126 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7612.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7612/head:pull/7612

PR: https://git.openjdk.java.net/jdk/pull/7612

From duke at openjdk.java.net  Thu Feb 24 14:15:47 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 24 Feb 2022 14:15:47 GMT
Subject: RFR: 8230382: Clean up ConvI2L,
 CastII and CastLL::Ideal methods [v2]
In-Reply-To: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
References: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
Message-ID: <OXZr4bln9snP2BjQsDVJg_nFkdtDDZHWYk3TWL6uFA8=.63b79703-c4ca-4be1-8af7-0ffab9b96308@github.com>

> This is a cleanup job: move code from `::Ideal` methods that only change types to `::Value` where the code belongs.
> 
> `CastLLNode::Ideal` was introduced in [JDK-8229496](https://bugs.openjdk.java.net/browse/JDK-8229496) and reverted (deleted) in [JDK-8242108](https://bugs.openjdk.java.net/browse/JDK-8242108).
> Currently, `CastLLNode` does not have its own `::Ideal` method. Hence, I changed nothing for it.
> 
> For `ConvI2LNode` and `CastIINode`, I went through a process of first copying the relevant code to `::Value`, calling it from `::Ideal` and asserting that they deliver equivalent results.
> These intermediate code results can be found in the comments of [JDK-8230382](https://bugs.openjdk.java.net/browse/JDK-8230382).
> I ran tests: final code and intermediate code versions. Ensures code behaves equivalent and nothing broke.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup, some dead cases removed, some code made similar

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7609/files
  - new: https://git.openjdk.java.net/jdk/pull/7609/files/abc9592a..3a69f805

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7609&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7609&range=00-01

  Stats: 83 lines in 2 files changed: 9 ins; 29 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7609/head:pull/7609

PR: https://git.openjdk.java.net/jdk/pull/7609

From jbhateja at openjdk.java.net  Thu Feb 24 14:18:13 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Feb 2022 14:18:13 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
Message-ID: <oCd9O4Ecr3MnFogrUlo-lMw-MUHNTfwJqdUIV2fxXNc=.e3ec0775-0264-4cea-b1a4-657be815b390@github.com>

On Thu, 24 Feb 2022 02:43:46 GMT, Vamsi Parasa <duke at openjdk.java.net> wrote:

>> Optimizes the divideUnsigned() and remainderUnsigned() methods in java.lang.Integer and java.lang.Long classes using x86 intrinsics. This change shows 3x improvement for Integer methods and upto 25% improvement for Long. This change also implements the DivMod optimization which fuses division and modulus operations if needed. The DivMod optimization shows 3x improvement for Integer and ~65% improvement for Long.
>
> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix 32bit build issues

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4408:

> 4406:   jmp(done);
> 4407:   bind(neg_divisor_fastpath);
> 4408:   // Fastpath for divisor < 0:

How about checking if divisor is +ve or -ve constant and non-constant dividend in identity routine and setting a flag in IR node, which can be used to either emit fast / slow path in a new instruction selection pattern. It will save emitting redundant instructions.

src/hotspot/share/opto/divnode.cpp line 881:

> 879:   return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) : this;
> 880: }
> 881: //------------------------------Value------------------------------------------

Ideal transform to replace unsigned divide by cheaper logical right shift instruction if divisor is POW will be useful.

src/hotspot/share/opto/divnode.cpp line 897:

> 895: 
> 896:   // Either input is BOTTOM ==> the result is the local BOTTOM
> 897:   const Type *bot = bottom_type();

Can we add constant folding handling when both dividend and divisor are constants.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From lucy at openjdk.java.net  Thu Feb 24 14:39:48 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 24 Feb 2022 14:39:48 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v2]
In-Reply-To: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
Message-ID: <cdgzs2GZfurm_aB03CvxLO-sRWymipglEj6LOKvatO4=.99c52987-4189-4d94-a318-8adc0baaa848@github.com>

> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
> 
> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
> 
> As this is a s390x-only change, other platforms are not impacted.

Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:

  changes to satisfy review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7324/files
  - new: https://git.openjdk.java.net/jdk/pull/7324/files/3f78a84c..2094825b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7324&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7324&range=00-01

  Stats: 46 lines in 2 files changed: 13 ins; 23 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7324/head:pull/7324

PR: https://git.openjdk.java.net/jdk/pull/7324

From duke at openjdk.java.net  Thu Feb 24 14:42:52 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 24 Feb 2022 14:42:52 GMT
Subject: RFR: 8230382: Clean up ConvI2L,
 CastII and CastLL::Ideal methods [v3]
In-Reply-To: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
References: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
Message-ID: <cTE-kV9rrdNqRoKvELohAc-5jIPmrNjLqc7E1qo-w6M=.586f4c9e-4abd-4564-bc64-4490268b65a7@github.com>

> This is a cleanup job: move code from `::Ideal` methods that only change types to `::Value` where the code belongs.
> 
> `CastLLNode::Ideal` was introduced in [JDK-8229496](https://bugs.openjdk.java.net/browse/JDK-8229496) and reverted (deleted) in [JDK-8242108](https://bugs.openjdk.java.net/browse/JDK-8242108).
> Currently, `CastLLNode` does not have its own `::Ideal` method. Hence, I changed nothing for it.
> 
> For `ConvI2LNode` and `CastIINode`, I went through a process of first copying the relevant code to `::Value`, calling it from `::Ideal` and asserting that they deliver equivalent results.
> These intermediate code results can be found in the comments of [JDK-8230382](https://bugs.openjdk.java.net/browse/JDK-8230382).
> I also tried to make the two code versions more similar, where they were unnecessarily different (used `can_reshape` instead of `igvn != NULL`, and removed the dead Overflow/wraparound case which can never happen).
> I ran tests: final code and intermediate code versions. Ensures code behaves equivalent and nothing broke.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  code style issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7609/files
  - new: https://git.openjdk.java.net/jdk/pull/7609/files/3a69f805..a79a95b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7609&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7609&range=01-02

  Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7609/head:pull/7609

PR: https://git.openjdk.java.net/jdk/pull/7609

From jbhateja at openjdk.java.net  Thu Feb 24 14:56:03 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Feb 2022 14:56:03 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v7]
In-Reply-To: <kaC15h_DGeCKO-Qni0hfmY_FJ696AfbHdP6rBBdjovA=.b93791a1-74f5-4ca3-abd1-36db73129f4a@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <cywj8L_sEGLoeEKWVJLRNKG6BqzkOhHVfEiAW2jGpaE=.553ac6dd-13dc-4940-810f-587ad0baa1d6@github.com>
 <kaC15h_DGeCKO-Qni0hfmY_FJ696AfbHdP6rBBdjovA=.b93791a1-74f5-4ca3-abd1-36db73129f4a@github.com>
Message-ID: <Hz9QErmwNa0W0a8YsHnAqK1_VkZc6DCC1GG5J13bf8I=.7e2db892-4713-46c6-9c2a-5a82507e82b1@github.com>

On Thu, 24 Feb 2022 00:43:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Also curious, how does the performance look with all these changes.

Updated new perf numbers.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From redestad at openjdk.java.net  Thu Feb 24 15:21:37 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 24 Feb 2022 15:21:37 GMT
Subject: RFR: 8282347: AARCH64: Untaken branch in has_negatives stub
Message-ID: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>

Trivial(?) cleanup removing an untaken branch in the aarch64 has_negatives stub.

-------------

Commit messages:
 - 8282347: AARCH64: Untaken branch in has_negatives stub

Changes: https://git.openjdk.java.net/jdk/pull/7611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7611&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282347
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7611/head:pull/7611

PR: https://git.openjdk.java.net/jdk/pull/7611

From aph at openjdk.java.net  Thu Feb 24 15:21:37 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 24 Feb 2022 15:21:37 GMT
Subject: RFR: 8282347: AARCH64: Untaken branch in has_negatives stub
In-Reply-To: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
References: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
Message-ID: <eC-7hd7BwQ7ePxDlTMl4dHxKbqe36IMo5npAYyuZFBs=.be2ae55e-7020-4dc7-bdcb-e532e390b037@github.com>

On Thu, 24 Feb 2022 13:15:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivial(?) cleanup removing an untaken branch in the aarch64 has_negatives stub.

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7611

From phh at openjdk.java.net  Thu Feb 24 15:30:07 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 24 Feb 2022 15:30:07 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v5]
In-Reply-To: <d9cUi0w5EDjan5DnzU8byzetTUht3VDwwG-m-YXsxbI=.dcf4ac5d-d41d-42cb-babf-b14d6b1231b3@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <d9cUi0w5EDjan5DnzU8byzetTUht3VDwwG-m-YXsxbI=.dcf4ac5d-d41d-42cb-babf-b14d6b1231b3@github.com>
Message-ID: <u8qWXyklkp6nqbh1GBn-Q9fMTLizE-GKlwGlZcDV80s=.91c816e4-5c92-4c08-8dc3-861e6b68a98b@github.com>

On Thu, 24 Feb 2022 00:42:59 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test on code cache verbose output

Latest lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Thu Feb 24 15:45:08 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Thu, 24 Feb 2022 15:45:08 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v5]
In-Reply-To: <d9cUi0w5EDjan5DnzU8byzetTUht3VDwwG-m-YXsxbI=.dcf4ac5d-d41d-42cb-babf-b14d6b1231b3@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <d9cUi0w5EDjan5DnzU8byzetTUht3VDwwG-m-YXsxbI=.dcf4ac5d-d41d-42cb-babf-b14d6b1231b3@github.com>
Message-ID: <G_-kUcQAfe-B2_zHI7qNVfNpspQVWdB58W8cEZ9X8Z8=.72766419-2ec2-425b-8fbb-604a6e54fb67@github.com>

On Thu, 24 Feb 2022 00:42:59 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test on code cache verbose output

Two minor comments.

test/hotspot/jtreg/compiler/codecache/CheckCodeCacheInfo.java line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Amazon.com Inc. or its affiliates. All rights reserved.

We don't specify a year any more.
The correct one is "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." See https://github.com/openjdk/jdk/pull/6915

test/hotspot/jtreg/compiler/codecache/CheckCodeCacheInfo.java line 26:

> 24: /*
> 25:  * @test CheckCodeCacheInfo
> 26:  * @summary Checks VM verbose information related to the code cache

Missing `@bug 8005885`

-------------

Changes requested by eastig at github.com (no known OpenJDK username).

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Thu Feb 24 16:52:42 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Thu, 24 Feb 2022 16:52:42 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v6]
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <GTdTiyvunpQkN7zU44PuV2mDoJTeXAqRp3NKnacuNl4=.d68cadbe-079c-41cc-adf8-718d903c6666@github.com>

> 8005885: enhance PrintCodeCache to print more data

Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright statement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7389/files
  - new: https://git.openjdk.java.net/jdk/pull/7389/files/b989547c..89f18351

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7389&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7389/head:pull/7389

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Thu Feb 24 19:08:08 2022
From: duke at openjdk.java.net (Vamsi Parasa)
Date: Thu, 24 Feb 2022 19:08:08 GMT
Subject: RFR: 8282221: x86 intrinsics for divideUnsigned and
 remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
In-Reply-To: <oCd9O4Ecr3MnFogrUlo-lMw-MUHNTfwJqdUIV2fxXNc=.e3ec0775-0264-4cea-b1a4-657be815b390@github.com>
References: <GpDaOvmQ0jX2V29JoVtlsTef5OjZQVnZEdWZJcYRcR4=.707aff45-31d4-46a3-a070-aa73e93e63d0@github.com>
 <cwKV4mTg3NBMUUHxowae5spxx7LfTuURx1oVKNTi4RU=.946ab01d-e0e9-46da-bf4e-33b3fdbda5ec@github.com>
 <oCd9O4Ecr3MnFogrUlo-lMw-MUHNTfwJqdUIV2fxXNc=.e3ec0775-0264-4cea-b1a4-657be815b390@github.com>
Message-ID: <fJGpa0iOx6AwnUsmoZA7pzw0B-PocgklwxSWzDqoRZQ=.b12fb49a-4b2e-4514-9b84-e093d2fbbb03@github.com>

On Thu, 24 Feb 2022 14:13:47 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix 32bit build issues
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4408:
> 
>> 4406:   jmp(done);
>> 4407:   bind(neg_divisor_fastpath);
>> 4408:   // Fastpath for divisor < 0:
> 
> How about checking if divisor is +ve or -ve constant and non-constant dividend in identity routine and setting a flag in IR node, which can be used to either emit fast / slow path in a new instruction selection pattern. It will save emitting redundant instructions.

Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365

> src/hotspot/share/opto/divnode.cpp line 881:
> 
>> 879:   return (phase->type( in(2) )->higher_equal(TypeLong::ONE)) ? in(1) : this;
>> 880: }
>> 881: //------------------------------Value------------------------------------------
> 
> Ideal transform to replace unsigned divide by cheaper logical right shift instruction if divisor is POW will be useful.

Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365

> src/hotspot/share/opto/divnode.cpp line 897:
> 
>> 895: 
>> 896:   // Either input is BOTTOM ==> the result is the local BOTTOM
>> 897:   const Type *bot = bottom_type();
> 
> Can we add constant folding handling when both dividend and divisor are constants.

Thanks for suggesting the enhancement. This enhancement will be implemented as a part of https://bugs.openjdk.java.net/browse/JDK-8282365

-------------

PR: https://git.openjdk.java.net/jdk/pull/7572

From phh at openjdk.java.net  Thu Feb 24 19:46:10 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Thu, 24 Feb 2022 19:46:10 GMT
Subject: RFR: 8005885: enhance PrintCodeCache to print more data [v6]
In-Reply-To: <GTdTiyvunpQkN7zU44PuV2mDoJTeXAqRp3NKnacuNl4=.d68cadbe-079c-41cc-adf8-718d903c6666@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
 <GTdTiyvunpQkN7zU44PuV2mDoJTeXAqRp3NKnacuNl4=.d68cadbe-079c-41cc-adf8-718d903c6666@github.com>
Message-ID: <-wsufMgpQs4pmDLJxanjGcMulQhzYDZ1lnmyxqi9oTU=.086ddd05-af3b-416c-aced-dcc324a3abb7@github.com>

On Thu, 24 Feb 2022 16:52:42 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

>> 8005885: enhance PrintCodeCache to print more data
>
> Yi-Fan Tsai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright statement

One final time, lgtm.

-------------

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7389

From duke at openjdk.java.net  Thu Feb 24 19:46:11 2022
From: duke at openjdk.java.net (Yi-Fan Tsai)
Date: Thu, 24 Feb 2022 19:46:11 GMT
Subject: Integrated: 8005885: enhance PrintCodeCache to print more data
In-Reply-To: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
References: <CNS7youwfKoTXa16G31LqZ0eRTSJK2H3c9NcdowuB7A=.1711b308-29e6-4902-9185-63c96c27f168@github.com>
Message-ID: <JeTViiDEmmijdEry2w7NFTtUtEx3U-x4w02FQ9IziQU=.8e432b02-2392-4bbd-ae04-eb63da26b7ed@github.com>

On Tue, 8 Feb 2022 19:17:32 GMT, Yi-Fan Tsai <duke at openjdk.java.net> wrote:

> 8005885: enhance PrintCodeCache to print more data

This pull request has now been integrated.

Changeset: b6843a16
Author:    Yi-Fan Tsai <yftsai at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6843a162411b0fa32271592d8f3a6f241a54384
Stats:     168 lines in 2 files changed: 141 ins; 1 del; 26 mod

8005885: enhance PrintCodeCache to print more data

Reviewed-by: xliu, phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/7389

From kvn at openjdk.java.net  Thu Feb 24 19:56:04 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Feb 2022 19:56:04 GMT
Subject: RFR: 8282218: C1: Missing side effects of dynamic class loading
 during constant linkage
In-Reply-To: <QtiGzHnIhiQauS8LKRR-p7FStpCaDg5l3f39W2N1-nQ=.6cc51db4-0bd3-4cb4-b6ab-7a702d832e0c@github.com>
References: <QtiGzHnIhiQauS8LKRR-p7FStpCaDg5l3f39W2N1-nQ=.6cc51db4-0bd3-4cb4-b6ab-7a702d832e0c@github.com>
Message-ID: <mRaP0k7P4tk6PtyLkVf2NeJcrV0AOr6y94AltYtjwx4=.9d889ead-1adf-47d3-ad9d-6e274eef106b@github.com>

On Thu, 24 Feb 2022 13:51:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> (The problem is similar to JDK-8282194, but with class loading this time.)
> 
> C1 handles unresolved constants by performing constant resolution at runtime and then putting the constant value into the generated code by patching it. But it treats the not-yet-resolved value as a pure constant without any side effects.
> 
> It's not the case for constants which trigger class loading using custom class loaders. (All non-String constants do that.)
> 
> There are no guarantees that there are no side effects during class loading, so C1 has to be conservative.
> 
> Proposed fix kills memory after accessing not-yet-loaded constant in the context of any non-trusted class loader.
> 
> Testing: hs-tier1 - hs-tier4

src/hotspot/share/ci/ciStreams.hpp line 258:

> 256: 
> 257:     int index = get_constant_pool_index();
> 258:     constantTag tag = get_raw_pool_tag(index);

Looks like these lines are the same as in `is_dynamic_constant()`. Can you move them in separate method to avoid duplication?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7612

From duke at openjdk.java.net  Thu Feb 24 22:48:16 2022
From: duke at openjdk.java.net (Haomin)
Date: Thu, 24 Feb 2022 22:48:16 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will
 fail when --with-jvm-features=-compiler1
Message-ID: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>

?l when --with-jvm-features=-compiler1

-------------

Commit messages:
 - 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

Changes: https://git.openjdk.java.net/jdk/pull/7541/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7541&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282142
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7541.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7541/head:pull/7541

PR: https://git.openjdk.java.net/jdk/pull/7541

From jbhateja at openjdk.java.net  Fri Feb 25 01:07:51 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 25 Feb 2022 01:07:51 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v5]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <rAKYdnrZ3UDhsZCbdVh52TH3SJ3DLL9wAjWeQsBY04o=.22384481-972e-4854-944f-e2b798c3282f@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

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 six additional commits since the last revision:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8281375
 - 8281375: Adding descriptive comments.
 - 8281375: Review comments resolved.
 - 8281375: Review comments resoultion.
 - 8281375: Review comments resolved.
 - 8281375: Accelerate bitCount operation for AVX2 and AVX512 target.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/b4257341..3d92bd6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=03-04

  Stats: 28809 lines in 696 files changed: 20526 ins; 4158 del; 4125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7373/head:pull/7373

PR: https://git.openjdk.java.net/jdk/pull/7373

From jbhateja at openjdk.java.net  Fri Feb 25 01:11:41 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 25 Feb 2022 01:11:41 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8281375: Fix a typo.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/3d92bd6c..92071f7b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7373/head:pull/7373

PR: https://git.openjdk.java.net/jdk/pull/7373

From dlong at openjdk.java.net  Fri Feb 25 04:45:04 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 25 Feb 2022 04:45:04 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <Yibt68Hv1Nen43DHEEVe4rAC26G-QR3wJhtidRlLUO8=.b9496627-5978-4f20-82e1-03b85f802dc8@github.com>

On Sat, 19 Feb 2022 03:49:58 GMT, Haomin <duke at openjdk.java.net> wrote:

> ?l when --with-jvm-features=-compiler1

Should we consider updating the test so that it works when only C2 is present?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From jbhateja at openjdk.java.net  Fri Feb 25 06:22:42 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 25 Feb 2022 06:22:42 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Adding descriptive comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/f7dec3d9..54d4ea36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=07-08

  Stats: 31 lines in 2 files changed: 14 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Fri Feb 25 06:44:59 2022
From: duke at openjdk.java.net (Haomin)
Date: Fri, 25 Feb 2022 06:44:59 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <jzwOqrKbkEk_sC-Ype_6E7a6C9tw5ci60g21klYmsfs=.f877b898-ccd4-4265-b415-beb78160910f@github.com>

On Sat, 19 Feb 2022 03:49:58 GMT, Haomin <duke at openjdk.java.net> wrote:

> ?l when --with-jvm-features=-compiler1

Hi, Dean. Just like you said, "The test was written to test a C1 issue," https://github.com/openjdk/jdk18/pull/80/files Should we update it When only C2 is present? I dont know the answer. I prefer to test it when only C1 enabled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From jiefu at openjdk.java.net  Fri Feb 25 07:00:57 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Feb 2022 07:00:57 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <E4tj4oQvSPbyeD7SRak_Xc3wXxM9gHByW2NopvGc0Ks=.df42964b-ac36-4bd4-8174-2135a102c7d7@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
 <uuZvaCwbFc7sM44SGzVOTVcUmIHboQSMFr5qmvv23GM=.d08b63a6-a2e6-4c17-a011-cfd8f1921165@github.com>
 <E4tj4oQvSPbyeD7SRak_Xc3wXxM9gHByW2NopvGc0Ks=.df42964b-ac36-4bd4-8174-2135a102c7d7@github.com>
Message-ID: <jVBneA2cgeYUpBQ0WGhL7-zol-R1DbWiVDmEcGjJn_I=.58eb66fc-a053-4838-a9a7-770ea50f0df9@github.com>

On Thu, 24 Feb 2022 12:10:09 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>>> @vnkozlov Given `lea` is a really efficient instruction, merging multiple ones into it offers a lot of benefits and all other compilers do so.
>> 
>> So any benchmark to show the perf improvement?
>
> @DamonFool I found benchmarking these single arithmetic-instruction optimizations is hard, especially these rules which contain constant immediates. This is the result from a benchmark I wrote, my machine doesn't match 3-operand rules so the result of `B_I_D_*` is the same, and `B_IS_D_int` seems to suffer from loop alignment which leads to decoder bottleneck trying to read a lot of `nop`.
> Thank you very much.
> 
>     Before:
>     Benchmark                   Mode  Cnt     Score     Error  Units
>     LeaInstruction.B_IS_D_int   avgt   10  1171.089 ?  12.051  ns/op
>     LeaInstruction.B_IS_D_long  avgt   10  1214.248 ? 164.069  ns/op
>     LeaInstruction.B_IS_int     avgt   10   908.979 ?  57.721  ns/op
>     LeaInstruction.B_IS_long    avgt   10  1218.707 ?   2.169  ns/op
>     LeaInstruction.B_I_D_int    avgt   10   842.187 ?  65.795  ns/op
>     LeaInstruction.B_I_D_long   avgt   10  1289.333 ?   9.978  ns/op
>     LeaInstruction.IS_D_int     avgt   10   533.597 ?   1.302  ns/op
>     LeaInstruction.IS_D_long    avgt   10   533.198 ?   0.559  ns/op
> 
>     After:
>     Benchmark                   Mode  Cnt     Score    Error  Units
>     LeaInstruction.B_IS_D_int   avgt   10  1217.740 ?  4.110  ns/op
>     LeaInstruction.B_IS_D_long  avgt   10   809.962 ?  8.156  ns/op
>     LeaInstruction.B_IS_int     avgt   10   536.518 ?  5.076  ns/op
>     LeaInstruction.B_IS_long    avgt   10   534.041 ?  1.158  ns/op
>     LeaInstruction.B_I_D_int    avgt   10   808.131 ?  0.965  ns/op
>     LeaInstruction.B_I_D_long   avgt   10  1287.391 ? 10.025  ns/op
>     LeaInstruction.IS_D_int     avgt   10   305.940 ?  9.886  ns/op
>     LeaInstruction.IS_D_long    avgt   10   308.969 ?  0.844  ns/op

Thanks @merykitty for your benchmark.
I also saw the perf improvement with your micro bench.

I read the "Intel? 64 and IA-32 Architectures Optimization Reference Manual" :  https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

There is `Assembly/Compiler Coding Rule 34`.

Assembly/Compiler Coding Rule 34. (ML impact, L generality) If an LEA instruction using the
scaled index is on the critical path, a sequence with ADDs may be better. If code density and bandwidth
out of the trace cache are the critical factor, then use the LEA instruction. 


Also please note :
![image](https://user-images.githubusercontent.com/19923746/155669026-28d11a2e-cf4c-4fd0-8d36-cd10b703107d.png)

So what do you think of these description?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Feb 25 07:27:04 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Feb 2022 07:27:04 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v4]
In-Reply-To: <kKtETDmXF23qtCVuEeMJrp9iquibiloG5qZjuzWOjhc=.80b0861c-a4b0-4d90-afe7-fc3df1bc9d56@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <kKtETDmXF23qtCVuEeMJrp9iquibiloG5qZjuzWOjhc=.80b0861c-a4b0-4d90-afe7-fc3df1bc9d56@github.com>
Message-ID: <gECN3J6_iThVOXOaGRyF9lmyjS-VgtTWjRAzTPdWXhA=.448df43e-1bd7-484e-bcc2-188509cd17aa@github.com>

On Thu, 24 Feb 2022 12:16:58 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 32:

> 30: @BenchmarkMode(Mode.AverageTime)
> 31: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 32: @Fork(value = 2, jvmArgsAppend = {"-XX:LoopUnrollLimit=1"})

Why we need `-XX:LoopUnrollLimit=1`?

test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 43:

> 41:         int x = this.x;
> 42:         for (int i = 0; i < ITERATION; i++) {
> 43:             x = x * 4 + 10;

Do we need `bh.consume(x)` here?

test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 53:

> 51:             x = x + y + 10;
> 52:             y = x + y + 20;
> 53:             bh.consume(x);

I would suggest `bh.consume` to be out of the for loop.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From haosun at openjdk.java.net  Fri Feb 25 07:39:58 2022
From: haosun at openjdk.java.net (Hao Sun)
Date: Fri, 25 Feb 2022 07:39:58 GMT
Subject: RFR: 8282347: AARCH64: Untaken branch in has_negatives stub
In-Reply-To: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
References: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
Message-ID: <FCm771mXQzFi2o_du3zbUwWUvfzIjJl93tpMzxcaq3A=.a0614e54-6400-4ece-9095-e3fd0a6dc57f@github.com>

On Thu, 24 Feb 2022 13:15:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivial(?) cleanup removing an untaken branch in the aarch64 has_negatives stub.

LGTM. (I'm not a reviewer)

-------------

Marked as reviewed by haosun (Author).

PR: https://git.openjdk.java.net/jdk/pull/7611

From thartmann at openjdk.java.net  Fri Feb 25 07:58:04 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Feb 2022 07:58:04 GMT
Subject: RFR: 8282218: C1: Missing side effects of dynamic class loading
 during constant linkage
In-Reply-To: <QtiGzHnIhiQauS8LKRR-p7FStpCaDg5l3f39W2N1-nQ=.6cc51db4-0bd3-4cb4-b6ab-7a702d832e0c@github.com>
References: <QtiGzHnIhiQauS8LKRR-p7FStpCaDg5l3f39W2N1-nQ=.6cc51db4-0bd3-4cb4-b6ab-7a702d832e0c@github.com>
Message-ID: <y-N2hkoFDZUKDJpLN88_RMcLpMoggn6kN9ZbsLL2_2o=.11409973-f3ea-48fb-8615-fc40a0198f18@github.com>

On Thu, 24 Feb 2022 13:51:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> (The problem is similar to JDK-8282194, but with class loading this time.)
> 
> C1 handles unresolved constants by performing constant resolution at runtime and then putting the constant value into the generated code by patching it. But it treats the not-yet-resolved value as a pure constant without any side effects.
> 
> It's not the case for constants which trigger class loading using custom class loaders. (All non-String constants do that.)
> 
> There are no guarantees that there are no side effects during class loading, so C1 has to be conservative.
> 
> Proposed fix kills memory after accessing not-yet-loaded constant in the context of any non-trusted class loader.
> 
> Testing: hs-tier1 - hs-tier4

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7612

From thartmann at openjdk.java.net  Fri Feb 25 08:00:00 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Feb 2022 08:00:00 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
Message-ID: <vEsVjhKuq8aSuNSt7-WMlEy7ShYLec6QTO8WuZmZWQg=.8178129c-4acc-48dc-8f03-6bbb9d61bc78@github.com>

On Wed, 23 Feb 2022 17:08:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
>> 
>> 
>>   void log_metaspace_failure(const char* reason) {
>>     ResourceMark rm;
>>     StringLogMessage lm;
>>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>>     lm.print("\n");
>>     log(JavaThread::current(), "%s", (const char*)lm);
>>   }
>> 
>> 
>> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
>> 
>> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
>> 
>> 
>> 12700 breakpoints set
>> 12800 breakpoints set
>> 12900 breakpoints set
>> 13000 breakpoints set
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
>> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
>> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
>> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
>> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
>> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
>> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
>> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore
>
> Aleksey Shipilev 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:
> 
>  - Another fix
>  - Merge branch 'master' into JDK-8282172-compiler-broker-message
>  - Fix

Looks good to me too.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7555

From thartmann at openjdk.java.net  Fri Feb 25 08:03:59 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Feb 2022 08:03:59 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v5]
In-Reply-To: <R8tDDk2bdyprRy8D5JHfpmAyhJg1saXW2qhGs_TvHl0=.d876cbd0-e9f0-4af5-a5f4-217413b5dc48@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <R8tDDk2bdyprRy8D5JHfpmAyhJg1saXW2qhGs_TvHl0=.d876cbd0-e9f0-4af5-a5f4-217413b5dc48@github.com>
Message-ID: <K4tVmOcz2xuLazhtOuF8C1VszqHXvRjA6zs0HJ56Q54=.591bc6c5-f2eb-49d2-8464-4046b6142641@github.com>

On Wed, 23 Feb 2022 14:47:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good to me otherwise.

src/hotspot/share/opto/escape.hpp line 584:

> 582:         ptn->dump_header(true);
> 583:         tty->print_cr("is NSR. %s", reason);
> 584:     }

Suggestion:

    if (_compile->directive()->TraceEscapeAnalysisOption) {
      assert(ptn != nullptr, "should not be null");
      ptn->dump_header(true);
      tty->print_cr("is NSR. %s", reason);
    }


Indentation is incorrect.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7428

From thartmann at openjdk.java.net  Fri Feb 25 08:12:00 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Feb 2022 08:12:00 GMT
Subject: RFR: 8282347: AARCH64: Untaken branch in has_negatives stub
In-Reply-To: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
References: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
Message-ID: <LVSwWkYdvpgFLvP8Er5F57h3sI76QCdUXvcD-RjUqwo=.32d0903f-0868-4621-a89f-f3c682586183@github.com>

On Thu, 24 Feb 2022 13:15:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivial(?) cleanup removing an untaken branch in the aarch64 has_negatives stub.

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7611

From thartmann at openjdk.java.net  Fri Feb 25 08:19:58 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 25 Feb 2022 08:19:58 GMT
Subject: RFR: 8230382: Clean up ConvI2L,
 CastII and CastLL::Ideal methods [v3]
In-Reply-To: <cTE-kV9rrdNqRoKvELohAc-5jIPmrNjLqc7E1qo-w6M=.586f4c9e-4abd-4564-bc64-4490268b65a7@github.com>
References: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
 <cTE-kV9rrdNqRoKvELohAc-5jIPmrNjLqc7E1qo-w6M=.586f4c9e-4abd-4564-bc64-4490268b65a7@github.com>
Message-ID: <nM7tCRtoHWIqLK_BlBqibek_LPSFhVIfXb4mOQiiJZk=.bedf7543-9a75-4e74-b9a6-6fa12128c0c6@github.com>

On Thu, 24 Feb 2022 14:42:52 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> This is a cleanup job: move code from `::Ideal` methods that only change types to `::Value` where the code belongs.
>> 
>> `CastLLNode::Ideal` was introduced in [JDK-8229496](https://bugs.openjdk.java.net/browse/JDK-8229496) and reverted (deleted) in [JDK-8242108](https://bugs.openjdk.java.net/browse/JDK-8242108).
>> Currently, `CastLLNode` does not have its own `::Ideal` method. Hence, I changed nothing for it.
>> 
>> For `ConvI2LNode` and `CastIINode`, I went through a process of first copying the relevant code to `::Value`, calling it from `::Ideal` and asserting that they deliver equivalent results.
>> These intermediate code results can be found in the comments of [JDK-8230382](https://bugs.openjdk.java.net/browse/JDK-8230382).
>> I also tried to make the two code versions more similar, where they were unnecessarily different (used `can_reshape` instead of `igvn != NULL`, and removed the dead Overflow/wraparound case which can never happen).
>> I ran tests: final code and intermediate code versions. Ensures code behaves equivalent and nothing broke.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style issues

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7609

From redestad at openjdk.java.net  Fri Feb 25 08:59:03 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 25 Feb 2022 08:59:03 GMT
Subject: RFR: 8282347: AARCH64: Untaken branch in has_negatives stub
In-Reply-To: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
References: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
Message-ID: <tUIjyIBUt2Gru_2TsgnohK7dflNUso_lJeAkLIK2Y9c=.264ef1be-92cd-40c5-ac12-790d428356ab@github.com>

On Thu, 24 Feb 2022 13:15:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivial(?) cleanup removing an untaken branch in the aarch64 has_negatives stub.

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7611

From redestad at openjdk.java.net  Fri Feb 25 08:59:04 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 25 Feb 2022 08:59:04 GMT
Subject: Integrated: 8282347: AARCH64: Untaken branch in has_negatives stub
In-Reply-To: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
References: <z8WefdgJ27PQhn5RlafCxZb2-iUPvcbL72Z6W517Yzs=.e38b690f-7987-42a9-bbb2-64d48bb4bf0a@github.com>
Message-ID: <F6UbiBK3U33vd12ZxFr554LjqhmXbtBN1711BdrcYwI=.c94b44d8-4f05-47a5-8bb3-db292a167124@github.com>

On Thu, 24 Feb 2022 13:15:11 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Trivial(?) cleanup removing an untaken branch in the aarch64 has_negatives stub.

This pull request has now been integrated.

Changeset: 3efd6aa4
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3efd6aa4c9b6420520709281ab1ca46ba4242c87
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8282347: AARCH64: Untaken branch in has_negatives stub

Reviewed-by: aph, haosun, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7611

From stuefe at openjdk.java.net  Fri Feb 25 09:30:01 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 25 Feb 2022 09:30:01 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
Message-ID: <EQTvyLMVlRztA_gZcJ1B3F121Lig1UjICa4Qsljrg-U=.7df30faf-ff84-4446-8185-93edc1d6208c@github.com>

On Wed, 23 Feb 2022 17:08:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
>> 
>> 
>>   void log_metaspace_failure(const char* reason) {
>>     ResourceMark rm;
>>     StringLogMessage lm;
>>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>>     lm.print("\n");
>>     log(JavaThread::current(), "%s", (const char*)lm);
>>   }
>> 
>> 
>> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
>> 
>> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
>> 
>> 
>> 12700 breakpoints set
>> 12800 breakpoints set
>> 12900 breakpoints set
>> 13000 breakpoints set
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
>> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
>> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
>> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
>> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
>> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
>> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
>> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore
>
> Aleksey Shipilev 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:
> 
>  - Another fix
>  - Merge branch 'master' into JDK-8282172-compiler-broker-message
>  - Fix

AFAICS FormatStringEventLog::log() - which is only used from the compiler btw - is always called with the current thread. Maybe it should just use Thread::current instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From duke at openjdk.java.net  Fri Feb 25 12:11:43 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 25 Feb 2022 12:11:43 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  address reviews

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/6d2680b5..41fd4801

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=03-04

  Stats: 115 lines in 2 files changed: 99 ins; 13 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Feb 25 12:30:00 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 25 Feb 2022 12:30:00 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v4]
In-Reply-To: <gECN3J6_iThVOXOaGRyF9lmyjS-VgtTWjRAzTPdWXhA=.448df43e-1bd7-484e-bcc2-188509cd17aa@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <kKtETDmXF23qtCVuEeMJrp9iquibiloG5qZjuzWOjhc=.80b0861c-a4b0-4d90-afe7-fc3df1bc9d56@github.com>
 <gECN3J6_iThVOXOaGRyF9lmyjS-VgtTWjRAzTPdWXhA=.448df43e-1bd7-484e-bcc2-188509cd17aa@github.com>
Message-ID: <enDa-7V5aI5zz04Y6XBtZoUgvX3zO1IqZNuIq7_aUOk=.bdac750e-0538-47e9-a682-d1d7ed4c91c5@github.com>

On Fri, 25 Feb 2022 07:22:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add benchmark
>
> test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 32:
> 
>> 30: @BenchmarkMode(Mode.AverageTime)
>> 31: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> 32: @Fork(value = 2, jvmArgsAppend = {"-XX:LoopUnrollLimit=1"})
> 
> Why we need `-XX:LoopUnrollLimit=1`?

Because our benchmark computation involves constants, loop unrolling leads to the constants being hoisted outside, leading to us not actually measuring the desired.

> test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 43:
> 
>> 41:         int x = this.x;
>> 42:         for (int i = 0; i < ITERATION; i++) {
>> 43:             x = x * 4 + 10;
> 
> Do we need `bh.consume(x)` here?

Yes, it's my bad copying things.
Thank you very much.

> test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 53:
> 
>> 51:             x = x + y + 10;
>> 52:             y = x + y + 20;
>> 53:             bh.consume(x);
> 
> I would suggest `bh.consume` to be out of the for loop.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Feb 25 12:29:56 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 25 Feb 2022 12:29:56 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <jVBneA2cgeYUpBQ0WGhL7-zol-R1DbWiVDmEcGjJn_I=.58eb66fc-a053-4838-a9a7-770ea50f0df9@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
 <uuZvaCwbFc7sM44SGzVOTVcUmIHboQSMFr5qmvv23GM=.d08b63a6-a2e6-4c17-a011-cfd8f1921165@github.com>
 <E4tj4oQvSPbyeD7SRak_Xc3wXxM9gHByW2NopvGc0Ks=.df42964b-ac36-4bd4-8174-2135a102c7d7@github.com>
 <jVBneA2cgeYUpBQ0WGhL7-zol-R1DbWiVDmEcGjJn_I=.58eb66fc-a053-4838-a9a7-770ea50f0df9@github.com>
Message-ID: <rNUHGkabKtCcdmr_M4e6jSoSr9kyNf8GDaih3vxNAuM=.5f01485f-c480-42d8-87dd-738959e34085@github.com>

On Fri, 25 Feb 2022 06:58:15 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Assembly/Compiler Coding Rule 34. (ML impact, L generality) If an LEA instruction using the
> scaled index is on the critical path, a sequence with ADDs may be better. If code density and bandwidth
> out of the trace cache are the critical factor, then use the LEA instruction. 

As noted in the previous paragraph of the document, this is a trade-off since an `add` sequence may offer a little better latency in the expense of more uops and larger code size. As `lea` is an efficient instruction anyway in general it is more preferable to emit it.

Intels since Icelake can compute complex `lea` on more ports and have less latency, I have a predicate to check for that. Also the second bullet is due to `rbp` and `r13` base leads to the instruction must contain a displacement, effectively transform a 2-operand into a 3-operand `lea`, I have also fixed that. Thanks for noticing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jvernee at openjdk.java.net  Fri Feb 25 12:57:46 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Feb 2022 12:57:46 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v6]
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <vqG5pdUa0dej8EieLWHPXmdhMEQFaCcjMZjyL_c_PQM=.3ba2368a-664d-48ae-9ee8-57ff0533818b@github.com>

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Reduce indentation
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7428/files
  - new: https://git.openjdk.java.net/jdk/pull/7428/files/98f0193a..14ec09e9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7428&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7428&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7428.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7428/head:pull/7428

PR: https://git.openjdk.java.net/jdk/pull/7428

From jiefu at openjdk.java.net  Fri Feb 25 13:12:52 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Feb 2022 13:12:52 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v2]
In-Reply-To: <rNUHGkabKtCcdmr_M4e6jSoSr9kyNf8GDaih3vxNAuM=.5f01485f-c480-42d8-87dd-738959e34085@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <4AgA9zYY-SjQ8cAsR37vAGEpLFvkVFufmUV7W3Iz5_E=.a15a93fa-c81a-4e8e-8391-403419a6a7dc@github.com>
 <dUzS1HIALKiRHe50F-bUrGEpTVfgG7HGAPJG3UX54LU=.68326c56-c788-4142-8268-7f62f6e48405@github.com>
 <uuZvaCwbFc7sM44SGzVOTVcUmIHboQSMFr5qmvv23GM=.d08b63a6-a2e6-4c17-a011-cfd8f1921165@github.com>
 <E4tj4oQvSPbyeD7SRak_Xc3wXxM9gHByW2NopvGc0Ks=.df42964b-ac36-4bd4-8174-2135a102c7d7@github.com>
 <jVBneA2cgeYUpBQ0WGhL7-zol-R1DbWiVDmEcGjJn_I=.58eb66fc-a053-4838-a9a7-770ea50f0df9@github.com>
 <rNUHGkabKtCcdmr_M4e6jSoSr9kyNf8GDaih3vxNAuM=.5f01485f-c480-42d8-87dd-738959e34085@github.com>
Message-ID: <mV6JnR5qsSPyygbam48TEINnpEhspbHUBd7JLelkSZw=.e0595958-b992-4f5f-976b-cdefa4719fdf@github.com>

On Fri, 25 Feb 2022 12:24:14 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Intels since Icelake can compute complex `lea` on more ports and have less latency

Can you provide us with something like the official document about this statement?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Feb 25 13:37:54 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 25 Feb 2022 13:37:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
Message-ID: <GvgU0tA-1FHFQrpf12kwWJG7xb49Pnl6OL_rNzCi2-8=.a0b8706f-48b6-47cd-865e-5ce5531822a1@github.com>

On Fri, 25 Feb 2022 12:11:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

You can look up the detailed measurements of each instruction on each architecture generation on [uops.info](https://uops.info/table.html?search=lea&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SNB=on&cb_ICL=on&cb_measurements=on&cb_doc=on&cb_base=on) or check out on a summary at [Agner's optimization guide](https://www.agner.org/optimize/instruction_tables.pdf).

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Feb 25 15:22:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Feb 2022 15:22:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
Message-ID: <8K8HxaflT_MN4SPKionhT5f4rJK0oSwUwlMVku2IvjE=.fe70137b-842c-4585-805f-dab33355be78@github.com>

On Fri, 25 Feb 2022 12:11:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

I checked your last version of the patch.
It fails to generate `lea` for `testInt3` but both gcc and llvm would generate `lea` with -O{1,2,3}.

    @Benchmark
    public int testInt1() {
        return x + (y << 2) + 32;
    }

    @Benchmark
    public int testInt2() {
        return x + (y << 2);
    }

    @Benchmark
    public int testInt3() {
        return x + y + 16;
    }


Shall we also generate `lea` for testInt3?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Feb 25 15:53:56 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 25 Feb 2022 15:53:56 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
Message-ID: <zFzF2rlkO1QrIIEewtOa-OwjDIcyhC8j-z4O_qju_ZY=.247a5351-df6c-452a-90c4-acad8dd67dd0@github.com>

On Fri, 25 Feb 2022 12:11:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

May I ask what version of llvm are you using? Because due to [this patch](https://reviews.llvm.org/D32277), clang from 6.0.0 refuses to generate a 3-op `lea` for this operation while gcc seems to not care (although I checked msvc and also rustc all refrain from generating a complex `lea`).

You do see a `lea`, however, but that is due to a peephole that merges a `mov` and an `add` into a `lea` I believe. This is a little hard in hotspot since our peephole is not powerful enough, and using the matcher is not ideal either since an `add` is often more efficient than a `lea`, and if we make a rule such as `Set dst (AddI src1 src2)` and check if `src1 == dst` to use an `add` then most of the time we will end up with a less efficient `lea`.

I don't know if we have a mechanism to tell the register allocator to try its best to allocate the same register for the specified operands and if it fails to do so then it is still fine. If we can do so then we can cut off a portion of an uop for each addition which is really nice.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Feb 25 23:22:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Feb 2022 23:22:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <zFzF2rlkO1QrIIEewtOa-OwjDIcyhC8j-z4O_qju_ZY=.247a5351-df6c-452a-90c4-acad8dd67dd0@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <zFzF2rlkO1QrIIEewtOa-OwjDIcyhC8j-z4O_qju_ZY=.247a5351-df6c-452a-90c4-acad8dd67dd0@github.com>
Message-ID: <X6EvqUDDnrZHd9fNFYknDApVr-JBwFkH_TRmFt8nNGE=.bf58fe6b-9b9e-4feb-b898-a7e6326ad6a3@github.com>

On Fri, 25 Feb 2022 15:48:21 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> May I ask what version of llvm are you using? Because due to [this patch](https://reviews.llvm.org/D32277), clang from 6.0.0 refuses to generate a 3-op `lea` for this operation while gcc seems to not care (although I checked msvc and also rustc all refrain from generating a complex `lea`).

The llvm info

Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0


I tested the following code pattern with `clang -c  -O{1, 2, 3} ...`.
`lea` is generated for all the cases.

int testInt1(int x, int y) {
  return x + (y << 2) + 32;
}

int testInt2(int x, int y) {
  return x + (y << 2);
}

int testInt3(int x, int y) {
  return x + y + 16;
}

long testLong1(long x, long y) {
  return x + (y << 2) + 32;
}

long testLong2(long x, long y) {
  return x + (y << 2);
}

long testLong3(long x, long y) {
  return x + y + 16;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Feb 25 23:22:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Feb 2022 23:22:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <X6EvqUDDnrZHd9fNFYknDApVr-JBwFkH_TRmFt8nNGE=.bf58fe6b-9b9e-4feb-b898-a7e6326ad6a3@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <zFzF2rlkO1QrIIEewtOa-OwjDIcyhC8j-z4O_qju_ZY=.247a5351-df6c-452a-90c4-acad8dd67dd0@github.com>
 <X6EvqUDDnrZHd9fNFYknDApVr-JBwFkH_TRmFt8nNGE=.bf58fe6b-9b9e-4feb-b898-a7e6326ad6a3@github.com>
Message-ID: <OxWEhOucmPMHMHgZk5g_bJIV5a3XBtuvXsK4IlMXoLU=.f123f330-cc09-4415-bba7-fada8017f14b@github.com>

On Fri, 25 Feb 2022 23:19:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I tested the following code pattern with `clang -c -O{1, 2, 3} ...`.
> `lea` is generated for all the cases.

The generated `lea`:

const.o:	file format Mach-O 64-bit x86-64


Disassembly of section __TEXT,__text:

0000000000000000 __Z8testInt1ii:
       0: 55                           	pushq	%rbp
       1: 48 89 e5                     	movq	%rsp, %rbp
       4: 8d 44 b7 20                  	leal	32(%rdi,%rsi,4), %eax
       8: 5d                           	popq	%rbp
       9: c3                           	retq
       a: 66 0f 1f 44 00 00            	nopw	(%rax,%rax)

0000000000000010 __Z8testInt2ii:
      10: 55                           	pushq	%rbp
      11: 48 89 e5                     	movq	%rsp, %rbp
      14: 8d 04 b7                     	leal	(%rdi,%rsi,4), %eax
      17: 5d                           	popq	%rbp
      18: c3                           	retq
      19: 0f 1f 80 00 00 00 00         	nopl	(%rax)

0000000000000020 __Z8testInt3ii:
      20: 55                           	pushq	%rbp
      21: 48 89 e5                     	movq	%rsp, %rbp
      24: 8d 44 37 10                  	leal	16(%rdi,%rsi), %eax
      28: 5d                           	popq	%rbp
      29: c3                           	retq
      2a: 66 0f 1f 44 00 00            	nopw	(%rax,%rax)

0000000000000030 __Z9testLong1ll:
      30: 55                           	pushq	%rbp
      31: 48 89 e5                     	movq	%rsp, %rbp
      34: 48 8d 44 b7 20               	leaq	32(%rdi,%rsi,4), %rax
      39: 5d                           	popq	%rbp
      3a: c3                           	retq
      3b: 0f 1f 44 00 00               	nopl	(%rax,%rax)

0000000000000040 __Z9testLong2ll:
      40: 55                           	pushq	%rbp
      41: 48 89 e5                     	movq	%rsp, %rbp
      44: 48 8d 04 b7                  	leaq	(%rdi,%rsi,4), %rax
      48: 5d                           	popq	%rbp
      49: c3                           	retq
      4a: 66 0f 1f 44 00 00            	nopw	(%rax,%rax)

0000000000000050 __Z9testLong3ll:
      50: 55                           	pushq	%rbp
      51: 48 89 e5                     	movq	%rsp, %rbp
      54: 48 8d 44 37 10               	leaq	16(%rdi,%rsi), %rax
      59: 5d                           	popq	%rbp
      5a: c3                           	retq

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Sat Feb 26 01:33:54 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 26 Feb 2022 01:33:54 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
Message-ID: <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>

On Fri, 25 Feb 2022 06:22:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Adding descriptive comments.

Other than this the patch looks good to me. What testing have you done?

src/hotspot/cpu/x86/x86.ad line 7263:

> 7261:     __ vector_round_float_avx($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister,
> 7262:                               $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $xtmp4$$XMMRegister,
> 7263:                               ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc);

The vector_float_signflip() here should be replaced by vector_all_bits_set().
cvtps2dq description:
If a converted result cannot be represented in the destination
format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value
(2w-1, where w represents the number of bits in the destination format) is returned.

src/hotspot/cpu/x86/x86.ad line 7280:

> 7278:     __ vector_round_float_evex($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister,
> 7279:                                $xtmp2$$XMMRegister, $ktmp1$$KRegister, $ktmp2$$KRegister,
> 7280:                                ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc);

The vector_float_signflip() here should be replaced by vector_all_bits_set().

src/hotspot/cpu/x86/x86.ad line 7295:

> 7293:     __ vector_round_double_evex($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister,
> 7294:                                 $xtmp2$$XMMRegister, $ktmp1$$KRegister, $ktmp2$$KRegister,
> 7295:                                 ExternalAddress(vector_double_signflip()), new_mxcsr, $scratch$$Register, vlen_enc);

The vector_double_signflip() here should be replaced by vector_all_bits_set().
vcvtpd2qq description:
If a converted result cannot be represented in the destination
format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value
(2w-1, where w represents the number of bits in the destination format) is returned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Sat Feb 26 01:49:54 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 01:49:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
Message-ID: <jcjUo_kai4Qz59fTsvQ2jyG2A-wN3SOnn4sbYe8rsrU=.c43a1136-4ccd-48df-98f8-702074765cb9@github.com>

On Fri, 25 Feb 2022 12:11:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

I'm really confused here because I can't reproduce this locally as well as on Godbolt with all relevant architectures, and also I don't see why clang is trying to change stack frame in such a small function in your generated code. Maybe the compiler is a little different on MacOS?

By the way, as noted in the manual as well as experimenting with various different compilers, I think 2 `add`s would be more efficient for pre-Icelakes since it offers a little better latency and removes the concern of bottleneck on port 1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Sat Feb 26 03:05:54 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 26 Feb 2022 03:05:54 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
Message-ID: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com>

On Sat, 26 Feb 2022 01:06:21 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Adding descriptive comments.
>
> src/hotspot/cpu/x86/x86.ad line 7263:
> 
>> 7261:     __ vector_round_float_avx($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister,
>> 7262:                               $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $xtmp4$$XMMRegister,
>> 7263:                               ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc);
> 
> The vector_float_signflip() here should be replaced by vector_all_bits_set().
> cvtps2dq description:
> If a converted result cannot be represented in the destination
> format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value
> (2w-1, where w represents the number of bits in the destination format) is returned.

Clarification, the number in my comments above is (2^w  - 1). This is from Intel SDM (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html).
Also you will need to take care when the valid unoverflowed result is -1 i.e. 0xFFFFFFFF (2^32 - 1).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Sat Feb 26 03:42:02 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 03:42:02 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
 <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com>
 <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com>
Message-ID: <mPYDVHjrBrCoZU853aifNgYbVOokUK__UWdd4QPtVQ8=.45572f64-bf9d-42f6-b033-b39f3bf5b7be@github.com>

On Sat, 26 Feb 2022 03:37:32 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Clarification, the number in my comments above is (2^w  - 1). This is from Intel SDM (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html).
>> Also you will need to take care when the valid unoverflowed result is -1 i.e. 0xFFFFFFFF (2^32 - 1).
>
> I believe the indefinite value should be 2^(w - 1) (a.k.a 0x80000000) and the documentation is typoed. If you look at `cvtss2si`, the indefinite value is also written as 2^w - 1 but yet in `MacroAssembler::convert_f2i` we compare it with 0x80000000. In addition, choosing -1 as an indefinite value is weird enough and to complicate it as 2^w - 1 is really unusual.

`MacroAssembler::convert_f2i`

https://github.com/openjdk/jdk/blob/c5c6058fd57d4b594012035eaf18a57257f4ad85/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8919

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Sat Feb 26 03:42:02 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 03:42:02 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
 <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com>
Message-ID: <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com>

On Sat, 26 Feb 2022 03:02:51 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 7263:
>> 
>>> 7261:     __ vector_round_float_avx($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister,
>>> 7262:                               $xtmp2$$XMMRegister, $xtmp3$$XMMRegister, $xtmp4$$XMMRegister,
>>> 7263:                               ExternalAddress(vector_float_signflip()), new_mxcsr, $scratch$$Register, vlen_enc);
>> 
>> The vector_float_signflip() here should be replaced by vector_all_bits_set().
>> cvtps2dq description:
>> If a converted result cannot be represented in the destination
>> format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value
>> (2w-1, where w represents the number of bits in the destination format) is returned.
>
> Clarification, the number in my comments above is (2^w  - 1). This is from Intel SDM (https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html).
> Also you will need to take care when the valid unoverflowed result is -1 i.e. 0xFFFFFFFF (2^32 - 1).

I believe the indefinite value should be 2^(w - 1) (a.k.a 0x80000000) and the documentation is typoed. If you look at `cvtss2si`, the indefinite value is also written as 2^w - 1 but yet in `MacroAssembler::convert_f2i` we compare it with 0x80000000. In addition, choosing -1 as an indefinite value is weird enough and to complicate it as 2^w - 1 is really unusual.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Sat Feb 26 04:57:55 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 26 Feb 2022 04:57:55 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
Message-ID: <gM42lIzUQBnOjZLyuBAh4-VqZZs0864NoDP5mOCUVDk=.12c99ec0-98ef-4e67-8fe7-279f82bdf9c9@github.com>

On Fri, 25 Feb 2022 06:22:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Adding descriptive comments.

As per SDM, if post conversion a floating point number is non-representable in destination format e.g. a floating point value 3.4028235E10 post integer conversion will overflow the value range of integer primitive type, hence a -0.0 value or 0x80000000 is returned here. Similarly for +/- NaN and  +/-Inf post conversion value returns is -0.0.  All these cases i.e. post conversion non-representable floating point values and NaN/Inf values are handled in a special manner where algorithm first performs an unordered comparison b/w original source value and returns a 0 in case of  NaN, this weeds out the NaN case and for rest of the special values we check the MSB bit of the source and either return an Integer.MAX_VALUE for +ve numbers or a Integer.MIN_VALUE to adhere to the semantics of Math.round API.

Existing tests were enhanced to cover various special cases (NaN/Inf/+ve/-ve value/values which may be inexact after adding 0.5/ values which post conversion overflow integer value range).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Sat Feb 26 05:58:22 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 05:58:22 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions
Message-ID: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>

Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.

For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.

For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.

Thank you very much.

-------------

Commit messages:
 - fix get operand
 - shorter instructions

Changes: https://git.openjdk.java.net/jdk/pull/7628/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282414
  Stats: 83 lines in 2 files changed: 69 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7628/head:pull/7628

PR: https://git.openjdk.java.net/jdk/pull/7628

From duke at openjdk.java.net  Sat Feb 26 06:49:35 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 06:49:35 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions [v2]
In-Reply-To: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
Message-ID: <C7FL_hnit6WmhiVItXGLA-jxUkapfMcLFFxi9SZqabM=.5f178eec-d68b-457a-b889-a44778f76833@github.com>

> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
> 
> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
> 
> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - punctuation
 - remove wrong instruction

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7628/files
  - new: https://git.openjdk.java.net/jdk/pull/7628/files/05a0e707..2c6dc08e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 9 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7628/head:pull/7628

PR: https://git.openjdk.java.net/jdk/pull/7628

From duke at openjdk.java.net  Sat Feb 26 07:13:32 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 07:13:32 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions [v3]
In-Reply-To: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
Message-ID: <p20D4DV-Oftr8KM-QjQWVYHPQ_2RzgR7TlwH0LZD49o=.72c218da-8ca6-414d-a0ed-7bc4728bcf73@github.com>

> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
> 
> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
> 
> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix build

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7628/files
  - new: https://git.openjdk.java.net/jdk/pull/7628/files/2c6dc08e..d9db9b8f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7628/head:pull/7628

PR: https://git.openjdk.java.net/jdk/pull/7628

From duke at openjdk.java.net  Sat Feb 26 07:44:28 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Feb 2022 07:44:28 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions [v4]
In-Reply-To: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
Message-ID: <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>

> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
> 
> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
> 
> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7628/files
  - new: https://git.openjdk.java.net/jdk/pull/7628/files/d9db9b8f..1bdc273b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7628&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7628.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7628/head:pull/7628

PR: https://git.openjdk.java.net/jdk/pull/7628

From phedlin at openjdk.java.net  Sat Feb 26 10:13:48 2022
From: phedlin at openjdk.java.net (Patric Hedlin)
Date: Sat, 26 Feb 2022 10:13:48 GMT
Subject: Withdrawn: 8277926: [aarch64] Address constructors are lacking
 initialisation.
In-Reply-To: <FpkfK7ou6hrzFQN2XXiwktzbujdDj8fQu9zmnG57xuA=.4aa8e128-9ca9-44db-b8a0-e2dd398ad2b7@github.com>
References: <FpkfK7ou6hrzFQN2XXiwktzbujdDj8fQu9zmnG57xuA=.4aa8e128-9ca9-44db-b8a0-e2dd398ad2b7@github.com>
Message-ID: <FK0V8LByvSV8hK9T-PWCJnsrfKIRhTAieSKqyFfc1gk=.f5b02dbc-14f0-4d02-9db9-a1923e9d2689@github.com>

On Sun, 23 Jan 2022 15:54:35 GMT, Patric Hedlin <phedlin at openjdk.org> wrote:

> Please review changes to secure proper initialisation in Address constructors.
> 
> Changes include (with additional clean-up):
> 
> Renamed '**literal**' to '**addr_literal**'.
> Renamed '**_ext**' to '**_extend**'.
> Renamed Address::mode enum to Address::addr_mode.
> Renamed Address::getMode() to Address::mode().
> Reorder _mode.
> 
> Initialise '**_extend**' to **lsl(0)**.
> Initialise '**_target**' to **nullptr**.
> 
> Added preconditions to constructors.
> Added preconditions to check 'target' address.
> 
> Removed '**pcrel**' addressing mode (unused).
> Removed direct attribute use in Address.
> 
> Minor clean-up to RuntimeAddress use.
> 
> ---8<---
> 
> Testing: tier1-6 (Linux), tier1-3 (MacOSX)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7191

From duke at openjdk.java.net  Mon Feb 28 03:25:51 2022
From: duke at openjdk.java.net (Haomin)
Date: Mon, 28 Feb 2022 03:25:51 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <w_iNlV-aAiQkeRX4kXvqPUceapJ5nTST8rgAfYbT4Qw=.da9e5ed5-84c9-4b53-8589-607efcb96084@github.com>

On Sat, 19 Feb 2022 03:49:58 GMT, Haomin <duke at openjdk.java.net> wrote:

> ?l when --with-jvm-features=-compiler1

@DamonFool Please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From jiefu at openjdk.java.net  Mon Feb 28 05:03:44 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 05:03:44 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <z4F1nEcnAkk3ecx1r-hcXQwpF86_iLxwqEx6ZiOLpYo=.86696447-3230-43e6-8131-1d8aa4e18996@github.com>

On Sat, 19 Feb 2022 03:49:58 GMT, Haomin <duke at openjdk.java.net> wrote:

> ?l when --with-jvm-features=-compiler1

I would suggest something like this

diff --git a/test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java b/test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java
index dfeee6c..b7977d0 100644
--- a/test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java
+++ b/test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java
@@ -25,7 +25,7 @@
  * @test
  * @bug 8279515
  *
- * @requires vm.flagless
+ * @requires vm.flagless & vm.compMode != "Xint" & vm.compiler1.enabled & vm.compiler2.enabled
  * @modules java.base/jdk.internal.misc
  * @library /test/lib /
  *


This is because the test fails with C1-only too (I tested it with the minimal VM).
Also I don't think it would pass with interpreter-only mode.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From duke at openjdk.java.net  Mon Feb 28 06:20:16 2022
From: duke at openjdk.java.net (Haomin)
Date: Mon, 28 Feb 2022 06:20:16 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v2]
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <JMAXxuBRajVa5FkjSp1KuG2bfo2JTUAtmwCRjq10mhc=.8dd6695e-275b-4359-b8b7-df43977d5220@github.com>

> ?l when --with-jvm-features=-compiler1

Haomin has updated the pull request incrementally with one additional commit since the last revision:

  8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7541/files
  - new: https://git.openjdk.java.net/jdk/pull/7541/files/67f4b9e4..130bda3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7541&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7541&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7541.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7541/head:pull/7541

PR: https://git.openjdk.java.net/jdk/pull/7541

From jiefu at openjdk.java.net  Mon Feb 28 06:34:53 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 06:34:53 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v2]
In-Reply-To: <JMAXxuBRajVa5FkjSp1KuG2bfo2JTUAtmwCRjq10mhc=.8dd6695e-275b-4359-b8b7-df43977d5220@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <JMAXxuBRajVa5FkjSp1KuG2bfo2JTUAtmwCRjq10mhc=.8dd6695e-275b-4359-b8b7-df43977d5220@github.com>
Message-ID: <9GAeXXrweMp1lcAO7bqwPRgkDS7n9_MWxikQiNOLUwo=.1e112c8d-3fe1-4c81-8d3d-3313c3992497@github.com>

On Mon, 28 Feb 2022 06:20:16 GMT, Haomin <duke at openjdk.java.net> wrote:

>> ?l when --with-jvm-features=-compiler1
>
> Haomin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java line 28:

> 26:  * @bug 8279515
> 27:  *
> 28:  * @requires vm.flagless & vm.compMode != "Xint" & vm.compiler1.enabled & vm.compiler2.enabled

Thanks for the update.

Since there are already `vm.compiler1.enabled & vm.compiler2.enabled` and `vm.flagless`, `vm.compMode != "Xint"` seems to be unnecessary.

So we can safely drop `vm.compMode != "Xint"` even with zero-vm, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From duke at openjdk.java.net  Mon Feb 28 06:45:17 2022
From: duke at openjdk.java.net (Haomin)
Date: Mon, 28 Feb 2022 06:45:17 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v3]
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>

> ?l when --with-jvm-features=-compiler1

Haomin has updated the pull request incrementally with one additional commit since the last revision:

  8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7541/files
  - new: https://git.openjdk.java.net/jdk/pull/7541/files/130bda3b..5e28f5fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7541&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7541&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7541.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7541/head:pull/7541

PR: https://git.openjdk.java.net/jdk/pull/7541

From duke at openjdk.java.net  Mon Feb 28 06:45:20 2022
From: duke at openjdk.java.net (Haomin)
Date: Mon, 28 Feb 2022 06:45:20 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v2]
In-Reply-To: <9GAeXXrweMp1lcAO7bqwPRgkDS7n9_MWxikQiNOLUwo=.1e112c8d-3fe1-4c81-8d3d-3313c3992497@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <JMAXxuBRajVa5FkjSp1KuG2bfo2JTUAtmwCRjq10mhc=.8dd6695e-275b-4359-b8b7-df43977d5220@github.com>
 <9GAeXXrweMp1lcAO7bqwPRgkDS7n9_MWxikQiNOLUwo=.1e112c8d-3fe1-4c81-8d3d-3313c3992497@github.com>
Message-ID: <jQ-9TPA99JBHhYk0Oz_jgz_3AW-mn9Mq3JUSfNvcX4k=.6dda3522-707c-4503-8ead-4fa77870996b@github.com>

On Mon, 28 Feb 2022 06:31:59 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Haomin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1
>
> test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java line 28:
> 
>> 26:  * @bug 8279515
>> 27:  *
>> 28:  * @requires vm.flagless & vm.compMode != "Xint" & vm.compiler1.enabled & vm.compiler2.enabled
> 
> Thanks for the update.
> 
> Since there are already `vm.compiler1.enabled & vm.compiler2.enabled` and `vm.flagless`, `vm.compMode != "Xint"` seems to be unnecessary.
> 
> So we can safely drop `vm.compMode != "Xint"` even with zero-vm, right?

OK? DONE

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From jiefu at openjdk.java.net  Mon Feb 28 06:47:47 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 06:47:47 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v3]
In-Reply-To: <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
Message-ID: <OKuyhY3xZsiYbSM5okvl5K29Rs22MPbtAqO5sufSwiA=.120a9b83-cf18-411d-bba4-7e193d819265@github.com>

On Mon, 28 Feb 2022 06:45:17 GMT, Haomin <duke at openjdk.java.net> wrote:

>> ?l when --with-jvm-features=-compiler1
>
> Haomin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

Looks good to me.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7541

From jiefu at openjdk.java.net  Mon Feb 28 07:05:53 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 07:05:53 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v3]
In-Reply-To: <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
Message-ID: <8zS9Sdu9yxCW98PuHb5Ph1VjO1X4312wZAHkz2V4i0A=.ac9a6b29-5aae-448c-81ed-6cad7327f916@github.com>

On Mon, 28 Feb 2022 06:45:17 GMT, Haomin <duke at openjdk.java.net> wrote:

>> ?l when --with-jvm-features=-compiler1
>
> Haomin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

> /integrate

Let's wait for two days to see if @dean-long and others have better solution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From duke at openjdk.java.net  Mon Feb 28 07:17:49 2022
From: duke at openjdk.java.net (Haomin)
Date: Mon, 28 Feb 2022 07:17:49 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v2]
In-Reply-To: <jQ-9TPA99JBHhYk0Oz_jgz_3AW-mn9Mq3JUSfNvcX4k=.6dda3522-707c-4503-8ead-4fa77870996b@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <JMAXxuBRajVa5FkjSp1KuG2bfo2JTUAtmwCRjq10mhc=.8dd6695e-275b-4359-b8b7-df43977d5220@github.com>
 <9GAeXXrweMp1lcAO7bqwPRgkDS7n9_MWxikQiNOLUwo=.1e112c8d-3fe1-4c81-8d3d-3313c3992497@github.com>
 <jQ-9TPA99JBHhYk0Oz_jgz_3AW-mn9Mq3JUSfNvcX4k=.6dda3522-707c-4503-8ead-4fa77870996b@github.com>
Message-ID: <Kax5dQT-BiAvvCTrCGtL3xwQCgwi6t6McNZ1xF_S3do=.ece4daa8-9008-42bb-810f-9c882091ee2c@github.com>

On Mon, 28 Feb 2022 06:41:43 GMT, Haomin <duke at openjdk.java.net> wrote:

>> test/hotspot/jtreg/compiler/inlining/ResolvedClassTest.java line 28:
>> 
>>> 26:  * @bug 8279515
>>> 27:  *
>>> 28:  * @requires vm.flagless & vm.compMode != "Xint" & vm.compiler1.enabled & vm.compiler2.enabled
>> 
>> Thanks for the update.
>> 
>> Since there are already `vm.compiler1.enabled & vm.compiler2.enabled` and `vm.flagless`, `vm.compMode != "Xint"` seems to be unnecessary.
>> 
>> So we can safely drop `vm.compMode != "Xint"` even with zero-vm, right?
>
> OK? DONE

> > /integrate
> 
> Let's wait for two days to see if @dean-long and others have better solution.

Sure. Thank you, jiege

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From roland at openjdk.java.net  Mon Feb 28 09:14:48 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 09:14:48 GMT
Subject: RFR: 8230382: Clean up ConvI2L,
 CastII and CastLL::Ideal methods [v3]
In-Reply-To: <cTE-kV9rrdNqRoKvELohAc-5jIPmrNjLqc7E1qo-w6M=.586f4c9e-4abd-4564-bc64-4490268b65a7@github.com>
References: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
 <cTE-kV9rrdNqRoKvELohAc-5jIPmrNjLqc7E1qo-w6M=.586f4c9e-4abd-4564-bc64-4490268b65a7@github.com>
Message-ID: <1MP0brsWFq_YJEI6M-VTcF63vdChEMEeKgYly5_NRfY=.c75024d9-a7bd-4f50-b8f6-94cb914be942@github.com>

On Thu, 24 Feb 2022 14:42:52 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> This is a cleanup job: move code from `::Ideal` methods that only change types to `::Value` where the code belongs.
>> 
>> `CastLLNode::Ideal` was introduced in [JDK-8229496](https://bugs.openjdk.java.net/browse/JDK-8229496) and reverted (deleted) in [JDK-8242108](https://bugs.openjdk.java.net/browse/JDK-8242108).
>> Currently, `CastLLNode` does not have its own `::Ideal` method. Hence, I changed nothing for it.
>> 
>> For `ConvI2LNode` and `CastIINode`, I went through a process of first copying the relevant code to `::Value`, calling it from `::Ideal` and asserting that they deliver equivalent results.
>> These intermediate code results can be found in the comments of [JDK-8230382](https://bugs.openjdk.java.net/browse/JDK-8230382).
>> I also tried to make the two code versions more similar, where they were unnecessarily different (used `can_reshape` instead of `igvn != NULL`, and removed the dead Overflow/wraparound case which can never happen).
>> I ran tests: final code and intermediate code versions. Ensures code behaves equivalent and nothing broke.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code style issues

Looks good to me.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7609

From duke at openjdk.java.net  Mon Feb 28 09:18:49 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 28 Feb 2022 09:18:49 GMT
Subject: RFR: 8230382: Clean up ConvI2L,
 CastII and CastLL::Ideal methods [v3]
In-Reply-To: <1MP0brsWFq_YJEI6M-VTcF63vdChEMEeKgYly5_NRfY=.c75024d9-a7bd-4f50-b8f6-94cb914be942@github.com>
References: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
 <cTE-kV9rrdNqRoKvELohAc-5jIPmrNjLqc7E1qo-w6M=.586f4c9e-4abd-4564-bc64-4490268b65a7@github.com>
 <1MP0brsWFq_YJEI6M-VTcF63vdChEMEeKgYly5_NRfY=.c75024d9-a7bd-4f50-b8f6-94cb914be942@github.com>
Message-ID: <Q0LuD1RVsMBvwW-vC3wtl7wbB3hcKbCXA-A0zfyDYaQ=.b8b07b2c-9dba-4dbf-96e7-9f4e885b9ee3@github.com>

On Mon, 28 Feb 2022 09:12:02 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code style issues
>
> Looks good to me.

Thanks @rwestrel for the review! Thanks @TobiHartmann for the help, corrections and review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7609

From roland at openjdk.java.net  Mon Feb 28 09:41:50 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 09:41:50 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799
In-Reply-To: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
Message-ID: <AGsItTdra7C2BAw0lm3hUxIF99F324Tjah8ii0VOmmk=.11cf6c40-3917-422b-9068-3317e1681353@github.com>

On Wed, 16 Feb 2022 13:28:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The crash occurs because a Shenandoah barrier is expanded between the
> Start node and its control projection. One of the test cases I added
> also shows the same failure with a barrier expansion between a MemBar
> and its control projection. The barrier is expanded at the control
> that PhaseIdealLoop assigns to it.
> 
> This code:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
> I added back with JDK-8280799 is what's causing the incorrect
> placement of the barrier.
> 
> The fix I propose is to skip that logic if the loop opts pass is for
> barrier expansion as there's no range check elimination then.

Thanks for looking at this.

> Could you explain what exactly is different in the GC specific loop opts pass that makes this code incorrect?

The shenandoah barrier is initially a floating macro node. It needs to be expanded to a series of tests and a call. Because it's floating, the usual macro expansion pass cannot be used. Instead, the barrier expansion logic relies on a loop opts pass that assigns control to the barriers. The control flow is then constructed at the barrier's control. That control needs to be a valid control but because of JDK-8280799, it's not always the case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7494

From jbhateja at openjdk.java.net  Mon Feb 28 09:41:53 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 28 Feb 2022 09:41:53 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
Message-ID: <-CRSiJ61a0N0pZFNCYZhIKnVlxXSEOuDjk2OUyMaO9M=.3cf2f59a-6acd-4dd8-9d97-afe33ab44498@github.com>

On Tue, 8 Feb 2022 09:01:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Fix a typo.
>
> Hi Jatin, nice work!
> 
> One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.
> 
> Best regards,
> Nils

Hi @neliasso, reviewers, just want to check if any other modification needed here. Regards, Jatin

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From roland at openjdk.java.net  Mon Feb 28 09:45:51 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 09:45:51 GMT
Subject: RFR: 8281322: irTests/TestLongRangeChecks.java fails with strip
 mining off
In-Reply-To: <U5mhGwub7FLr-KdEUBnW4nhMucQneRs_i-cAtJQS1AE=.bd326571-d143-4f81-802b-0cf236676848@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <U5mhGwub7FLr-KdEUBnW4nhMucQneRs_i-cAtJQS1AE=.bd326571-d143-4f81-802b-0cf236676848@github.com>
Message-ID: <CiU4R0YaQz0Vq9oen7iah8c-wJZhgtmMduY6NOa5ENA=.7502e425-1ed3-4bad-9306-414df36cbe0f@github.com>

On Fri, 11 Feb 2022 10:05:44 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> For the record: Christian's testing found issues (he reported them to Roland already).

8282045 (When loop strip mining fails, safepoints are removed from loop anyway) is an underlying issue that Christian's testing caught.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7364

From chagedorn at openjdk.java.net  Mon Feb 28 09:52:49 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 28 Feb 2022 09:52:49 GMT
Subject: RFR: 8281122: [IR Framework] Cleanup IR matching code in
 preparation for JDK-8280378
In-Reply-To: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
References: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
Message-ID: <8TUucW2sn2ArwuA5y9MVx2hnFkfx7xe-_SvbjEfGO2Y=.9434a067-a833-4321-838d-d505368efea5@github.com>

On Fri, 18 Feb 2022 13:36:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch does some restructurings and refactorings of the `IRMatcher.java` class in preparation for adding IR matching support on different compile phases with [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). There are no semantic changes of how IR matching is eventually done on regexes and how the results are checked with the `failOn` and `counts` constraints provided by the user. The only user-visible change is an improved output format of matching failures.
> 
> The old format also did not report a `counts` constraint failure correctly. It wrongly used the format of `failOn` failures which was misleading. This is also fixed by this patch.
> 
> **Example:**
> 
> @Test
> @IR(counts = {IRNode.STORE_F, "!= 1"}) // fails
> @IR(counts = {IRNode.STORE_F, "2", IRNode.LOAD_F, "> 1"}) // both constraints fail
> public void test1() {
>     fFld = 4.2f;
> }
> 
> @Test
> @IR(failOn = IRNode.ALLOC, counts = {IRNode.STORE_F, ">= 2"}) // failOn and counts fail
> public void test2() {
>     fFld = 4.2f;
>     o = new Object();
> }
> 
> _Failure outputs:_
> <details>
>   <summary>Old format</summary>
> 
> 
> Failed IR Rules (3)
> ------------------
> - Method "public void ir_framework.tests.Testi.test1()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 1 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>   * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>         Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> - Method "public void ir_framework.tests.Testi.test2()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>     - failOn: Graph contains forbidden nodes:
>         Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>         Matched forbidden node:
>           1a5     movq    RSI, precise java/lang/Object: 0x00007fb188007318:Constant:exact *	# ptr
>     1af     call,static  wrapper for: _new_instance_Java
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> <details>
>   <summary>New format</summary>
> 
> 
> Failed IR Rules (3) of Methods (2)
> ----------------------------------
> 1) Method "public void ir_framework.tests.Testi.test1()" - [Failed IR rules: 2]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 != 1 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>    * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 = 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>        * Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 0 > 1 [given]
>          - No nodes matched!
> 
> 2) Method "public void ir_framework.tests.Testi.test2()" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>      - failOn: Graph contains forbidden nodes:
>        * Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>          - Matched forbidden node:
>            * 1a5     movq    RSI, precise java/lang/Object: 0x00007fd3c4007318:Constant:exact *	# ptr
>              1af     call,static  wrapper for: _new_instance_Java
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 >= 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> 
> **New class structure:**
> 
> The old `IRMatcher` class mixed different tasks such as parsing, IR annotation verification, IR matching and failure reporting together. This made it difficult to extend the existing code to add IR matching support on different compile phases. Therefore, the class was split to separate the different tasks:
> - parser classes (`IREncodingParser`, `HotSpotPidFileParser`, `IRMethodParser` etc.)
> - entity classes for the different parts of an `@IR` annotation (`IRMethod`, `IRRule`, `Counts`, `FailOn` etc.)
> - match result classes for each entity class to provide a formatted failure message (`IRMethodMatchResult`, `IRRuleMatchResult` etc.)
> 
> The main structure of the new classes will be kept in JDK-8280378 but will be further improved to match the new needs.
> 
> **Testing:**
> - Normal tier testing including tier5 and 6 where the IR framework tests are executed.
> - Testing of this patch in Valhalla with tier1-3 + some Valhalla-specific stress testing
> 
> 
> Thanks,
> Christian

Thanks a lot for your review Tobias! Yes, unfortunately, it is quite an extensive cleanup which makes it hard to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7533

From duke at openjdk.java.net  Mon Feb 28 10:04:56 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Mon, 28 Feb 2022 10:04:56 GMT
Subject: Integrated: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations
In-Reply-To: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
Message-ID: <p3XdOJB8ihceP-TdK85VY-RcPNQ6MBTPi-T56vzt1K8=.03a64257-2b07-4bb5-b537-27a23f88c97d@github.com>

On Thu, 10 Feb 2022 22:12:53 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

> Hi, can I please get some reviews for this Pull Request? Here is a summary of the changes:
> 
> - Add tests, using the new IR-based test framework, for several of the Ideal transformations on Add, Sub, Mul, Div, Loop nodes and some simple Scalar Replacement transformations.
> - Add more default IR regex's to IR-based test framework.

This pull request has now been integrated.

Changeset: efd3967b
Author:    John Tortugo <disoares at microsoft.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/efd3967b54fed7eaa3c3072267f766d73a3acadb
Stats:     1983 lines in 11 files changed: 1983 ins; 0 del; 0 mod

8267265: Use new IR Test Framework to create tests for C2 Ideal transformations

Reviewed-by: chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7434

From duke at openjdk.java.net  Mon Feb 28 10:51:07 2022
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Mon, 28 Feb 2022 10:51:07 GMT
Subject: RFR: 8277055: Assert "missing inlining msg" with -XX:+PrintIntrinsics
Message-ID: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>

in `CallGenerator::do_late_inline_helper()` we hit an assert `"missing inlining msg"` when calling  `C->print_inlining_update_delayed(this)`. The reason is that not all implementations of do_late_inline_check() print an inline message. The fix is to add an inline message for the two `return false` in `LateInlineVirtualCallGenerator::do_late_inline_check(...)` where we do not print an inline message.

Tier1-3 passed

-------------

Commit messages:
 - fix whitespace
 - fix whitespace
 - reverse whitespace removal
 - added if statements for printing
 - added jtreg test
 - removed trailing whitespaces
 - added print message if late call devirtualization fails
 - JDK-8277055: Assert missing inlining msg with -XX:+PrintIntrinsics
 - Merge branch 'JDK-8277055' of github.com:tobiasholenstein/jdk into JDK-8277055
 - moved print_inlining_update_delayed into do_late_inline_check
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f5d8cebb...162e97aa

Changes: https://git.openjdk.java.net/jdk/pull/7385/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7385&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277055
  Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7385/head:pull/7385

PR: https://git.openjdk.java.net/jdk/pull/7385

From jiefu at openjdk.java.net  Mon Feb 28 10:51:52 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 10:51:52 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <jcjUo_kai4Qz59fTsvQ2jyG2A-wN3SOnn4sbYe8rsrU=.c43a1136-4ccd-48df-98f8-702074765cb9@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <jcjUo_kai4Qz59fTsvQ2jyG2A-wN3SOnn4sbYe8rsrU=.c43a1136-4ccd-48df-98f8-702074765cb9@github.com>
Message-ID: <cXtB53pVmi-rWfI_Ka5fQAU3FFx7Kb5BRF2VuGv7uXU=.1abceb41-a7f6-4895-bc17-8324482aeb86@github.com>

On Sat, 26 Feb 2022 01:46:52 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> I'm really confused here because I can't reproduce this locally as well as on Godbolt with all relevant architectures, and also I don't see why clang is trying to change stack frame in such a small function in your generated code. Maybe the compiler is a little different on MacOS?
> 
> By the way, as noted in the manual as well as experimenting with various different compilers, I think 2 `add`s would be more efficient for pre-Icelakes since it offers a little better latency and removes the concern of bottleneck on port 1.

Yes, I see.

It will generate `lea` for `base + index + disp` pattern only when fast-3op is supported.
So it would be smarter than gcc and llvm.

The patch still generates rpb as base register, which should be avoided according to Intel's manual.

040     B2: #   out( B2 B3 ) <- in( B1 B2 ) Loop( B2-B2 inner ) Freq: 1007.4
040     addl    RDX, RBP        # int
042     addr32 leal RBP, [RBP + RDX + #30]      # int
047     addl    RDX, #10        # int
04a     incl    R11     # int
04d     cmpl    R11, #1000
054     jl,s   B2       # loop end  P=0.999007 C=260663.000000

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Mon Feb 28 11:29:52 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 11:29:52 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
Message-ID: <oy1Ecg-Q0lCrL0_VYvXJ8bWmrTK7q76_ukRKgRDMAdw=.88a14343-12e3-4506-b968-8911407a75fc@github.com>

On Fri, 25 Feb 2022 12:11:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

Changes requested by jiefu (Reviewer).

src/hotspot/cpu/x86/vm_version_x86.hpp line 1056:

> 1054:   // Pre Icelake Intels have inefficient 3-op lea with 3 latency, this can be
> 1055:   // replaced by add-add or lea-add
> 1056:   static bool supports_fast_3op_lea() {

Please make it clear what do you mean by '3op'.

src/hotspot/cpu/x86/vm_version_x86.hpp line 1058:

> 1056:   static bool supports_fast_3op_lea() {
> 1057:     return supports_fast_2op_lea() &&
> 1058:            ((is_intel() && supports_clwb()) || // Icelake and above

Why we use `supports_clwb ()` here?

src/hotspot/cpu/x86/vm_version_x86.hpp line 1059:

> 1057:     return supports_fast_2op_lea() &&
> 1058:            ((is_intel() && supports_clwb()) || // Icelake and above
> 1059:             is_amd());

Does it mean all AMD cpus would be fast-3op if they are fast-2op?

src/hotspot/cpu/x86/x86_64.ad line 450:

> 448:   _INT_NO_RCX_REG_mask.Remove(OptoReg::as_OptoReg(rcx->as_VMReg()));
> 449: 
> 450:   _INT_NO_RBP_R13_REG_mask = _LONG_REG_mask;

Should it be `= _INT_REG_mask` ?

src/hotspot/cpu/x86/x86_64.ad line 7503:

> 7501: instruct leaI_rReg_immI2_immI(rRegI dst, rRegI index, immI2 scale, immI disp)
> 7502: %{
> 7503:   predicate(VM_Version::supports_fast_2op_lea());

We actually have three operands (index, scale and dis) for this rule.
Shouldn't this predicate be `VM_Version::supports_fast_3op_lea()`?

Please make it clear what do you mean by `supports_fast_3op_lea`.
I guess you mean 3 operands including `base, index and disp`, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Mon Feb 28 11:38:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 11:38:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
Message-ID: <7rzCnQCtpXRIZq8N7xPJpiCqno9lD4G4VioY2X6HfEw=.19ccb040-74eb-470e-9513-5195143301cf@github.com>

On Fri, 25 Feb 2022 12:11:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

src/hotspot/cpu/x86/x86_64.ad line 3702:

> 3700:   match(RegL);
> 3701:   match(rax_RegL);
> 3702:   match(rcx_RegL);

Why we need this change?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Mon Feb 28 12:01:31 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 28 Feb 2022 12:01:31 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  reviews

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/41fd4801..a866de71

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=04-05

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Mon Feb 28 12:01:36 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 28 Feb 2022 12:01:36 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <oy1Ecg-Q0lCrL0_VYvXJ8bWmrTK7q76_ukRKgRDMAdw=.88a14343-12e3-4506-b968-8911407a75fc@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <oy1Ecg-Q0lCrL0_VYvXJ8bWmrTK7q76_ukRKgRDMAdw=.88a14343-12e3-4506-b968-8911407a75fc@github.com>
Message-ID: <Td0k0p6nfSuNy586YViYw7qACpR-P3ZtVC4frPcPprg=.8508a6a6-5cdd-4d89-a25b-483b63f816f8@github.com>

On Mon, 28 Feb 2022 11:11:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> src/hotspot/cpu/x86/vm_version_x86.hpp line 1058:
> 
>> 1056:   static bool supports_fast_3op_lea() {
>> 1057:     return supports_fast_2op_lea() &&
>> 1058:            ((is_intel() && supports_clwb()) || // Icelake and above
> 
> Why we use `supports_clwb ()` here?

Icelakes introduce `clwb` instruction so I use that to filter Intel cpus.

> src/hotspot/cpu/x86/vm_version_x86.hpp line 1059:
> 
>> 1057:     return supports_fast_2op_lea() &&
>> 1058:            ((is_intel() && supports_clwb()) || // Icelake and above
>> 1059:             is_amd());
> 
> Does it mean all AMD cpus would be fast-3op if they are fast-2op?

Yes, AMD complex `lea` has 2 cycle latency and can be executed on 2 ports so it is better than 2 `add`s.

> src/hotspot/cpu/x86/x86_64.ad line 450:
> 
>> 448:   _INT_NO_RCX_REG_mask.Remove(OptoReg::as_OptoReg(rcx->as_VMReg()));
>> 449: 
>> 450:   _INT_NO_RBP_R13_REG_mask = _LONG_REG_mask;
> 
> Should it be `= _INT_REG_mask` ?

Fixed, thanks

> src/hotspot/cpu/x86/x86_64.ad line 7503:
> 
>> 7501: instruct leaI_rReg_immI2_immI(rRegI dst, rRegI index, immI2 scale, immI disp)
>> 7502: %{
>> 7503:   predicate(VM_Version::supports_fast_2op_lea());
> 
> We actually have three operands (index, scale and dis) for this rule.
> Shouldn't this predicate be `VM_Version::supports_fast_3op_lea()`?
> 
> Please make it clear what do you mean by `supports_fast_3op_lea`.
> I guess you mean 3 operands including `base, index and disp`, right?

Yes, I have clarified this in the comment of `VM_Version::supports_fast_3op_lea()`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From mdoerr at openjdk.java.net  Mon Feb 28 12:04:48 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 28 Feb 2022 12:04:48 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v2]
In-Reply-To: <cdgzs2GZfurm_aB03CvxLO-sRWymipglEj6LOKvatO4=.99c52987-4189-4d94-a318-8adc0baaa848@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <cdgzs2GZfurm_aB03CvxLO-sRWymipglEj6LOKvatO4=.99c52987-4189-4d94-a318-8adc0baaa848@github.com>
Message-ID: <vZA8ursTlXF-Rv8nlpYFxbE6IjF7mMt_FVCzlcYkeBg=.83e85d6b-cf29-454d-b4d3-f743bbb72c3c@github.com>

On Thu, 24 Feb 2022 14:39:48 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to satisfy review comments

LGTM. Thanks for cleaning it up. Needs to get tested before integration.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7324

From duke at openjdk.java.net  Mon Feb 28 12:07:52 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 28 Feb 2022 12:07:52 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <7rzCnQCtpXRIZq8N7xPJpiCqno9lD4G4VioY2X6HfEw=.19ccb040-74eb-470e-9513-5195143301cf@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <7rzCnQCtpXRIZq8N7xPJpiCqno9lD4G4VioY2X6HfEw=.19ccb040-74eb-470e-9513-5195143301cf@github.com>
Message-ID: <bONxLbF4uvuY_x9fMXeR4aBAe57Th3nDwEDlZxSklss=.05acc7c3-143c-4433-8756-73a5b99eb0bc@github.com>

On Mon, 28 Feb 2022 11:34:47 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> src/hotspot/cpu/x86/x86_64.ad line 3702:
> 
>> 3700:   match(RegL);
>> 3701:   match(rax_RegL);
>> 3702:   match(rcx_RegL);
> 
> Why we need this change?

Mostly for completeness only, do you think I should revert this? Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Mon Feb 28 12:16:53 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 28 Feb 2022 12:16:53 GMT
Subject: Integrated: 8230382: Clean up ConvI2L,
 CastII and CastLL::Ideal methods
In-Reply-To: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
References: <oMfLmJFx9LYW3ArcDpLeef4C7aoKfAq2btzbq7zc_bU=.242d13a2-79c0-4dec-a4e6-d2127070fbb3@github.com>
Message-ID: <hZaWvsm0FT7am4Hs2mX2ucOoHRMFTUN4b4gUe43_qbw=.072dbd17-b354-47d8-909e-0d5e2c2f4a0f@github.com>

On Thu, 24 Feb 2022 13:03:31 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> This is a cleanup job: move code from `::Ideal` methods that only change types to `::Value` where the code belongs.
> 
> `CastLLNode::Ideal` was introduced in [JDK-8229496](https://bugs.openjdk.java.net/browse/JDK-8229496) and reverted (deleted) in [JDK-8242108](https://bugs.openjdk.java.net/browse/JDK-8242108).
> Currently, `CastLLNode` does not have its own `::Ideal` method. Hence, I changed nothing for it.
> 
> For `ConvI2LNode` and `CastIINode`, I went through a process of first copying the relevant code to `::Value`, calling it from `::Ideal` and asserting that they deliver equivalent results.
> These intermediate code results can be found in the comments of [JDK-8230382](https://bugs.openjdk.java.net/browse/JDK-8230382).
> I also tried to make the two code versions more similar, where they were unnecessarily different (used `can_reshape` instead of `igvn != NULL`, and removed the dead Overflow/wraparound case which can never happen).
> I ran tests: final code and intermediate code versions. Ensures code behaves equivalent and nothing broke.

This pull request has now been integrated.

Changeset: 06cadb36
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/06cadb36e05a86a528c8f3bc64c1a42b47ca94a0
Stats:     162 lines in 2 files changed: 72 ins; 80 del; 10 mod

8230382: Clean up ConvI2L, CastII and CastLL::Ideal methods

Reviewed-by: thartmann, roland

-------------

PR: https://git.openjdk.java.net/jdk/pull/7609

From roland at openjdk.java.net  Mon Feb 28 12:25:11 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 12:25:11 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799 [v2]
In-Reply-To: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
Message-ID: <lpwr--8lGSN_GFYzzpAWHZe8DZQV7nXdmt0r1zKTZnI=.3dea475a-6a73-4bc9-88e0-c3b4f92d03f0@github.com>

> The crash occurs because a Shenandoah barrier is expanded between the
> Start node and its control projection. One of the test cases I added
> also shows the same failure with a barrier expansion between a MemBar
> and its control projection. The barrier is expanded at the control
> that PhaseIdealLoop assigns to it.
> 
> This code:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
> I added back with JDK-8280799 is what's causing the incorrect
> placement of the barrier.
> 
> The fix I propose is to skip that logic if the loop opts pass is for
> barrier expansion as there's no range check elimination then.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8281811
 - test
 - fix

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7494/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7494&range=01
  Stats: 90 lines in 3 files changed: 74 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7494.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7494/head:pull/7494

PR: https://git.openjdk.java.net/jdk/pull/7494

From roland at openjdk.java.net  Mon Feb 28 12:42:28 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 12:42:28 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799 [v3]
In-Reply-To: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
Message-ID: <5cPXKQx_MBcV8TVASmC1CziX6khVGMIPePn0qa0nplU=.2c0621ea-b24b-4ef4-877f-b42d2977d330@github.com>

> The crash occurs because a Shenandoah barrier is expanded between the
> Start node and its control projection. One of the test cases I added
> also shows the same failure with a barrier expansion between a MemBar
> and its control projection. The barrier is expanded at the control
> that PhaseIdealLoop assigns to it.
> 
> This code:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
> I added back with JDK-8280799 is what's causing the incorrect
> placement of the barrier.
> 
> The fix I propose is to skip that logic if the loop opts pass is for
> barrier expansion as there's no range check elimination then.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  merge error

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7494/files
  - new: https://git.openjdk.java.net/jdk/pull/7494/files/3af1c2ae..29e53f66

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7494&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7494&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7494.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7494/head:pull/7494

PR: https://git.openjdk.java.net/jdk/pull/7494

From shade at openjdk.java.net  Mon Feb 28 13:15:51 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Feb 2022 13:15:51 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <EQTvyLMVlRztA_gZcJ1B3F121Lig1UjICa4Qsljrg-U=.7df30faf-ff84-4446-8185-93edc1d6208c@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
 <EQTvyLMVlRztA_gZcJ1B3F121Lig1UjICa4Qsljrg-U=.7df30faf-ff84-4446-8185-93edc1d6208c@github.com>
Message-ID: <w9hcqKOO-29ObswrR1HBAiGk2w9VHcko7OAJ1v0zQjo=.b7a742dd-3206-4d71-ad65-7c81cc1fc631@github.com>

On Fri, 25 Feb 2022 09:26:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> AFAICS FormatStringEventLog::log() - which is only used from the compiler btw - is always called with the current thread. Maybe it should just use Thread::current instead?

Maybe. Let's do that separately?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From roland at openjdk.java.net  Mon Feb 28 13:20:41 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 13:20:41 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway [v2]
In-Reply-To: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
Message-ID: <lMuc_77DeCiZA8H-_SFgbMesoXYY8z9chtw4__Y40u0=.f3a4df78-1dca-4d0f-bd94-d16723945fe3@github.com>

> I noticed that if loop strip mining fails because a safepoint is not
> found right above the exit test (following partial peel for instance),
> all safepoints are removed from the loop anyway. That's fixed by the
> change in IdealLoopTree::counted_loop() where rather than test if loop
> strip mining is enabled, the check now verifies that loop strip mining
> was successful.
> 
> With that change,
> compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
> is not converted into a strip mined loop because there's no safepoint
> above the exit test after partial peeling. The loop strip mining logic
> is too strict when it comes to the safepoint location. Any safepoint
> that dominates the exit and is in the loop as long as there's no side
> effect between the safepoint and the exit can be used. The patch
> implements that change as well. TestAutoVectorization2DArray.java
> passes as a result.
> 
> The existing requirement to have no safepoint on the backedge is too
> strict as well. If the loop has another safepoint that can be used for
> strip mining, then the safepoint on the backedge can safely be
> dropped. That's also implemented by the patch.

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:

 - review
 - Merge branch 'master' into JDK-8282045
 - whitespaces
 - fix & test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7513/files
  - new: https://git.openjdk.java.net/jdk/pull/7513/files/73e1ad08..fa8e76d0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7513&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7513&range=00-01

  Stats: 19436 lines in 459 files changed: 13349 ins; 3058 del; 3029 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7513.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7513/head:pull/7513

PR: https://git.openjdk.java.net/jdk/pull/7513

From roland at openjdk.java.net  Mon Feb 28 13:20:41 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 13:20:41 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway [v2]
In-Reply-To: <tBUTDnIQnxkGowunN2yP629eLy485hZxpNjREUA9shE=.cc412199-4de5-4cb6-81ed-ee950a2e3b8c@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
 <tBUTDnIQnxkGowunN2yP629eLy485hZxpNjREUA9shE=.cc412199-4de5-4cb6-81ed-ee950a2e3b8c@github.com>
Message-ID: <j-YGRgro8PqrKf2UttPBpbDoVG9LeoOBY9HD7Sx1Yic=.4c74aa15-fdf2-4f85-ab4f-bc201329b317@github.com>

On Wed, 23 Feb 2022 09:48:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8282045
>>  - whitespaces
>>  - fix & test
>
> Noticed a typo in `PhaseIdealLoop::find_safepoint` that you might want to fix as well with this patch:
> `there's not side effect` -> `there's no side effect`

@TobiHartmann  thanks for looking at this. The new commit should take care of your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7513

From stuefe at openjdk.java.net  Mon Feb 28 13:26:52 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 28 Feb 2022 13:26:52 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <w9hcqKOO-29ObswrR1HBAiGk2w9VHcko7OAJ1v0zQjo=.b7a742dd-3206-4d71-ad65-7c81cc1fc631@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
 <EQTvyLMVlRztA_gZcJ1B3F121Lig1UjICa4Qsljrg-U=.7df30faf-ff84-4446-8185-93edc1d6208c@github.com>
 <w9hcqKOO-29ObswrR1HBAiGk2w9VHcko7OAJ1v0zQjo=.b7a742dd-3206-4d71-ad65-7c81cc1fc631@github.com>
Message-ID: <T4HkyQyHizlbmk-BSaz2kblcdcbk9mDxScF8xM8Nix8=.55c4f853-97fe-4698-87a6-eabd9e54cbc5@github.com>

On Mon, 28 Feb 2022 13:12:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > AFAICS FormatStringEventLog::log() - which is only used from the compiler btw - is always called with the current thread. Maybe it should just use Thread::current instead?
> 
> Maybe. Let's do that separately?

Oh, sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From shade at openjdk.java.net  Mon Feb 28 13:31:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Feb 2022 13:31:49 GMT
Subject: RFR: 8282172: CompileBroker::log_metaspace_failure is called from
 non-Java/compiler threads [v2]
In-Reply-To: <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
 <tD6hMRTk7_r_H9tR7QKUGW1ycwHnBKcUbRGVGikhOXo=.21b7505a-7b4f-4ba4-97a6-4feb9fc4fb41@github.com>
Message-ID: <Mc6JExHB3eNnzQ0IQfL3p9cpBImytHVSrK9R4UkkkR0=.289c5a78-f19a-4c2b-aa71-0c86a6adf275@github.com>

On Wed, 23 Feb 2022 17:08:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
>> 
>> 
>>   void log_metaspace_failure(const char* reason) {
>>     ResourceMark rm;
>>     StringLogMessage lm;
>>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>>     lm.print("\n");
>>     log(JavaThread::current(), "%s", (const char*)lm);
>>   }
>> 
>> 
>> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
>> 
>> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
>> 
>> 
>> 12700 breakpoints set
>> 12800 breakpoints set
>> 12900 breakpoints set
>> 13000 breakpoints set
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
>> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
>> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
>> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
>> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
>> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
>> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
>> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore
>
> Aleksey Shipilev 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:
> 
>  - Another fix
>  - Merge branch 'master' into JDK-8282172-compiler-broker-message
>  - Fix

Good. Thanks for reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From shade at openjdk.java.net  Mon Feb 28 13:31:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Feb 2022 13:31:49 GMT
Subject: Integrated: 8282172: CompileBroker::log_metaspace_failure is called
 from non-Java/compiler threads
In-Reply-To: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
References: <-t1HtQ-kL7Lh4hiKSEsI1SQVuTYcfFaUbpqM7w8qsLE=.87cf86a5-acc1-484c-9c8c-af3419577368@github.com>
Message-ID: <KiPj4fXRdYnHQNa_eJh-ERCyXwIYNDEvRvLJtS80K5U=.4fd4f236-e2db-434b-ba55-d399fb70a61f@github.com>

On Mon, 21 Feb 2022 11:22:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In several places in hotspot, we call CompileBroker::log_metaspace_failure(). I believe the intent is to call it from compiler threads only, because it ends up calling:
> 
> 
>   void log_metaspace_failure(const char* reason) {
>     ResourceMark rm;
>     StringLogMessage lm;
>     lm.print("%4d COMPILE PROFILING SKIPPED: %s", -1, reason);
>     lm.print("\n");
>     log(JavaThread::current(), "%s", (const char*)lm);
>   }
> 
> 
> ...which would fail the cast in `JavaThread::current()` if current thread is not Java thread (compiler threads are Java threads too).
> 
> It clearly manifests on [JDK-8282170](https://bugs.openjdk.java.net/browse/JDK-8282170) test:
> 
> 
> 12700 breakpoints set
> 12800 breakpoints set
> 12900 breakpoints set
> 13000 breakpoints set
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc: SuppressErrorAt=/thread.hpp:1458
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/runtime/thread.hpp:1458), pid=889379, tid=889389
> # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread
> V [libjvm.so+0xacfad4] CompilationLog::log_metaspace_failure(char const*)+0x494
> V [libjvm.so+0xac84b0] CompileBroker::log_metaspace_failure()+0x20
> V [libjvm.so+0x15069e9] Method::build_method_counters(Thread*, Method*)+0x119
> V [libjvm.so+0x150851b] BreakpointInfo::set(Method*)+0xfb
> V [libjvm.so+0x127d5ea] JvmtiBreakpoint::each_method_version_do(void (Method::*)(int))+0x5a
> V [libjvm.so+0x1b342ae] VM_Operation::evaluate()+0x18e 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug does not fail JDK-8282170 test anymore

This pull request has now been integrated.

Changeset: 4e7fb41d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4e7fb41dafaf03baabe18ee1dabefed50d69e16d
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8282172: CompileBroker::log_metaspace_failure is called from non-Java/compiler threads

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7555

From roland at openjdk.java.net  Mon Feb 28 14:28:40 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 14:28:40 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses [v2]
In-Reply-To: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
Message-ID: <IZNb8OqZiYD6dyr8-D9uda17r5Deb9KVGEHaGGtcNxk=.9fdfa5c7-220f-49d4-a882-6c3a4955f206@github.com>

> Outside the type system code itself, c2 usually assumes that a
> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
> klass(). To have proper support for interfaces, that can't be true as
> a type needs to be represented by an instance class and a set of
> interfaces. This patch hides the klass() accessor of
> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
> that makes that code suitable for proper interface support in a
> subsequent change. This patch doesn't add proper interface support yet
> and is mostly refactoring. "Mostly" because there are cases where the
> previous logic would use a ciKlass but the new one works with a
> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
> klass is exact or not. That extra bit of information can sometimes
> help and so could result in slightly different decisions.
> 
> To remove the klass() accessors, the new logic either relies on:
> 
> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
> toop->klass()->is_subtype_of(other_toop->klass())
> the new code is:
> toop->is_java_subtype_of(other_toop)
> 
> - variants of the klass() accessors for narrower cases like
>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>   interface in which case it returns Object),
>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>   the type is exact).
> 
> When I tested this patch, for most changes in this patch, I had the
> previous logic, the new logic and a check that verified that they
> return the same result. I ran as much testing as I could that way.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - review
 - Merge branch 'master' into JDK-8275201
 - Merge branch 'master' into JDK-8275201
 - build fix
 - Merge branch 'master' into JDK-8275201
 - whitespaces
 - remove klass accessor

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6717/files
  - new: https://git.openjdk.java.net/jdk/pull/6717/files/669421ca..98fcf8fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6717&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6717&range=00-01

  Stats: 107606 lines in 2811 files changed: 74820 ins; 17905 del; 14881 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6717/head:pull/6717

PR: https://git.openjdk.java.net/jdk/pull/6717

From roland at openjdk.java.net  Mon Feb 28 14:28:40 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 14:28:40 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses
In-Reply-To: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
Message-ID: <eyY4AukLvwyxXbOyP_OB3WF-NxAzGkt9HPvgA3Qs97M=.e41e17e6-4ed1-4ad2-af93-7a10a0fa0eac@github.com>

On Mon, 6 Dec 2021 09:59:44 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Outside the type system code itself, c2 usually assumes that a
> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
> klass(). To have proper support for interfaces, that can't be true as
> a type needs to be represented by an instance class and a set of
> interfaces. This patch hides the klass() accessor of
> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
> that makes that code suitable for proper interface support in a
> subsequent change. This patch doesn't add proper interface support yet
> and is mostly refactoring. "Mostly" because there are cases where the
> previous logic would use a ciKlass but the new one works with a
> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
> klass is exact or not. That extra bit of information can sometimes
> help and so could result in slightly different decisions.
> 
> To remove the klass() accessors, the new logic either relies on:
> 
> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
> toop->klass()->is_subtype_of(other_toop->klass())
> the new code is:
> toop->is_java_subtype_of(other_toop)
> 
> - variants of the klass() accessors for narrower cases like
>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>   interface in which case it returns Object),
>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>   the type is exact).
> 
> When I tested this patch, for most changes in this patch, I had the
> previous logic, the new logic and a check that verified that they
> return the same result. I ran as much testing as I could that way.

Thanks for the review and testing. I merged and pushed a new commit that should address your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6717

From roland at openjdk.java.net  Mon Feb 28 14:28:41 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Feb 2022 14:28:41 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses [v2]
In-Reply-To: <Xj1ZSqzxXLh1b4yK2HrzPFAU50508YTmxnU0EYUHxqA=.766f1807-ba79-40ed-9f63-21f453bf2a01@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
 <Xj1ZSqzxXLh1b4yK2HrzPFAU50508YTmxnU0EYUHxqA=.766f1807-ba79-40ed-9f63-21f453bf2a01@github.com>
Message-ID: <efY7HLQ1D_Or8kPifiOAQgA7qZgOPRImKM8egbquxzs=.78572817-40af-4a51-9253-f9efc0ce8c6a@github.com>

On Fri, 18 Feb 2022 10:11:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8275201
>>  - Merge branch 'master' into JDK-8275201
>>  - build fix
>>  - Merge branch 'master' into JDK-8275201
>>  - whitespaces
>>  - remove klass accessor
>
> src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 800:
> 
>> 798:   } else if (src_type->isa_aryptr()) {
>> 799:     BasicType src_elem = src_type->isa_aryptr()->elem()->array_element_basic_type();
>> 800:     if (is_reference_type(src_elem) || src_elem == T_NARROWOOP) {
> 
> I find numerous new `T_NARROWOOP` checks distracting. Is it possible to get rid of them?
> E.g., either normalize it to `T_OBJECT` in `array_element_basic_type()` or enhance `is_reference_type()`.

I enhance is_reference_type() but it's called from so many locations that it's hard to tell if simply accepting T_NARROWOOP works for all uses. So I also added a boolean parameter.

> src/hotspot/share/opto/type.hpp line 1198:
> 
>> 1196:   // Instance klass, ignoring any interface
>> 1197:   ciInstanceKlass* instance_klass() const {
>> 1198:     if (klass()->is_loaded() && klass()->is_interface()) {
> 
> Does it make sense to normalize `_klass` during construction instead?

I don't think that would work. The type of the element of `new I[]` is a TypeInstPtr. If I is an interface, that TypeInstPtr must not be Object. In any case, this will become cleaner with the next change where the instance klass and interfaces are recorded separately in TypeInstPtr.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6717

From jiefu at openjdk.java.net  Mon Feb 28 15:05:47 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 15:05:47 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <Td0k0p6nfSuNy586YViYw7qACpR-P3ZtVC4frPcPprg=.8508a6a6-5cdd-4d89-a25b-483b63f816f8@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <oy1Ecg-Q0lCrL0_VYvXJ8bWmrTK7q76_ukRKgRDMAdw=.88a14343-12e3-4506-b968-8911407a75fc@github.com>
 <Td0k0p6nfSuNy586YViYw7qACpR-P3ZtVC4frPcPprg=.8508a6a6-5cdd-4d89-a25b-483b63f816f8@github.com>
Message-ID: <bQqm-OVDKj7riwhp8W1bMNKKeZ5fmurESHENA5QQT6I=.f2ca086b-53ae-4a3a-b0be-30a804eac444@github.com>

On Mon, 28 Feb 2022 11:55:32 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Icelakes introduce `clwb` instruction so I use that to filter Intel cpus.

I'm not sure if we can find a better way (e.g., cpuid) to filter Intel CPUs.
However, this seems fine since gcc and llvm will generate `lea` even without `clwb`.

> Mostly for completeness only, do you think I should revert this? Thank you very much.

Yes.
I would suggest not touching unnecessary part of code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Mon Feb 28 15:13:54 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 15:13:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
Message-ID: <U3JJrS1pAC1R9fhVZQkGL7PC0LjeHjKgO7ZD6dDbMIY=.fae65f80-b312-4a16-8020-c803fb0ed8cb@github.com>

On Mon, 28 Feb 2022 12:01:31 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

The Intel manual mentions that

For LEA instructions with three source operands and some specific situations, instruction latency has
increased to 3 cycles, and must dispatch via port 1:
? LEA that has all three source operands: base, index, and offset.
? LEA that uses base and index registers where the base is EBP, RBP, or R13.
...


My understanding is that we should avoid generating lea with base=rbp/r13.
But the current patch fails to do so, e.g., 

instruct leaI_rReg_rReg_immI(rRegI dst, rRegI src1, rRegI src2, immI disp)
%{
  predicate(VM_Version::supports_fast_3op_lea());
  match(Set dst (AddI (AddI src1 src2) disp));

  format %{ "addr32 leal $dst, [$src1 + $src2 + $disp]\t# int" %}
  ins_encode %{
    __ leal($dst$$Register, Address($src1$$Register, $src2$$Register, Address::times_1, $disp$$constant));
  %}
  ins_pipe(ialu_reg_reg);
%}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Mon Feb 28 15:31:49 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 28 Feb 2022 15:31:49 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
Message-ID: <cFIjqCC21z0zuBA1cVbB6tmICu9JnUeox0KKsa6D4WM=.bc7afe8e-416e-4cc1-94fa-e0dcf8837ac2@github.com>

On Mon, 28 Feb 2022 12:01:31 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

The reason for the second bullet point is that for `lea`s containing 2 register operands with the base register being `rbp` or `r13`, the assembler must emit a displacement even if it is 0. In another word, the cause for the regression observed in the second bullet point is the same as the first one. As a consequence, if we can execute the 3-operand `lea` efficiently then we don't have to worry about the base register. Thanks.

Assembler address emission:
https://github.com/openjdk/jdk/blob/4e7fb41dafaf03baabe18ee1dabefed50d69e16d/src/hotspot/cpu/x86/assembler_x86.cpp#L583
Measurement with `rbp` as base:
Throughput:
https://bit.ly/3pnT9ms
Latency:
https://bit.ly/3tcJTTv

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From lucy at openjdk.java.net  Mon Feb 28 17:10:27 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 28 Feb 2022 17:10:27 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v2]
In-Reply-To: <cdgzs2GZfurm_aB03CvxLO-sRWymipglEj6LOKvatO4=.99c52987-4189-4d94-a318-8adc0baaa848@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <cdgzs2GZfurm_aB03CvxLO-sRWymipglEj6LOKvatO4=.99c52987-4189-4d94-a318-8adc0baaa848@github.com>
Message-ID: <NVT2iyxJOPEZNULK-QjwDfUizn0EUJFe5Xt0V2YBEjI=.c49c1198-8b39-4225-9c20-8df66156700f@github.com>

On Thu, 24 Feb 2022 14:39:48 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changes to satisfy review comments

Thank you, Martin, for your review. 
I will perform testing to the best of my abilities.
For formal testing, I have to rely on @backwaterred

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From lucy at openjdk.java.net  Mon Feb 28 17:10:26 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 28 Feb 2022 17:10:26 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
Message-ID: <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>

> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
> 
> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
> 
> As this is a s390x-only change, other platforms are not impacted.

Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:

  minor comment adaptations and code formatting

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7324/files
  - new: https://git.openjdk.java.net/jdk/pull/7324/files/2094825b..22516908

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7324&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7324&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7324/head:pull/7324

PR: https://git.openjdk.java.net/jdk/pull/7324

From duke at openjdk.java.net  Mon Feb 28 18:55:32 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Mon, 28 Feb 2022 18:55:32 GMT
Subject: RFR: 8267265: Use new IR Test Framework to create tests for C2
 Ideal transformations [v3]
In-Reply-To: <Me6EQoBBM_XOVo_BPm-2Gm4GFi1uE7lwZn6ZzGvAh7w=.6ef1d37a-ecc6-470c-a9a2-84d2a6add6d9@github.com>
References: <JgX4p9OCXLCU_cReXFDi066uowtIILur1F1SOyrd9uo=.8a621c67-c47c-4822-899b-87a60194877a@github.com>
 <enxdYe9Ror3TBnLI3yetuoOQJGpdi0xs5UFlkbylE08=.d3a93e8c-c13a-4d16-8f8d-d72e80cfcaf9@github.com>
 <NXUVRzSSFvE3c6yd-I78IlivH7g1F8bP4ovMHcQJ0pA=.68f82ed3-0ed5-49bd-8fa0-2f9af61257f1@github.com>
 <Me6EQoBBM_XOVo_BPm-2Gm4GFi1uE7lwZn6ZzGvAh7w=.6ef1d37a-ecc6-470c-a9a2-84d2a6add6d9@github.com>
Message-ID: <FLBo2IVMdsm1fP9piynZwJ3BkliLm5ine0fc8s3a6WI=.32dfe4e0-95b5-4b63-bb57-3c83c305c631@github.com>

On Mon, 21 Feb 2022 08:54:29 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Looks good, thanks for doing the updates!
>> 
>> I'll submit another round of testing over the weekend.
>
>> I'll submit another round of testing over the weekend.
> 
> hs-tier1-3 looked good!

Thank you @chhagedorn !

-------------

PR: https://git.openjdk.java.net/jdk/pull/7434

From iveresov at openjdk.java.net  Mon Feb 28 20:51:46 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Mon, 28 Feb 2022 20:51:46 GMT
Subject: RFR: 8279886: C1: Turn off SelectivePhiFunctions in presence of
 irreducible loops
Message-ID: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>

This change add irreducible loops detection to `BlockListBuilder::mark_loops()` - a loop marking routine necessary for the SSA conversion. Here is brief description of the algorithm (copy-pasted from the comments I left in the code).

The loop detection algorithm works as follows:

- We maintain the `_loop_map`, where for each block we have a bitmap indicating which loops contain this block.
- The CFG is recursively traversed (depth-first) and if we detect a loop, we assign the loop a unique number that is stored in the bitmap associated with the loop header block. Until we return back through that loop header the bitmap contains only a single bit corresponding to the loop number.
- The bit is then propagated for all the blocks in the loop after we exit them (post-order). There could be multiple bits of course in case of nested loops.
- When we exit the loop header we remove that single bit and assign the real loop state for it.
- Now, the tricky part here is how we detect irriducible loops. In the algorithm above the loop state bits are propagated to the predecessors. If we encounter an irreducible loop (a loop with multiple heads) we would see a node with some loop bit set that would then propagate back and be never cleared because we would never go back through the original loop header. Therefore if there are any irreducible loops the bits in the states for these loops are going to propagate back to the root.

Testing is clean: hs-tier{1-7}

-------------

Commit messages:
 - Add comments
 - Detect irreducible loops during parsing/phi insertion.

Changes: https://git.openjdk.java.net/jdk/pull/7636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7636&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279886
  Stats: 63 lines in 5 files changed: 27 ins; 7 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7636/head:pull/7636

PR: https://git.openjdk.java.net/jdk/pull/7636

From lucy at openjdk.java.net  Mon Feb 28 22:12:05 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Mon, 28 Feb 2022 22:12:05 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
Message-ID: <kOvHTLs8n3635oLdZCUDwnXyq_l8zZT5yEeRga_8DaE=.4b2eaeaa-8602-48f9-917a-2ba9d812b441@github.com>

On Mon, 28 Feb 2022 17:10:26 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment adaptations and code formatting

This is a pure s390 change. Test failures on Windows x64 must be unrelated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From Tyler.Steele at ibm.com  Mon Feb 28 22:26:15 2022
From: Tyler.Steele at ibm.com (Tyler Steele)
Date: Mon, 28 Feb 2022 22:26:15 +0000
Subject: testbug? ResolvedClassTest fails on AIX with output very similar to
 expected
Message-ID: <ddf90565e2973958bbdd655aae2df8dd56c4bca5.camel@ibm.com>

Hello all,

I am currently looking into a test failure present on AIX, but not on other systems (Linux on various architectures) I
have tested. I am looking for some guidance to help validate my suspicions about this test failure so that I can submit
an appropriate fix.

The test I am looking at is ResolvedClassTest.java which fails when it does not find the line?
`@ 3   java.lang.invoke.Invokers$Holder::linkToTargetMethod (9 bytes)   force inline by annotation` in the output
produced by PrintCompilation. Snippets of the output produced on Linux and AIX are shown below. As you can see, they are
very similar.

--- Linux (expected) output ---
> 128    7 %  b  3       compiler.jsr292.ResolvedClassTest$TestIndy::test @ 11 (33 bytes)
>	@ 3   java.lang.invoke.Invokers$Holder::linkToTargetMethod (9 bytes)   force inline by annotation
>	@ 5   java.lang.invoke.DirectMethodHandle$Holder::invokeStatic (14 bytes)   force inline by annotation
--- AIX (failing) output ---
< 237    7 %  b  3       compiler.jsr292.ResolvedClassTest$TestIndy::test @ 11 (33 bytes)
<	@ 3   java.lang.invoke.LambdaForm$MH/0x00000007c0002400::linkToTargetMethod (9 bytes)   force inline by
annotation
<	@ 5   java.lang.invoke.LambdaForm$DMH/0x00000007c0001c00::invokeStatic (14 bytes)   force inline by annotation

As I understand it Invokers$Holder, and DirectMethodHandle$Holder are placeholders for pre-compiled or speculatively
compiled code. I suspect this step happens differently (or doesn't happen) on AIX, but I don't understand where the
divergence occurs. I would appreciate any suggestions as to what (optimization? enhancement?) changes this behaviour on
AIX.

More importantly, is this equivalent output? If so, would something like shouldMatch (rather than shouldContain) be
appropriate to allow the test to pass on AIX?

Thanks in advance for your help.
Tyler

From duke at openjdk.java.net  Mon Feb 28 22:40:21 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 28 Feb 2022 22:40:21 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <kOvHTLs8n3635oLdZCUDwnXyq_l8zZT5yEeRga_8DaE=.4b2eaeaa-8602-48f9-917a-2ba9d812b441@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
 <kOvHTLs8n3635oLdZCUDwnXyq_l8zZT5yEeRga_8DaE=.4b2eaeaa-8602-48f9-917a-2ba9d812b441@github.com>
Message-ID: <LEWK5zYTVWrwc4wE1r95lAXtrt20Ebujj4lS2ols3C8=.e1f127b0-8801-4a92-9f77-a0ec6bbf9a4d@github.com>

On Mon, 28 Feb 2022 22:08:43 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor comment adaptations and code formatting
>
> This is a pure s390 change. Test failures on Windows x64 must be unrelated.

@RealLucy, I am happy to help. I am currently running tier1 tests on s390, and I will update this comment when they complete

---

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From dean.long at oracle.com  Mon Feb 28 23:07:34 2022
From: dean.long at oracle.com (dean.long at oracle.com)
Date: Mon, 28 Feb 2022 15:07:34 -0800
Subject: testbug? ResolvedClassTest fails on AIX with output very similar
 to expected
In-Reply-To: <ddf90565e2973958bbdd655aae2df8dd56c4bca5.camel@ibm.com>
References: <ddf90565e2973958bbdd655aae2df8dd56c4bca5.camel@ibm.com>
Message-ID: <d6526338-3cf0-dc79-d941-f3d7a9d25791@oracle.com>

Hi Tyler.

Apparently the $Holder classes are generated by jlink.  Is your AIX 
build different from your other builds?

dl

On 2/28/22 2:26 PM, Tyler Steele wrote:
> Hello all,
> 
> I am currently looking into a test failure present on AIX, but not on other systems (Linux on various architectures) I
> have tested. I am looking for some guidance to help validate my suspicions about this test failure so that I can submit
> an appropriate fix.
> 
> The test I am looking at is ResolvedClassTest.java which fails when it does not find the line
> `@ 3   java.lang.invoke.Invokers$Holder::linkToTargetMethod (9 bytes)   force inline by annotation` in the output
> produced by PrintCompilation. Snippets of the output produced on Linux and AIX are shown below. As you can see, they are
> very similar.
> 
> --- Linux (expected) output ---
>> 128    7 %  b  3       compiler.jsr292.ResolvedClassTest$TestIndy::test @ 11 (33 bytes)
>> 	@ 3   java.lang.invoke.Invokers$Holder::linkToTargetMethod (9 bytes)   force inline by annotation
>> 	@ 5   java.lang.invoke.DirectMethodHandle$Holder::invokeStatic (14 bytes)   force inline by annotation
> --- AIX (failing) output ---
> < 237    7 %  b  3       compiler.jsr292.ResolvedClassTest$TestIndy::test @ 11 (33 bytes)
> <	@ 3   java.lang.invoke.LambdaForm$MH/0x00000007c0002400::linkToTargetMethod (9 bytes)   force inline by
> annotation
> <	@ 5   java.lang.invoke.LambdaForm$DMH/0x00000007c0001c00::invokeStatic (14 bytes)   force inline by annotation
> 
> As I understand it Invokers$Holder, and DirectMethodHandle$Holder are placeholders for pre-compiled or speculatively
> compiled code. I suspect this step happens differently (or doesn't happen) on AIX, but I don't understand where the
> divergence occurs. I would appreciate any suggestions as to what (optimization? enhancement?) changes this behaviour on
> AIX.
> 
> More importantly, is this equivalent output? If so, would something like shouldMatch (rather than shouldContain) be
> appropriate to allow the test to pass on AIX?
> 
> Thanks in advance for your help.
> Tyler

From jiefu at openjdk.java.net  Mon Feb 28 23:22:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Feb 2022 23:22:06 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <cFIjqCC21z0zuBA1cVbB6tmICu9JnUeox0KKsa6D4WM=.bc7afe8e-416e-4cc1-94fa-e0dcf8837ac2@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
 <cFIjqCC21z0zuBA1cVbB6tmICu9JnUeox0KKsa6D4WM=.bc7afe8e-416e-4cc1-94fa-e0dcf8837ac2@github.com>
Message-ID: <nuYnQdsyTElGlPoPviLMinglS6E8IC5Jrnr69Pn4SO4=.b5550638-fc68-4695-b1f3-cffd61cdb104@github.com>

On Mon, 28 Feb 2022 15:28:25 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Measurement with `rbp` as base:
> Throughput:
> https://bit.ly/3pnT9ms
> Latency:
> https://bit.ly/3tcJTTv

Should it be 3 cycles for `lea rax, [rbp + rcx + 0x8]` on Sandy Bridge according to Intel's manual?
But https://uica.uops.info/ shows it only 1 cycle.
So I'm a little confused.

Someone from Intel should take a look at this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Mon Feb 28 23:48:29 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 28 Feb 2022 23:48:29 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
Message-ID: <2OyaRp6UdLYtDJSJQash1i6Nfo4jriWELQA30ITrwIY=.ab68593c-de96-493f-a215-0be40cb69a36@github.com>

On Mon, 28 Feb 2022 12:01:31 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reviews

The tool measures the throughput of the operations, which is the number of cycles per iteration. Because the processor can execute multiple instructions at the same time, to measure the latency, you should create a dependency chain between the output of the instruction and its input in the next iteration. The technique used by uops.info is to `movsx` (which is an instruction that is not elided) from the output operand back to the input operand, so that the processor must wait for the result of the previous iteration before executing the next one, instead of executing multiple iterations concurrently when there is a lack of dependencies.

A simple `lea rax, [rbp + rcx + 0x8]; movsx rbp, eax` gives the throughput of 4 cycles, minus the latency of the `movsx` which is 1 gives you the documented latency of 3 (this is the latency between the output and the base operand, similar experiment will give the same answer for the latency between the output and the index operand).

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560