From sadayapalam at openjdk.java.net  Mon May  3 04:57:48 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 May 2021 04:57:48 GMT
Subject: [lworld] RFR: 8265423: [lworld] Provide experimental support for
 generating a single class file per primitive class [v2]
In-Reply-To: <tnYW9q774pPhYz2Xgjpi8DJO3OdWPU-iB5A9JdJ54Jo=.2f574146-7e39-4a98-a09d-2c03d69dc377@github.com>
References: <tnYW9q774pPhYz2Xgjpi8DJO3OdWPU-iB5A9JdJ54Jo=.2f574146-7e39-4a98-a09d-2c03d69dc377@github.com>
Message-ID: <9ULt962hAUbLZWVwrx6PFwO5ZSaMng8HIRzhA-sFLcY=.080ffa58-d284-4f2e-b1c8-b01539ba16e0@github.com>

> Use -XDunifiedValRefClass option to javac to get unified class file generation for primitive classes. Note: Javac will require some tweaks to consume such files, this is WIP.

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments to refactor common code pattern into a utility method

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/394/files
  - new: https://git.openjdk.java.net/valhalla/pull/394/files/d5bae7df..75632dcd

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

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

PR: https://git.openjdk.java.net/valhalla/pull/394


From sadayapalam at openjdk.java.net  Mon May  3 12:42:51 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 May 2021 12:42:51 GMT
Subject: [lworld] RFR: 8265423: [lworld] Provide experimental support for
 generating a single class file per primitive class [v3]
In-Reply-To: <tnYW9q774pPhYz2Xgjpi8DJO3OdWPU-iB5A9JdJ54Jo=.2f574146-7e39-4a98-a09d-2c03d69dc377@github.com>
References: <tnYW9q774pPhYz2Xgjpi8DJO3OdWPU-iB5A9JdJ54Jo=.2f574146-7e39-4a98-a09d-2c03d69dc377@github.com>
Message-ID: <xv14J3VBZnI-pjcznMMTjzFlD66zs6YYkOLXqUyZL8A=.c4d73bd6-71ee-47b9-a42b-f42f6c2c3bd4@github.com>

> Use -XDunifiedValRefClass option to javac to get unified class file generation for primitive classes. Note: Javac will require some tweaks to consume such files, this is WIP.

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Tests for experimental unified mode class generation for primitive classes

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/394/files
  - new: https://git.openjdk.java.net/valhalla/pull/394/files/75632dcd..5443d48c

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

  Stats: 566 lines in 6 files changed: 566 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/394.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/394/head:pull/394

PR: https://git.openjdk.java.net/valhalla/pull/394


From sadayapalam at openjdk.java.net  Mon May  3 12:42:52 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 May 2021 12:42:52 GMT
Subject: [lworld] Integrated: 8265423: [lworld] Provide experimental support
 for generating a single class file per primitive class
In-Reply-To: <tnYW9q774pPhYz2Xgjpi8DJO3OdWPU-iB5A9JdJ54Jo=.2f574146-7e39-4a98-a09d-2c03d69dc377@github.com>
References: <tnYW9q774pPhYz2Xgjpi8DJO3OdWPU-iB5A9JdJ54Jo=.2f574146-7e39-4a98-a09d-2c03d69dc377@github.com>
Message-ID: <WFTVGt23zKoofUahTzz71cmCXQbB6QrSAo7mGUsgeA8=.24c0d0f4-084e-420b-acff-9359f70e2bff@github.com>

On Tue, 27 Apr 2021 08:45:18 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Use -XDunifiedValRefClass option to javac to get unified class file generation for primitive classes. Note: Javac will require some tweaks to consume such files, this is WIP.

This pull request has now been integrated.

Changeset: 17b12ac7
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/17b12ac7e3169beff5fb7b0caa561d391a94c455
Stats:     623 lines in 14 files changed: 602 ins; 1 del; 20 mod

8265423: [lworld] Provide experimental support for generating a single class file per primitive class

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

PR: https://git.openjdk.java.net/valhalla/pull/394


From thartmann at openjdk.java.net  Mon May  3 14:54:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 3 May 2021 14:54:38 GMT
Subject: [lworld] RFR: 8265973: [lworld] C2 compilation fails due to infinite
 loop in PhaseIterGVN::optimize
Message-ID: <6sw5F4cpfk4q1UaTyOGsFZe9YmUfGmxsWvilyk_tr9I=.1d82abf8-3f99-4249-aa44-7cde6801245e@github.com>

This is another instance of [JDK-8264586](https://bugs.openjdk.java.net/browse/JDK-8264586). The fix was not sufficient. The root cause is a subgraph that becomes unreachable from the bottom (but remains reachable from the top) after CCP removes a redundant null check. 

**Gory details:**
CCP has two phases. First, `PhaseCCP::analyze` visits all nodes and updates their types in `_types.map`. Then, `PhaseCCP::do_transform` only visits the nodes that are reachable from the bottom, updates their `bottom_type` and adds them to the IGVN worklist. During the second step, parts of the graph might be cut off (for example, due to a null-check that is found to be redundant) and the nodes of that subgraph are not visited. I.e., the following code is not executed:
https://github.com/openjdk/valhalla/blob/28a4ec0249fd86fe17f2b816c6f5f8eed31abfeb/src/hotspot/share/opto/phaseX.cpp#L1988-L1992

As a result, `LoadNodes` in the dead subgraph end up with types that are inconsistent with their bottom types. Since they are still reachable from the top, they will be processed by IGVN and then re-enqueued for IGVN indefinitely by this code:
https://github.com/openjdk/valhalla/blob/28a4ec0249fd86fe17f2b816c6f5f8eed31abfeb/src/hotspot/share/opto/memnode.cpp#L352-L358

The fix is to aggressively remove useless nodes after CCP. I'll consider upstreaming the fix after some bake time in Valhalla.

Thanks,
Tobias

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

Commit messages:
 - Some fixes
 - 8265973: [lworld] C2 compilation fails due to infinite loop in PhaseIterGVN::optimize

Changes: https://git.openjdk.java.net/valhalla/pull/397/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=397&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265973
  Stats: 82 lines in 7 files changed: 64 ins; 8 del; 10 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/397.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/397/head:pull/397

PR: https://git.openjdk.java.net/valhalla/pull/397


From hseigel at openjdk.java.net  Mon May  3 19:02:18 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 3 May 2021 19:02:18 GMT
Subject: [lworld] RFR: 8266324: [lworld] [lw3] Component type of arrays of
 primitive objects incorrectly loaded at link time
In-Reply-To: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
References: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
Message-ID: <zjddIBpYkJ5DP0CcC1epwtjTdZ-Y6n7hspLGM367MyY=.6713e223-d5c6-44c9-a64a-2a09b57930f7@github.com>

On Thu, 29 Apr 2021 20:44:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix to prevent the VM from loading component types of arrays of primitive objects at link time.

Looks good!
Thanks, Harold

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

Marked as reviewed by hseigel (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/396


From lfoltan at openjdk.java.net  Mon May  3 20:04:13 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 3 May 2021 20:04:13 GMT
Subject: [lworld] RFR: 8266361: [lworld] [lw3] Experimental JNI APIs to
 access flattened arrays should be removed
In-Reply-To: <npr-T7j0Iu-U9PDYQGAG3zwTqSFZ4_r8NKSXpdXVXoY=.b0e0721f-80ad-4454-9b7f-eafd3e03b22a@github.com>
References: <npr-T7j0Iu-U9PDYQGAG3zwTqSFZ4_r8NKSXpdXVXoY=.b0e0721f-80ad-4454-9b7f-eafd3e03b22a@github.com>
Message-ID: <t-DR7Y95IGeWNmni415F7sOy9d_7CjPxMgZU7GqlR3M=.35401711-84b1-4796-bcae-a54a57812259@github.com>

On Fri, 30 Apr 2021 12:27:18 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Removing experimental JNI APIs for flattened arrays in preparation of the integration of the Valhalla code into the mainline.
> 
> Regards,
> 
> Fred

Looks good.
Lois

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

Marked as reviewed by lfoltan (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/398


From lfoltan at openjdk.java.net  Mon May  3 20:05:10 2021
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 3 May 2021 20:05:10 GMT
Subject: [lworld] RFR: 8266324: [lworld] [lw3] Component type of arrays of
 primitive objects incorrectly loaded at link time
In-Reply-To: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
References: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
Message-ID: <L9jcBPJo1ZrQvX_hzYhX9OiqOSKULNfSEEy71fNr6Pk=.77daf72c-e1fd-4c80-969b-c939aee1fc6b@github.com>

On Thu, 29 Apr 2021 20:44:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix to prevent the VM from loading component types of arrays of primitive objects at link time.

Looks good.
Lois

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

Marked as reviewed by lfoltan (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/396


From fparain at openjdk.java.net  Mon May  3 20:05:11 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 3 May 2021 20:05:11 GMT
Subject: [lworld] RFR: 8266324: [lworld] [lw3] Component type of arrays of
 primitive objects incorrectly loaded at link time
In-Reply-To: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
References: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
Message-ID: <FG5j0idd7nT2_UKPghRAgNhvjwZ5vnNatF1bi14JtpA=.a18b23d2-3c2d-483d-b833-984c7d457388@github.com>

On Thu, 29 Apr 2021 20:44:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix to prevent the VM from loading component types of arrays of primitive objects at link time.

Thank you Lois and Harold!

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/396


From fparain at openjdk.java.net  Mon May  3 20:05:11 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 3 May 2021 20:05:11 GMT
Subject: [lworld] Integrated: 8266324: [lworld] [lw3] Component type of arrays
 of primitive objects incorrectly loaded at link time
In-Reply-To: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
References: <2xI1nsp0s4rgjan9Wag_wu5evDYrpiRdEpPb0_1zxus=.1d1707b6-79da-4ee4-929e-5d0cda3c9fae@github.com>
Message-ID: <0o8TDY0rXso_snU_7Il1FptJ2wFXNDu5uUiCyglqZQg=.25655950-75f9-44d1-a557-619be3bf6fff@github.com>

On Thu, 29 Apr 2021 20:44:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix to prevent the VM from loading component types of arrays of primitive objects at link time.

This pull request has now been integrated.

Changeset: 93c4160f
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/93c4160f4c038eb2d7ed4712253a16b3b65413f2
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8266324: [lworld] [lw3] Component type of arrays of primitive objects incorrectly loaded at link time

Reviewed-by: hseigel, lfoltan

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

PR: https://git.openjdk.java.net/valhalla/pull/396


From fparain at openjdk.java.net  Mon May  3 20:09:10 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 3 May 2021 20:09:10 GMT
Subject: [lworld] RFR: 8266361: [lworld] [lw3] Experimental JNI APIs to
 access flattened arrays should be removed
In-Reply-To: <npr-T7j0Iu-U9PDYQGAG3zwTqSFZ4_r8NKSXpdXVXoY=.b0e0721f-80ad-4454-9b7f-eafd3e03b22a@github.com>
References: <npr-T7j0Iu-U9PDYQGAG3zwTqSFZ4_r8NKSXpdXVXoY=.b0e0721f-80ad-4454-9b7f-eafd3e03b22a@github.com>
Message-ID: <5kk6zbAf6f-HC0kmrfpcDTuMxc61CG5_ufcoMKP3290=.3cdf8d5e-720a-4ec4-b3f7-e2e0a9816950@github.com>

On Fri, 30 Apr 2021 12:27:18 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Removing experimental JNI APIs for flattened arrays in preparation of the integration of the Valhalla code into the mainline.
> 
> Regards,
> 
> Fred

Thank you Lois.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/398


From fparain at openjdk.java.net  Mon May  3 20:09:10 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 3 May 2021 20:09:10 GMT
Subject: [lworld] Integrated: 8266361: [lworld] [lw3] Experimental JNI APIs to
 access flattened arrays should be removed
In-Reply-To: <npr-T7j0Iu-U9PDYQGAG3zwTqSFZ4_r8NKSXpdXVXoY=.b0e0721f-80ad-4454-9b7f-eafd3e03b22a@github.com>
References: <npr-T7j0Iu-U9PDYQGAG3zwTqSFZ4_r8NKSXpdXVXoY=.b0e0721f-80ad-4454-9b7f-eafd3e03b22a@github.com>
Message-ID: <NscWq7VDIJgp-fAr8lBYWL9mBTE2b-Za6NpbiTEmylE=.6b532556-8606-4321-a241-969e8d2bf963@github.com>

On Fri, 30 Apr 2021 12:27:18 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Removing experimental JNI APIs for flattened arrays in preparation of the integration of the Valhalla code into the mainline.
> 
> Regards,
> 
> Fred

This pull request has now been integrated.

Changeset: c01d10b2
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c01d10b2a0d81aa9381e89f8cd2a52afee9fab86
Stats:     1997 lines in 10 files changed: 0 ins; 1996 del; 1 mod

8266361: [lworld] [lw3] Experimental JNI APIs to access flattened arrays should be removed

Reviewed-by: lfoltan

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

PR: https://git.openjdk.java.net/valhalla/pull/398


From dsimms at openjdk.java.net  Tue May  4 07:40:36 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 07:40:36 GMT
Subject: [lworld] Integrated: 8265720: [lworld] RedefineLeak.java is still
 problem listed
Message-ID: <RboGHd80XU4k37Lh2PhTX1ksg9acQe_NuQ0mcgzK-ro=.5bc55b3b-42d4-4bcd-bd45-df03f711929d@github.com>

Trivial delisting

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

Commit messages:
 - 8265720: [lworld] RedefineLeak.java is still problem listed

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

PR: https://git.openjdk.java.net/valhalla/pull/399


From dsimms at openjdk.java.net  Tue May  4 07:40:37 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 07:40:37 GMT
Subject: [lworld] Integrated: 8265720: [lworld] RedefineLeak.java is still
 problem listed
In-Reply-To: <RboGHd80XU4k37Lh2PhTX1ksg9acQe_NuQ0mcgzK-ro=.5bc55b3b-42d4-4bcd-bd45-df03f711929d@github.com>
References: <RboGHd80XU4k37Lh2PhTX1ksg9acQe_NuQ0mcgzK-ro=.5bc55b3b-42d4-4bcd-bd45-df03f711929d@github.com>
Message-ID: <IxQc-hJzUWZI13a3Y-vvEChC_ZR3LGHwz7jFXVvlxBc=.fd6f4453-47ca-4433-a6c1-ba6d1e4dbdab@github.com>

On Tue, 4 May 2021 07:35:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Trivial delisting

This pull request has now been integrated.

Changeset: d77a0d4c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d77a0d4cdd91d97f4d9fa7114a7da3fc83040056
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8265720: [lworld] RedefineLeak.java is still problem listed

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

PR: https://git.openjdk.java.net/valhalla/pull/399


From dsimms at openjdk.java.net  Tue May  4 09:27:20 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 09:27:20 GMT
Subject: [lworld] Integrated: 8265725: [lworld] Fix code in synchronizer.cpp
 after the merge
Message-ID: <4VcLblRijSlVz1VJhG5WFJY4eWxmy0SCv4zYvPt1Z0A=.ac0dba28-4784-449f-a17e-376c354b2373@github.com>

THREAD_AND_LOCATION macro make expansion to function more trouble than it is worth

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

Commit messages:
 - 8265725: [lworld] Fix code in synchronizer.cpp after the merge

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

PR: https://git.openjdk.java.net/valhalla/pull/400


From dsimms at openjdk.java.net  Tue May  4 09:27:20 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 09:27:20 GMT
Subject: [lworld] Integrated: 8265725: [lworld] Fix code in synchronizer.cpp
 after the merge
In-Reply-To: <4VcLblRijSlVz1VJhG5WFJY4eWxmy0SCv4zYvPt1Z0A=.ac0dba28-4784-449f-a17e-376c354b2373@github.com>
References: <4VcLblRijSlVz1VJhG5WFJY4eWxmy0SCv4zYvPt1Z0A=.ac0dba28-4784-449f-a17e-376c354b2373@github.com>
Message-ID: <L6jGuL8J9onZV7KAR7_ITgQ67EAod4SFVORVVGjr9LM=.50656a46-4b85-465f-b5be-6815a588592c@github.com>

On Tue, 4 May 2021 09:19:39 GMT, David Simms <dsimms at openjdk.org> wrote:

> THREAD_AND_LOCATION macro make expansion to function more trouble than it is worth

This pull request has now been integrated.

Changeset: b8712b3a
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b8712b3ad61bfee2cb87d6b99b890913408da017
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8265725: [lworld] Fix code in synchronizer.cpp after the merge

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

PR: https://git.openjdk.java.net/valhalla/pull/400


From dsimms at openjdk.java.net  Tue May  4 12:16:23 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 12:16:23 GMT
Subject: [lworld] RFR: [lworld] CDS tests fail after the merge with master
Message-ID: <azsToyLif_7kqB9_ezS2tsKbhEkraCj595pw015FC4Q=.047dea66-b545-4b42-b7e9-ac1bc9fae461@github.com>

Adjust the class list to also specify IdentityObject

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

Commit messages:
 - [lworld] CDS tests fail after the merge with master

Changes: https://git.openjdk.java.net/valhalla/pull/401/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=401&range=00
  Stats: 86 lines in 15 files changed: 16 ins; 38 del; 32 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/401.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/401/head:pull/401

PR: https://git.openjdk.java.net/valhalla/pull/401


From dsimms at openjdk.java.net  Tue May  4 15:03:47 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 15:03:47 GMT
Subject: git: openjdk/valhalla: lworld: 8265719: [lworld] CDS tests fail after
 the merge with master
Message-ID: <ef79ac8b-21f7-4ef1-9b1d-e1018aa7b61a@openjdk.org>

Changeset: 74dbd64e
Author:    David Simms <dsimms at openjdk.org>
Date:      2021-05-04 15:03:20 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/74dbd64e4577489843b992f43ae1f8104762c328

8265719: [lworld] CDS tests fail after the merge with master

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedMirrorTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/CheckCachedResolvedReferences.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatA.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatD.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatE.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/HelloCustom.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/LoaderSegregationTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ParallelTestBase.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/PrintSharedArchiveAndExit.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/ProtectionDomain.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/SameNameInTwoLoadersTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnintendedLoadersTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java
! test/hotspot/jtreg/runtime/cds/appcds/jvmti/transformRelatedClasses/TransformRelatedClassesAppCDS.java



From dsimms at openjdk.java.net  Tue May  4 15:06:15 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 4 May 2021 15:06:15 GMT
Subject: [lworld] Integrated: 8265719: [lworld] CDS tests fail after the merge
 with master
In-Reply-To: <azsToyLif_7kqB9_ezS2tsKbhEkraCj595pw015FC4Q=.047dea66-b545-4b42-b7e9-ac1bc9fae461@github.com>
References: <azsToyLif_7kqB9_ezS2tsKbhEkraCj595pw015FC4Q=.047dea66-b545-4b42-b7e9-ac1bc9fae461@github.com>
Message-ID: <SKFF0aWkO28-K5bczourMUNyXWDbdE-g1DF0U702Z6U=.9fa4bf9f-11d2-4295-9770-810c3835605b@github.com>

On Tue, 4 May 2021 12:11:06 GMT, David Simms <dsimms at openjdk.org> wrote:

> Adjust the class list to also specify IdentityObject

This pull request has now been integrated.

Changeset: 74dbd64e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/74dbd64e4577489843b992f43ae1f8104762c328
Stats:     86 lines in 15 files changed: 16 ins; 38 del; 32 mod

8265719: [lworld] CDS tests fail after the merge with master

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

PR: https://git.openjdk.java.net/valhalla/pull/401


From thartmann at openjdk.java.net  Wed May  5 09:20:27 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 5 May 2021 09:20:27 GMT
Subject: [lworld] RFR: 8265973: [lworld] C2 compilation fails due to
 infinite loop in PhaseIterGVN::optimize [v2]
In-Reply-To: <6sw5F4cpfk4q1UaTyOGsFZe9YmUfGmxsWvilyk_tr9I=.1d82abf8-3f99-4249-aa44-7cde6801245e@github.com>
References: <6sw5F4cpfk4q1UaTyOGsFZe9YmUfGmxsWvilyk_tr9I=.1d82abf8-3f99-4249-aa44-7cde6801245e@github.com>
Message-ID: <J7bsFV_C4eP_nEaSc3SzTy3-6Yf3Y7idv66Rsg44aUU=.946d4f5c-2639-43a5-996b-8a3b49eaf32d@github.com>

> This is another instance of [JDK-8264586](https://bugs.openjdk.java.net/browse/JDK-8264586). The fix was not sufficient. The root cause is a subgraph that becomes unreachable from the bottom (but remains reachable from the top) after CCP removes a redundant null check. 
> 
> **Gory details:**
> CCP has two phases. First, `PhaseCCP::analyze` visits all nodes and updates their types in `_types.map`. Then, `PhaseCCP::do_transform` only visits the nodes that are reachable from the bottom, updates their `bottom_type` and adds them to the IGVN worklist. During the second step, parts of the graph might be cut off (for example, due to a null-check that is found to be redundant) and the nodes of that subgraph are not visited. I.e., the following code is not executed:
> https://github.com/openjdk/valhalla/blob/28a4ec0249fd86fe17f2b816c6f5f8eed31abfeb/src/hotspot/share/opto/phaseX.cpp#L1988-L1992
> 
> As a result, `LoadNodes` in the dead subgraph end up with types that are inconsistent with their bottom types. Since they are still reachable from the top, they will be processed by IGVN and then re-enqueued for IGVN indefinitely by this code:
> https://github.com/openjdk/valhalla/blob/28a4ec0249fd86fe17f2b816c6f5f8eed31abfeb/src/hotspot/share/opto/memnode.cpp#L352-L358
> 
> The fix is to aggressively remove useless nodes after CCP. I'll consider upstreaming the fix after some bake time in Valhalla.
> 
> Thanks,
> Tobias

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

  Make sure safepoints are visited by PhaseCCP

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/397/files
  - new: https://git.openjdk.java.net/valhalla/pull/397/files/710c485a..be8812c9

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

  Stats: 26 lines in 3 files changed: 16 ins; 3 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/397.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/397/head:pull/397

PR: https://git.openjdk.java.net/valhalla/pull/397


From dsimms at openjdk.java.net  Wed May  5 17:26:09 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 5 May 2021 17:26:09 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <exyaQCYhVFWFrDx2f7pyiF9_Pn798AZC-hHXnE4ai48=.6dc48ecb-d799-4f03-b796-8951130d0b14@github.com>

Merge jdk at 20210505

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

Commit messages:
 - Logical merge fixes
 - Merge branch 'master' into lworld_merge_20210505
 - 8266453: Shenandoah: Disable write protections before patching nmethod in nmethod_barrier on MacOSX/AArch64
 - 8266497: Remove unnecessary EMCP liveness indication
 - 8266498: Make debug ps() call print_stack
 - 8266499: Delete dead code in aarch64.ad
 - 8266522: Shenandoah: Shenandoah LRB calls wrong runtime barrier on aarch64
 - 8266506: [aix] Treat mapping attempt too close to BRK as a mapping error
 - 8266419: [aix] in mmap mode, os::attempt_reserve_memory_at() fails to handle wrong mapping address
 - 8266222: [aix] In mmap-mode, partial releases with os::release_memory may trash internal bookkeeping
 - ... and 254 more: https://git.openjdk.java.net/valhalla/compare/74dbd64e...ce90f9e7

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=402&range=00.0
 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=402&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/402/files
  Stats: 529736 lines in 4358 files changed: 32243 ins; 489857 del; 7636 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/402/head:pull/402

PR: https://git.openjdk.java.net/valhalla/pull/402


From fparain at openjdk.java.net  Wed May  5 20:04:18 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 5 May 2021 20:04:18 GMT
Subject: [lworld] RFR: 8266582: [lworld] [lw3] C1 should have a flag to
 control use of delayed reads of flattened fields
Message-ID: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>

Trivial change to control the delayed read of nested flattened fields in C1.

Fred

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

Commit messages:
 - Merge remote-tracking branch 'upstream/lworld' into c1_delayed_flag
 - Fix typo
 - Add flag to control delayed flattened field reads in C1

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

PR: https://git.openjdk.java.net/valhalla/pull/403


From dsimms at openjdk.java.net  Thu May  6 06:34:08 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 6 May 2021 06:34:08 GMT
Subject: [lworld] RFR: 8266582: [lworld] [lw3] C1 should have a flag to
 control use of delayed reads of flattened fields
In-Reply-To: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
References: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
Message-ID: <8EEwXBXpvj2M3eOChpj6G_c99FZjsPoE09BdC_rX7A0=.07936f5c-a271-4c0f-bdd8-5bab0d909c5e@github.com>

On Wed, 5 May 2021 19:58:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Trivial change to control the delayed read of nested flattened fields in C1.
> 
> Fred

Looks fine to me

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

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/403


From dsimms at openjdk.java.net  Thu May  6 06:56:02 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 6 May 2021 06:56:02 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <exyaQCYhVFWFrDx2f7pyiF9_Pn798AZC-hHXnE4ai48=.6dc48ecb-d799-4f03-b796-8951130d0b14@github.com>
References: <exyaQCYhVFWFrDx2f7pyiF9_Pn798AZC-hHXnE4ai48=.6dc48ecb-d799-4f03-b796-8951130d0b14@github.com>
Message-ID: <O8fNX60K9mAPXp3qvxJaS9A51KpIewJB5irdXqRnLiI=.412082c4-f500-429b-9839-8edbebf7b6d0@github.com>

> Merge jdk at 20210505

David Simms has updated the pull request incrementally with seven additional commits since the last revision:

 - Adjust CDS class list in test
 - Merge commit '138d573c3567e9a51b1ac2b1de89b41c4b51ae93' into lworld_merge_20210505
 - 8262392: Update Mesa 3-D Headers to version 21.0.3
   
   Reviewed-by: serb, jdv, kcr
 - 8266505: Cleanup LibraryCallKit::make_unsafe_address()
   
   Reviewed-by: roland, kvn
 - 8266504: Remove leftovers from BarrierSetAssemblerC1
   
   Reviewed-by: thartmann
 - 8259316: [REDO] C1/C2 compiler support for blackholes
   
   Reviewed-by: vlivanov, kvn, iignatyev
 - 8250766: javadoc adds redundant spaces when @see program element is wrapped
   
   Reviewed-by: prappo

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/402/files
  - new: https://git.openjdk.java.net/valhalla/pull/402/files/ce90f9e7..b60a6625

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

  Stats: 1456 lines in 50 files changed: 1332 ins; 63 del; 61 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/402/head:pull/402

PR: https://git.openjdk.java.net/valhalla/pull/402


From thartmann at openjdk.java.net  Thu May  6 09:01:28 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 May 2021 09:01:28 GMT
Subject: [lworld] Integrated: 8265973: [lworld] C2 compilation fails due to
 infinite loop in PhaseIterGVN::optimize
In-Reply-To: <6sw5F4cpfk4q1UaTyOGsFZe9YmUfGmxsWvilyk_tr9I=.1d82abf8-3f99-4249-aa44-7cde6801245e@github.com>
References: <6sw5F4cpfk4q1UaTyOGsFZe9YmUfGmxsWvilyk_tr9I=.1d82abf8-3f99-4249-aa44-7cde6801245e@github.com>
Message-ID: <xKoFjLAK9-sYRW4DlwPVYQrK-Uchj7UyQ4ltj_xZVa8=.0d2f3a3a-6713-47aa-a28a-69e42c600297@github.com>

On Fri, 30 Apr 2021 12:26:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is another instance of [JDK-8264586](https://bugs.openjdk.java.net/browse/JDK-8264586). The fix was not sufficient. The root cause is a subgraph that becomes unreachable from the bottom (but remains reachable from the top) after CCP removes a redundant null check. 
> 
> **Gory details:**
> CCP has two phases. First, `PhaseCCP::analyze` visits all nodes and updates their types in `_types.map`. Then, `PhaseCCP::do_transform` only visits the nodes that are reachable from the bottom, updates their `bottom_type` and adds them to the IGVN worklist. During the second step, parts of the graph might be cut off (for example, due to a null-check that is found to be redundant) and the nodes of that subgraph are not visited. I.e., the following code is not executed:
> https://github.com/openjdk/valhalla/blob/28a4ec0249fd86fe17f2b816c6f5f8eed31abfeb/src/hotspot/share/opto/phaseX.cpp#L1988-L1992
> 
> As a result, `LoadNodes` in the dead subgraph end up with types that are inconsistent with their bottom types. Since they are still reachable from the top, they will be processed by IGVN and then re-enqueued for IGVN indefinitely by this code:
> https://github.com/openjdk/valhalla/blob/28a4ec0249fd86fe17f2b816c6f5f8eed31abfeb/src/hotspot/share/opto/memnode.cpp#L352-L358
> 
> The fix is to aggressively remove useless nodes after CCP. I'll consider upstreaming the fix after some bake time in Valhalla.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: f43fafc7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f43fafc7d81f3d34f6e971765dbadae41ae5c393
Stats:     106 lines in 7 files changed: 80 ins; 11 del; 15 mod

8265973: [lworld] C2 compilation fails due to infinite loop in PhaseIterGVN::optimize

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

PR: https://git.openjdk.java.net/valhalla/pull/397


From thartmann at openjdk.java.net  Thu May  6 09:11:24 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 May 2021 09:11:24 GMT
Subject: [lworld] RFR: 8266582: [lworld] [lw3] C1 should have a flag to
 control use of delayed reads of flattened fields
In-Reply-To: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
References: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
Message-ID: <y2rHXUQbJzYf-wrQvsdE2_XltYQti-uQ1w9uBwjVjps=.c94c3a44-b130-467c-b37a-0d1f7dd5ba2e@github.com>

On Wed, 5 May 2021 19:58:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Trivial change to control the delayed read of nested flattened fields in C1.
> 
> Fred

Marked as reviewed by thartmann (Committer).

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

PR: https://git.openjdk.java.net/valhalla/pull/403


From thartmann at openjdk.java.net  Thu May  6 08:58:11 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 May 2021 08:58:11 GMT
Subject: git: openjdk/valhalla: lworld: 8265973: [lworld] C2 compilation fails
 due to infinite loop in PhaseIterGVN::optimize
Message-ID: <ca36f182-99fe-46a6-9b04-d7e47f8dfc3a@openjdk.org>

Changeset: f43fafc7
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-05-06 08:57:48 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f43fafc7d81f3d34f6e971765dbadae41ae5c393

8265973: [lworld] C2 compilation fails due to infinite loop in PhaseIterGVN::optimize

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/inlinetypenode.cpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/phaseX.hpp
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestGenerated.java



From fparain at openjdk.java.net  Thu May  6 12:06:16 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 May 2021 12:06:16 GMT
Subject: [lworld] RFR: 8266582: [lworld] [lw3] C1 should have a flag to
 control use of delayed reads of flattened fields
In-Reply-To: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
References: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
Message-ID: <9ofa2vqG8z_QK6reEeOoPYrCJED_V-qo7775K5lVXPI=.2b9b3d2d-dd25-4c08-9786-5bdbd1ac16a0@github.com>

On Wed, 5 May 2021 19:58:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Trivial change to control the delayed read of nested flattened fields in C1.
> 
> Fred

Tobias, Mr Simms,

Thank you for the reviews.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/403


From fparain at openjdk.java.net  Thu May  6 12:06:17 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 May 2021 12:06:17 GMT
Subject: [lworld] Integrated: 8266582: [lworld] [lw3] C1 should have a flag to
 control use of delayed reads of flattened fields
In-Reply-To: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
References: <Tcd0kNyMlZ58Nu7XXF_zJY5F4U4pGzZZyjPc6xz-8Lo=.eecb848d-e188-47d3-8ef8-3ee1b50a436e@github.com>
Message-ID: <dYT1EYNu7iu8QQPg1IPUx4Z_8OPDHXU518ldhU4DQxw=.37022bc0-8a7d-47aa-9a7c-b6852a77af36@github.com>

On Wed, 5 May 2021 19:58:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Trivial change to control the delayed read of nested flattened fields in C1.
> 
> Fred

This pull request has now been integrated.

Changeset: b7478179
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b7478179e4f96ffd82b9b5e0d7f807e25fb2769e
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8266582: [lworld] [lw3] C1 should have a flag to control use of delayed reads of flattened fields

Reviewed-by: dsimms, thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/403


From fparain at openjdk.java.net  Thu May  6 13:07:42 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 May 2021 13:07:42 GMT
Subject: [lworld] RFR: 8266586: [lworld] [lw3] Remove experimental support for
 primitive classes in JPDA
Message-ID: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>

Remove experimental support for primitive classes in Java debugger in anticipation of a merge with mainline.
At some point the whole JPDA (JDI/JDWP/JVMTI) will have to be updated (specifications and implementations) to fully support primitive classes.

Regards,

Fred

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

Commit messages:
 - More cleanup
 - Merge remote-tracking branch 'upstream/lworld' into jpda_cleanup
 - Remove experimental primitive class support in JPDA

Changes: https://git.openjdk.java.net/valhalla/pull/404/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=404&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266586
  Stats: 246 lines in 12 files changed: 0 ins; 236 del; 10 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/404.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/404/head:pull/404

PR: https://git.openjdk.java.net/valhalla/pull/404


From dsimms at openjdk.java.net  Thu May  6 13:11:08 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 6 May 2021 13:11:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <exyaQCYhVFWFrDx2f7pyiF9_Pn798AZC-hHXnE4ai48=.6dc48ecb-d799-4f03-b796-8951130d0b14@github.com>
References: <exyaQCYhVFWFrDx2f7pyiF9_Pn798AZC-hHXnE4ai48=.6dc48ecb-d799-4f03-b796-8951130d0b14@github.com>
Message-ID: <o0dSi-TBxGSOkncWWWhTLg3YqesPlv9RWTujuDGFfjM=.c8f99ea4-5c99-460f-99e9-52d879d874c3@github.com>

On Wed, 5 May 2021 17:09:48 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk at 20210505

This pull request has now been integrated.

Changeset: 65578e15
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/65578e15eb494f3dbfc0cc45e2671ad45df9cafa
Stats:     531183 lines in 4392 files changed: 33573 ins; 489920 del; 7690 mod

Merge jdk

Merge jdk at 20210505

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

PR: https://git.openjdk.java.net/valhalla/pull/402


From dsimms at openjdk.java.net  Thu May  6 13:30:02 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 6 May 2021 13:30:02 GMT
Subject: [lworld] RFR: 8266586: [lworld] [lw3] Remove experimental support
 for primitive classes in JPDA
In-Reply-To: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
References: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
Message-ID: <2p_z25jTfuWUcB8MxUM7xaGqw0hAdIfBZO3w6ikWNp4=.d0897428-26fa-49e0-9f96-261304813945@github.com>

On Thu, 6 May 2021 13:01:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove experimental support for primitive classes in Java debugger in anticipation of a merge with mainline.
> At some point the whole JPDA (JDI/JDWP/JVMTI) will have to be updated (specifications and implementations) to fully support primitive classes.
> 
> Regards,
> 
> Fred

Looks good

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

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/404


From fparain at openjdk.java.net  Thu May  6 14:12:37 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 May 2021 14:12:37 GMT
Subject: [lworld] RFR: 8266586: [lworld] [lw3] Remove experimental support
 for primitive classes in JPDA [v2]
In-Reply-To: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
References: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
Message-ID: <19HZMg9mGd_yrxajuslch_QZlAW55gEJYeczCYD6rMQ=.b5c3f3fc-f379-4041-b6dc-c087f6ee4a70@github.com>

> Remove experimental support for primitive classes in Java debugger in anticipation of a merge with mainline.
> At some point the whole JPDA (JDI/JDWP/JVMTI) will have to be updated (specifications and implementations) to fully support primitive classes.
> 
> Regards,
> 
> Fred

Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge lworld
 - More cleanup
 - Merge remote-tracking branch 'upstream/lworld' into jpda_cleanup
 - Remove experimental primitive class support in JPDA

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

Changes: https://git.openjdk.java.net/valhalla/pull/404/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=404&range=01
  Stats: 245 lines in 11 files changed: 0 ins; 236 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/404.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/404/head:pull/404

PR: https://git.openjdk.java.net/valhalla/pull/404


From fparain at openjdk.java.net  Thu May  6 14:21:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 May 2021 14:21:22 GMT
Subject: [lworld] RFR: 8266586: [lworld] [lw3] Remove experimental support
 for primitive classes in JPDA [v2]
In-Reply-To: <19HZMg9mGd_yrxajuslch_QZlAW55gEJYeczCYD6rMQ=.b5c3f3fc-f379-4041-b6dc-c087f6ee4a70@github.com>
References: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
 <19HZMg9mGd_yrxajuslch_QZlAW55gEJYeczCYD6rMQ=.b5c3f3fc-f379-4041-b6dc-c087f6ee4a70@github.com>
Message-ID: <f-cp66D_Gpj4poVhxXuNtvbQrZUZ1OW2rhckjR6H03s=.b326a326-adba-436a-81b9-5611bd421b05@github.com>

On Thu, 6 May 2021 14:12:37 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Remove experimental support for primitive classes in Java debugger in anticipation of a merge with mainline.
>> At some point the whole JPDA (JDI/JDWP/JVMTI) will have to be updated (specifications and implementations) to fully support primitive classes.
>> 
>> Regards,
>> 
>> Fred
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge lworld
>  - More cleanup
>  - Merge remote-tracking branch 'upstream/lworld' into jpda_cleanup
>  - Remove experimental primitive class support in JPDA

Thank you for the review.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/404


From fparain at openjdk.java.net  Thu May  6 14:21:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 May 2021 14:21:22 GMT
Subject: [lworld] Integrated: 8266586: [lworld] [lw3] Remove experimental
 support for primitive classes in JPDA
In-Reply-To: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
References: <cNCJJoE9jdFce3LVSeeTmrMuuBLAz4NyI2tVV5cKVXY=.cf81c11d-8a43-423b-bd27-0e65dceb4080@github.com>
Message-ID: <5MMQKKA8vNUMVWG0vXe06dw_pkXd3hNJUm3smLf5j2w=.4b35fa23-ffa4-45d5-b9b8-f52eb13b5dfe@github.com>

On Thu, 6 May 2021 13:01:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Remove experimental support for primitive classes in Java debugger in anticipation of a merge with mainline.
> At some point the whole JPDA (JDI/JDWP/JVMTI) will have to be updated (specifications and implementations) to fully support primitive classes.
> 
> Regards,
> 
> Fred

This pull request has now been integrated.

Changeset: ab997be2
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ab997be25794f650e4a22fc9b5499f18bb0b61cb
Stats:     245 lines in 11 files changed: 0 ins; 236 del; 9 mod

8266586: [lworld] [lw3] Remove experimental support for primitive classes in JPDA

Reviewed-by: dsimms

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

PR: https://git.openjdk.java.net/valhalla/pull/404


From thartmann at openjdk.java.net  Fri May  7 08:21:30 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 7 May 2021 08:21:30 GMT
Subject: [lworld] RFR: 8266709: [lworld]
 compiler/valhalla/inlinetypes/TestLWorldProfiling.java fails after merge
Message-ID: <s40QTHXJ8HTkbzmiQrZCLQ1U_VKf-L3iTakvOCgeK8Q=.c1dccd8b-571b-407a-bff7-0c764ebba623@github.com>

Compilation levels mirrored from `CompilerWhiteBoxTest.java` need to be updated after removal of AOT.

Best regards,
Tobias

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

Commit messages:
 - 8266709: [lworld] compiler/valhalla/inlinetypes/TestLWorldProfiling.java fails after merge

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

PR: https://git.openjdk.java.net/valhalla/pull/405


From thartmann at openjdk.java.net  Fri May  7 08:28:08 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 7 May 2021 08:28:08 GMT
Subject: [lworld] Integrated: 8266709: [lworld]
 compiler/valhalla/inlinetypes/TestLWorldProfiling.java fails after merge
In-Reply-To: <s40QTHXJ8HTkbzmiQrZCLQ1U_VKf-L3iTakvOCgeK8Q=.c1dccd8b-571b-407a-bff7-0c764ebba623@github.com>
References: <s40QTHXJ8HTkbzmiQrZCLQ1U_VKf-L3iTakvOCgeK8Q=.c1dccd8b-571b-407a-bff7-0c764ebba623@github.com>
Message-ID: <PiJ5mTbVF0UHeBy3S2Babw6XnViwqDfPEWAMHzirl1s=.626336ee-7980-4dd1-8c24-b1c4ffd71232@github.com>

On Fri, 7 May 2021 08:15:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Compilation levels mirrored from `CompilerWhiteBoxTest.java` need to be updated after removal of AOT.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 716b530e
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/716b530e0527a7de27a6719c3d9c68a6242001e8
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8266709: [lworld] compiler/valhalla/inlinetypes/TestLWorldProfiling.java fails after merge

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

PR: https://git.openjdk.java.net/valhalla/pull/405


From thartmann at openjdk.java.net  Fri May  7 09:17:29 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 7 May 2021 09:17:29 GMT
Subject: [lworld] RFR: 8266712: [lworld]
 compiler/loopstripmining/DeadNodesInOuterLoopAtLoopCloning.java fails after
 merge
Message-ID: <C0o_JF__y0PWVxF5z1cm874n1905k65dGaGIkSzOcQw=.a45a9f6e-fc01-4425-9d99-02925d689fec@github.com>

[JDK-8189802](https://bugs.openjdk.java.net/browse/JDK-8189802) weakened the conditions for calling `can_see_stored_value` from `StoreNode::Identity` (see http://hg.openjdk.java.net/valhalla/valhalla/rev/b826402f953a#l16.35). New code added by [JDK-8263972](https://bugs.openjdk.java.net/browse/JDK-8263972) needs to be adjusted accordingly.

Best regards,
Tobias

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

Commit messages:
 - 8266712: [lworld] compiler/loopstripmining/DeadNodesInOuterLoopAtLoopCloning.java fails after merge

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

PR: https://git.openjdk.java.net/valhalla/pull/406


From sadayapalam at openjdk.java.net  Fri May  7 09:34:27 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 7 May 2021 09:34:27 GMT
Subject: [lworld] RFR: 8266710: [lworld]
 tools/javac/valhalla/lworld-values/EnhancedForLoopTest.java fails after merge
Message-ID: <7AEVwHEkL3FDcSMQhjVytz9WpCP9g66MgQFgdSXdhsk=.efd3720b-eb1b-49ef-be72-9e5ddb5363bc@github.com>

Fix call to asSuper to operate on reference projection.

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

Commit messages:
 - 8266710: tools/javac/valhalla/lworld-values/EnhancedForLoopTest.java fails after merge

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

PR: https://git.openjdk.java.net/valhalla/pull/407


From thartmann at openjdk.java.net  Fri May  7 09:35:18 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 7 May 2021 09:35:18 GMT
Subject: [lworld] Integrated: 8266712: [lworld]
 compiler/loopstripmining/DeadNodesInOuterLoopAtLoopCloning.java fails after
 merge
In-Reply-To: <C0o_JF__y0PWVxF5z1cm874n1905k65dGaGIkSzOcQw=.a45a9f6e-fc01-4425-9d99-02925d689fec@github.com>
References: <C0o_JF__y0PWVxF5z1cm874n1905k65dGaGIkSzOcQw=.a45a9f6e-fc01-4425-9d99-02925d689fec@github.com>
Message-ID: <9dJ-dfcDgcUPNQE7k6B5CiLH9oPRY3svB32g4DdXrt4=.35ecf7d1-e87b-40a5-b2ae-127ac7a52077@github.com>

On Fri, 7 May 2021 09:12:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8189802](https://bugs.openjdk.java.net/browse/JDK-8189802) weakened the conditions for calling `can_see_stored_value` from `StoreNode::Identity` (see http://hg.openjdk.java.net/valhalla/valhalla/rev/b826402f953a#l16.35). New code added by [JDK-8263972](https://bugs.openjdk.java.net/browse/JDK-8263972) needs to be adjusted accordingly.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: e2b66fce
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e2b66fcea64bac04460c2dc02d4f48e1f8b4fe81
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8266712: [lworld] compiler/loopstripmining/DeadNodesInOuterLoopAtLoopCloning.java fails after merge

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

PR: https://git.openjdk.java.net/valhalla/pull/406


From sadayapalam at openjdk.java.net  Fri May  7 09:38:15 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 7 May 2021 09:38:15 GMT
Subject: [lworld] Integrated: 8266710: [lworld]
 tools/javac/valhalla/lworld-values/EnhancedForLoopTest.java fails after merge
In-Reply-To: <7AEVwHEkL3FDcSMQhjVytz9WpCP9g66MgQFgdSXdhsk=.efd3720b-eb1b-49ef-be72-9e5ddb5363bc@github.com>
References: <7AEVwHEkL3FDcSMQhjVytz9WpCP9g66MgQFgdSXdhsk=.efd3720b-eb1b-49ef-be72-9e5ddb5363bc@github.com>
Message-ID: <akdKCbitsWYORAJxDIPr1PfIg2Rk2v6Vbx3QPUROgr0=.303a83b2-16d0-4f5f-b311-dd5c36577b01@github.com>

On Fri, 7 May 2021 09:28:23 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Fix call to asSuper to operate on reference projection.

This pull request has now been integrated.

Changeset: c8d7c826
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c8d7c8260921ccb2b2e72dcc6cc04144ff7649fc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8266710: [lworld] tools/javac/valhalla/lworld-values/EnhancedForLoopTest.java fails after merge

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

PR: https://git.openjdk.java.net/valhalla/pull/407


From dsimms at openjdk.java.net  Mon May 10 13:30:36 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 May 2021 13:30:36 GMT
Subject: RFR: Merge lworld
Message-ID: <-Dl48yXveZfyzxsTg_sddq2O7-nF7OplyrFBiey1LqM=.38efa192-34fb-4981-bc65-e7417119de1e@github.com>

Merge fixes from lworld into lqagain

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

Commit messages:
 - 8266710: [lworld] tools/javac/valhalla/lworld-values/EnhancedForLoopTest.java fails after merge
 - 8266712: [lworld] compiler/loopstripmining/DeadNodesInOuterLoopAtLoopCloning.java fails after merge
 - 8266709: [lworld] compiler/valhalla/inlinetypes/TestLWorldProfiling.java fails after merge

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/valhalla/pull/408/files
  Stats: 6 lines in 3 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/408.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/408/head:pull/408

PR: https://git.openjdk.java.net/valhalla/pull/408


From dsimms at openjdk.java.net  Mon May 10 13:47:57 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 May 2021 13:47:57 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <-Dl48yXveZfyzxsTg_sddq2O7-nF7OplyrFBiey1LqM=.38efa192-34fb-4981-bc65-e7417119de1e@github.com>
References: <-Dl48yXveZfyzxsTg_sddq2O7-nF7OplyrFBiey1LqM=.38efa192-34fb-4981-bc65-e7417119de1e@github.com>
Message-ID: <nNk26fAXszpc15qp2wmQb6rFlaMxhesG0oE2IXsDV5Q=.54c45be3-2dec-4971-96a7-c002e47e18bf@github.com>

> Merge fixes from lworld into lqagain

David Simms 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.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/408/files
  - new: https://git.openjdk.java.net/valhalla/pull/408/files/c8d7c826..c8d7c826

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

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

PR: https://git.openjdk.java.net/valhalla/pull/408


From dsimms at openjdk.java.net  Mon May 10 13:47:58 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 May 2021 13:47:58 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <-Dl48yXveZfyzxsTg_sddq2O7-nF7OplyrFBiey1LqM=.38efa192-34fb-4981-bc65-e7417119de1e@github.com>
References: <-Dl48yXveZfyzxsTg_sddq2O7-nF7OplyrFBiey1LqM=.38efa192-34fb-4981-bc65-e7417119de1e@github.com>
Message-ID: <p-uHEpHKR0xdgi6dPqOPfMbUyQZBnGrPj-UdFCutieo=.e971c671-4da2-42e7-bc10-3a448621dd10@github.com>

On Mon, 10 May 2021 11:52:38 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge fixes from lworld into lqagain

This pull request has now been integrated.

Changeset: 4de6a484
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4de6a4848e4c1852b0bbe085f757903967d48a1e
Stats:     6 lines in 3 files changed: 0 ins; 3 del; 3 mod

Merge lworld

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

PR: https://git.openjdk.java.net/valhalla/pull/408


From fparain at openjdk.java.net  Mon May 10 14:25:31 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 May 2021 14:25:31 GMT
Subject: Integrated: First set of changes to initiate the transition to the
 L/Q model
Message-ID: <hB4KUSmFKhdP2PwEQGcFk56or3OzJOlQ_3usPn3eMZc=.646e255d-2f20-462a-88e5-0a4202344a71@github.com>

Here's a first set of changes to migrate the code base to the L/Q model again.
Changes are in the runtime, the interpreter, CI and C1.
The changeset also activates the mode in javac that generates a single class file per primitive class (instead of two).
Changes allow a reasonable number of test in runtime/valhalla/inlinetypes to pass with -XX:TieredStopAtLevel=1 but some tests are failing, mainly because of missing changes in array code and C2.

Fred

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

Commit messages:
 - Merge remote-tracking branch 'upstream/lqagain' into lq_firststep
 - First set of changes to transition to the L/Q model

Changes: https://git.openjdk.java.net/valhalla/pull/409/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=409&range=00
  Stats: 149 lines in 33 files changed: 83 ins; 1 del; 65 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/409.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/409/head:pull/409

PR: https://git.openjdk.java.net/valhalla/pull/409


From fparain at openjdk.java.net  Mon May 10 14:25:33 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 May 2021 14:25:33 GMT
Subject: Integrated: First set of changes to initiate the transition to the
 L/Q model
In-Reply-To: <hB4KUSmFKhdP2PwEQGcFk56or3OzJOlQ_3usPn3eMZc=.646e255d-2f20-462a-88e5-0a4202344a71@github.com>
References: <hB4KUSmFKhdP2PwEQGcFk56or3OzJOlQ_3usPn3eMZc=.646e255d-2f20-462a-88e5-0a4202344a71@github.com>
Message-ID: <5oJKPPCgLtIc-SekXNz6u3YID3v1P33zyl4tRrgxJdY=.22e1be2d-5cfb-46ed-a9d0-3a64ccb1f355@github.com>

On Mon, 10 May 2021 14:16:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Here's a first set of changes to migrate the code base to the L/Q model again.
> Changes are in the runtime, the interpreter, CI and C1.
> The changeset also activates the mode in javac that generates a single class file per primitive class (instead of two).
> Changes allow a reasonable number of test in runtime/valhalla/inlinetypes to pass with -XX:TieredStopAtLevel=1 but some tests are failing, mainly because of missing changes in array code and C2.
> 
> Fred

This pull request has now been integrated.

Changeset: adff6884
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/adff6884c8647e6263127e2616d32da8c569672e
Stats:     149 lines in 33 files changed: 83 ins; 1 del; 65 mod

First set of changes to initiate the transition to the L/Q model

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

PR: https://git.openjdk.java.net/valhalla/pull/409


From dsimms at openjdk.java.net  Mon May 10 16:42:12 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 May 2021 16:42:12 GMT
Subject: Integrated: Merge lworld
Message-ID: <zPeiJbFikfJ0PLfH1XvCAcCwQnI6GVSuVOyenWssDsA=.b6e3da6e-f09c-4daf-8b41-f6a38c0695a1@github.com>

Merge lworld into universal-tvars

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

Commit messages:


The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

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

PR: https://git.openjdk.java.net/valhalla/pull/410


From dsimms at openjdk.java.net  Mon May 10 16:42:15 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 May 2021 16:42:15 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <zPeiJbFikfJ0PLfH1XvCAcCwQnI6GVSuVOyenWssDsA=.b6e3da6e-f09c-4daf-8b41-f6a38c0695a1@github.com>
References: <zPeiJbFikfJ0PLfH1XvCAcCwQnI6GVSuVOyenWssDsA=.b6e3da6e-f09c-4daf-8b41-f6a38c0695a1@github.com>
Message-ID: <EWCt0VRtilBMQz3vvVcMQxW4c0GfJm4gLHp4RE7X18s=.7864f117-8f90-4218-9a0e-914b5d60235b@github.com>

On Mon, 10 May 2021 16:32:51 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge lworld into universal-tvars

This pull request has now been integrated.

Changeset: e8e33390
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e8e333902aa51afd3e6f13842a981400aaa14ee3
Stats:     534338 lines in 4443 files changed: 34353 ins; 492207 del; 7778 mod

Merge lworld

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

PR: https://git.openjdk.java.net/valhalla/pull/410


From mandy.chung at oracle.com  Mon May 10 19:26:33 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 May 2021 12:26:33 -0700
Subject: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass
Message-ID: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>

Hidden classes were added in Java SE 15. Class data support was added in 
16. `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15 and 
deprecated for terminally removal in JDK 16.

I propose to remove `sun.misc.Unsafe::defineAnonymousClass` from JDK 17:
CSR: https://bugs.openjdk.java.net/browse/JDK-8266760

Comments?

Mandy


From forax at univ-mlv.fr  Mon May 10 19:36:03 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 10 May 2021 21:36:03 +0200 (CEST)
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
Message-ID: <132617846.862177.1620675363150.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Lundi 10 Mai 2021 21:26:33
> Objet: Review CSR JDK-8266760: Remove sun.misc.Unsafe::defineAnonymousClass

> Hidden classes were added in Java SE 15. Class data support was added in
> 16. `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15 and
> deprecated for terminally removal in JDK 16.
> 
> I propose to remove `sun.misc.Unsafe::defineAnonymousClass` from JDK 17:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8266760
> 
> Comments?

Do it.

I will be brave and not cry too much :)

> 
> Mandy

R?mi


From paul.sandoz at oracle.com  Mon May 10 21:27:07 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 10 May 2021 21:27:07 +0000
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
Message-ID: <BC0BBB8B-408E-436D-B2C0-E735E2E4B290@oracle.com>

Looks good, I took the liberty of making some minor edits, mostly fixing some typos.

Paul.

> On May 10, 2021, at 12:26 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Hidden classes were added in Java SE 15. Class data support was added in 16. `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15 and deprecated for terminally removal in JDK 16.
> 
> I propose to remove `sun.misc.Unsafe::defineAnonymousClass` from JDK 17:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8266760
> 
> Comments?
> 
> Mandy



From mandy.chung at oracle.com  Mon May 10 23:03:02 2021
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 10 May 2021 16:03:02 -0700
Subject: Review CSR JDK-8266760: Remove
 sun.misc.Unsafe::defineAnonymousClass
In-Reply-To: <BC0BBB8B-408E-436D-B2C0-E735E2E4B290@oracle.com>
References: <07d57bb9-1787-b86a-0009-d7690745986c@oracle.com>
 <BC0BBB8B-408E-436D-B2C0-E735E2E4B290@oracle.com>
Message-ID: <86151eab-7beb-1e56-a389-1860cbd8e554@oracle.com>

Thank you all.

Mandy

On 5/10/21 2:27 PM, Paul Sandoz wrote:
> Looks good, I took the liberty of making some minor edits, mostly fixing some typos.
>
> Paul.
>
>> On May 10, 2021, at 12:26 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>
>> Hidden classes were added in Java SE 15. Class data support was added in 16. `sun.misc.Unsafe::defineAnonymousClass` was deprecated in JDK 15 and deprecated for terminally removal in JDK 16.
>>
>> I propose to remove `sun.misc.Unsafe::defineAnonymousClass` from JDK 17:
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8266760
>>
>> Comments?
>>
>> Mandy



From dsimms at openjdk.java.net  Tue May 11 13:17:14 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 May 2021 13:17:14 GMT
Subject: RFR: Initial runtime arrays support for L or Q type
Message-ID: <NBClIKkvEZt48ZHOud13aZOJn0TodtME27NW8If1Z3w=.2202d6ba-9cbc-4497-bdc1-0ebae6212ea3@github.com>

Added InlineKlass::null_free_inline_array_klass() akin to Klass::array_klass()
but specifically for Q class descriptors, with a separate chain for array klass
for Q-type arrays.

TODO: metadata visitor and cleanup for the new chain of Q-type array classes

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

Commit messages:
 - Initial runtime arrays support for L or Q type

Changes: https://git.openjdk.java.net/valhalla/pull/411/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=411&range=00
  Stats: 128 lines in 12 files changed: 58 ins; 27 del; 43 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/411.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/411/head:pull/411

PR: https://git.openjdk.java.net/valhalla/pull/411


From fparain at openjdk.java.net  Tue May 11 13:36:50 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 11 May 2021 13:36:50 GMT
Subject: Integrated: Implement type restrictions on method arguments in the
 callee
Message-ID: <wnvBJn9AlYYcRymty70SnUFOTSBrgPF05Fk3ygbph3U=.88042b8c-d9b2-41d6-ac05-2b051cd05066@github.com>

Implement type restrictions on method arguments in the callee (instead of the caller) in both the interpreter and C1.

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

Commit messages:
 - Fix tabs in unit test
 - File cleanup and simplification of TR checks.
 - Move argument TR checks to callee (interpreter and C1)
 - Add support for unloaded case and many fixes
 - Partial support for RestrictedMethod in C1

Changes: https://git.openjdk.java.net/valhalla/pull/412/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=412&range=00
  Stats: 199 lines in 16 files changed: 124 ins; 32 del; 43 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/412.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/412/head:pull/412

PR: https://git.openjdk.java.net/valhalla/pull/412


From fparain at openjdk.java.net  Tue May 11 13:36:52 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 11 May 2021 13:36:52 GMT
Subject: Integrated: Implement type restrictions on method arguments in the
 callee
In-Reply-To: <wnvBJn9AlYYcRymty70SnUFOTSBrgPF05Fk3ygbph3U=.88042b8c-d9b2-41d6-ac05-2b051cd05066@github.com>
References: <wnvBJn9AlYYcRymty70SnUFOTSBrgPF05Fk3ygbph3U=.88042b8c-d9b2-41d6-ac05-2b051cd05066@github.com>
Message-ID: <jEHjcoyQkX319A6XjzBnJnrBs3M-p0DaCc5Z5F4wahA=.da7ef4a0-defa-4d24-85be-4e81eb0363cc@github.com>

On Tue, 11 May 2021 13:16:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Implement type restrictions on method arguments in the callee (instead of the caller) in both the interpreter and C1.

This pull request has now been integrated.

Changeset: 63e0ebf4
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/63e0ebf484190516990c91663671ab12515c888b
Stats:     199 lines in 16 files changed: 124 ins; 32 del; 43 mod

Implement type restrictions on method arguments in the callee

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

PR: https://git.openjdk.java.net/valhalla/pull/412


From andvasp at gmail.com  Wed May 12 02:51:04 2021
From: andvasp at gmail.com (Anderson Vasconcelos Pires)
Date: Tue, 11 May 2021 23:51:04 -0300
Subject: Alternative to the suffix .val and .ref in JEP 401: Primitive Objects
Message-ID: <CACB8oqWxhiutEJ04Gmn81kP-EyVpYat11vFaNFDSm0w55Ci18A@mail.gmail.com>

Hi guys,

I saw Michael Kuhlmann's e-mail [1] where he quotes:

"The suffixes .ref and .val don't fit into our concept of class names, they
look ugly and can easily be mixed up."

I have no complaints about them. But I believe it would be better, *if
possible*, not to use them.

I believe it would be better to use the operator "?" instead of .ref.
because it can be used when the "null safety" feature comes to Java. :)

If it is necessary to represent the .val, the operator "!" could be a
possibility to help.

Probably this has already been discussed, but unfortunately is not so easy
to find out in the archives e-mail.

The maximum I found out was the e-mail [2] from Stephen Colebourne
scolebourne at joda.org where he mentioned the use of these symbols.

Just let me (maybe the community) at least know if the suffix is going to
be used because of a matter of preference or other reason.

[1]
https://mail.openjdk.java.net/pipermail/valhalla-dev/2021-April/008872.html
[2]
https://mail.openjdk.java.net/pipermail/valhalla-spec-comments/2016-April/000000.html

Kind regards,
Anderson.


From dsimms at openjdk.java.net  Wed May 12 06:29:18 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 12 May 2021 06:29:18 GMT
Subject: Integrated: Initial runtime arrays support for L or Q type
In-Reply-To: <NBClIKkvEZt48ZHOud13aZOJn0TodtME27NW8If1Z3w=.2202d6ba-9cbc-4497-bdc1-0ebae6212ea3@github.com>
References: <NBClIKkvEZt48ZHOud13aZOJn0TodtME27NW8If1Z3w=.2202d6ba-9cbc-4497-bdc1-0ebae6212ea3@github.com>
Message-ID: <JqAvQHSK0ZmDMUc5vI1K2fU9XmkNZjLJUg7TAVWg7-Y=.71439872-4bad-439c-b624-e1bec063ddaf@github.com>

On Tue, 11 May 2021 13:10:54 GMT, David Simms <dsimms at openjdk.org> wrote:

> Added InlineKlass::null_free_inline_array_klass() akin to Klass::array_klass()
> but specifically for Q class descriptors, with a separate chain for array klass
> for Q-type arrays.
> 
> TODO: metadata visitor and cleanup for the new chain of Q-type array classes

This pull request has now been integrated.

Changeset: a6f937bb
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a6f937bb19739572b305a8380e7feb1b08548c0f
Stats:     128 lines in 12 files changed: 58 ins; 27 del; 43 mod

Initial runtime arrays support for L or Q type

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

PR: https://git.openjdk.java.net/valhalla/pull/411


From forax at univ-mlv.fr  Wed May 12 13:46:33 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 12 May 2021 15:46:33 +0200 (CEST)
Subject: Alternative to the suffix .val and .ref in JEP 401: Primitive
 Objects
In-Reply-To: <CACB8oqWxhiutEJ04Gmn81kP-EyVpYat11vFaNFDSm0w55Ci18A@mail.gmail.com>
References: <CACB8oqWxhiutEJ04Gmn81kP-EyVpYat11vFaNFDSm0w55Ci18A@mail.gmail.com>
Message-ID: <228108382.2155686.1620827193015.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Anderson Vasconcelos Pires" <andvasp at gmail.com>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Mercredi 12 Mai 2021 04:51:04
> Objet: Alternative to the suffix .val and .ref in JEP 401: Primitive Objects

> Hi guys,

Hi

> 
> I saw Michael Kuhlmann's e-mail [1] where he quotes:
> 
> "The suffixes .ref and .val don't fit into our concept of class names, they
> look ugly and can easily be mixed up."
> 
> I have no complaints about them. But I believe it would be better, *if
> possible*, not to use them.
> 
> I believe it would be better to use the operator "?" instead of .ref.
> because it can be used when the "null safety" feature comes to Java. :)
> 
> If it is necessary to represent the .val, the operator "!" could be a
> possibility to help.
> 
> Probably this has already been discussed, but unfortunately is not so easy
> to find out in the archives e-mail.

We have used the notation V? in the past, the JVMS language submit 2019 was the point were we decide to stop using it for different reasons, here is a kind of summary why  
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2019-August/001096.html

More recently, we have explored the fact that some primitive classes may still want to be nullable, allowing null to be assigned to a variable of type Foo.val,
this obviously does not work well is Foo.val is written Foo!

So dividing ref/val types along the axis of the nullabbility is a kind of dead end.

[...]

> Kind regards,
> Anderson.

regards,
R?mi


From brian.goetz at oracle.com  Wed May 12 14:09:48 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 12 May 2021 10:09:48 -0400
Subject: Alternative to the suffix .val and .ref in JEP 401: Primitive
 Objects
In-Reply-To: <CACB8oqWxhiutEJ04Gmn81kP-EyVpYat11vFaNFDSm0w55Ci18A@mail.gmail.com>
References: <CACB8oqWxhiutEJ04Gmn81kP-EyVpYat11vFaNFDSm0w55Ci18A@mail.gmail.com>
Message-ID: <4b00379e-5f2b-e5f8-fb47-f8f9b86046af@oracle.com>



On 5/11/2021 10:51 PM, Anderson Vasconcelos Pires wrote:
> Hi guys,
>
> I saw Michael Kuhlmann's e-mail [1] where he quotes:
>
> "The suffixes .ref and .val don't fit into our concept of class names, they
> look ugly and can easily be mixed up."
>
> I have no complaints about them. But I believe it would be better, *if
> possible*, not to use them.

I know this isn't what you meant, but it is definitely better not to use 
them if they can be avoided!? The design of the feature works hard to 
minimize the cases where someone actually has to say .ref or .val; these 
are escape hatches that most users should not use regularly.

> I believe it would be better to use the operator "?" instead of .ref.
> because it can be used when the "null safety" feature comes to Java. :)

We have discussed this extensively, but the reasons you cite are exactly 
why we *cannot* use `?` here, and that is -- because it means something 
else.? Ref/val refer to how the object is stored (flat vs indirect), not 
to its value set.? But by calling it `Foo?`, it would be almost 
impossible for users to see this as anything other than non-nullable 
Foo.? But identity classes, such as ArrayList, cannot be flattened (they 
need their identity for mutation), and yet the notion of "non-nullable 
reference to ArrayList" makes perfect sense.? So while `?` and `ref` 
seem to have a lot in common, they are not the same thing, and trying to 
pun them together would only be confusing.




From andvasp at gmail.com  Thu May 13 01:25:25 2021
From: andvasp at gmail.com (Anderson Vasconcelos Pires)
Date: Wed, 12 May 2021 22:25:25 -0300
Subject: Alternative to the suffix .val and .ref in JEP 401: Primitive
 Objects
In-Reply-To: <4b00379e-5f2b-e5f8-fb47-f8f9b86046af@oracle.com>
References: <CACB8oqWxhiutEJ04Gmn81kP-EyVpYat11vFaNFDSm0w55Ci18A@mail.gmail.com>
 <4b00379e-5f2b-e5f8-fb47-f8f9b86046af@oracle.com>
Message-ID: <CACB8oqXGfk+0DoVLPffRfbSJt0pE4XL8Fk35j5Axhmc_05eGRg@mail.gmail.com>

Thank you Remi and Brian!

Understood. val / ref makes the concept clearer.

Is the 401/402 JEPs available for testing in the valhalla repository?

Thanks,
Anderson.

On Wed, May 12, 2021 at 11:09 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> On 5/11/2021 10:51 PM, Anderson Vasconcelos Pires wrote:
> > Hi guys,
> >
> > I saw Michael Kuhlmann's e-mail [1] where he quotes:
> >
> > "The suffixes .ref and .val don't fit into our concept of class names,
> they
> > look ugly and can easily be mixed up."
> >
> > I have no complaints about them. But I believe it would be better, *if
> > possible*, not to use them.
>
> I know this isn't what you meant, but it is definitely better not to use
> them if they can be avoided!  The design of the feature works hard to
> minimize the cases where someone actually has to say .ref or .val; these
> are escape hatches that most users should not use regularly.
>
> > I believe it would be better to use the operator "?" instead of .ref.
> > because it can be used when the "null safety" feature comes to Java. :)
>
> We have discussed this extensively, but the reasons you cite are exactly
> why we *cannot* use `?` here, and that is -- because it means something
> else.  Ref/val refer to how the object is stored (flat vs indirect), not
> to its value set.  But by calling it `Foo?`, it would be almost
> impossible for users to see this as anything other than non-nullable
> Foo.  But identity classes, such as ArrayList, cannot be flattened (they
> need their identity for mutation), and yet the notion of "non-nullable
> reference to ArrayList" makes perfect sense.  So while `?` and `ref`
> seem to have a lot in common, they are not the same thing, and trying to
> pun them together would only be confusing.
>
>
>


From fparain at openjdk.java.net  Mon May 17 13:41:30 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 17 May 2021 13:41:30 GMT
Subject: RFR: 8266931: [lworld] [lw3] Test InlineTypeArrays.java fails because
 of incorrect instanceof behavior
Message-ID: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>

Fix super types of null-free arrays of primitive classes ([LFoo; must be present in the list of super types of [QFoo;).

Fred

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

Commit messages:
 - Fix supers of null-free arrays of primitive classes

Changes: https://git.openjdk.java.net/valhalla/pull/413/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=413&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266931
  Stats: 49 lines in 4 files changed: 25 ins; 6 del; 18 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/413.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/413/head:pull/413

PR: https://git.openjdk.java.net/valhalla/pull/413


From dsimms at openjdk.java.net  Mon May 17 14:09:22 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 17 May 2021 14:09:22 GMT
Subject: RFR: 8266931: [lworld] [lw3] Test InlineTypeArrays.java fails
 because of incorrect instanceof behavior
In-Reply-To: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>
References: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>
Message-ID: <I1gfk62e1DNeemdWoYco37v-c2oiItNHlFcISD_jvrM=.156eacc2-4b27-4bf1-bbd9-c651f11c8ef6@github.com>

On Mon, 17 May 2021 13:34:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix super types of null-free arrays of primitive classes ([LFoo; must be present in the list of super types of [QFoo;).
> 
> Fred

Looks good, nice catch

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

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/413


From fparain at openjdk.java.net  Mon May 17 14:32:15 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 17 May 2021 14:32:15 GMT
Subject: RFR: 8266931: [lworld] [lw3] Test InlineTypeArrays.java fails
 because of incorrect instanceof behavior
In-Reply-To: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>
References: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>
Message-ID: <W3f0zRmuFMwy4lyMHz2QsNki4VmGOxJamOmqf8TCUxM=.8d6eabf5-de0a-486e-a53d-1b09155457a3@github.com>

On Mon, 17 May 2021 13:34:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix super types of null-free arrays of primitive classes ([LFoo; must be present in the list of super types of [QFoo;).
> 
> Fred

Mr Simms,

Thank you for the review.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/413


From fparain at openjdk.java.net  Mon May 17 14:32:16 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 17 May 2021 14:32:16 GMT
Subject: Integrated: 8266931: [lworld] [lw3] Test InlineTypeArrays.java fails
 because of incorrect instanceof behavior
In-Reply-To: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>
References: <KkpmJMrxKWVw-IBuJrKXg3TUCkeWkyWeQCX1zuaaQ7I=.75a72a04-fd19-401e-ac0c-5f3151ec71d2@github.com>
Message-ID: <_9WwyswWaAu2rh5ll82KNNSQtJlnMHEwjjXaaj3FEG8=.11997cc5-af24-4b20-9da5-81a44e3bd02c@github.com>

On Mon, 17 May 2021 13:34:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix super types of null-free arrays of primitive classes ([LFoo; must be present in the list of super types of [QFoo;).
> 
> Fred

This pull request has now been integrated.

Changeset: ac1feac3
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ac1feac3ae302273ae62705f22225b0ad344cdc6
Stats:     49 lines in 4 files changed: 25 ins; 6 del; 18 mod

8266931: [lworld] [lw3] Test InlineTypeArrays.java fails because of incorrect instanceof behavior

Reviewed-by: dsimms

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

PR: https://git.openjdk.java.net/valhalla/pull/413


From zjx001202 at gmail.com  Tue May 18 10:22:09 2021
From: zjx001202 at gmail.com (Glavo)
Date: Tue, 18 May 2021 18:22:09 +0800
Subject: The feasibility of unifying the void as type
Message-ID: <CAJL5A3m9wF5c4GhweoRnyt1fhjVKM-x05EX1pMYyL0KqA8U7QA@mail.gmail.com>

I know that up to now, the void is not a type in JLS, but it also has many
similar features.

In Valhalla, it seems that the void can be implemented as a special
primitive class, so that it will be more useful in generic code (e.g.
`Task<void>`, `Function<T, void>`), and it is easier to be optimized by the
compiler than the current `java.lang.Void`.

I want to know the feasibility of this idea and the problems it may bring,
because this proposal seems very attractive.


From brian.goetz at oracle.com  Tue May 18 15:22:38 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 18 May 2021 11:22:38 -0400
Subject: The feasibility of unifying the void as type
In-Reply-To: <CAJL5A3m9wF5c4GhweoRnyt1fhjVKM-x05EX1pMYyL0KqA8U7QA@mail.gmail.com>
References: <CAJL5A3m9wF5c4GhweoRnyt1fhjVKM-x05EX1pMYyL0KqA8U7QA@mail.gmail.com>
Message-ID: <f26c4a08-a4b4-8dd1-8278-35449010a9df@oracle.com>

You are correct that it seems possible, and that this idea has many 
attractive aspects.? For example, we may be able to unify everything 
under one `Function` type:

 ??? interface IntFunction<T> extends Function<int, T> { }
 ??? interface ToIntFunction<T> extends Function<T, int> { }
 ??? interface Consumer<T> extends Function<T, void> { }
 ??? interface Runnable extends Function<void, void> { }

For another, we may be able to unify switch expressions and switch 
statements, where a switch statement is a void switch expression.

So the opportunities are very attractive; the devil is in the details.? 
There is much JLS to be combed through, to evaluate whether we can align 
these concepts.? (For example, we currently make a distinction between 
void-compatible and value-compatible lambdas in overload selection; if 
these merge, would this result in incompatible changes to overload 
selection decisions?)

So this has been "on the list to investigate" for a long time, and we're 
hopefully soon coming to the point where we can do so.

On 5/18/2021 6:22 AM, Glavo wrote:
> I know that up to now, the void is not a type in JLS, but it also has many
> similar features.
>
> In Valhalla, it seems that the void can be implemented as a special
> primitive class, so that it will be more useful in generic code (e.g.
> `Task<void>`, `Function<T, void>`), and it is easier to be optimized by the
> compiler than the current `java.lang.Void`.
>
> I want to know the feasibility of this idea and the problems it may bring,
> because this proposal seems very attractive.



From fparain at openjdk.java.net  Tue May 18 19:13:55 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 18 May 2021 19:13:55 GMT
Subject: RFR: L/Q again, step two
Message-ID: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>

Please review this second set of fixes for the L/Q transition.
A few changes in C1, most changes in CI.
CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).

With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).

Thank you,

Fred

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

Commit messages:
 - Remove useless statement
 - Merge remote-tracking branch 'upstream/lqagain' into lq_steptwo
 - Second set of fixes, focus on CI/C1

Changes: https://git.openjdk.java.net/valhalla/pull/414/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=414&range=00
  Stats: 62 lines in 11 files changed: 41 ins; 4 del; 17 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/414.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/414/head:pull/414

PR: https://git.openjdk.java.net/valhalla/pull/414


From github.com+828220+forax at openjdk.java.net  Tue May 18 19:58:28 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 18 May 2021 19:58:28 GMT
Subject: RFR: L/Q again, step two
In-Reply-To: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
Message-ID: <ytreYxMstudkRABEedr0eoxo04CQ4jVE_Fnn7ZYqYdc=.c990e152-765b-495f-8d24-2fed2d9adff7@github.com>

On Tue, 18 May 2021 19:00:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this second set of fixes for the L/Q transition.
> A few changes in C1, most changes in CI.
> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
> 
> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
> 
> Thank you,
> 
> Fred

test/hotspot/jtreg/runtime/valhalla/inlinetypes/MultiANewArrayTest/MultiANewArrayTest.java line 52:

> 50:             ex = e;
> 51:         }
> 52:         Asserts.assertNull(ex, "No ICCE should have been thrown");

The negation of "An ICCE should have been thrown" is "No error should have been thrown",
talking about ICCE it that context can be misleading.

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Tue May 18 21:02:41 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 18 May 2021 21:02:41 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <ytreYxMstudkRABEedr0eoxo04CQ4jVE_Fnn7ZYqYdc=.c990e152-765b-495f-8d24-2fed2d9adff7@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <ytreYxMstudkRABEedr0eoxo04CQ4jVE_Fnn7ZYqYdc=.c990e152-765b-495f-8d24-2fed2d9adff7@github.com>
Message-ID: <GmUyQEbITiuc_8lMGB9N2ZveT7J7X1KJhopERA6sRD4=.bedd6148-be16-433a-b70a-4cc72b6e3ee7@github.com>

On Tue, 18 May 2021 19:54:34 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change error message in test
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/MultiANewArrayTest/MultiANewArrayTest.java line 52:
> 
>> 50:             ex = e;
>> 51:         }
>> 52:         Asserts.assertNull(ex, "No ICCE should have been thrown");
> 
> The negation of "An ICCE should have been thrown" is "No error should have been thrown",
> talking about ICCE it that context can be misleading.

Error message updated in the last commit.

Thanks,

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Tue May 18 21:02:40 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 18 May 2021 21:02:40 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
Message-ID: <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>

> Please review this second set of fixes for the L/Q transition.
> A few changes in C1, most changes in CI.
> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
> 
> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Change error message in test

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/414/files
  - new: https://git.openjdk.java.net/valhalla/pull/414/files/1c436083..e88d8a79

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

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From dsimms at openjdk.java.net  Wed May 19 08:06:47 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 19 May 2021 08:06:47 GMT
Subject: RFR: CDS support for InlineKlass::null_free_array_klasses() &
 corrected modifiers
Message-ID: <9eLlrLhLbMHElq9sS6c-1PpigO5u0ZKZljSrr8qtXGM=.4c52ebba-1760-47ec-be9b-e037480dc1e3@github.com>

Filled in the initial L/Q array TODO missing items

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

Commit messages:
 - CDS support for InlineKlass::null_free_array_klasses() & corrected modifiers

Changes: https://git.openjdk.java.net/valhalla/pull/415/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=415&range=00
  Stats: 84 lines in 4 files changed: 65 ins; 12 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/415.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/415/head:pull/415

PR: https://git.openjdk.java.net/valhalla/pull/415


From dsimms at openjdk.java.net  Wed May 19 08:07:56 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 19 May 2021 08:07:56 GMT
Subject: Integrated: CDS support for InlineKlass::null_free_array_klasses() &
 corrected modifiers
In-Reply-To: <9eLlrLhLbMHElq9sS6c-1PpigO5u0ZKZljSrr8qtXGM=.4c52ebba-1760-47ec-be9b-e037480dc1e3@github.com>
References: <9eLlrLhLbMHElq9sS6c-1PpigO5u0ZKZljSrr8qtXGM=.4c52ebba-1760-47ec-be9b-e037480dc1e3@github.com>
Message-ID: <ALqbifcg4AndIHlp15jjvxg5zhdhGg50BG1C5nTEVEc=.e1480347-f0fb-43b2-9f14-f594767d7871@github.com>

On Wed, 19 May 2021 08:00:49 GMT, David Simms <dsimms at openjdk.org> wrote:

> Filled in the initial L/Q array TODO missing items

This pull request has now been integrated.

Changeset: 671a3461
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/671a3461fd8d5e5d649eaa42237154315b57d671
Stats:     84 lines in 4 files changed: 65 ins; 12 del; 7 mod

CDS support for InlineKlass::null_free_array_klasses() & corrected modifiers

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

PR: https://git.openjdk.java.net/valhalla/pull/415


From dsimms at openjdk.java.net  Wed May 19 08:43:32 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 19 May 2021 08:43:32 GMT
Subject: RFR: Rename nullfree to null_free
Message-ID: <TPJrJLTAmWu5s0KQ6CCfsQIxAD4DKNZhh9t_HCRG62Q=.a4b80733-e3af-4bda-b9f6-16847e350fcb@github.com>

Renamed nullfree to null_free

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

Commit messages:
 - Rename nullfree to null_free

Changes: https://git.openjdk.java.net/valhalla/pull/416/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=416&range=00
  Stats: 46 lines in 12 files changed: 0 ins; 2 del; 44 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/416.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/416/head:pull/416

PR: https://git.openjdk.java.net/valhalla/pull/416


From dsimms at openjdk.java.net  Wed May 19 09:07:44 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 19 May 2021 09:07:44 GMT
Subject: Integrated: Rename nullfree to null_free
In-Reply-To: <TPJrJLTAmWu5s0KQ6CCfsQIxAD4DKNZhh9t_HCRG62Q=.a4b80733-e3af-4bda-b9f6-16847e350fcb@github.com>
References: <TPJrJLTAmWu5s0KQ6CCfsQIxAD4DKNZhh9t_HCRG62Q=.a4b80733-e3af-4bda-b9f6-16847e350fcb@github.com>
Message-ID: <VS-JD5Q-cn9NxM7681k_Yh5AEfYxutiMeQ_g6XUfosM=.f10631be-f6ea-40f5-9083-a788d4a5a05d@github.com>

On Wed, 19 May 2021 08:37:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Renamed nullfree to null_free

This pull request has now been integrated.

Changeset: 68419170
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/684191705df79110da8f5420898e66d046b47b1f
Stats:     46 lines in 12 files changed: 0 ins; 2 del; 44 mod

Rename nullfree to null_free

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

PR: https://git.openjdk.java.net/valhalla/pull/416


From ngasson at openjdk.java.net  Wed May 19 10:05:17 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 19 May 2021 10:05:17 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
Message-ID: <isAgEUeFfA-fClLKqmsgTePtOQPla1zRN61jrU8uRMM=.42da73eb-a283-4800-a49d-7e3dff12c2bf@github.com>

On Tue, 18 May 2021 21:02:40 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this second set of fixes for the L/Q transition.
>> A few changes in C1, most changes in CI.
>> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
>> 
>> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
>> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change error message in test

src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp line 313:

> 311: 
> 312: NewObjectArrayStub::NewObjectArrayStub(LIR_Opr klass_reg, LIR_Opr length, LIR_Opr result,
> 313:                                        CodeEmitInfo* info, bool is_null_free) {

Would you mind making the same change in `c1_CodeStubs_aarch64.cpp` to keep them in sync?

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 12:12:37 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 12:12:37 GMT
Subject: RFR: L/Q again, step two [v3]
In-Reply-To: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
Message-ID: <TXgtfTutcq3_ZvFG9ciR2dp3HQcNIMRhkXp0EeDTWcY=.b96f0e59-2520-43ed-9220-63d3a3e6d99b@github.com>

> Please review this second set of fixes for the L/Q transition.
> A few changes in C1, most changes in CI.
> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
> 
> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Apply changes to the aarch54 file

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/414/files
  - new: https://git.openjdk.java.net/valhalla/pull/414/files/e88d8a79..01fb4956

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

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 12:12:40 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 12:12:40 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <isAgEUeFfA-fClLKqmsgTePtOQPla1zRN61jrU8uRMM=.42da73eb-a283-4800-a49d-7e3dff12c2bf@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
 <isAgEUeFfA-fClLKqmsgTePtOQPla1zRN61jrU8uRMM=.42da73eb-a283-4800-a49d-7e3dff12c2bf@github.com>
Message-ID: <ox2mi3_weu2fqC0UdUzlS4v7RwpQ682PvPfqJB54XQk=.0c3b2fb0-4051-4b1b-a202-b891d7220b4a@github.com>

On Wed, 19 May 2021 10:02:22 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change error message in test
>
> src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp line 313:
> 
>> 311: 
>> 312: NewObjectArrayStub::NewObjectArrayStub(LIR_Opr klass_reg, LIR_Opr length, LIR_Opr result,
>> 313:                                        CodeEmitInfo* info, bool is_null_free) {
> 
> Would you mind making the same change in `c1_CodeStubs_aarch64.cpp` to keep them in sync?

Sure, sorry for the breakage of the aarch64 platform.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From thartmann at openjdk.java.net  Wed May 19 12:19:54 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 May 2021 12:19:54 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
Message-ID: <lIWIRPxlfF0iQ_NXUiaayFoNUVKL2YbAf2T71F2q4iU=.34a4d5a3-4082-4919-9cb6-b2ee0eef6e47@github.com>

On Tue, 18 May 2021 21:02:40 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this second set of fixes for the L/Q transition.
>> A few changes in C1, most changes in CI.
>> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
>> 
>> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
>> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change error message in test

Looks good to me. Added some minor comments.

src/hotspot/share/ci/ciArrayKlass.cpp line 124:

> 122:         } else {
> 123:           if (ak != NULL && ak->is_flatArray_klass()) {
> 124:             is_array_flattened = true;

Why is that boolean needed? Can't we simply return `ciFlatArrayKlass::make(klass)` here?

src/hotspot/share/ci/ciArrayKlass.cpp line 134:

> 132:       }
> 133:     } else {
> 134:       return ciEnv::unloaded_ciobjarrayklass();

Can't we delegate handling the unloaded case to `ciObjArrayKlass::make(klass)` below? I.e. check for `if (null_free && klass->is_loaded())` above.

src/hotspot/share/ci/ciEnv.cpp line 478:

> 476:     if (elem_klass != NULL && elem_klass->is_loaded()) {
> 477:       // Now make an array for it
> 478:       bool null_free_array = sym->is_Q_array_signature() && sym->char_at(1) == JVM_SIGNATURE_INLINE_TYPE;

Why do we need the `sym->char_at(1) == JVM_SIGNATURE_INLINE_TYPE` check? Isn't that part of `is_Q_array_signature()`?

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

Changes requested by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 13:05:00 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 13:05:00 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <lIWIRPxlfF0iQ_NXUiaayFoNUVKL2YbAf2T71F2q4iU=.34a4d5a3-4082-4919-9cb6-b2ee0eef6e47@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
 <lIWIRPxlfF0iQ_NXUiaayFoNUVKL2YbAf2T71F2q4iU=.34a4d5a3-4082-4919-9cb6-b2ee0eef6e47@github.com>
Message-ID: <EZZXkPxJY6rYAVI8kvaQ1AzU4eGScrja3BecTQ_MlSg=.2b069a07-4b1d-432c-a2bb-45f6e38ee503@github.com>

On Wed, 19 May 2021 12:12:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change error message in test
>
> src/hotspot/share/ci/ciEnv.cpp line 478:
> 
>> 476:     if (elem_klass != NULL && elem_klass->is_loaded()) {
>> 477:       // Now make an array for it
>> 478:       bool null_free_array = sym->is_Q_array_signature() && sym->char_at(1) == JVM_SIGNATURE_INLINE_TYPE;
> 
> Why do we need the `sym->char_at(1) == JVM_SIGNATURE_INLINE_TYPE` check? Isn't that part of `is_Q_array_signature()`?

The problem with is_Q_array_signature() is that it returns true for arrays of any dimension with the last dimension element klass being a null-free primitive class. It returns true for [QFoo; but also for [[[QFoo;. But for the [[[QFoo; array, the first two dimensions are regular nullable object arrays, only the last array is a null-free array (possibly flattened).

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 13:15:19 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 13:15:19 GMT
Subject: RFR: L/Q again, step two [v4]
In-Reply-To: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
Message-ID: <K7u1yPb3IULiRKQFPjoZkjdYB4ZGgNMVHtbCI6c6z6A=.ff674197-96bb-4881-94b8-0d67f0039099@github.com>

> Please review this second set of fixes for the L/Q transition.
> A few changes in C1, most changes in CI.
> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
> 
> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Refactor ciArrayKlass::make()

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/414/files
  - new: https://git.openjdk.java.net/valhalla/pull/414/files/01fb4956..bd779242

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

  Stats: 23 lines in 1 file changed: 2 ins; 11 del; 10 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/414.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/414/head:pull/414

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 13:15:24 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 13:15:24 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <lIWIRPxlfF0iQ_NXUiaayFoNUVKL2YbAf2T71F2q4iU=.34a4d5a3-4082-4919-9cb6-b2ee0eef6e47@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
 <lIWIRPxlfF0iQ_NXUiaayFoNUVKL2YbAf2T71F2q4iU=.34a4d5a3-4082-4919-9cb6-b2ee0eef6e47@github.com>
Message-ID: <RPjy6KCI4J-9Z-aW1qU7-E-rBGCtTmN3N2EcXaCFrJI=.7606ee3b-b4cf-4ed7-868a-1e430b46d176@github.com>

On Wed, 19 May 2021 12:16:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change error message in test
>
> src/hotspot/share/ci/ciArrayKlass.cpp line 124:
> 
>> 122:         } else {
>> 123:           if (ak != NULL && ak->is_flatArray_klass()) {
>> 124:             is_array_flattened = true;
> 
> Why is that boolean needed? Can't we simply return `ciFlatArrayKlass::make(klass)` here?

Boolean removed in the latest commit.

> src/hotspot/share/ci/ciArrayKlass.cpp line 134:
> 
>> 132:       }
>> 133:     } else {
>> 134:       return ciEnv::unloaded_ciobjarrayklass();
> 
> Can't we delegate handling the unloaded case to `ciObjArrayKlass::make(klass)` below? I.e. check for `if (null_free && klass->is_loaded())` above.

I can change that. This was the way it was implemented initially, then I changed it to have the whole logic in a single method, but I don't have a strong opinion about this one.
Updated in the latest commit.

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From thartmann at openjdk.java.net  Wed May 19 13:56:11 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 May 2021 13:56:11 GMT
Subject: RFR: L/Q again, step two [v4]
In-Reply-To: <K7u1yPb3IULiRKQFPjoZkjdYB4ZGgNMVHtbCI6c6z6A=.ff674197-96bb-4881-94b8-0d67f0039099@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <K7u1yPb3IULiRKQFPjoZkjdYB4ZGgNMVHtbCI6c6z6A=.ff674197-96bb-4881-94b8-0d67f0039099@github.com>
Message-ID: <_lG2Ls_P_c6wxLWomzo039ZnILM9wct7sfaPI6GBZb0=.67e51931-7600-4824-bd17-fb9e65a665b8@github.com>

On Wed, 19 May 2021 13:15:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this second set of fixes for the L/Q transition.
>> A few changes in C1, most changes in CI.
>> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
>> 
>> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
>> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor ciArrayKlass::make()

Thanks for updating, looks good to me (added one minor suggestion).

src/hotspot/share/ci/ciArrayKlass.cpp line 121:

> 119:         CLEAR_PENDING_EXCEPTION;
> 120:       } else {
> 121:         if (ak != NULL && ak->is_flatArray_klass()) {

`else` and `if` can be merged

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/414


From thartmann at openjdk.java.net  Wed May 19 13:56:12 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 May 2021 13:56:12 GMT
Subject: RFR: L/Q again, step two [v2]
In-Reply-To: <EZZXkPxJY6rYAVI8kvaQ1AzU4eGScrja3BecTQ_MlSg=.2b069a07-4b1d-432c-a2bb-45f6e38ee503@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <YJhjoQxDJ9S0zgF5YjTL0WrexgOhK_1T0eaXLHzdRUk=.f003b137-745b-41a8-85c4-8966be9bc718@github.com>
 <lIWIRPxlfF0iQ_NXUiaayFoNUVKL2YbAf2T71F2q4iU=.34a4d5a3-4082-4919-9cb6-b2ee0eef6e47@github.com>
 <EZZXkPxJY6rYAVI8kvaQ1AzU4eGScrja3BecTQ_MlSg=.2b069a07-4b1d-432c-a2bb-45f6e38ee503@github.com>
Message-ID: <9kTkNZNM3_UlKglKZKoIh8oBOTm0N8o68NQWrDZLkzI=.2ec3c1be-aca1-44be-bdc4-61da346f0a62@github.com>

On Wed, 19 May 2021 13:01:41 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/ci/ciEnv.cpp line 478:
>> 
>>> 476:     if (elem_klass != NULL && elem_klass->is_loaded()) {
>>> 477:       // Now make an array for it
>>> 478:       bool null_free_array = sym->is_Q_array_signature() && sym->char_at(1) == JVM_SIGNATURE_INLINE_TYPE;
>> 
>> Why do we need the `sym->char_at(1) == JVM_SIGNATURE_INLINE_TYPE` check? Isn't that part of `is_Q_array_signature()`?
>
> The problem with is_Q_array_signature() is that it returns true for arrays of any dimension with the last dimension element klass being a null-free primitive class. It returns true for [QFoo; but also for [[[QFoo;. But for the [[[QFoo; array, the first two dimensions are regular nullable object arrays, only the last array is a null-free array (possibly flattened).

Ah, right. Thanks for the explanation!

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 14:21:48 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 14:21:48 GMT
Subject: RFR: L/Q again, step two [v5]
In-Reply-To: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
Message-ID: <_PGJSZUOnwlXeQXtFKHUxI7ywSlRDSVetmubSXIgxWA=.e96560a5-e269-49e8-bc7f-77284ba41ca1@github.com>

> Please review this second set of fixes for the L/Q transition.
> A few changes in C1, most changes in CI.
> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
> 
> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Second refactoring of ciArrayKlass::make()

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/414/files
  - new: https://git.openjdk.java.net/valhalla/pull/414/files/bd779242..f5d27d4d

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

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From thartmann at openjdk.java.net  Wed May 19 14:21:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 May 2021 14:21:48 GMT
Subject: RFR: L/Q again, step two [v5]
In-Reply-To: <_PGJSZUOnwlXeQXtFKHUxI7ywSlRDSVetmubSXIgxWA=.e96560a5-e269-49e8-bc7f-77284ba41ca1@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <_PGJSZUOnwlXeQXtFKHUxI7ywSlRDSVetmubSXIgxWA=.e96560a5-e269-49e8-bc7f-77284ba41ca1@github.com>
Message-ID: <gZrSOUG_qJty1xTxrOYSlGA_wJo3_bQ-nafoX8C2HMQ=.47b9068b-6325-41eb-a22b-0010b6bc990a@github.com>

On Wed, 19 May 2021 14:19:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this second set of fixes for the L/Q transition.
>> A few changes in C1, most changes in CI.
>> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
>> 
>> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
>> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second refactoring of ciArrayKlass::make()

Marked as reviewed by thartmann (Committer).

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 14:21:49 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 14:21:49 GMT
Subject: RFR: L/Q again, step two [v4]
In-Reply-To: <_lG2Ls_P_c6wxLWomzo039ZnILM9wct7sfaPI6GBZb0=.67e51931-7600-4824-bd17-fb9e65a665b8@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
 <K7u1yPb3IULiRKQFPjoZkjdYB4ZGgNMVHtbCI6c6z6A=.ff674197-96bb-4881-94b8-0d67f0039099@github.com>
 <_lG2Ls_P_c6wxLWomzo039ZnILM9wct7sfaPI6GBZb0=.67e51931-7600-4824-bd17-fb9e65a665b8@github.com>
Message-ID: <g_jG_Bx1-JIM0IEBf5r0rTuscG2KyZeN1xTkwACoGS0=.de0325e8-3996-4ba8-8b0c-d2a2ec8f598a@github.com>

On Wed, 19 May 2021 13:51:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor ciArrayKlass::make()
>
> src/hotspot/share/ci/ciArrayKlass.cpp line 121:
> 
>> 119:         CLEAR_PENDING_EXCEPTION;
>> 120:       } else {
>> 121:         if (ak != NULL && ak->is_flatArray_klass()) {
> 
> `else` and `if` can be merged

Code updated.

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 14:21:50 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 14:21:50 GMT
Subject: Integrated: L/Q again, step two
In-Reply-To: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
References: <f-flPHQZlrp1nkCErk1cTsPm29D6uFHiEMmXH8lL_0Q=.854aafe7-556f-45ea-941a-3623a0e9f286@github.com>
Message-ID: <LHYVrqzJicV5aLUUb-KoEaRWEgc0pvLAxIbCiwbqJQI=.87aaf015-b5aa-494b-89ff-f1c218c480fc@github.com>

On Tue, 18 May 2021 19:00:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this second set of fixes for the L/Q transition.
> A few changes in C1, most changes in CI.
> CI always delegates to the runtime to know if a null-free array is flattened or not (to avoid duplication of the flattening decision code).
> 
> With those changes, all tests in runtime/valhalla/inlinetypes now pass with -Xcomp -XX:TieredStopAtLevel=1 (at least on Linux x64).
> Some tests in compiler/valhalla/inlinetypes still fail but they will require more time to be investigated (some tests force use of C2 or expect code to be C2 compiled, but C2 is not fixed yet).
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 4aa22fbd
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4aa22fbd60749ab3aeec60a3b5ec58f18f29771e
Stats:     54 lines in 12 files changed: 30 ins; 4 del; 20 mod

L/Q again, step two

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/414


From fparain at openjdk.java.net  Wed May 19 19:06:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 19:06:22 GMT
Subject: [lworld] Integrated: 8267428: Several features lack the
 EnableValhalla guard
Message-ID: <DhednpkBQT8_ervUUQZhQj9Oey_C2Jdmtdelx4osWzQ=.6556f2c1-e41c-4b50-8ebd-a14b0862bf6f@github.com>

Add if(EnableValhalla) guards around:
  - injection of the IdentityObject interface
  - iteration over fields to pre-load primitive class fields
  - iteration of method arguments to eagerly load primitive class arguments
  - support for flattened and null-free fields in the interpreter

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

Commit messages:
 - Add missing if(EnableValhalla) guards

Changes: https://git.openjdk.java.net/valhalla/pull/417/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=417&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267428
  Stats: 169 lines in 3 files changed: 66 ins; 52 del; 51 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/417.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/417/head:pull/417

PR: https://git.openjdk.java.net/valhalla/pull/417


From fparain at openjdk.java.net  Wed May 19 19:06:23 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 May 2021 19:06:23 GMT
Subject: [lworld] Integrated: 8267428: Several features lack the
 EnableValhalla guard
In-Reply-To: <DhednpkBQT8_ervUUQZhQj9Oey_C2Jdmtdelx4osWzQ=.6556f2c1-e41c-4b50-8ebd-a14b0862bf6f@github.com>
References: <DhednpkBQT8_ervUUQZhQj9Oey_C2Jdmtdelx4osWzQ=.6556f2c1-e41c-4b50-8ebd-a14b0862bf6f@github.com>
Message-ID: <zW7a8pxI1bCP2tKYVECRFL2ymWdhiN9Wwmba3MnBCU8=.58a373a2-49e7-4f3f-b5b6-ca8cc30be591@github.com>

On Wed, 19 May 2021 18:57:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Add if(EnableValhalla) guards around:
>   - injection of the IdentityObject interface
>   - iteration over fields to pre-load primitive class fields
>   - iteration of method arguments to eagerly load primitive class arguments
>   - support for flattened and null-free fields in the interpreter

This pull request has now been integrated.

Changeset: 13e7d4a3
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/13e7d4a35c6d27128f03bba724cf4c8d93dd68cd
Stats:     169 lines in 3 files changed: 66 ins; 52 del; 51 mod

8267428: Several features lack the EnableValhalla guard

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

PR: https://git.openjdk.java.net/valhalla/pull/417


From fparain at openjdk.java.net  Thu May 20 17:39:10 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 20 May 2021 17:39:10 GMT
Subject: [lworld] RFR: 8267503: [lworld] [lw3] NPE message thrown by checkcast
 is incorrect
Message-ID: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>

Please review those changes fixing the error message for NullPointerExceptions thrown by checkcast.

Without the fix:
java.lang.NullPointerException: There cannot be a NullPointerException at bci 23 of method void NPECheckcastTest.main(java.lang.String[])

With the fix:
java.lang.NullPointerException: Cannot cast to null-free type "QNPECheckcastTest$C1;" because "<local2\>" is null

Thank you,

Fred

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

Commit messages:
 - Fix error message for NPE thrown by checkcast

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

PR: https://git.openjdk.java.net/valhalla/pull/418


From fparain at openjdk.java.net  Thu May 20 19:06:14 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 20 May 2021 19:06:14 GMT
Subject: Integrated: More C1 fixes
Message-ID: <PZvAwxD2XPHTzGyh59lNJB9jv24iqMFy-R816Bk72jY=.b970c569-c3df-4f25-83e9-5b87518ab8ea@github.com>

C1 fixes in LIRGenerator.

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

Commit messages:
 - More C1 fixes

Changes: https://git.openjdk.java.net/valhalla/pull/419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=419&range=00
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/419.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/419/head:pull/419

PR: https://git.openjdk.java.net/valhalla/pull/419


From fparain at openjdk.java.net  Thu May 20 19:06:14 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 20 May 2021 19:06:14 GMT
Subject: Integrated: More C1 fixes
In-Reply-To: <PZvAwxD2XPHTzGyh59lNJB9jv24iqMFy-R816Bk72jY=.b970c569-c3df-4f25-83e9-5b87518ab8ea@github.com>
References: <PZvAwxD2XPHTzGyh59lNJB9jv24iqMFy-R816Bk72jY=.b970c569-c3df-4f25-83e9-5b87518ab8ea@github.com>
Message-ID: <wiKi8F21nW-Yjvgy4U7IdPJjJvix3_KXGO5r5mL5RSo=.3f8ef2d2-7186-4847-8eac-0fad2d975bf5@github.com>

On Thu, 20 May 2021 18:58:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> C1 fixes in LIRGenerator.

This pull request has now been integrated.

Changeset: 375479ee
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/375479ee5bfee2fb84e31ba8a4be542c420db261
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

More C1 fixes

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

PR: https://git.openjdk.java.net/valhalla/pull/419


From dsimms at openjdk.java.net  Fri May 21 06:42:49 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 21 May 2021 06:42:49 GMT
Subject: [lworld] RFR: 8267503: [lworld] [lw3] NPE message thrown by
 checkcast is incorrect
In-Reply-To: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>
References: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>
Message-ID: <2yIoEWbHkJbn7HnYkB4ig7gIQALWRUZpp74i1h55VwE=.cd12c71b-812b-49f0-90ee-7fb835611d6e@github.com>

On Thu, 20 May 2021 17:32:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing the error message for NullPointerExceptions thrown by checkcast.
> 
> Without the fix:
> java.lang.NullPointerException: There cannot be a NullPointerException at bci 23 of method void NPECheckcastTest.main(java.lang.String[])
> 
> With the fix:
> java.lang.NullPointerException: Cannot cast to null-free type "QNPECheckcastTest$C1;" because "<local2\>" is null
> 
> Thank you,
> 
> Fred

Looks good to me

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

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/418


From ngasson at openjdk.java.net  Fri May 21 10:47:18 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 21 May 2021 10:47:18 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs
Message-ID: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>

This patch implements InlineTypePassFieldsAsArgs on AArch64 and the
associated stack extension/repair mechanism. It mostly follows the x86
implementation closely except for how the stack increment is stored in
the callee frame. On x86 the sp_inc stack slot stores the total size of
the frame which is the sum of the extension space, return address copy,
and the original method frame size (i.e. the total bytes needed to pop
the frame). On AArch64 we just store the size of the extension space. I
did it this way because it simplifies the stack repair code in
MacroAssembler::remove_frame (I've added some notes there to document
this). I don't think this should cause any problem because only the
MacroAssembler and platform-dependant frame walking code need to be
aware of this.

This patch includes JDK-8266609 which is a small refactoring in mainline
JDK to simplify how the frame size is passed around in the AArch64 C1
backend.

There was some X86 specific code in unpack_inline_args() in
macroAssembler_common.cpp. I've split this out into an arch-dependant
MacroAssembler::extend_stack_for_inline_args().

MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take
a new Register val_array argument which is the register holding the
buffered oop array for packing. Previously it assumed this was already
loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly
makes the code easier to understand.

There is one new test failure: TestNullableInlineTypes.java. The test
seems functionally correct but there is a failure verifying the C2 IR
graph (see below). I haven't investigated this but the test enables
InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that
might be causing the failure.


Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableInlineTypes::test26' contains forbidden node:
83  StoreL  ===  176  177  84  14  [[ 89 ]]  @compiler/valhalla/inlinetypes/MyValue3:exact+16 *, name=l, idx=6;  Memory: @rawptr:BotPTR, idx=Raw; !orig=82 !jvms: TestNullableInlineTypes::test26 @ bci:13 (line 704): expected false, was true


Tested tier1, runtime/valhalla, and compiler/valhalla on x86 and AArch64. There are some "bad AD file" failures on x86 but don't seem to be related to this patch.

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

Commit messages:
 - 8266890: [lworld] [AArch64] add support for InlineTypePassFieldsAsArgs

Changes: https://git.openjdk.java.net/valhalla/pull/420/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=420&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266890
  Stats: 509 lines in 21 files changed: 238 ins; 114 del; 157 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/420.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/420/head:pull/420

PR: https://git.openjdk.java.net/valhalla/pull/420


From sadayapalam at openjdk.java.net  Fri May 21 11:39:15 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 21 May 2021 11:39:15 GMT
Subject: [lworld] RFR: 8266466: [lworld] Enhance javac to consume unified
 primitive class files generated under the option -XDunifiedValRefClass
Message-ID: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>

Post the integration of https://bugs.openjdk.java.net/browse/JDK-8244227,
the constructor of ClassType, takes a boolean isReferenceProjection as an additional
parameter. Till now, it was feasible to upfront decide at the time of constructing
a class type whether the proposed type is supposed to be a reference projection or not.

This is no longer possible under the unified class file generation scheme we are
moving to. When we see LFoo; in field/method signatures/descriptors, we don't know
whether the type is Foo.ref of a primitive class Foo or a plain old reference type.

Likewise when we see QFoo; we have an ambiguity whether this is the primitive class
type Foo or is Foo.val type of a ref-default primitive class Foo. Till a class is
fully built ("completed"), we don't know whether it is a primitive class and if so,
what its ref-val defaultness is.

Completing class Foo every time we see a type descriptor LFoo; or QFoo; is wasteful
of resources. Nor is it possible as it is, since it would call for the ClassReader's
code to be reentered even as some other class is being read in: So the proposed patch
implements an incremental piece meal augmentation of attributes.

I suggest the review be started with Type.java in ClassType#Flavor enumeration to gather
a high level picture of the abstractions put in place to characterize a class type in
an incremental basis. After Type.java, Attr.java, ClassReader.java and Symbol.java in
that order provide a good order for review.

Please note, while this patch puts together the infrastructure and layes the groundwork
for modelling ref-default classes and thereby enable VBC migration work, such work will
arrive separately at a later time.

As of now javac knows only about primitive class and their reference projections and
plain old reference types. There is no notion of ref-val defaultness yet, Nor a way
to declare them.

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

Commit messages:
 - Fix white space problems
 - 8266466: Enhance javac to consume unified class files generated for primitive classes

Changes: https://git.openjdk.java.net/valhalla/pull/421/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=421&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266466
  Stats: 310 lines in 15 files changed: 247 ins; 8 del; 55 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/421.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/421/head:pull/421

PR: https://git.openjdk.java.net/valhalla/pull/421


From mcimadamore at openjdk.java.net  Fri May 21 11:55:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 21 May 2021 11:55:55 GMT
Subject: [lworld] RFR: 8266466: [lworld] Enhance javac to consume unified
 primitive class files generated under the option -XDunifiedValRefClass
In-Reply-To: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
References: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
Message-ID: <RZn5-zOcVP4JZGEB05VmhCGkg9NWmpqrnKXaI7M84RY=.bec1f70e-2484-46b2-a496-7273a5ac2708@github.com>

On Fri, 21 May 2021 11:28:55 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Post the integration of https://bugs.openjdk.java.net/browse/JDK-8244227,
> the constructor of ClassType, takes a boolean isReferenceProjection as an additional
> parameter. Till now, it was feasible to upfront decide at the time of constructing
> a class type whether the proposed type is supposed to be a reference projection or not.
> 
> This is no longer possible under the unified class file generation scheme we are
> moving to. When we see LFoo; in field/method signatures/descriptors, we don't know
> whether the type is Foo.ref of a primitive class Foo or a plain old reference type.
> 
> Likewise when we see QFoo; we have an ambiguity whether this is the primitive class
> type Foo or is Foo.val type of a ref-default primitive class Foo. Till a class is
> fully built ("completed"), we don't know whether it is a primitive class and if so,
> what its ref-val defaultness is.
> 
> Completing class Foo every time we see a type descriptor LFoo; or QFoo; is wasteful
> of resources. Nor is it possible as it is, since it would call for the ClassReader's
> code to be reentered even as some other class is being read in: So the proposed patch
> implements an incremental piece meal augmentation of attributes.
> 
> I suggest the review be started with Type.java in ClassType#Flavor enumeration to gather
> a high level picture of the abstractions put in place to characterize a class type in
> an incremental basis. After Type.java, Attr.java, ClassReader.java and Symbol.java in
> that order provide a good order for review.
> 
> Please note, while this patch puts together the infrastructure and layes the groundwork
> for modelling ref-default classes and thereby enable VBC migration work, such work will
> arrive separately at a later time.
> 
> As of now javac knows only about primitive class and their reference projections and
> plain old reference types. There is no notion of ref-val defaultness yet, Nor a way
> to declare them.

Overall, a clever strategy.

I'm a bit doubtful that we have seen the end of the string here. In particular, when it comes to LFoo; ambiguities (is it a regular reference Foo or a projection Foo.ref of some primitive type?) I think the old and trusted signature attribute also has a role to play.

The signature attribute will in fact require updates also to support universal generics.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1033:

> 1031:          * viewed against the default nature of the associated class.
> 1032:          */
> 1033:         public enum Flavor {

Perhaps you could add a method which "upgrades" a flavor to a new one, given new info.

e.g.


L_TypeOf_X.update(sym.isPrimitiveClass()) ->  L_TypeOf_Q/L_TypeOf_L (depending on isPrimitiveClass)


This would allow you to rule out (e.g. throw) bad updates. E.g. X flavors can be updated, all the other "leaf" flavors can only be updated to self. 

I think a method such as this would remove a lot of conditional logic in the clients.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 666:

> 664:                     } else {
> 665:                         // We are seeing QFoo; or LFoo; The name itself does not shine any light on default val-refness
> 666:                         flavor = prefix == 'L' ? Flavor.L_TypeOf_X : Flavor.L_TypeOf_X;

Is there a typo here - shouldn't be:


                        flavor = prefix == 'L' ? Flavor.L_TypeOf_X : Flavor.Q_TypeOf_X;

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

PR: https://git.openjdk.java.net/valhalla/pull/421


From fparain at openjdk.java.net  Fri May 21 12:02:03 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 21 May 2021 12:02:03 GMT
Subject: [lworld] RFR: 8267503: [lworld] [lw3] NPE message thrown by
 checkcast is incorrect
In-Reply-To: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>
References: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>
Message-ID: <bSawPkLskyxRdKxuwd17PEg6uwkbUKsBqHILqytI-x8=.1ce2238c-f385-4a00-99f8-f22891d70e5a@github.com>

On Thu, 20 May 2021 17:32:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing the error message for NullPointerExceptions thrown by checkcast.
> 
> Without the fix:
> java.lang.NullPointerException: There cannot be a NullPointerException at bci 23 of method void NPECheckcastTest.main(java.lang.String[])
> 
> With the fix:
> java.lang.NullPointerException: Cannot cast to null-free type "QNPECheckcastTest$C1;" because "<local2\>" is null
> 
> Thank you,
> 
> Fred

Mr Simms,
thank you for the review.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/418


From sadayapalam at openjdk.java.net  Fri May 21 14:04:45 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 21 May 2021 14:04:45 GMT
Subject: [lworld] RFR: 8266466: [lworld] Enhance javac to consume unified
 primitive class files generated under the option -XDunifiedValRefClass [v2]
In-Reply-To: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
References: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
Message-ID: <cIChBOjw-OYUzjwxAnSlLisTMvcs0DRUfCLGWwBtUU0=.32c85dae-b43c-4b99-b1c1-9a408e84f11e@github.com>

> Post the integration of https://bugs.openjdk.java.net/browse/JDK-8244227,
> the constructor of ClassType, takes a boolean isReferenceProjection as an additional
> parameter. Till now, it was feasible to upfront decide at the time of constructing
> a class type whether the proposed type is supposed to be a reference projection or not.
> 
> This is no longer possible under the unified class file generation scheme we are
> moving to. When we see LFoo; in field/method signatures/descriptors, we don't know
> whether the type is Foo.ref of a primitive class Foo or a plain old reference type.
> 
> Likewise when we see QFoo; we have an ambiguity whether this is the primitive class
> type Foo or is Foo.val type of a ref-default primitive class Foo. Till a class is
> fully built ("completed"), we don't know whether it is a primitive class and if so,
> what its ref-val defaultness is.
> 
> Completing class Foo every time we see a type descriptor LFoo; or QFoo; is wasteful
> of resources. Nor is it possible as it is, since it would call for the ClassReader's
> code to be reentered even as some other class is being read in: So the proposed patch
> implements an incremental piece meal augmentation of attributes.
> 
> I suggest the review be started with Type.java in ClassType#Flavor enumeration to gather
> a high level picture of the abstractions put in place to characterize a class type in
> an incremental basis. After Type.java, Attr.java, ClassReader.java and Symbol.java in
> that order provide a good order for review.
> 
> Please note, while this patch puts together the infrastructure and layes the groundwork
> for modelling ref-default classes and thereby enable VBC migration work, such work will
> arrive separately at a later time.
> 
> As of now javac knows only about primitive class and their reference projections and
> plain old reference types. There is no notion of ref-val defaultness yet, Nor a way
> to declare them.

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Fix problem caught by Maurizio during review - Use the right flavor.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/421/files
  - new: https://git.openjdk.java.net/valhalla/pull/421/files/3f0b2ef9..1df1b722

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

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

PR: https://git.openjdk.java.net/valhalla/pull/421


From sadayapalam at openjdk.java.net  Fri May 21 14:05:17 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 21 May 2021 14:05:17 GMT
Subject: [lworld] RFR: 8266466: [lworld] Enhance javac to consume unified
 primitive class files generated under the option -XDunifiedValRefClass [v2]
In-Reply-To: <RZn5-zOcVP4JZGEB05VmhCGkg9NWmpqrnKXaI7M84RY=.bec1f70e-2484-46b2-a496-7273a5ac2708@github.com>
References: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
 <RZn5-zOcVP4JZGEB05VmhCGkg9NWmpqrnKXaI7M84RY=.bec1f70e-2484-46b2-a496-7273a5ac2708@github.com>
Message-ID: <iCDx3_RPG6DR1CEjFlrkCZAO3wMIZU6nDFb6uD6GLAg=.6ee8c0a9-16e1-4d47-ad1e-5e95804cbe50@github.com>

On Fri, 21 May 2021 11:52:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Overall, a clever strategy.
> 
> I'm a bit doubtful that we have seen the end of the string here. In particular, when it comes to LFoo; ambiguities (is it a regular reference Foo or a projection Foo.ref of some primitive type?) I think the old and trusted signature attribute also has a role to play.
> 
> The signature attribute will in fact require updates also to support universal generics.

You are right that this is not the end of the story. The implementation deals with just a single bit ACC_PRIMITIVE and weaves that into the type system - so as of this patch, we can have plain old L_TypeOf_L, L_Typeof_Q and Q_TypeOf_Q as fully "evolved forms"  and X_Typeof_X, Q_Typeof_X and L_Typeof_X as the "larval forms".

BUT,  the ambiguity you right about i.e "In particular, when it comes to LFoo;  ... (is it a regular reference Foo or a projection Foo.ref of some primitive type?)" is handled already in this patch. The single bit ACC_PRIMITIVE is enough for this.

See com.sun.tools.javac.code.Type.ClassType#isReferenceProjection which disambiguates L_TypeOf_X into one of L_TypeOf_Q or L_TypeOf_L. 

I plan to take up work on JDK-8244231 right after this,  at which point, a larval form may see other evolutions.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1033:
> 
>> 1031:          * viewed against the default nature of the associated class.
>> 1032:          */
>> 1033:         public enum Flavor {
> 
> Perhaps you could add a method which "upgrades" a flavor to a new one, given new info.
> 
> e.g.
> 
> 
> L_TypeOf_X.update(sym.isPrimitiveClass()) ->  L_TypeOf_Q/L_TypeOf_L (depending on isPrimitiveClass)
> 
> 
> This would allow you to rule out (e.g. throw) bad updates. E.g. X flavors can be updated, all the other "leaf" flavors can only be updated to self. 
> 
> I think a method such as this would remove a lot of conditional logic in the clients.

I'll take a look ...

> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 666:
> 
>> 664:                     } else {
>> 665:                         // We are seeing QFoo; or LFoo; The name itself does not shine any light on default val-refness
>> 666:                         flavor = prefix == 'L' ? Flavor.L_TypeOf_X : Flavor.L_TypeOf_X;
> 
> Is there a typo here - shouldn't be:
> 
> 
>                         flavor = prefix == 'L' ? Flavor.L_TypeOf_X : Flavor.Q_TypeOf_X;

Oops. Yes it should be as you say. I am puzzled because this was copy pasted code. Don't know how the error got introduced! Good catch! The other two places do the right thing. Hmm.

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

PR: https://git.openjdk.java.net/valhalla/pull/421


From fparain at openjdk.java.net  Fri May 21 14:12:20 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 21 May 2021 14:12:20 GMT
Subject: [lworld] Integrated: 8267503: [lworld] [lw3] NPE message thrown by
 checkcast is incorrect
In-Reply-To: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>
References: <Z13GjaO7G96YHy1xKGVbP95sezV9fvLrdCk8KmBaneE=.5a2f932a-7820-4911-b3aa-1584e4b5de0f@github.com>
Message-ID: <sFxcvGSFVNFLdhK1ZjowJnWz06Lxm2p0Mrfz7DPLg40=.c0f8d612-640a-42da-bd92-9cf532ca8100@github.com>

On Thu, 20 May 2021 17:32:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing the error message for NullPointerExceptions thrown by checkcast.
> 
> Without the fix:
> java.lang.NullPointerException: There cannot be a NullPointerException at bci 23 of method void NPECheckcastTest.main(java.lang.String[])
> 
> With the fix:
> java.lang.NullPointerException: Cannot cast to null-free type "QNPECheckcastTest$C1;" because "<local2\>" is null
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: ae4ce74e
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ae4ce74eb7de87cc57ebf869187484d757573ef6
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8267503: [lworld] [lw3] NPE message thrown by checkcast is incorrect

Reviewed-by: dsimms

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

PR: https://git.openjdk.java.net/valhalla/pull/418


From sadayapalam at openjdk.java.net  Mon May 24 06:27:09 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 May 2021 06:27:09 GMT
Subject: [lworld] RFR: 8266466: [lworld] Enhance javac to consume unified
 primitive class files generated under the option -XDunifiedValRefClass [v3]
In-Reply-To: <iCDx3_RPG6DR1CEjFlrkCZAO3wMIZU6nDFb6uD6GLAg=.6ee8c0a9-16e1-4d47-ad1e-5e95804cbe50@github.com>
References: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
 <RZn5-zOcVP4JZGEB05VmhCGkg9NWmpqrnKXaI7M84RY=.bec1f70e-2484-46b2-a496-7273a5ac2708@github.com>
 <iCDx3_RPG6DR1CEjFlrkCZAO3wMIZU6nDFb6uD6GLAg=.6ee8c0a9-16e1-4d47-ad1e-5e95804cbe50@github.com>
Message-ID: <YBDYAJNb0doleRR0VbtC62uo6Tw6PSZe2eU8lYKAM5E=.b2b44832-0e4d-4ad9-b855-3cb784ddbd97@github.com>

On Fri, 21 May 2021 12:30:32 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1033:
>> 
>>> 1031:          * viewed against the default nature of the associated class.
>>> 1032:          */
>>> 1033:         public enum Flavor {
>> 
>> Perhaps you could add a method which "upgrades" a flavor to a new one, given new info.
>> 
>> e.g.
>> 
>> 
>> L_TypeOf_X.update(sym.isPrimitiveClass()) ->  L_TypeOf_Q/L_TypeOf_L (depending on isPrimitiveClass)
>> 
>> 
>> This would allow you to rule out (e.g. throw) bad updates. E.g. X flavors can be updated, all the other "leaf" flavors can only be updated to self. 
>> 
>> I think a method such as this would remove a lot of conditional logic in the clients.
>
> I'll take a look ...

> Perhaps you could add a method which "upgrades" a flavor to a new one, given new info.
> 
> e.g.
> 
> ```
> L_TypeOf_X.update(sym.isPrimitiveClass()) ->  L_TypeOf_Q/L_TypeOf_L (depending on isPrimitiveClass)
> ```
> 
> This would allow you to rule out (e.g. throw) bad updates. E.g. X flavors can be updated, all the other "leaf" flavors can only be updated to self.
> 
> I think a method such as this would remove a lot of conditional logic in the clients.

Thanks, this turned out to be a nice suggestion and helped simplify the code at 3 or 4 places.

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

PR: https://git.openjdk.java.net/valhalla/pull/421


From sadayapalam at openjdk.java.net  Mon May 24 06:27:08 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 May 2021 06:27:08 GMT
Subject: [lworld] RFR: 8266466: [lworld] Enhance javac to consume unified
 primitive class files generated under the option -XDunifiedValRefClass [v3]
In-Reply-To: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
References: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
Message-ID: <g4DieEMjX2UZIplaJRFPnWGePXRtxzh2Tjae8MKjG1U=.f791cdc1-9c8a-4c59-a68c-7caf035abe39@github.com>

> Post the integration of https://bugs.openjdk.java.net/browse/JDK-8244227,
> the constructor of ClassType, takes a boolean isReferenceProjection as an additional
> parameter. Till now, it was feasible to upfront decide at the time of constructing
> a class type whether the proposed type is supposed to be a reference projection or not.
> 
> This is no longer possible under the unified class file generation scheme we are
> moving to. When we see LFoo; in field/method signatures/descriptors, we don't know
> whether the type is Foo.ref of a primitive class Foo or a plain old reference type.
> 
> Likewise when we see QFoo; we have an ambiguity whether this is the primitive class
> type Foo or is Foo.val type of a ref-default primitive class Foo. Till a class is
> fully built ("completed"), we don't know whether it is a primitive class and if so,
> what its ref-val defaultness is.
> 
> Completing class Foo every time we see a type descriptor LFoo; or QFoo; is wasteful
> of resources. Nor is it possible as it is, since it would call for the ClassReader's
> code to be reentered even as some other class is being read in: So the proposed patch
> implements an incremental piece meal augmentation of attributes.
> 
> I suggest the review be started with Type.java in ClassType#Flavor enumeration to gather
> a high level picture of the abstractions put in place to characterize a class type in
> an incremental basis. After Type.java, Attr.java, ClassReader.java and Symbol.java in
> that order provide a good order for review.
> 
> Please note, while this patch puts together the infrastructure and layes the groundwork
> for modelling ref-default classes and thereby enable VBC migration work, such work will
> arrive separately at a later time.
> 
> As of now javac knows only about primitive class and their reference projections and
> plain old reference types. There is no notion of ref-val defaultness yet, Nor a way
> to declare them.

Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:

  Per Maurizio's review comment add a method to ClassType.Flavor to manage flavor evolution

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/421/files
  - new: https://git.openjdk.java.net/valhalla/pull/421/files/1df1b722..6716cd3b

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

  Stats: 51 lines in 4 files changed: 24 ins; 16 del; 11 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/421.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/421/head:pull/421

PR: https://git.openjdk.java.net/valhalla/pull/421


From sadayapalam at openjdk.java.net  Mon May 24 08:26:38 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 May 2021 08:26:38 GMT
Subject: [lworld] Integrated: 8266466: [lworld] Enhance javac to consume
 unified primitive class files generated under the option
 -XDunifiedValRefClass
In-Reply-To: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
References: <J-bqzsPsz_u17YTRizuIW2hxq5w6N6mbzMDhP6dwUnA=.58f9d868-e801-49b2-a7c8-204bbe2d82af@github.com>
Message-ID: <wSj9Utd3e4trKEd9tewYueIA4iqEkQmAM6f24iCUB3Q=.8c0ff9eb-a007-4e15-8517-23ace6e4454f@github.com>

On Fri, 21 May 2021 11:28:55 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Post the integration of https://bugs.openjdk.java.net/browse/JDK-8244227,
> the constructor of ClassType, takes a boolean isReferenceProjection as an additional
> parameter. Till now, it was feasible to upfront decide at the time of constructing
> a class type whether the proposed type is supposed to be a reference projection or not.
> 
> This is no longer possible under the unified class file generation scheme we are
> moving to. When we see LFoo; in field/method signatures/descriptors, we don't know
> whether the type is Foo.ref of a primitive class Foo or a plain old reference type.
> 
> Likewise when we see QFoo; we have an ambiguity whether this is the primitive class
> type Foo or is Foo.val type of a ref-default primitive class Foo. Till a class is
> fully built ("completed"), we don't know whether it is a primitive class and if so,
> what its ref-val defaultness is.
> 
> Completing class Foo every time we see a type descriptor LFoo; or QFoo; is wasteful
> of resources. Nor is it possible as it is, since it would call for the ClassReader's
> code to be reentered even as some other class is being read in: So the proposed patch
> implements an incremental piece meal augmentation of attributes.
> 
> I suggest the review be started with Type.java in ClassType#Flavor enumeration to gather
> a high level picture of the abstractions put in place to characterize a class type in
> an incremental basis. After Type.java, Attr.java, ClassReader.java and Symbol.java in
> that order provide a good order for review.
> 
> Please note, while this patch puts together the infrastructure and layes the groundwork
> for modelling ref-default classes and thereby enable VBC migration work, such work will
> arrive separately at a later time.
> 
> As of now javac knows only about primitive class and their reference projections and
> plain old reference types. There is no notion of ref-val defaultness yet, Nor a way
> to declare them.

This pull request has now been integrated.

Changeset: f9806a41
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f9806a412e9440e3bf025f6421049dcdfb39e64d
Stats:     318 lines in 15 files changed: 255 ins; 8 del; 55 mod

8266466: [lworld] Enhance javac to consume unified primitive class files generated under the option -XDunifiedValRefClass

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

PR: https://git.openjdk.java.net/valhalla/pull/421


From sadayapalam at openjdk.java.net  Mon May 24 08:52:23 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 May 2021 08:52:23 GMT
Subject: [lworld] RFR: 8244313: [lworld] Evolve javac's code generation to
 match scheme documented in SoV
In-Reply-To: <EJHysm1otmkx3ziFRKV6-Q0pdS-22yXksuYfuYX6sAI=.08d5c8d0-6773-4fdd-8f71-3771a2a5848b@github.com>
References: <EJHysm1otmkx3ziFRKV6-Q0pdS-22yXksuYfuYX6sAI=.08d5c8d0-6773-4fdd-8f71-3771a2a5848b@github.com>
Message-ID: <6AEELlDGM8OU_EHiYtVVdgQTGgsKjOt4Epurpk6qIFo=.9e8acf3f-2c20-4d2d-9b05-37955fad3600@github.com>

On Fri, 16 Apr 2021 12:12:32 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Generate code according to the scheme outlined in the Members section of https://cr.openjdk.java.net/~briangoetz/valhalla/sov/04-translation.html

This work is abandoned in favor of the single class file model pursued under https://bugs.openjdk.java.net/browse/JDK-8265423

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

PR: https://git.openjdk.java.net/valhalla/pull/386


From sadayapalam at openjdk.java.net  Mon May 24 08:52:23 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 May 2021 08:52:23 GMT
Subject: [lworld] Withdrawn: 8244313: [lworld] Evolve javac's code generation
 to match scheme documented in SoV
In-Reply-To: <EJHysm1otmkx3ziFRKV6-Q0pdS-22yXksuYfuYX6sAI=.08d5c8d0-6773-4fdd-8f71-3771a2a5848b@github.com>
References: <EJHysm1otmkx3ziFRKV6-Q0pdS-22yXksuYfuYX6sAI=.08d5c8d0-6773-4fdd-8f71-3771a2a5848b@github.com>
Message-ID: <OPL1jKlwoaGdlVhn1Bm8TCSGYR0N31GKo35aAkM421c=.881ecba4-ae8b-4dfb-bfb2-ed656292c79f@github.com>

On Fri, 16 Apr 2021 12:12:32 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Generate code according to the scheme outlined in the Members section of https://cr.openjdk.java.net/~briangoetz/valhalla/sov/04-translation.html

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/valhalla/pull/386


From fparain at openjdk.java.net  Mon May 24 22:18:48 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 24 May 2021 22:18:48 GMT
Subject: [lworld] RFR: 8267559: [lworld] [lw3] NPE thrown when attempting to
 write null to a null-free array has incorrect error message
Message-ID: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>

Please review this small fix in the error message of the NullPointerException thrown when trying to write null on a null-free array.

Thank you,

Fred

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

Commit messages:
 - Fix NPE error message for null-free arrays

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

PR: https://git.openjdk.java.net/valhalla/pull/422


From dsimms at openjdk.java.net  Tue May 25 06:07:33 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 25 May 2021 06:07:33 GMT
Subject: [lworld] RFR: 8267559: [lworld] [lw3] NPE thrown when attempting
 to write null to a null-free array has incorrect error message
In-Reply-To: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>
References: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>
Message-ID: <xAFKHgD1zTY20ino8TMRW0AYSEXk3YpzjOxBAIiKdro=.e2c1a437-d8da-4e0c-843e-2ef41452e9b6@github.com>

On Mon, 24 May 2021 19:14:24 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small fix in the error message of the NullPointerException thrown when trying to write null on a null-free array.
> 
> Thank you,
> 
> Fred

Looks good

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

Marked as reviewed by dsimms (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/422


From sadayapalam at openjdk.java.net  Tue May 25 06:21:06 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 25 May 2021 06:21:06 GMT
Subject: [lworld] Integrated: 8267542: [lworld] [lqagain] javac emits useless
 checkcast when accessing fields through the reference projection
Message-ID: <f6BtJyqosKFyfk7SZ04M5DpcLq9mlrbEh-HBxPeGCto=.d65c6cb2-d1a0-428d-8e58-0c3ae7683670@github.com>

Emit the checkcast only when the class files are bifurcated.

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

Commit messages:
 - 8267542: [lworld] [lqagain] javac emits useless checkcast when accessing fields through the reference projection

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

PR: https://git.openjdk.java.net/valhalla/pull/423


From sadayapalam at openjdk.java.net  Tue May 25 06:21:10 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 25 May 2021 06:21:10 GMT
Subject: [lworld] Integrated: 8267542: [lworld] [lqagain] javac emits useless
 checkcast when accessing fields through the reference projection
In-Reply-To: <f6BtJyqosKFyfk7SZ04M5DpcLq9mlrbEh-HBxPeGCto=.d65c6cb2-d1a0-428d-8e58-0c3ae7683670@github.com>
References: <f6BtJyqosKFyfk7SZ04M5DpcLq9mlrbEh-HBxPeGCto=.d65c6cb2-d1a0-428d-8e58-0c3ae7683670@github.com>
Message-ID: <mgpxxuwm_8nDQl4dO95OKWIVipQh9nHLgOiv7mfsUUY=.970dc85b-d4d8-4f71-bce5-4e6ea92b1c4a@github.com>

On Tue, 25 May 2021 06:13:09 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Emit the checkcast only when the class files are bifurcated.

This pull request has now been integrated.

Changeset: e150bd9b
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e150bd9b14bd6f22987aedc2ecbd8552c90dc0e2
Stats:     246 lines in 3 files changed: 244 ins; 0 del; 2 mod

8267542: [lworld] [lqagain] javac emits useless checkcast when accessing fields through the reference projection

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

PR: https://git.openjdk.java.net/valhalla/pull/423


From dsimms at openjdk.java.net  Tue May 25 06:58:08 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 25 May 2021 06:58:08 GMT
Subject: RFR: Merge lworld
Message-ID: <Dd_4FkJS51P8n1aSv3rBtkmEVeWobyqmzMR5F5399Io=.3cc59a35-b746-448d-bf2d-b0657f94b06c@github.com>

Merge branch 'lworld' into lqagain_merge_lworld_20210525

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

Commit messages:
 - Merge branch 'lworld' into lqagain_merge_lworld_20210525
 - 8266466: [lworld] Enhance javac to consume unified primitive class files generated under the option -XDunifiedValRefClass
 - 8267503: [lworld] [lw3] NPE message thrown by checkcast is incorrect
 - 8267428: Several features lack the EnableValhalla guard

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lqagain: https://webrevs.openjdk.java.net/?repo=valhalla&pr=424&range=00.0
 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=424&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/424/files
  Stats: 493 lines in 19 files changed: 327 ins; 60 del; 106 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/424.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/424/head:pull/424

PR: https://git.openjdk.java.net/valhalla/pull/424


From dsimms at openjdk.java.net  Tue May 25 07:05:13 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 25 May 2021 07:05:13 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <Dd_4FkJS51P8n1aSv3rBtkmEVeWobyqmzMR5F5399Io=.3cc59a35-b746-448d-bf2d-b0657f94b06c@github.com>
References: <Dd_4FkJS51P8n1aSv3rBtkmEVeWobyqmzMR5F5399Io=.3cc59a35-b746-448d-bf2d-b0657f94b06c@github.com>
Message-ID: <6c8hbfxL7i-4gZ_Tujjt6r6d6zCHdGIU9N2RYOaH_zM=.82a3afce-14e0-4649-a106-428b792904b5@github.com>

> Merge branch 'lworld' into lqagain_merge_lworld_20210525

David Simms has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'lworld' into lqagain_merge_lworld_20210525
 - 8267542: [lworld] [lqagain] javac emits useless checkcast when accessing fields through the reference projection

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/424/files
  - new: https://git.openjdk.java.net/valhalla/pull/424/files/e08a58b3..7ffa6d4f

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

  Stats: 246 lines in 3 files changed: 244 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/424.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/424/head:pull/424

PR: https://git.openjdk.java.net/valhalla/pull/424


From sadayapalam at openjdk.java.net  Tue May 25 11:55:54 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 25 May 2021 11:55:54 GMT
Subject: [lworld] Integrated: 8267672: [lworld] A couple of cleanups to
 Unified class file generation scheme
Message-ID: <HnczLGJt-P3OhCyUfuLbDQYr9M8bnnZht-gN5QpDgds=.10408bab-b81a-436a-b86d-e47aee5903cf@github.com>

Minor cleanups.

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

Commit messages:
 - 8267672: [lworld] A couple of minor cleanups to Unified class file generation code

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

PR: https://git.openjdk.java.net/valhalla/pull/425


From sadayapalam at openjdk.java.net  Tue May 25 11:55:59 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 25 May 2021 11:55:59 GMT
Subject: [lworld] Integrated: 8267672: [lworld] A couple of cleanups to
 Unified class file generation scheme
In-Reply-To: <HnczLGJt-P3OhCyUfuLbDQYr9M8bnnZht-gN5QpDgds=.10408bab-b81a-436a-b86d-e47aee5903cf@github.com>
References: <HnczLGJt-P3OhCyUfuLbDQYr9M8bnnZht-gN5QpDgds=.10408bab-b81a-436a-b86d-e47aee5903cf@github.com>
Message-ID: <_HOgDfx2AUP6ERsccn_1C2y2iyh9EcSJy5qb7fyGG4c=.5940b486-44ff-4733-94d3-025c04346dfa@github.com>

On Tue, 25 May 2021 09:45:26 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Minor cleanups.

This pull request has now been integrated.

Changeset: 7e2f2022
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7e2f202253cac45c066e3280947a944a37806505
Stats:     8 lines in 2 files changed: 6 ins; 0 del; 2 mod

8267672: [lworld] A couple of cleanups to Unified class file generation scheme

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

PR: https://git.openjdk.java.net/valhalla/pull/425


From dsimms at openjdk.java.net  Tue May 25 11:56:44 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 25 May 2021 11:56:44 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <Dd_4FkJS51P8n1aSv3rBtkmEVeWobyqmzMR5F5399Io=.3cc59a35-b746-448d-bf2d-b0657f94b06c@github.com>
References: <Dd_4FkJS51P8n1aSv3rBtkmEVeWobyqmzMR5F5399Io=.3cc59a35-b746-448d-bf2d-b0657f94b06c@github.com>
Message-ID: <G4BNCMA1uZ_1lvewKWbdAScZ5bOePHveME5JBzZXNgY=.619dd819-8dc3-42a5-9f3c-60aa29bf1658@github.com>

On Tue, 25 May 2021 06:52:07 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge branch 'lworld' into lqagain_merge_lworld_20210525

This pull request has now been integrated.

Changeset: bca447bb
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bca447bb2ff095ac72e82edec3a452c70e21b984
Stats:     739 lines in 22 files changed: 571 ins; 60 del; 108 mod

Merge lworld

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

PR: https://git.openjdk.java.net/valhalla/pull/424


From fparain at openjdk.java.net  Tue May 25 12:05:20 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 May 2021 12:05:20 GMT
Subject: [lworld] RFR: 8267559: [lworld] [lw3] NPE thrown when attempting
 to write null to a null-free array has incorrect error message
In-Reply-To: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>
References: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>
Message-ID: <KVxfO0WcVKAHi9PnG3a9-iUAUPcRymE1KxMbQEBPuzA=.b71e944c-f579-45ec-9045-9d9b74c18423@github.com>

On Mon, 24 May 2021 19:14:24 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small fix in the error message of the NullPointerException thrown when trying to write null on a null-free array.
> 
> Thank you,
> 
> Fred

Thank you for the review.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/422


From fparain at openjdk.java.net  Tue May 25 12:08:56 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 May 2021 12:08:56 GMT
Subject: [lworld] Integrated: 8267559: [lworld] [lw3] NPE thrown when
 attempting to write null to a null-free array has incorrect error message
In-Reply-To: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>
References: <XTTlBuiKBpziwGAliFoJCXPzMxmy_YHWCY4vjaygsGc=.6c25da9f-7504-4a98-9056-e36983082256@github.com>
Message-ID: <u_eerjPaY5VFSomw0rZlVZOxYUm-4BHxF3cUtbh8x-k=.3cdce5df-1289-410b-b034-3d8e7e7d4ff8@github.com>

On Mon, 24 May 2021 19:14:24 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small fix in the error message of the NullPointerException thrown when trying to write null on a null-free array.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 340ecece
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/340ecece1b7058ae5766d063fb73cb4483b8a4ee
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8267559: [lworld] [lw3] NPE thrown when attempting to write null to a null-free array has incorrect error message

Reviewed-by: dsimms

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

PR: https://git.openjdk.java.net/valhalla/pull/422


From shade at redhat.com  Tue May 25 15:32:19 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 25 May 2021 17:32:19 +0200
Subject: Value types and access atomicity
Message-ID: <fe3a6b6c-e699-ac95-e337-90d6f4ec26e6@redhat.com>

Hi there,

I am updating the jcstress examples about access atomicity, and wonder what is the accepted state of 
value type atomicity? For example, see this test:

     @JCStressTest
     @Outcome(id = "0, 0",  expect = Expect.ACCEPTABLE, desc = "Seeing the default value: writer had 
not acted yet.")
     @Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "Seeing the full value.")
     @Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "Other cases are allowed, because 
reads/writes are not atomic.")
     @State
     public static class ValueTypes {
         static primitive class Value {
             long x;
             long y;
             public Value(long x, long y) {
                 this.x = x;
                 this.y = y;
             }
         }

         Value v = Value.default;

         @Actor
         public void writer() {
             v = new Value(1, 1);
         }

         @Actor
         public void reader(JJ_Result r) {
             Value tv = v;
             r.r1 = tv.x;
             r.r2 = tv.y;
         }
     }

On x86_64, this yields:

RESULT     SAMPLES    FREQ       EXPECT  DESCRIPTION
   0, 0   1,244,897    2.4%   Acceptable  Seeing the default value: writer had not acted yet.
   0, 1           4   <0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
   1, 0      51,540    0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
   1, 1  49,608,697   97.5%   Acceptable  Seeing the full value.

That is understandable behavior, as the atomic read of 128-bit-wide Value is not guaranteed to be 
supported on underlying hardware. Is this the accepted behavior? Are there any plans to change it? 
(If not, I should probably work on eliminating the experimental AlwaysAtomicAccesses option we did 
for JMM 9, as it would be rendered moot...)

-- 
Thanks,
-Aleksey



From fparain at openjdk.java.net  Tue May 25 16:13:19 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 May 2021 16:13:19 GMT
Subject: [lworld] RFR: 8267698: [lworld] [lw3]
 runtime\exceptionMsgs\NullPointerException\NullPointerExceptionTest.java test
 fails because of new error message
Message-ID: <HnPSyMvqjxFjz7otRnXr2g3jpQzkH3eBWyLEc5QE4Y8=.3880dbe9-a00b-4e20-934e-5a75e46de805@github.com>

Fix test to recognize the new exception message.

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

Commit messages:
 - Fix NPE message test

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

PR: https://git.openjdk.java.net/valhalla/pull/426


From paul.sandoz at oracle.com  Tue May 25 16:14:41 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 25 May 2021 16:14:41 +0000
Subject: Value types and access atomicity
In-Reply-To: <fe3a6b6c-e699-ac95-e337-90d6f4ec26e6@redhat.com>
References: <fe3a6b6c-e699-ac95-e337-90d6f4ec26e6@redhat.com>
Message-ID: <20B66AA6-F2E5-467A-AC2F-707F0F3F4C08@oracle.com>

Hi Alexey,

See https://openjdk.java.net/jeps/401#Enforcing-instance-validation

What you observe is the proposed default behavior, with the following to enable atomicity:

- mark the field as volatile (dunno if the implementation currently supports this); and

- a possible feature to add a (to be determined) class modified on the class. 

VHs will require some spec/impl adjustment. Atomic VH access to a plain field of non-atomic primitive class is gonna be problematic (fail? or global lock, yuck!).

I believe the implementation technique at the moment is to not flatten volatile fields. I am not aware of any attempts to optimize for say smaller sizes (e.g. seq locks), or those that fit in 64 bits.

Paul.

> On May 25, 2021, at 8:32 AM, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> Hi there,
> 
> I am updating the jcstress examples about access atomicity, and wonder what is the accepted state of value type atomicity? For example, see this test:
> 
>    @JCStressTest
>    @Outcome(id = "0, 0",  expect = Expect.ACCEPTABLE, desc = "Seeing the default value: writer had not acted yet.")
>    @Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "Seeing the full value.")
>    @Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "Other cases are allowed, because reads/writes are not atomic.")
>    @State
>    public static class ValueTypes {
>        static primitive class Value {
>            long x;
>            long y;
>            public Value(long x, long y) {
>                this.x = x;
>                this.y = y;
>            }
>        }
> 
>        Value v = Value.default;
> 
>        @Actor
>        public void writer() {
>            v = new Value(1, 1);
>        }
> 
>        @Actor
>        public void reader(JJ_Result r) {
>            Value tv = v;
>            r.r1 = tv.x;
>            r.r2 = tv.y;
>        }
>    }
> 
> On x86_64, this yields:
> 
> RESULT     SAMPLES    FREQ       EXPECT  DESCRIPTION
>  0, 0   1,244,897    2.4%   Acceptable  Seeing the default value: writer had not acted yet.
>  0, 1           4   <0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
>  1, 0      51,540    0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
>  1, 1  49,608,697   97.5%   Acceptable  Seeing the full value.
> 
> That is understandable behavior, as the atomic read of 128-bit-wide Value is not guaranteed to be supported on underlying hardware. Is this the accepted behavior? Are there any plans to change it? (If not, I should probably work on eliminating the experimental AlwaysAtomicAccesses option we did for JMM 9, as it would be rendered moot...)
> 
> -- 
> Thanks,
> -Aleksey
> 



From fparain at openjdk.java.net  Tue May 25 16:58:08 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 May 2021 16:58:08 GMT
Subject: git: openjdk/valhalla: lworld: 8267698: [lworld] [lw3]
 runtime\exceptionMsgs\NullPointerException\NullPointerExceptionTest.java test
 fails because of new error message
Message-ID: <4d230d74-6af5-485c-980f-e16f8a95e944@openjdk.org>

Changeset: 25983c72
Author:    Frederic Parain <fparain at openjdk.org>
Date:      2021-05-25 16:57:47 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/25983c72163bc23e5001d6f023100ed59acbf770

8267698: [lworld] [lw3] runtime\exceptionMsgs\NullPointerException\NullPointerExceptionTest.java test fails because of new error message

! test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java



From shade at redhat.com  Tue May 25 17:27:54 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 25 May 2021 19:27:54 +0200
Subject: Value types and access atomicity
In-Reply-To: <20B66AA6-F2E5-467A-AC2F-707F0F3F4C08@oracle.com>
References: <fe3a6b6c-e699-ac95-e337-90d6f4ec26e6@redhat.com>
 <20B66AA6-F2E5-467A-AC2F-707F0F3F4C08@oracle.com>
Message-ID: <9c665885-2e5a-31fc-9d80-b0bc76c08143@redhat.com>

On 5/25/21 6:14 PM, Paul Sandoz wrote:
> What you observe is the proposed default behavior, with the following to enable atomicity: - mark
> the field as volatile (dunno if the implementation currently supports this); and
Right. Adding "volatile" indeed restores the access atomicity, like it should for longs/doules.

> VHs will require some spec/impl adjustment. Atomic VH access to a plain field of non-atomic
> primitive class is gonna be problematic (fail? or global lock, yuck!).
Yes. I would expect that doing VH.getOpaque over primitive-class-typed field gives me atomicity 
back. It would be sad to sacrifice nearly the only guarantee that opaque mode actually provides...

> I believe the implementation technique at the moment is to not flatten volatile fields. I am not
aware of any attempts to optimize for say smaller sizes (e.g. seq locks), or those that fit in 64 bits.

Right. So -XX:+AlwaysAtomicAccesses can stay a while and be plugged to the code that avoids 
flattening volatile primitive fields:
   https://github.com/openjdk/valhalla/pull/427

-- 
Thanks,
-Aleksey



From frederic.parain at oracle.com  Tue May 25 17:38:19 2021
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 25 May 2021 17:38:19 +0000
Subject: Value types and access atomicity
In-Reply-To: <20B66AA6-F2E5-467A-AC2F-707F0F3F4C08@oracle.com>
References: <fe3a6b6c-e699-ac95-e337-90d6f4ec26e6@redhat.com>
 <20B66AA6-F2E5-467A-AC2F-707F0F3F4C08@oracle.com>
Message-ID: <0D13DE19-FC54-4D7E-AA04-7F586BB5E18F@oracle.com>



> On May 25, 2021, at 12:14 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Alexey,
> 
> See https://openjdk.java.net/jeps/401#Enforcing-instance-validation
> 
> What you observe is the proposed default behavior, with the following to enable atomicity:
> 
> - mark the field as volatile (dunno if the implementation currently supports this); and
> 
> - a possible feature to add a (to be determined) class modified on the class. 

An atomicity requirement can be added to a primitive class by making it implementing
the java.lang.NonTearable interface (temporary name).

Fred

> 
> VHs will require some spec/impl adjustment. Atomic VH access to a plain field of non-atomic primitive class is gonna be problematic (fail? or global lock, yuck!).
> 
> I believe the implementation technique at the moment is to not flatten volatile fields. I am not aware of any attempts to optimize for say smaller sizes (e.g. seq locks), or those that fit in 64 bits.
> 
> Paul.
> 
>> On May 25, 2021, at 8:32 AM, Aleksey Shipilev <shade at redhat.com> wrote:
>> 
>> Hi there,
>> 
>> I am updating the jcstress examples about access atomicity, and wonder what is the accepted state of value type atomicity? For example, see this test:
>> 
>>   @JCStressTest
>>   @Outcome(id = "0, 0",  expect = Expect.ACCEPTABLE, desc = "Seeing the default value: writer had not acted yet.")
>>   @Outcome(id = "1, 1", expect = Expect.ACCEPTABLE, desc = "Seeing the full value.")
>>   @Outcome(expect = Expect.ACCEPTABLE_INTERESTING, desc = "Other cases are allowed, because reads/writes are not atomic.")
>>   @State
>>   public static class ValueTypes {
>>       static primitive class Value {
>>           long x;
>>           long y;
>>           public Value(long x, long y) {
>>               this.x = x;
>>               this.y = y;
>>           }
>>       }
>> 
>>       Value v = Value.default;
>> 
>>       @Actor
>>       public void writer() {
>>           v = new Value(1, 1);
>>       }
>> 
>>       @Actor
>>       public void reader(JJ_Result r) {
>>           Value tv = v;
>>           r.r1 = tv.x;
>>           r.r2 = tv.y;
>>       }
>>   }
>> 
>> On x86_64, this yields:
>> 
>> RESULT     SAMPLES    FREQ       EXPECT  DESCRIPTION
>> 0, 0   1,244,897    2.4%   Acceptable  Seeing the default value: writer had not acted yet.
>> 0, 1           4   <0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
>> 1, 0      51,540    0.1%  Interesting  Other cases are allowed, because reads/writes are not at...
>> 1, 1  49,608,697   97.5%   Acceptable  Seeing the full value.
>> 
>> That is understandable behavior, as the atomic read of 128-bit-wide Value is not guaranteed to be supported on underlying hardware. Is this the accepted behavior? Are there any plans to change it? (If not, I should probably work on eliminating the experimental AlwaysAtomicAccesses option we did for JMM 9, as it would be rendered moot...)
>> 
>> -- 
>> Thanks,
>> -Aleksey
>> 
> 



From shade at openjdk.java.net  Tue May 25 21:51:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 25 May 2021 21:51:12 GMT
Subject: [lworld] RFR: 8267710: Hook AlwaysAtomicAccesses to primitive classes
 atomicity rules
Message-ID: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>

`AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.

Testing:
 - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`

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

Commit messages:
 - 8267710: Hook AlwaysAtomicAccesses to primitive classes atomicity rules

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From fparain at openjdk.java.net  Tue May 25 21:51:18 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 May 2021 21:51:18 GMT
Subject: [lworld] RFR: 8267710: Hook AlwaysAtomicAccesses to primitive
 classes atomicity rules
In-Reply-To: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
Message-ID: <fPrW3j5oalHrlbV_VeynyPMXx1UNd0yd11XKtjJD5wc=.946c2d53-f139-4164-88d3-1482c49b29bf@github.com>

On Tue, 25 May 2021 17:27:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
> 
> Testing:
>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`

Looks good to me.

Fred

You can push now.
"[lworld] [lw3]" in the title of CR are more of a custom than a rule.
What is important is to have the labels (I've added them to the CR).

Could you add the same fix to method FieldLayoutBuilder::inline_class_field_sorting()?
Thank you.

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/427


From shade at openjdk.java.net  Tue May 25 21:51:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 25 May 2021 21:51:27 GMT
Subject: [lworld] RFR: 8267710: Hook AlwaysAtomicAccesses to primitive
 classes atomicity rules
In-Reply-To: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
Message-ID: <6i9aeuj8SAO_NLxtgctza1kCnsQluF55-bCzASZPnzU=.346513c2-af0a-4beb-8088-9b8f141ca5a8@github.com>

On Tue, 25 May 2021 17:27:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
> 
> Testing:
>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`

Thanks! What are the rules here? Should I prefix the PR with "[lworld] [lw3]"? Should I just push after one approval?

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From fparain at openjdk.java.net  Tue May 25 21:57:21 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 May 2021 21:57:21 GMT
Subject: [lworld] Integrated: 8267698: [lworld] [lw3]
 runtime\exceptionMsgs\NullPointerException\NullPointerExceptionTest.java test
 fails because of new error message
In-Reply-To: <HnPSyMvqjxFjz7otRnXr2g3jpQzkH3eBWyLEc5QE4Y8=.3880dbe9-a00b-4e20-934e-5a75e46de805@github.com>
References: <HnPSyMvqjxFjz7otRnXr2g3jpQzkH3eBWyLEc5QE4Y8=.3880dbe9-a00b-4e20-934e-5a75e46de805@github.com>
Message-ID: <1mdrXpwyfTt8kx1XyLYrtZU84oTzx40TQdy-VTxdDb0=.4b8b0da7-2288-4b21-9284-e86a2dc24f92@github.com>

On Tue, 25 May 2021 16:08:06 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix test to recognize the new exception message.

This pull request has now been integrated.

Changeset: 25983c72
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/25983c72163bc23e5001d6f023100ed59acbf770
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8267698: [lworld] [lw3] runtime\exceptionMsgs\NullPointerException\NullPointerExceptionTest.java test fails because of new error message

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

PR: https://git.openjdk.java.net/valhalla/pull/426


From shade at openjdk.java.net  Wed May 26 06:58:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 26 May 2021 06:58:40 GMT
Subject: [lworld] RFR: [lworld][lw3] 8267710: Hook AlwaysAtomicAccesses to
 primitive classes atomicity rules [v2]
In-Reply-To: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
Message-ID: <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>

> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
> 
> Testing:
>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`

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

  Also add in another method

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/427/files
  - new: https://git.openjdk.java.net/valhalla/pull/427/files/8c18235d..b16de71e

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

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From shade at openjdk.java.net  Wed May 26 06:58:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 26 May 2021 06:58:41 GMT
Subject: [lworld] RFR: [lworld][lw3] 8267710: Hook AlwaysAtomicAccesses to
 primitive classes atomicity rules
In-Reply-To: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
Message-ID: <6YEC_sFx-gDjpI0K6rjFcDmjVlKEvxtQReI1V-G1nRs=.add655d9-2957-42f9-b9a0-5e3d9695d7de@github.com>

On Tue, 25 May 2021 17:27:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
> 
> Testing:
>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`

OK, added, renamed, ran `runtime/valhalla` without problems.

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From shade at openjdk.java.net  Wed May 26 07:44:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 26 May 2021 07:44:51 GMT
Subject: [lworld] RFR: [lworld][lw3] Change "non-tearable" nomenclature to
 "access atomic"
Message-ID: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>

Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.

First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".

Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.

This nomenclature percolates to Valhalla VM code, so some change is needed there as well.

Additional testing:
 - [x] `runtime/valhalla` tests

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

Commit messages:
 - Change "non-tearable" nomenclature to "access atomic"

Changes: https://git.openjdk.java.net/valhalla/pull/428/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=428&range=00
  Stats: 722 lines in 12 files changed: 359 ins; 345 del; 18 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/428.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/428/head:pull/428

PR: https://git.openjdk.java.net/valhalla/pull/428


From shade at redhat.com  Wed May 26 08:45:19 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 26 May 2021 10:45:19 +0200
Subject: Value types and access atomicity
In-Reply-To: <9c665885-2e5a-31fc-9d80-b0bc76c08143@redhat.com>
References: <fe3a6b6c-e699-ac95-e337-90d6f4ec26e6@redhat.com>
 <20B66AA6-F2E5-467A-AC2F-707F0F3F4C08@oracle.com>
 <9c665885-2e5a-31fc-9d80-b0bc76c08143@redhat.com>
Message-ID: <39a9d801-49b2-296f-ffc0-79be9a77de93@redhat.com>

On 5/25/21 7:27 PM, Aleksey Shipilev wrote:
> On 5/25/21 6:14 PM, Paul Sandoz wrote:
>> What you observe is the proposed default behavior, with the following to enable atomicity: - mark
>> the field as volatile (dunno if the implementation currently supports this); and
> Right. Adding "volatile" indeed restores the access atomicity, like it should for longs/doules.
> 
>> VHs will require some spec/impl adjustment. Atomic VH access to a plain field of non-atomic
>> primitive class is gonna be problematic (fail? or global lock, yuck!).
> Yes. I would expect that doing VH.getOpaque over primitive-class-typed field gives me atomicity
> back. It would be sad to sacrifice nearly the only guarantee that opaque mode actually provides...

Seems like VH.{get|set}Opaque over (long,long) primitive class already "works" to regain access 
atomicity, but only because Unsafe.{get|set}ValueVolatile does the global lock. Yuck.

-- 
Thanks,
-Aleksey



From fparain at openjdk.java.net  Wed May 26 12:15:23 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 26 May 2021 12:15:23 GMT
Subject: [lworld] RFR: [lworld][lw3] 8267710: Hook AlwaysAtomicAccesses to
 primitive classes atomicity rules [v2]
In-Reply-To: <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
 <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>
Message-ID: <b18OVqYjYCvC2Aj5zjolzWBN_hH9pwARSRF_68aI7R0=.6ef51730-17a9-409a-905b-82cce322160e@github.com>

On Wed, 26 May 2021 06:58:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
>> 
>> Testing:
>>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also add in another method

Thanks for the update.

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From shade at openjdk.java.net  Wed May 26 12:46:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 26 May 2021 12:46:44 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes for
 inline types
Message-ID: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>

JDK-8259316 added the support for compiler blackholes. We need to check and implement the support for inline type arguments for them. I am sure we would find more wrinkles with nano-benchmarks, but insofar sample benchmark work as they should:


public class PrimitiveClasses {
    static primitive class Value {
        long x;
        long y;
        public Value(long x, long y) {
            this.x = x;
            this.y = y;
        }
    }

    [volatile] Value v = Value.default;

    @Benchmark
    public Value test() {
        return v;
    }
}


Before: crash on assert, `assert(vt->fast_out(i)->is_InlineTypeBase(), "Unexpected inline type user");`

After, generated code in non-`volatile` case shows blackhole of individual components:


$ java -Djmh.blackhole.mode=COMPILER -jar target/benchmarks.jar PrimitiveClasses -prof perfasm
...
....[Hottest Region 1]..............................................................................
c2, level 4, org.openjdk.jmh_generated.PrimitiveClasses_test_jmhTest::test_avgt_jmhStub, version 641 (39 bytes) 
...
         ?  0x00007f67bcc8eee0:   mov    0x18(%r8),%r10        ; read and blackhole MyValue.x
  0.02%  ?  0x00007f67bcc8eee4:   mov    0x10(%r8),%r11        ; read and blackhole MyValue.y
  0.10%  ?  0x00007f67bcc8eee8:   movzbl 0x94(%r14),%r11d      ; read isDone
  0.10%  ?  0x00007f67bcc8eef0:   mov    0x3b0(%r15),%r10      ; TL handshake
  2.79%  ?  0x00007f67bcc8eef7:   add    $0x1,%rbp             ; ops++
         ?  0x00007f67bcc8eefb:   test   %eax,(%r10)           ; TL handshake
 86.74%  ?  0x00007f67bcc8eefe:   test   %r11d,%r11d           ; isDone?
  2.31%  ?  0x00007f67bcc8ef01:   je     0x00007f67bcc8eee0    


And generated code in `volatile` case shows blackhole of the box (with the null-check):


          ?   0x00007f3948c8db70:   shl    $0x3,%r10            ; unpack and blackhole MyValue
  0.02%   ??  0x00007f3948c8db74:   movzbl 0x94(%r14),%r8d      ; read isDone
  0.68%   ??  0x00007f3948c8db7c:   mov    0x3b0(%r15),%r9      ; TL handshake
  0.72%   ??  0x00007f3948c8db83:   add    $0x1,%rbp            ; ops++
          ??  0x00007f3948c8db87:   test   %eax,(%r9)           ; TL handshake
 92.30%   ??  0x00007f3948c8db8a:   test   %r8d,%r8d            ; isDone?
         ???  0x00007f3948c8db8d:   jne    0x00007f3948c8dba4   
         ???  0x00007f3948c8db8f:   mov    0xc(%r11),%r10d      ; load "v" (MyValue box)
  0.35%  ???  0x00007f3948c8db93:   test   %r10d,%r10d          ; null check it
         ???  0x00007f3948c8db96:   jne    0x00007f3948c8db70

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

Commit messages:
 - Comment fixes
 - Handle boxed case too
 - 8267791: [lworld][lw3] Support compiler blackholes for inline types

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From fparain at openjdk.java.net  Wed May 26 13:28:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 26 May 2021 13:28:22 GMT
Subject: [lworld] RFR: 8267710: [lworld][lw3] Hook AlwaysAtomicAccesses to
 primitive classes atomicity rules [v2]
In-Reply-To: <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
 <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>
Message-ID: <384l92GYe5HU7bkMBEIKu6vCAxjjHhu-yMB6re-T5Uk=.264f8b78-0a57-4182-b319-7bff1cbf3c88@github.com>

On Wed, 26 May 2021 06:58:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
>> 
>> Testing:
>>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also add in another method

Marked as reviewed by fparain (Committer).

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From thartmann at openjdk.java.net  Thu May 27 07:18:23 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 27 May 2021 07:18:23 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs
In-Reply-To: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
Message-ID: <MfDmcMX3CaQvZf2H1uGhhD60H8RfLs1udZW0gHXAjkU=.b36de946-93fa-4cb9-8638-202f727ed80a@github.com>

On Fri, 21 May 2021 10:40:29 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This patch implements InlineTypePassFieldsAsArgs on AArch64 and the
> associated stack extension/repair mechanism. It mostly follows the x86
> implementation closely except for how the stack increment is stored in
> the callee frame. On x86 the sp_inc stack slot stores the total size of
> the frame which is the sum of the extension space, return address copy,
> and the original method frame size (i.e. the total bytes needed to pop
> the frame). On AArch64 we just store the size of the extension space. I
> did it this way because it simplifies the stack repair code in
> MacroAssembler::remove_frame (I've added some notes there to document
> this). I don't think this should cause any problem because only the
> MacroAssembler and platform-dependant frame walking code need to be
> aware of this.
> 
> This patch includes JDK-8266609 which is a small refactoring in mainline
> JDK to simplify how the frame size is passed around in the AArch64 C1
> backend.
> 
> There was some X86 specific code in unpack_inline_args() in
> macroAssembler_common.cpp. I've split this out into an arch-dependant
> MacroAssembler::extend_stack_for_inline_args().
> 
> MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take
> a new Register val_array argument which is the register holding the
> buffered oop array for packing. Previously it assumed this was already
> loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly
> makes the code easier to understand.
> 
> There is one new test failure: TestNullableInlineTypes.java. The test
> seems functionally correct but there is a failure verifying the C2 IR
> graph (see below). I haven't investigated this but the test enables
> InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that
> might be causing the failure.
> 
> 
> Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableInlineTypes::test26' contains forbidden node:
> 83  StoreL  ===  176  177  84  14  [[ 89 ]]  @compiler/valhalla/inlinetypes/MyValue3:exact+16 *, name=l, idx=6;  Memory: @rawptr:BotPTR, idx=Raw; !orig=82 !jvms: TestNullableInlineTypes::test26 @ bci:13 (line 704): expected false, was true
> 
> 
> Tested tier1, runtime/valhalla, and compiler/valhalla on x86 and AArch64. There are some "bad AD file" failures on x86 but don't seem to be related to this patch.

Sorry for the delay, this looks good to me!

>  I did it this way because it simplifies the stack repair code in MacroAssembler::remove_frame

But that only simplifies the C++ code and not the assembly code that is emitted right? I wonder if we shouldn't aim for optimal assembly because this code will be exercised a lot.

Could you please file bugs for the other issues that you were seeing?

We currently don't have testing on aarch64 enabled for Valhalla in our CI but we will do so as soon as the port is stable.

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/420


From thartmann at openjdk.java.net  Thu May 27 07:36:27 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 27 May 2021 07:36:27 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes
 for inline types
In-Reply-To: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
Message-ID: <Kv4ogLj6y7nN8FTtC7n8EiAK1Ed9WdUR4ZeZ5qmxV9E=.7d6c5f89-928a-4c15-9cda-9502986ffffa@github.com>

On Wed, 26 May 2021 12:26:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8259316 added the support for compiler blackholes. We need to check and implement the support for inline type arguments for them. I am sure we would find more wrinkles with nano-benchmarks, but insofar sample benchmark work as they should:
> 
> 
> public class PrimitiveClasses {
>     static primitive class Value {
>         long x;
>         long y;
>         public Value(long x, long y) {
>             this.x = x;
>             this.y = y;
>         }
>     }
> 
>     [volatile] Value v = Value.default;
> 
>     @Benchmark
>     public Value test() {
>         return v;
>     }
> }
> 
> 
> Before: crash on assert, `assert(vt->fast_out(i)->is_InlineTypeBase(), "Unexpected inline type user");`
> 
> After, generated code in non-`volatile` case shows blackhole of individual components:
> 
> 
> $ java -Djmh.blackhole.mode=COMPILER -jar target/benchmarks.jar PrimitiveClasses -prof perfasm
> ...
> ....[Hottest Region 1]..............................................................................
> c2, level 4, org.openjdk.jmh_generated.PrimitiveClasses_test_jmhTest::test_avgt_jmhStub, version 641 (39 bytes) 
> ...
>          ?  0x00007f67bcc8eee0:   mov    0x18(%r8),%r10        ; read and blackhole MyValue.x
>   0.02%  ?  0x00007f67bcc8eee4:   mov    0x10(%r8),%r11        ; read and blackhole MyValue.y
>   0.10%  ?  0x00007f67bcc8eee8:   movzbl 0x94(%r14),%r11d      ; read isDone
>   0.10%  ?  0x00007f67bcc8eef0:   mov    0x3b0(%r15),%r10      ; TL handshake
>   2.79%  ?  0x00007f67bcc8eef7:   add    $0x1,%rbp             ; ops++
>          ?  0x00007f67bcc8eefb:   test   %eax,(%r10)           ; TL handshake
>  86.74%  ?  0x00007f67bcc8eefe:   test   %r11d,%r11d           ; isDone?
>   2.31%  ?  0x00007f67bcc8ef01:   je     0x00007f67bcc8eee0    
> 
> 
> And generated code in `volatile` case shows blackhole of the box (with the null-check):
> 
> 
>           ?   0x00007f3948c8db70:   shl    $0x3,%r10            ; unpack and blackhole MyValue
>   0.02%   ??  0x00007f3948c8db74:   movzbl 0x94(%r14),%r8d      ; read isDone
>   0.68%   ??  0x00007f3948c8db7c:   mov    0x3b0(%r15),%r9      ; TL handshake
>   0.72%   ??  0x00007f3948c8db83:   add    $0x1,%rbp            ; ops++
>           ??  0x00007f3948c8db87:   test   %eax,(%r9)           ; TL handshake
>  92.30%   ??  0x00007f3948c8db8a:   test   %r8d,%r8d            ; isDone?
>          ???  0x00007f3948c8db8d:   jne    0x00007f3948c8dba4   
>          ???  0x00007f3948c8db8f:   mov    0xc(%r11),%r10d      ; load "v" (MyValue box)
>   0.35%  ???  0x00007f3948c8db93:   test   %r10d,%r10d          ; null check it
>          ???  0x00007f3948c8db96:   jne    0x00007f3948c8db70

src/hotspot/share/opto/compile.cpp line 1931:

> 1929:       } else {
> 1930:         // Check if any users are blackholes. If so, rewrite them to use either the
> 1931:         // allocated box, or individual components, instead of the inline type node

Better replace `box` by `buffer`.

src/hotspot/share/opto/compile.cpp line 1945:

> 1943:             if (vt->is_allocated(&igvn)) {
> 1944:               // Already has the allocated instance, blackhole that
> 1945:               bh->add_req(vt->get_oop());

This might keep an otherwise unused buffer allocation alive. Is that the expected behavior of using backholes on inline types? Why not always blackhole the components?

test/hotspot/jtreg/runtime/valhalla/inlinetypes/BlackholeTest.java line 24:

> 22:  */
> 23: 
> 24: package runtime.valhalla.inlinetypes;

I think this test should go to compiler.

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From thartmann at openjdk.java.net  Thu May 27 07:38:29 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 27 May 2021 07:38:29 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic"
In-Reply-To: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
Message-ID: <Bpm3nI0lwu4_ZpBVrtD9O9M87Dqyrk-3l8akmH0_Zuw=.28bae6b0-2186-4b1f-80f2-28e032047247@github.com>

On Wed, 26 May 2021 07:39:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
> 
> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
> 
> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
> 
> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
> 
> Additional testing:
>  - [x] `runtime/valhalla` tests

The corresponding tests in `compiler/valhalla/inlinetypes` should be renamed as well (see `TestBufferTearing.java` and `TestBufferTearingC1.java`).

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

PR: https://git.openjdk.java.net/valhalla/pull/428


From ngasson at openjdk.java.net  Thu May 27 10:19:41 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 27 May 2021 10:19:41 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs [v2]
In-Reply-To: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
Message-ID: <STdQadHXy0GFbqrW8i44nYjSpmvORyPv6sbXt61n3g4=.f7938778-1f47-4c7b-97dd-0f5b80778645@github.com>

> This patch implements InlineTypePassFieldsAsArgs on AArch64 and the
> associated stack extension/repair mechanism. It mostly follows the x86
> implementation closely except for how the stack increment is stored in
> the callee frame. On x86 the sp_inc stack slot stores the total size of
> the frame which is the sum of the extension space, return address copy,
> and the original method frame size (i.e. the total bytes needed to pop
> the frame). On AArch64 we just store the size of the extension space. I
> did it this way because it simplifies the stack repair code in
> MacroAssembler::remove_frame (I've added some notes there to document
> this). I don't think this should cause any problem because only the
> MacroAssembler and platform-dependant frame walking code need to be
> aware of this.
> 
> This patch includes JDK-8266609 which is a small refactoring in mainline
> JDK to simplify how the frame size is passed around in the AArch64 C1
> backend.
> 
> There was some X86 specific code in unpack_inline_args() in
> macroAssembler_common.cpp. I've split this out into an arch-dependant
> MacroAssembler::extend_stack_for_inline_args().
> 
> MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take
> a new Register val_array argument which is the register holding the
> buffered oop array for packing. Previously it assumed this was already
> loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly
> makes the code easier to understand.
> 
> There is one new test failure: TestNullableInlineTypes.java. The test
> seems functionally correct but there is a failure verifying the C2 IR
> graph (see below). I haven't investigated this but the test enables
> InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that
> might be causing the failure.
> 
> 
> Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableInlineTypes::test26' contains forbidden node:
> 83  StoreL  ===  176  177  84  14  [[ 89 ]]  @compiler/valhalla/inlinetypes/MyValue3:exact+16 *, name=l, idx=6;  Memory: @rawptr:BotPTR, idx=Raw; !orig=82 !jvms: TestNullableInlineTypes::test26 @ bci:13 (line 704): expected false, was true
> 
> 
> Tested tier1, runtime/valhalla, and compiler/valhalla on x86 and AArch64. There are some "bad AD file" failures on x86 but don't seem to be related to this patch.

Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:

  Store total frame size in sp_inc

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/420/files
  - new: https://git.openjdk.java.net/valhalla/pull/420/files/435308d6..d9fa5724

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

  Stats: 30 lines in 4 files changed: 8 ins; 7 del; 15 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/420.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/420/head:pull/420

PR: https://git.openjdk.java.net/valhalla/pull/420


From ngasson at openjdk.java.net  Thu May 27 10:23:26 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 27 May 2021 10:23:26 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs [v2]
In-Reply-To: <MfDmcMX3CaQvZf2H1uGhhD60H8RfLs1udZW0gHXAjkU=.b36de946-93fa-4cb9-8638-202f727ed80a@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
 <MfDmcMX3CaQvZf2H1uGhhD60H8RfLs1udZW0gHXAjkU=.b36de946-93fa-4cb9-8638-202f727ed80a@github.com>
Message-ID: <yBHW2oPdTXgOxY2-2ViIpltiWtYUg_UHt_fklrHDYrs=.c95fdbf8-6bfe-4790-a67a-3dbd1346e876@github.com>

On Thu, 27 May 2021 07:14:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> 
> But that only simplifies the C++ code and not the assembly code that is emitted right? I wonder if we shouldn't aim for optimal assembly because this code will be exercised a lot.

Yes. I thought about it a bit more and I've modified it slightly so the sp_inc stack slot stores `total_frame_size - 2*wordSize` which is more like x86 and also saves one instruction when removing the frame (see the last commit 
d9fa572).

> 
> Could you please file bugs for the other issues that you were seeing?
> 

Sure. Do you have any ideas about this one? https://bugs.openjdk.java.net/browse/JDK-8264340

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

PR: https://git.openjdk.java.net/valhalla/pull/420


From ngasson at openjdk.java.net  Thu May 27 10:32:30 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 27 May 2021 10:32:30 GMT
Subject: [lworld] RFR: 8267818: [lworld] [AArch64] Shenandoah barrier set
 build warnings and register conflict
Message-ID: <Eq2dUy6nyWN3T7B9o2V1C3g0Gmo4FrFEwETaK2uHBmk=.549e6938-0a88-4119-9d87-8f29da9e5ebd@github.com>

I get this warning when building with Shenandoah enabled on AArch64:

[...]/barrierSetAssembler_aarch64.hpp:47:16: warning: 'virtual void BarrierSetAssembler::store_at(MacroAssembler*, DecoratorSet, BasicType, Address, Register, Register, Register, Register)' was hidden [-Woverloaded-virtual]

BarrierSetAssembler::store_at() gained an extra tmp3 argument. (The 
same fix was already applied on x86.)

ShenahdoahBarrierSetAssembler::load_at() uses rscratch1 and rscratch2
internally but the interpreter _fast_qgetfield implementation passes
rscratch1 as a separate temporary via get_default_value_oop() which
causes an assert_different_registers() failure. Instead just allocate a
fresh temporary register and pass that.

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

Commit messages:
 - 8267818: [lworld] [AArch64] Shenandoah barrier set build warnings and register conflict

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

PR: https://git.openjdk.java.net/valhalla/pull/430


From fparain at openjdk.java.net  Thu May 27 21:08:27 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 27 May 2021 21:08:27 GMT
Subject: [lworld] RFR: 8267818: [lworld] [AArch64] Shenandoah barrier set
 build warnings and register conflict
In-Reply-To: <Eq2dUy6nyWN3T7B9o2V1C3g0Gmo4FrFEwETaK2uHBmk=.549e6938-0a88-4119-9d87-8f29da9e5ebd@github.com>
References: <Eq2dUy6nyWN3T7B9o2V1C3g0Gmo4FrFEwETaK2uHBmk=.549e6938-0a88-4119-9d87-8f29da9e5ebd@github.com>
Message-ID: <-jl5ZZaliuvlFJ9-tpIB8KPY4fhxcMnwgKztMUp4OjM=.ab853217-9c0d-4542-8d92-ff949730a009@github.com>

On Thu, 27 May 2021 10:26:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I get this warning when building with Shenandoah enabled on AArch64:
> 
> [...]/barrierSetAssembler_aarch64.hpp:47:16: warning: 'virtual void BarrierSetAssembler::store_at(MacroAssembler*, DecoratorSet, BasicType, Address, Register, Register, Register, Register)' was hidden [-Woverloaded-virtual]
> 
> BarrierSetAssembler::store_at() gained an extra tmp3 argument. (The 
> same fix was already applied on x86.)
> 
> ShenahdoahBarrierSetAssembler::load_at() uses rscratch1 and rscratch2
> internally but the interpreter _fast_qgetfield implementation passes
> rscratch1 as a separate temporary via get_default_value_oop() which
> causes an assert_different_registers() failure. Instead just allocate a
> fresh temporary register and pass that.

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/430


From thartmann at openjdk.java.net  Fri May 28 09:26:24 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 28 May 2021 09:26:24 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs [v2]
In-Reply-To: <STdQadHXy0GFbqrW8i44nYjSpmvORyPv6sbXt61n3g4=.f7938778-1f47-4c7b-97dd-0f5b80778645@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
 <STdQadHXy0GFbqrW8i44nYjSpmvORyPv6sbXt61n3g4=.f7938778-1f47-4c7b-97dd-0f5b80778645@github.com>
Message-ID: <83_2gmZTOYDxNGCEzlV33_NLI13i5xDxS9-cBu15tXE=.d430689c-b3cf-4750-809e-9cc00a21618e@github.com>

On Thu, 27 May 2021 10:19:41 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> This patch implements InlineTypePassFieldsAsArgs on AArch64 and the
>> associated stack extension/repair mechanism. It mostly follows the x86
>> implementation closely except for how the stack increment is stored in
>> the callee frame. On x86 the sp_inc stack slot stores the total size of
>> the frame which is the sum of the extension space, return address copy,
>> and the original method frame size (i.e. the total bytes needed to pop
>> the frame). On AArch64 we just store the size of the extension space. I
>> did it this way because it simplifies the stack repair code in
>> MacroAssembler::remove_frame (I've added some notes there to document
>> this). I don't think this should cause any problem because only the
>> MacroAssembler and platform-dependant frame walking code need to be
>> aware of this.
>> 
>> This patch includes JDK-8266609 which is a small refactoring in mainline
>> JDK to simplify how the frame size is passed around in the AArch64 C1
>> backend.
>> 
>> There was some X86 specific code in unpack_inline_args() in
>> macroAssembler_common.cpp. I've split this out into an arch-dependant
>> MacroAssembler::extend_stack_for_inline_args().
>> 
>> MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take
>> a new Register val_array argument which is the register holding the
>> buffered oop array for packing. Previously it assumed this was already
>> loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly
>> makes the code easier to understand.
>> 
>> There is one new test failure: TestNullableInlineTypes.java. The test
>> seems functionally correct but there is a failure verifying the C2 IR
>> graph (see below). I haven't investigated this but the test enables
>> InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that
>> might be causing the failure.
>> 
>> 
>> Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableInlineTypes::test26' contains forbidden node:
>> 83  StoreL  ===  176  177  84  14  [[ 89 ]]  @compiler/valhalla/inlinetypes/MyValue3:exact+16 *, name=l, idx=6;  Memory: @rawptr:BotPTR, idx=Raw; !orig=82 !jvms: TestNullableInlineTypes::test26 @ bci:13 (line 704): expected false, was true
>> 
>> 
>> Tested tier1, runtime/valhalla, and compiler/valhalla on x86 and AArch64. There are some "bad AD file" failures on x86 but don't seem to be related to this patch.
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Store total frame size in sp_inc

Looks good to me.

> Sure. Do you have any ideas about this one? https://bugs.openjdk.java.net/browse/JDK-8264340

That doesn't ring a bell. Is it reproducible?

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/420


From thartmann at openjdk.java.net  Fri May 28 12:25:38 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 28 May 2021 12:25:38 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1)
Message-ID: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>

After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.

All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.

Thanks,
Tobias

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

Commit messages:
 - Removed debug code
 - 8267846: [lworld] JIT support for the L/Q model (step 1)

Changes: https://git.openjdk.java.net/valhalla/pull/431/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=431&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267846
  Stats: 343 lines in 38 files changed: 142 ins; 47 del; 154 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/431.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/431/head:pull/431

PR: https://git.openjdk.java.net/valhalla/pull/431


From fparain at openjdk.java.net  Fri May 28 15:56:14 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 28 May 2021 15:56:14 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1)
In-Reply-To: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
Message-ID: <CCdVT4ZWKmnU8TerpnBcS4kne8nao7AjzFq4E5UVtu4=.2faab047-f7fa-4851-8280-1264168f314f@github.com>

On Fri, 28 May 2021 12:18:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.
> 
> All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.
> 
> Thanks,
> Tobias

src/hotspot/share/c1/c1_Instruction.cpp line 142:

> 140:     if (type != NULL) {
> 141:       if (type->is_obj_array_klass() && !type->as_obj_array_klass()->is_elem_null_free()) {
> 142:         // The runtime type of [LMyValue might be [QMyValue due to [QMyValue <: [LMyValue.

if type->is_obj_array_klass() is true and type->as_obj_array_klass()->is_elem_null_free() is also true, the method returns false, is it the expected behavior?

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

PR: https://git.openjdk.java.net/valhalla/pull/431


From thartmann at openjdk.java.net  Mon May 31 06:32:35 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 06:32:35 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1)
In-Reply-To: <CCdVT4ZWKmnU8TerpnBcS4kne8nao7AjzFq4E5UVtu4=.2faab047-f7fa-4851-8280-1264168f314f@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
 <CCdVT4ZWKmnU8TerpnBcS4kne8nao7AjzFq4E5UVtu4=.2faab047-f7fa-4851-8280-1264168f314f@github.com>
Message-ID: <JHqp7R41GsGwfX2mmedSf-5_0DIZO_Muw5sc0mpWK38=.1d323de2-de31-4927-b14d-02b2602bdc1e@github.com>

On Fri, 28 May 2021 15:45:36 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.
>> 
>> All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.
>> 
>> Thanks,
>> Tobias
>
> src/hotspot/share/c1/c1_Instruction.cpp line 142:
> 
>> 140:     if (type != NULL) {
>> 141:       if (type->is_obj_array_klass() && !type->as_obj_array_klass()->is_elem_null_free()) {
>> 142:         // The runtime type of [LMyValue might be [QMyValue due to [QMyValue <: [LMyValue.
> 
> if type->is_obj_array_klass() is true and type->as_obj_array_klass()->is_elem_null_free() is also true, the method returns false, is it the expected behavior?

Yes, because in that case we have a null-free but non-flattened array. Right?

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

PR: https://git.openjdk.java.net/valhalla/pull/431


From ngasson at openjdk.java.net  Mon May 31 06:43:42 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 31 May 2021 06:43:42 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs [v2]
In-Reply-To: <83_2gmZTOYDxNGCEzlV33_NLI13i5xDxS9-cBu15tXE=.d430689c-b3cf-4750-809e-9cc00a21618e@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
 <STdQadHXy0GFbqrW8i44nYjSpmvORyPv6sbXt61n3g4=.f7938778-1f47-4c7b-97dd-0f5b80778645@github.com>
 <83_2gmZTOYDxNGCEzlV33_NLI13i5xDxS9-cBu15tXE=.d430689c-b3cf-4750-809e-9cc00a21618e@github.com>
Message-ID: <W8wWVtQ1k2QdvQexuY1YNeQJBSAw_RQOdVgkb_gnfU4=.d9cb5d1a-f116-4efb-bf0a-2fc44a4fb41d@github.com>

On Fri, 28 May 2021 09:23:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> > Sure. Do you have any ideas about this one? https://bugs.openjdk.java.net/browse/JDK-8264340
> 
> That doesn't ring a bell. Is it reproducible?

Yes, it always fails in that way on AArch64. It seems to be related to scheduling: I just ran it on x86 with `-XX:+UseOptoScheduling` and it also fails.

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

PR: https://git.openjdk.java.net/valhalla/pull/420


From shade at redhat.com  Mon May 31 09:07:24 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 31 May 2021 11:07:24 +0200
Subject: Pull current jdk/jdk to lworld?
Message-ID: <b773cfea-7c09-7cae-fbee-b54fc229b803@redhat.com>

Hi,

Could anyone pull current jdk/jdk to lworld? There are plenty of build failures in current lworld 
that are fixed in mainline.

-- 
Thanks,
-Aleksey



From shade at openjdk.java.net  Mon May 31 09:11:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 09:11:34 GMT
Subject: [lworld] RFR: 8267710: [lworld][lw3] Hook AlwaysAtomicAccesses to
 primitive classes atomicity rules [v2]
In-Reply-To: <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
 <m5Z-4wHduJAiUWfF9PWNMAjC99y1KVoPNZlFaabmukg=.3b2e1ae2-6e40-42da-842a-35af6d3a1fd1@github.com>
Message-ID: <ZtOnzbx3S_bRpNxUevBOmVw95xtQHcSqMEi9etBR0ts=.5117834d-a1d9-4341-9bd3-04792c2a8f9c@github.com>

On Wed, 26 May 2021 06:58:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
>> 
>> Testing:
>>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also add in another method

Any sponsors? :)

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From shade at openjdk.java.net  Mon May 31 09:29:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 09:29:46 GMT
Subject: [lworld] Integrated: 8267710: [lworld][lw3] Hook AlwaysAtomicAccesses
 to primitive classes atomicity rules
In-Reply-To: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
References: <GcZtwmIsJ5itCabzej1mbbmQk2-Sn3rHXi6RHK48Os0=.b2f70f49-c5b1-482b-8b83-32276c77ecc7@github.com>
Message-ID: <FNhFBkZjEvDG0NOtwtRp-l1m9RzQhyPk_CLnLL_JRDk=.dff723f7-7e99-4584-85aa-051c4fd85adf@github.com>

On Tue, 25 May 2021 17:27:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `AlwaysAtomicAccesses` was added in JDK 9 to aid the research in the costs of requiring the always-atomic accesses. It would be nice to hook it up to current Valhalla code that handles explicitly declared atomic primitive classes.
> 
> Testing:
>  - [x] ad-hoc jcstress tests with lworld and `-XX:(-|+)AlwaysAtomicAccesses`

This pull request has now been integrated.

Changeset: 0f1c33c7
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0f1c33c725e4baa23c1d90029301553a1fde38db
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8267710: [lworld][lw3] Hook AlwaysAtomicAccesses to primitive classes atomicity rules

Reviewed-by: fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/427


From ngasson at openjdk.java.net  Mon May 31 09:31:34 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 31 May 2021 09:31:34 GMT
Subject: [lworld] Integrated: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs
In-Reply-To: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
Message-ID: <1eRguOdwvO9evT65UgjY9fpBKTCKei4zwX-s5f2dK2A=.dd94a4f9-8ac3-487d-9209-1a3bbd0736fe@github.com>

On Fri, 21 May 2021 10:40:29 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This patch implements InlineTypePassFieldsAsArgs on AArch64 and the
> associated stack extension/repair mechanism. It mostly follows the x86
> implementation closely except for how the stack increment is stored in
> the callee frame. On x86 the sp_inc stack slot stores the total size of
> the frame which is the sum of the extension space, return address copy,
> and the original method frame size (i.e. the total bytes needed to pop
> the frame). On AArch64 we just store the size of the extension space. I
> did it this way because it simplifies the stack repair code in
> MacroAssembler::remove_frame (I've added some notes there to document
> this). I don't think this should cause any problem because only the
> MacroAssembler and platform-dependant frame walking code need to be
> aware of this.
> 
> This patch includes JDK-8266609 which is a small refactoring in mainline
> JDK to simplify how the frame size is passed around in the AArch64 C1
> backend.
> 
> There was some X86 specific code in unpack_inline_args() in
> macroAssembler_common.cpp. I've split this out into an arch-dependant
> MacroAssembler::extend_stack_for_inline_args().
> 
> MacroAssembler::pack_inline_helper() and shuffle_inline_args() now take
> a new Register val_array argument which is the register holding the
> buffered oop array for packing. Previously it assumed this was already
> loaded in RAX (x86) or x20 (AArch64) but IMO passing it in explicitly
> makes the code easier to understand.
> 
> There is one new test failure: TestNullableInlineTypes.java. The test
> seems functionally correct but there is a failure verifying the C2 IR
> graph (see below). I haven't investigated this but the test enables
> InlineTypePassFieldsAsArgs which we don't support yet on AArch64 so that
> might be causing the failure.
> 
> 
> Exception in thread "main" java.lang.RuntimeException: Graph for 'TestNullableInlineTypes::test26' contains forbidden node:
> 83  StoreL  ===  176  177  84  14  [[ 89 ]]  @compiler/valhalla/inlinetypes/MyValue3:exact+16 *, name=l, idx=6;  Memory: @rawptr:BotPTR, idx=Raw; !orig=82 !jvms: TestNullableInlineTypes::test26 @ bci:13 (line 704): expected false, was true
> 
> 
> Tested tier1, runtime/valhalla, and compiler/valhalla on x86 and AArch64. There are some "bad AD file" failures on x86 but don't seem to be related to this patch.

This pull request has now been integrated.

Changeset: 08715901
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/08715901f7463dc5bf77fc76ab33958c4de4e0bf
Stats:     510 lines in 21 files changed: 239 ins; 114 del; 157 mod

8266890: [lworld] [AArch64] add support for InlineTypePassFieldsAsArgs

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/420


From thartmann at openjdk.java.net  Mon May 31 09:31:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 09:31:33 GMT
Subject: [lworld] RFR: 8266890: [lworld] [AArch64] add support for
 InlineTypePassFieldsAsArgs [v2]
In-Reply-To: <W8wWVtQ1k2QdvQexuY1YNeQJBSAw_RQOdVgkb_gnfU4=.d9cb5d1a-f116-4efb-bf0a-2fc44a4fb41d@github.com>
References: <zi5-p5MHnG5eJ-5jN2MZKrGbfZVc0JFwfNkngbcJ4QI=.70a1d9fd-a4ae-4723-8b63-21856a59a19c@github.com>
 <STdQadHXy0GFbqrW8i44nYjSpmvORyPv6sbXt61n3g4=.f7938778-1f47-4c7b-97dd-0f5b80778645@github.com>
 <83_2gmZTOYDxNGCEzlV33_NLI13i5xDxS9-cBu15tXE=.d430689c-b3cf-4750-809e-9cc00a21618e@github.com>
 <W8wWVtQ1k2QdvQexuY1YNeQJBSAw_RQOdVgkb_gnfU4=.d9cb5d1a-f116-4efb-bf0a-2fc44a4fb41d@github.com>
Message-ID: <wf-SXYGAZb8V8jwpJ9LwT6h0zr59ew6CFyh9P6pN9fg=.6b63833a-b006-4a19-8ad0-66d757178f69@github.com>

On Mon, 31 May 2021 06:40:57 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Yes, it always fails in that way on AArch64. It seems to be related to scheduling: I just ran it on x86 with -XX:+UseOptoScheduling and it also fails.

Okay, thanks for the details!

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

PR: https://git.openjdk.java.net/valhalla/pull/420


From ngasson at openjdk.java.net  Mon May 31 09:32:32 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 31 May 2021 09:32:32 GMT
Subject: [lworld] Integrated: 8267818: [lworld] [AArch64] Shenandoah barrier
 set build warnings and register conflict
In-Reply-To: <Eq2dUy6nyWN3T7B9o2V1C3g0Gmo4FrFEwETaK2uHBmk=.549e6938-0a88-4119-9d87-8f29da9e5ebd@github.com>
References: <Eq2dUy6nyWN3T7B9o2V1C3g0Gmo4FrFEwETaK2uHBmk=.549e6938-0a88-4119-9d87-8f29da9e5ebd@github.com>
Message-ID: <CPBdDLDMYj747XhWkQUpHwG_pR1y6g1PYRzdpOCsPlQ=.00203a89-63eb-4c5d-89de-3a8397b80a29@github.com>

On Thu, 27 May 2021 10:26:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I get this warning when building with Shenandoah enabled on AArch64:
> 
> [...]/barrierSetAssembler_aarch64.hpp:47:16: warning: 'virtual void BarrierSetAssembler::store_at(MacroAssembler*, DecoratorSet, BasicType, Address, Register, Register, Register, Register)' was hidden [-Woverloaded-virtual]
> 
> BarrierSetAssembler::store_at() gained an extra tmp3 argument. (The 
> same fix was already applied on x86.)
> 
> ShenahdoahBarrierSetAssembler::load_at() uses rscratch1 and rscratch2
> internally but the interpreter _fast_qgetfield implementation passes
> rscratch1 as a separate temporary via get_default_value_oop() which
> causes an assert_different_registers() failure. Instead just allocate a
> fresh temporary register and pass that.

This pull request has now been integrated.

Changeset: 44cb67ea
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/44cb67ea3457e7359a3c055a08a4105bbd068564
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

8267818: [lworld] [AArch64] Shenandoah barrier set build warnings and register conflict

Reviewed-by: fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/430


From shade at openjdk.java.net  Mon May 31 09:36:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 09:36:40 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
Message-ID: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>

> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
> 
> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
> 
> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
> 
> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
> 
> Additional testing:
>  - [x] `runtime/valhalla` tests

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

  Rename a few other tests

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/428/files
  - new: https://git.openjdk.java.net/valhalla/pull/428/files/63f0fa7d..2d2274c0

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

  Stats: 313 lines in 3 files changed: 155 ins; 154 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/428.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/428/head:pull/428

PR: https://git.openjdk.java.net/valhalla/pull/428


From shade at openjdk.java.net  Mon May 31 09:36:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 09:36:40 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic"
In-Reply-To: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
Message-ID: <kbJORr3g2IokswtEdCazkSQyiC2c1ds88_IYx4MvRM8=.0acea3a9-4f6a-4e3e-aae4-dc45bd3909db@github.com>

On Wed, 26 May 2021 07:39:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
> 
> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
> 
> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
> 
> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
> 
> Additional testing:
>  - [x] `runtime/valhalla` tests

Renamed other "tearing" tests too now. `compiler/valhalla` passes with Linux x86_64 fastdebug builds.

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

PR: https://git.openjdk.java.net/valhalla/pull/428


From shade at openjdk.java.net  Mon May 31 09:45:11 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 09:45:11 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes
 for inline types [v2]
In-Reply-To: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
Message-ID: <7ErDzSmBDFjRiY6dOVaLNWQZKDwkToEe5G8Ysm7JS1Y=.3ea6623d-3cd8-4eb9-b08f-5b8397b056f7@github.com>

> JDK-8259316 added the support for compiler blackholes. We need to check and implement the support for inline type arguments for them. I am sure we would find more wrinkles with nano-benchmarks, but insofar sample benchmark work as they should:
> 
> 
> public class PrimitiveClasses {
>     static primitive class Value {
>         long x;
>         long y;
>         public Value(long x, long y) {
>             this.x = x;
>             this.y = y;
>         }
>     }
> 
>     [volatile] Value v = Value.default;
> 
>     @Benchmark
>     public Value test() {
>         return v;
>     }
> }
> 
> 
> Before: crash on assert, `assert(vt->fast_out(i)->is_InlineTypeBase(), "Unexpected inline type user");`
> 
> After, generated code in non-`volatile` case shows blackhole of individual components:
> 
> 
> $ java -Djmh.blackhole.mode=COMPILER -jar target/benchmarks.jar PrimitiveClasses -prof perfasm
> ...
> ....[Hottest Region 1]..............................................................................
> c2, level 4, org.openjdk.jmh_generated.PrimitiveClasses_test_jmhTest::test_avgt_jmhStub, version 641 (39 bytes) 
> ...
>          ?  0x00007f67bcc8eee0:   mov    0x18(%r8),%r10        ; read and blackhole MyValue.x
>   0.02%  ?  0x00007f67bcc8eee4:   mov    0x10(%r8),%r11        ; read and blackhole MyValue.y
>   0.10%  ?  0x00007f67bcc8eee8:   movzbl 0x94(%r14),%r11d      ; read isDone
>   0.10%  ?  0x00007f67bcc8eef0:   mov    0x3b0(%r15),%r10      ; TL handshake
>   2.79%  ?  0x00007f67bcc8eef7:   add    $0x1,%rbp             ; ops++
>          ?  0x00007f67bcc8eefb:   test   %eax,(%r10)           ; TL handshake
>  86.74%  ?  0x00007f67bcc8eefe:   test   %r11d,%r11d           ; isDone?
>   2.31%  ?  0x00007f67bcc8ef01:   je     0x00007f67bcc8eee0    
> 
> 
> And generated code in `volatile` case shows blackhole of the box (with the null-check):
> 
> 
>           ?   0x00007f3948c8db70:   shl    $0x3,%r10            ; unpack and blackhole MyValue
>   0.02%   ??  0x00007f3948c8db74:   movzbl 0x94(%r14),%r8d      ; read isDone
>   0.68%   ??  0x00007f3948c8db7c:   mov    0x3b0(%r15),%r9      ; TL handshake
>   0.72%   ??  0x00007f3948c8db83:   add    $0x1,%rbp            ; ops++
>           ??  0x00007f3948c8db87:   test   %eax,(%r9)           ; TL handshake
>  92.30%   ??  0x00007f3948c8db8a:   test   %r8d,%r8d            ; isDone?
>          ???  0x00007f3948c8db8d:   jne    0x00007f3948c8dba4   
>          ???  0x00007f3948c8db8f:   mov    0xc(%r11),%r10d      ; load "v" (MyValue box)
>   0.35%  ???  0x00007f3948c8db93:   test   %r10d,%r10d          ; null check it
>          ???  0x00007f3948c8db96:   jne    0x00007f3948c8db70

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Replace: box -> buffer
 - Move the test

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/429/files
  - new: https://git.openjdk.java.net/valhalla/pull/429/files/909d929a..20ecae3f

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

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From shade at openjdk.java.net  Mon May 31 09:45:17 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 09:45:17 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes
 for inline types [v2]
In-Reply-To: <Kv4ogLj6y7nN8FTtC7n8EiAK1Ed9WdUR4ZeZ5qmxV9E=.7d6c5f89-928a-4c15-9cda-9502986ffffa@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
 <Kv4ogLj6y7nN8FTtC7n8EiAK1Ed9WdUR4ZeZ5qmxV9E=.7d6c5f89-928a-4c15-9cda-9502986ffffa@github.com>
Message-ID: <ZvFFLPOlZLFs4ppDHF37rQa2OQFtiB5lvb7uN8iscb8=.8189d870-f97d-4153-af6a-17c7a789ed11@github.com>

On Thu, 27 May 2021 07:28:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace: box -> buffer
>>  - Move the test
>
> src/hotspot/share/opto/compile.cpp line 1931:
> 
>> 1929:       } else {
>> 1930:         // Check if any users are blackholes. If so, rewrite them to use either the
>> 1931:         // allocated box, or individual components, instead of the inline type node
> 
> Better replace `box` by `buffer`.

Done.

> src/hotspot/share/opto/compile.cpp line 1945:
> 
>> 1943:             if (vt->is_allocated(&igvn)) {
>> 1944:               // Already has the allocated instance, blackhole that
>> 1945:               bh->add_req(vt->get_oop());
> 
> This might keep an otherwise unused buffer allocation alive. Is that the expected behavior of using backholes on inline types? Why not always blackhole the components?

The expected behavior is debatable. Current behavior in the corner cases does make sense to me: for non-flattened cases, we blackhole the reference to wrapper (as that is what application code would be exposed to), in flattened cases, we blackhole the components (as that is what application code would be exposed to). 

I probably misunderstand the compiler code here. Can there be an allocated box that goes away later, and only the component accesses survive? If so, how should this code ask for "if the allocated instance is alive, then blackhole it"?

> test/hotspot/jtreg/runtime/valhalla/inlinetypes/BlackholeTest.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: package runtime.valhalla.inlinetypes;
> 
> I think this test should go to compiler.

Done.

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From thartmann at openjdk.java.net  Mon May 31 12:23:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 12:23:41 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
Message-ID: <AsVkVVWKweeBSUKGCBAfc6vO9j_Jt8bUjrQG1Ae3mWg=.7cc4fa45-ca52-4c9b-b070-61f87b9ff63d@github.com>

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

Looks good to me but since most of this touches runtime code, someone from runtime should review.

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

PR: https://git.openjdk.java.net/valhalla/pull/428


From thartmann at openjdk.java.net  Mon May 31 12:49:36 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 12:49:36 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes
 for inline types [v2]
In-Reply-To: <7ErDzSmBDFjRiY6dOVaLNWQZKDwkToEe5G8Ysm7JS1Y=.3ea6623d-3cd8-4eb9-b08f-5b8397b056f7@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
 <7ErDzSmBDFjRiY6dOVaLNWQZKDwkToEe5G8Ysm7JS1Y=.3ea6623d-3cd8-4eb9-b08f-5b8397b056f7@github.com>
Message-ID: <3Oqv2OEd9T6sBvarmOww3eZtQ-pshtrXMea2C_rPF1c=.a00ea3c2-abdc-4d91-b485-d9e132ff443e@github.com>

On Mon, 31 May 2021 09:45:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> JDK-8259316 added the support for compiler blackholes. We need to check and implement the support for inline type arguments for them. I am sure we would find more wrinkles with nano-benchmarks, but insofar sample benchmark work as they should:
>> 
>> 
>> public class PrimitiveClasses {
>>     static primitive class Value {
>>         long x;
>>         long y;
>>         public Value(long x, long y) {
>>             this.x = x;
>>             this.y = y;
>>         }
>>     }
>> 
>>     [volatile] Value v = Value.default;
>> 
>>     @Benchmark
>>     public Value test() {
>>         return v;
>>     }
>> }
>> 
>> 
>> Before: crash on assert, `assert(vt->fast_out(i)->is_InlineTypeBase(), "Unexpected inline type user");`
>> 
>> After, generated code in non-`volatile` case shows blackhole of individual components:
>> 
>> 
>> $ java -Djmh.blackhole.mode=COMPILER -jar target/benchmarks.jar PrimitiveClasses -prof perfasm
>> ...
>> ....[Hottest Region 1]..............................................................................
>> c2, level 4, org.openjdk.jmh_generated.PrimitiveClasses_test_jmhTest::test_avgt_jmhStub, version 641 (39 bytes) 
>> ...
>>          ?  0x00007f67bcc8eee0:   mov    0x18(%r8),%r10        ; read and blackhole MyValue.x
>>   0.02%  ?  0x00007f67bcc8eee4:   mov    0x10(%r8),%r11        ; read and blackhole MyValue.y
>>   0.10%  ?  0x00007f67bcc8eee8:   movzbl 0x94(%r14),%r11d      ; read isDone
>>   0.10%  ?  0x00007f67bcc8eef0:   mov    0x3b0(%r15),%r10      ; TL handshake
>>   2.79%  ?  0x00007f67bcc8eef7:   add    $0x1,%rbp             ; ops++
>>          ?  0x00007f67bcc8eefb:   test   %eax,(%r10)           ; TL handshake
>>  86.74%  ?  0x00007f67bcc8eefe:   test   %r11d,%r11d           ; isDone?
>>   2.31%  ?  0x00007f67bcc8ef01:   je     0x00007f67bcc8eee0    
>> 
>> 
>> And generated code in `volatile` case shows blackhole of the box (with the null-check):
>> 
>> 
>>           ?   0x00007f3948c8db70:   shl    $0x3,%r10            ; unpack and blackhole MyValue
>>   0.02%   ??  0x00007f3948c8db74:   movzbl 0x94(%r14),%r8d      ; read isDone
>>   0.68%   ??  0x00007f3948c8db7c:   mov    0x3b0(%r15),%r9      ; TL handshake
>>   0.72%   ??  0x00007f3948c8db83:   add    $0x1,%rbp            ; ops++
>>           ??  0x00007f3948c8db87:   test   %eax,(%r9)           ; TL handshake
>>  92.30%   ??  0x00007f3948c8db8a:   test   %r8d,%r8d            ; isDone?
>>          ???  0x00007f3948c8db8d:   jne    0x00007f3948c8dba4   
>>          ???  0x00007f3948c8db8f:   mov    0xc(%r11),%r10d      ; load "v" (MyValue box)
>>   0.35%  ???  0x00007f3948c8db93:   test   %r10d,%r10d          ; null check it
>>          ???  0x00007f3948c8db96:   jne    0x00007f3948c8db70
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Replace: box -> buffer
>  - Move the test

Marked as reviewed by thartmann (Committer).

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From thartmann at openjdk.java.net  Mon May 31 12:49:37 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 12:49:37 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes
 for inline types [v2]
In-Reply-To: <ZvFFLPOlZLFs4ppDHF37rQa2OQFtiB5lvb7uN8iscb8=.8189d870-f97d-4153-af6a-17c7a789ed11@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
 <Kv4ogLj6y7nN8FTtC7n8EiAK1Ed9WdUR4ZeZ5qmxV9E=.7d6c5f89-928a-4c15-9cda-9502986ffffa@github.com>
 <ZvFFLPOlZLFs4ppDHF37rQa2OQFtiB5lvb7uN8iscb8=.8189d870-f97d-4153-af6a-17c7a789ed11@github.com>
Message-ID: <G37R51E8zsq8Q7T6HnTEYZ2EdbQKH3w5_Smm1NqguMs=.cb6ab320-4014-409f-8730-f5f1492a460d@github.com>

On Mon, 31 May 2021 09:38:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/opto/compile.cpp line 1945:
>> 
>>> 1943:             if (vt->is_allocated(&igvn)) {
>>> 1944:               // Already has the allocated instance, blackhole that
>>> 1945:               bh->add_req(vt->get_oop());
>> 
>> This might keep an otherwise unused buffer allocation alive. Is that the expected behavior of using backholes on inline types? Why not always blackhole the components?
>
> The expected behavior is debatable. Current behavior in the corner cases does make sense to me: for non-flattened cases, we blackhole the reference to wrapper (as that is what application code would be exposed to), in flattened cases, we blackhole the components (as that is what application code would be exposed to). 
> 
> I probably misunderstand the compiler code here. Can there be an allocated box that goes away later, and only the component accesses survive? If so, how should this code ask for "if the allocated instance is alive, then blackhole it"?

On second thought, I think this is fine.

> Can there be an allocated box that goes away later, and only the component accesses survive?

Yes, in general that can happen and is not unlikely. For example, due to late inlining or other optimizations removing a non-scalarizable use of the buffer allocation. However, in this case all such optimizations are already over and unused allocations would have been removed. I.e., if `vt->is_allocated` is true, there is a user of the buffer allocation that won't go away and therefore linking the allocation to the blackhole should be fine.

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From sadayapalam at openjdk.java.net  Mon May 31 12:57:12 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 May 2021 12:57:12 GMT
Subject: [lworld] Integrated: 8267923: [lworld] Javac's implementation differs
 from JEP401 in a few matters.
Message-ID: <cZGMAgSHaKceouccRUOdJr9UyRy9SA_1CYEYNfKnMqQ=.3a4c67eb-32b0-4dda-b877-2138f28204b6@github.com>

Cumulative fix for the following issues:

    JDK-8267918 - Javac tolerates synchronizing on a primitive reference type
    JDK-8267907 - Withdraw support for the experimental option -XDallowValueMemberCycles
    JDK-8267843 - Duplicate error when primitive class instance is passed around before being fully initialized
    JDK-8267841 - A primitive class that implements Cloneable is tolerated by javac
    JDK-8267835 - Javac tolerates vacuous chaining to super constructor from primitive class constructor
    JDK-8267965 - Javac disallows calls to super.{hashCode(), equals(), toString()} on a primitive instance receiver

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

Commit messages:
 - Fix failures in tier1
 - 8267835: Javac tolerates vacuous chaining to super constructor from primitive class constructor
 - 8267843: Double diagnostics when primitive class instance is passed around before being fully initialized
 - 8267965:  Javac disallows calls to super.{hashCode(), equals(), toString()} on a primitive instance receiver
 - 8267841: A primitive class that implements Cloneable is tolerated by javac
 - 8267918:  Javac tolerates synchronizing on a primitive reference type
 - 8267907: Withdraw support for the experimental option -XDallowValueMemberCycles

Changes: https://git.openjdk.java.net/valhalla/pull/432/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=432&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267923
  Stats: 308 lines in 19 files changed: 271 ins; 20 del; 17 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/432.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/432/head:pull/432

PR: https://git.openjdk.java.net/valhalla/pull/432


From sadayapalam at openjdk.java.net  Mon May 31 12:57:13 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 May 2021 12:57:13 GMT
Subject: [lworld] Integrated: 8267923: [lworld] Javac's implementation differs
 from JEP401 in a few matters.
In-Reply-To: <cZGMAgSHaKceouccRUOdJr9UyRy9SA_1CYEYNfKnMqQ=.3a4c67eb-32b0-4dda-b877-2138f28204b6@github.com>
References: <cZGMAgSHaKceouccRUOdJr9UyRy9SA_1CYEYNfKnMqQ=.3a4c67eb-32b0-4dda-b877-2138f28204b6@github.com>
Message-ID: <vTFSscvEE3ssIQe7uzCtaDNOLAZY8kPMcxXF2GR9Cq8=.06e19118-7810-4215-808a-e09a555b70b5@github.com>

On Mon, 31 May 2021 12:45:09 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Cumulative fix for the following issues:
> 
>     JDK-8267918 - Javac tolerates synchronizing on a primitive reference type
>     JDK-8267907 - Withdraw support for the experimental option -XDallowValueMemberCycles
>     JDK-8267843 - Duplicate error when primitive class instance is passed around before being fully initialized
>     JDK-8267841 - A primitive class that implements Cloneable is tolerated by javac
>     JDK-8267835 - Javac tolerates vacuous chaining to super constructor from primitive class constructor
>     JDK-8267965 - Javac disallows calls to super.{hashCode(), equals(), toString()} on a primitive instance receiver

This pull request has now been integrated.

Changeset: f1b32691
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f1b32691431219c4d4861da296a1f33fb1bb8b01
Stats:     308 lines in 19 files changed: 271 ins; 20 del; 17 mod

8267923: [lworld] Javac's implementation differs from JEP401 in a few matters.
8267918: [lworld] Javac tolerates synchronizing on a primitive reference type
8267907: [lworld] Withdraw support for the experimental option -XDallowValueMemberCycles
8267843: [lworld] Double diagnostics when primitive class instance is passed around before being fully initialized
8267841: [lworld] A primitive class that implements Cloneable is tolerated by javac
8267835: [lworld] Javac tolerates vacuous chaining to super constructor from primitive class constructor
8267965: [lworld] Javac disallows calls to super.{hashCode(), equals(), toString()} on a primitive instance receiver

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

PR: https://git.openjdk.java.net/valhalla/pull/432


From shade at openjdk.java.net  Mon May 31 13:05:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 13:05:34 GMT
Subject: [lworld] RFR: 8267791: [lworld][lw3] Support compiler blackholes
 for inline types [v2]
In-Reply-To: <G37R51E8zsq8Q7T6HnTEYZ2EdbQKH3w5_Smm1NqguMs=.cb6ab320-4014-409f-8730-f5f1492a460d@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
 <Kv4ogLj6y7nN8FTtC7n8EiAK1Ed9WdUR4ZeZ5qmxV9E=.7d6c5f89-928a-4c15-9cda-9502986ffffa@github.com>
 <ZvFFLPOlZLFs4ppDHF37rQa2OQFtiB5lvb7uN8iscb8=.8189d870-f97d-4153-af6a-17c7a789ed11@github.com>
 <G37R51E8zsq8Q7T6HnTEYZ2EdbQKH3w5_Smm1NqguMs=.cb6ab320-4014-409f-8730-f5f1492a460d@github.com>
Message-ID: <OQwG1RJED_RsaZExkMZ14EOVd7DtRJz3vXnKbi6E-dI=.98806efb-3d4f-439a-9d92-7b9d6f2fc2dd@github.com>

On Mon, 31 May 2021 12:46:53 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The expected behavior is debatable. Current behavior in the corner cases does make sense to me: for non-flattened cases, we blackhole the reference to wrapper (as that is what application code would be exposed to), in flattened cases, we blackhole the components (as that is what application code would be exposed to). 
>> 
>> I probably misunderstand the compiler code here. Can there be an allocated box that goes away later, and only the component accesses survive? If so, how should this code ask for "if the allocated instance is alive, then blackhole it"?
>
> On second thought, I think this is fine.
> 
>> Can there be an allocated box that goes away later, and only the component accesses survive?
> 
> Yes, in general that can happen and is not unlikely. For example, due to late inlining or other optimizations removing a non-scalarizable use of the buffer allocation. However, in this case all such optimizations are already over and unused allocations would have been removed. I.e., if `vt->is_allocated` is true, there is a user of the buffer allocation that won't go away and therefore linking the allocation to the blackhole should be fine.

Right. So my understanding was correct: this is a final elimination phase, and we can trust `vt->_is_allocated`. I did a few more experiments, and they seem to produce the expected (AFAICS) generated code.

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From shade at openjdk.java.net  Mon May 31 13:57:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 31 May 2021 13:57:41 GMT
Subject: [lworld] Integrated: 8267791: [lworld][lw3] Support compiler
 blackholes for inline types
In-Reply-To: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
References: <XMzt7utq7UGdu4ujaI0n2psg5MZxaN4wFIgnxAVl9sk=.1513ad8b-1e57-48bd-afb1-21aa2ddddc94@github.com>
Message-ID: <hxGWfsBqC1DiBPPXkolhuu1R6F0WiY005FcMawwlulY=.1b3fb428-ba75-41fa-8eb0-af3ae4bc7ba4@github.com>

On Wed, 26 May 2021 12:26:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8259316 added the support for compiler blackholes. We need to check and implement the support for inline type arguments for them. I am sure we would find more wrinkles with nano-benchmarks, but insofar sample benchmark work as they should:
> 
> 
> public class PrimitiveClasses {
>     static primitive class Value {
>         long x;
>         long y;
>         public Value(long x, long y) {
>             this.x = x;
>             this.y = y;
>         }
>     }
> 
>     [volatile] Value v = Value.default;
> 
>     @Benchmark
>     public Value test() {
>         return v;
>     }
> }
> 
> 
> Before: crash on assert, `assert(vt->fast_out(i)->is_InlineTypeBase(), "Unexpected inline type user");`
> 
> After, generated code in non-`volatile` case shows blackhole of individual components:
> 
> 
> $ java -Djmh.blackhole.mode=COMPILER -jar target/benchmarks.jar PrimitiveClasses -prof perfasm
> ...
> ....[Hottest Region 1]..............................................................................
> c2, level 4, org.openjdk.jmh_generated.PrimitiveClasses_test_jmhTest::test_avgt_jmhStub, version 641 (39 bytes) 
> ...
>          ?  0x00007f67bcc8eee0:   mov    0x18(%r8),%r10        ; read and blackhole MyValue.x
>   0.02%  ?  0x00007f67bcc8eee4:   mov    0x10(%r8),%r11        ; read and blackhole MyValue.y
>   0.10%  ?  0x00007f67bcc8eee8:   movzbl 0x94(%r14),%r11d      ; read isDone
>   0.10%  ?  0x00007f67bcc8eef0:   mov    0x3b0(%r15),%r10      ; TL handshake
>   2.79%  ?  0x00007f67bcc8eef7:   add    $0x1,%rbp             ; ops++
>          ?  0x00007f67bcc8eefb:   test   %eax,(%r10)           ; TL handshake
>  86.74%  ?  0x00007f67bcc8eefe:   test   %r11d,%r11d           ; isDone?
>   2.31%  ?  0x00007f67bcc8ef01:   je     0x00007f67bcc8eee0    
> 
> 
> And generated code in `volatile` case shows blackhole of the box (with the null-check):
> 
> 
>           ?   0x00007f3948c8db70:   shl    $0x3,%r10            ; unpack and blackhole MyValue
>   0.02%   ??  0x00007f3948c8db74:   movzbl 0x94(%r14),%r8d      ; read isDone
>   0.68%   ??  0x00007f3948c8db7c:   mov    0x3b0(%r15),%r9      ; TL handshake
>   0.72%   ??  0x00007f3948c8db83:   add    $0x1,%rbp            ; ops++
>           ??  0x00007f3948c8db87:   test   %eax,(%r9)           ; TL handshake
>  92.30%   ??  0x00007f3948c8db8a:   test   %r8d,%r8d            ; isDone?
>          ???  0x00007f3948c8db8d:   jne    0x00007f3948c8dba4   
>          ???  0x00007f3948c8db8f:   mov    0xc(%r11),%r10d      ; load "v" (MyValue box)
>   0.35%  ???  0x00007f3948c8db93:   test   %r10d,%r10d          ; null check it
>          ???  0x00007f3948c8db96:   jne    0x00007f3948c8db70

This pull request has now been integrated.

Changeset: f931661b
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f931661b00c7d2fb88fd791a92b574f06cb5bf4e
Stats:     113 lines in 4 files changed: 112 ins; 0 del; 1 mod

8267791: [lworld][lw3] Support compiler blackholes for inline types

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/429


From sadayapalam at openjdk.java.net  Mon May 31 14:04:01 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 May 2021 14:04:01 GMT
Subject: [lworld] Integrated: 8267984: [lworld] The fix for JDK-8267918
 incorrectly precludes synchronization of variables of TypeVariable type
Message-ID: <M-OsCft1Myv465a_oB0h50UrVKc_3N_aan7dlaStgts=.de550400-45cd-4a7d-a2b5-4c90542e1eb7@github.com>

Simplify check for identity type requirement so type variables are precluded.

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

Commit messages:
 - 8267984: The fix for JDK-8267918 incorrectly precludes synchronization on variables of Type Variable type

Changes: https://git.openjdk.java.net/valhalla/pull/433/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=433&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267984
  Stats: 43 lines in 2 files changed: 39 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/433.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/433/head:pull/433

PR: https://git.openjdk.java.net/valhalla/pull/433


From sadayapalam at openjdk.java.net  Mon May 31 14:04:04 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 May 2021 14:04:04 GMT
Subject: [lworld] Integrated: 8267984: [lworld] The fix for JDK-8267918
 incorrectly precludes synchronization of variables of TypeVariable type
In-Reply-To: <M-OsCft1Myv465a_oB0h50UrVKc_3N_aan7dlaStgts=.de550400-45cd-4a7d-a2b5-4c90542e1eb7@github.com>
References: <M-OsCft1Myv465a_oB0h50UrVKc_3N_aan7dlaStgts=.de550400-45cd-4a7d-a2b5-4c90542e1eb7@github.com>
Message-ID: <MKduMHfJ1iaRn_Q0LxLpPPzLaIJpAXAhQmstGHE_A4k=.653b288e-6800-4009-80b1-d413a705ade2@github.com>

On Mon, 31 May 2021 13:57:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Simplify check for identity type requirement so type variables are precluded.

This pull request has now been integrated.

Changeset: d9bd2ae0
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d9bd2ae00e8bf23d8ec40cfba24b91da5a847465
Stats:     43 lines in 2 files changed: 39 ins; 3 del; 1 mod

8267984: [lworld] The fix for JDK-8267918 incorrectly precludes synchronization of variables of TypeVariable type

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

PR: https://git.openjdk.java.net/valhalla/pull/433


From thartmann at openjdk.java.net  Mon May 31 14:08:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 14:08:51 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1) [v2]
In-Reply-To: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
Message-ID: <cTP2BS-eAf8BVciywUsK13idxtoRz7YiKkLcs466BsY=.4280d7d8-bbf3-40ed-9609-324358172e47@github.com>

> After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.
> 
> All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.
> 
> Thanks,
> Tobias

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

  constantTag::internal_name() fix

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/431/files
  - new: https://git.openjdk.java.net/valhalla/pull/431/files/580cb505..eb8e2b09

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

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

PR: https://git.openjdk.java.net/valhalla/pull/431


From fparain at openjdk.java.net  Mon May 31 14:13:30 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 31 May 2021 14:13:30 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1) [v2]
In-Reply-To: <cTP2BS-eAf8BVciywUsK13idxtoRz7YiKkLcs466BsY=.4280d7d8-bbf3-40ed-9609-324358172e47@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
 <cTP2BS-eAf8BVciywUsK13idxtoRz7YiKkLcs466BsY=.4280d7d8-bbf3-40ed-9609-324358172e47@github.com>
Message-ID: <3StBrr45ecnvtXtZcn76aIku8tNDh70yFrf6Ee98CU8=.5ad3af2a-50b5-4619-8504-19cf6d9e6ac0@github.com>

On Mon, 31 May 2021 14:08:51 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.
>> 
>> All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   constantTag::internal_name() fix

I cannot review changes in C2 or CI typeFlow, but changes other changes in CI and C1 look good to me.

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/431


From fparain at openjdk.java.net  Mon May 31 14:13:31 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 31 May 2021 14:13:31 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1) [v2]
In-Reply-To: <JHqp7R41GsGwfX2mmedSf-5_0DIZO_Muw5sc0mpWK38=.1d323de2-de31-4927-b14d-02b2602bdc1e@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
 <CCdVT4ZWKmnU8TerpnBcS4kne8nao7AjzFq4E5UVtu4=.2faab047-f7fa-4851-8280-1264168f314f@github.com>
 <JHqp7R41GsGwfX2mmedSf-5_0DIZO_Muw5sc0mpWK38=.1d323de2-de31-4927-b14d-02b2602bdc1e@github.com>
Message-ID: <ws4usG48u90VLA77dZ97sqHdYKgBOnUJj5ygUDeg09w=.80be2b2c-57e4-4638-a90a-91064b981a4d@github.com>

On Mon, 31 May 2021 06:29:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_Instruction.cpp line 142:
>> 
>>> 140:     if (type != NULL) {
>>> 141:       if (type->is_obj_array_klass() && !type->as_obj_array_klass()->is_elem_null_free()) {
>>> 142:         // The runtime type of [LMyValue might be [QMyValue due to [QMyValue <: [LMyValue.
>> 
>> if type->is_obj_array_klass() is true and type->as_obj_array_klass()->is_elem_null_free() is also true, the method returns false, is it the expected behavior?
>
> Yes, because in that case we have a null-free but non-flattened array. Right?

Correct. Got it.

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

PR: https://git.openjdk.java.net/valhalla/pull/431


From thartmann at openjdk.java.net  Mon May 31 14:39:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 14:39:33 GMT
Subject: RFR: 8267846: [lworld] JIT support for the L/Q model (step 1) [v2]
In-Reply-To: <cTP2BS-eAf8BVciywUsK13idxtoRz7YiKkLcs466BsY=.4280d7d8-bbf3-40ed-9609-324358172e47@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
 <cTP2BS-eAf8BVciywUsK13idxtoRz7YiKkLcs466BsY=.4280d7d8-bbf3-40ed-9609-324358172e47@github.com>
Message-ID: <k3Z3dzCozC7D_QEvX-cStx56C8CxCuaGpNEQPMuroME=.1bad845c-cc73-434f-ade1-bbf5e4f9c473@github.com>

On Mon, 31 May 2021 14:08:51 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.
>> 
>> All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   constantTag::internal_name() fix

Thanks for the review, Fred!

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

PR: https://git.openjdk.java.net/valhalla/pull/431


From thartmann at openjdk.java.net  Mon May 31 14:39:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 May 2021 14:39:33 GMT
Subject: Integrated: 8267846: [lworld] JIT support for the L/Q model (step 1)
In-Reply-To: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
References: <9fTjqwhTwyg4pWDvsls3Yem8o-wK3XA_MM7FfEv9gL4=.e1d1b580-4a68-4d7d-8904-57e88e149830@github.com>
Message-ID: <eqiG8uoIGtFXIUg2VHRQI8mn8tVQDOzyu_Ye81m3hOM=.e0aeaa56-24ac-4fe2-9824-4d5fc41aecb6@github.com>

On Fri, 28 May 2021 12:18:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> After https://github.com/openjdk/valhalla/pull/409 and https://github.com/openjdk/valhalla/pull/414 have been integrated, we need to fix the JIT code as well. This mostly means re-applying the old changes from https://github.com/openjdk/valhalla/commit/22dd0da1 and https://github.com/openjdk/valhalla/commit/e895128f and adjust them to the current implementation.
> 
> All compiler tests now pass except for `TestNullableInlineTypes`, `TestNullableArrays` and `TestIntrinsics` which need reflection support. The corresponding C2 intrinsics are still broken. I'll fix them with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932) once reflection support is available.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 477ecf51
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/477ecf51097f8592e707cbd33be6bf4a0b4234bb
Stats:     344 lines in 39 files changed: 142 ins; 47 del; 155 mod

8267846: [lworld] JIT support for the L/Q model (step 1)

Reviewed-by: fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/431