From hseigel at openjdk.java.net  Thu Jul  1 12:27:23 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 1 Jul 2021 12:27:23 GMT
Subject: Integrated: 8269536: Fix verifier withfield test
In-Reply-To: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>
References: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>
Message-ID: <tKHIGB-I_JPgJ-ZQoY2tRDa9bzyok5WWyzzYTfZllZ0=.364be246-0875-44b2-b318-ff53ca8f3667@github.com>

On Tue, 29 Jun 2021 20:38:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to fix test VerifierInlineTypes.java. The fix removes from the jcod classes improper and unneeded methods that were causing unwanted ClassFormatError exceptions. The change also removes tests that are no longer applicable. Finally, it merges NoNullVT.jcod into verifierTests.jcod.
> 
> The changes were tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 1144cc8b
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1144cc8b8e97b03013d8af945a550abd46e85755
Stats:     1492 lines in 3 files changed: 422 ins; 1042 del; 28 mod

8269536: Fix verifier withfield test

Reviewed-by: fparain

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

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


From hseigel at openjdk.java.net  Thu Jul  1 12:27:22 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 1 Jul 2021 12:27:22 GMT
Subject: RFR: 8269536: Fix verifier withfield test
In-Reply-To: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>
References: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>
Message-ID: <sLGEHMbLcz_suMDpfQaVpZoF7fdtfLwj_FlNyjpR7co=.3b588236-3c44-4ebb-bcb7-3837ff9381d0@github.com>

On Tue, 29 Jun 2021 20:38:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to fix test VerifierInlineTypes.java. The fix removes from the jcod classes improper and unneeded methods that were causing unwanted ClassFormatError exceptions. The change also removes tests that are no longer applicable. Finally, it merges NoNullVT.jcod into verifierTests.jcod.
> 
> The changes were tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

Thanks Fred for reviewing this!

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

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


From sadayapalam at openjdk.java.net  Fri Jul  2 05:36:36 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 2 Jul 2021 05:36:36 GMT
Subject: [lworld] Integrated: 8269792: [lworld] Duplicate/redundant
 CONSTANT_Class_info entry in constant pool
Message-ID: <xpPqbHLZvuTVfCnkdxWj0L2Fg_h4Nqy7LrDMCzW-WR0=.13bd7917-2a53-44cd-87a2-9e4872b2db53@github.com>

Do not emit distinct Constant_class_info entries for Foo.ref and Foo.val

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

Commit messages:
 - 8269792: Duplicate/redundant CONSTANT_Class_info entry in constant pool

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

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


From sadayapalam at openjdk.java.net  Fri Jul  2 05:36:38 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 2 Jul 2021 05:36:38 GMT
Subject: [lworld] Integrated: 8269792: [lworld] Duplicate/redundant
 CONSTANT_Class_info entry in constant pool
In-Reply-To: <xpPqbHLZvuTVfCnkdxWj0L2Fg_h4Nqy7LrDMCzW-WR0=.13bd7917-2a53-44cd-87a2-9e4872b2db53@github.com>
References: <xpPqbHLZvuTVfCnkdxWj0L2Fg_h4Nqy7LrDMCzW-WR0=.13bd7917-2a53-44cd-87a2-9e4872b2db53@github.com>
Message-ID: <SyNWYUPk9lox7H9CZsGY-WjriD91qdjOwZOZ7dOVBWY=.fa6332bd-6312-49f5-8a10-04c6f8f5b096@github.com>

On Fri, 2 Jul 2021 05:29:53 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Do not emit distinct Constant_class_info entries for Foo.ref and Foo.val

This pull request has now been integrated.

Changeset: b3b7fb2b
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b3b7fb2bf96b40fd4636a699e150b8ab5c2d8610
Stats:     14 lines in 3 files changed: 7 ins; 0 del; 7 mod

8269792: [lworld] Duplicate/redundant CONSTANT_Class_info entry in constant pool

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

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


From fparain at openjdk.java.net  Fri Jul  2 17:56:35 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 2 Jul 2021 17:56:35 GMT
Subject: RFR: JDK-8269408: [lworld] [lqagain] Withfield and field
 resolution update [v2]
In-Reply-To: <PK5JD4RiMBeI8gYhH3ejNsoEs5BxnNQ4hAcqJSdyHPE=.2374bc0e-52ff-405f-ba12-c69c1f23bf74@github.com>
References: <PK5JD4RiMBeI8gYhH3ejNsoEs5BxnNQ4hAcqJSdyHPE=.2374bc0e-52ff-405f-ba12-c69c1f23bf74@github.com>
Message-ID: <XvM58DV3Faa5j1sl-RfThLk8JCV63g68x4hiqNBi1Ec=.8102fc14-21a0-42d6-af3f-dfd3934b3211@github.com>

> Please review those changes in the interpreter and the field resolution code.
> 
> With the L/Q model, field resolution must now check that putfield is applied only on identity objects and withfield is applied only on primitive objects.
> The interpreter now performs the required null check on the receiver when executing a withfield bytecode.
> The implementation of withfield has been reworked to remove some of the costly operations it was using (retrieving the last Java frame to be able to extract arguments of the withfield bytecode). The old version of withfield in the interpreter runtime has not been removed because it is still used by the aarch64 platform.
> The withfield unit test has been extended to cover all kind of fields.
> No additional test regarding field resolution has been added yet, I'll work with Harold to define and implement them. They'll be integrated in a later patch.
> 
> Thank you,
> 
> Fred

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

 - Merge remote-tracking branch 'upstream/lqagain' into withfield_int
 - More efficient interpreted withfield

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/465/files
  - new: https://git.openjdk.java.net/valhalla/pull/465/files/f88c8c30..89ec593e

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

  Stats: 1239 lines in 4 files changed: 282 ins; 768 del; 189 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/465.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/465/head:pull/465

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


From jespersm at openjdk.java.net  Sun Jul  4 19:18:51 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 4 Jul 2021 19:18:51 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v2]
In-Reply-To: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
Message-ID: <kUV6iIgHk2OzUHG97RHLnzcYtUyMHM3yhZaYK4UL-lY=.e77c30f2-0e48-401c-9906-3c95928f565a@github.com>

> Make .default a separate node type in the parser.
> 
> ## Issue
> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
> 
> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.

Jesper Steen M?ller has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  [lworld] Handling poly-inference of missing arguments by simulating a synthetic method.

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

Changes: https://git.openjdk.java.net/valhalla/pull/369/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=369&range=01
  Stats: 165 lines in 7 files changed: 124 ins; 25 del; 16 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/369.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/369/head:pull/369

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


From ngasson at openjdk.java.net  Mon Jul  5 09:09:03 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 5 Jul 2021 09:09:03 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
Message-ID: <cdc6ZzXMlKKhn9Fs7Qn-17vGK4otEO0Oh_D_gD4lZ8k=.06891bb0-e911-4fa9-894b-4849ed44b317@github.com>

On Tue, 29 Jun 2021 10:27:09 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Replace ConstantPoolCacheEntry::is_inline_type_shift with
> is_null_free_inline_type_shift and change inline_type to
> null_free_inline_type in a few other places to match x86.

Can I get a sponsor for this one please?

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

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


From ngasson at openjdk.java.net  Tue Jul  6 09:09:22 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 6 Jul 2021 09:09:22 GMT
Subject: [lworld] Integrated: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
Message-ID: <PRlYNnT6qMlvoH5hZCd3SUKWL4sthLhP1uJxV6MU1lc=.1c9753b9-f97e-4589-9b0f-afc1f13b4695@github.com>

On Tue, 29 Jun 2021 10:27:09 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Replace ConstantPoolCacheEntry::is_inline_type_shift with
> is_null_free_inline_type_shift and change inline_type to
> null_free_inline_type in a few other places to match x86.

This pull request has now been integrated.

Changeset: 37ea4103
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/37ea410358921ff5f0cc124a0c1b3a09e34d67e4
Stats:     14 lines in 3 files changed: 0 ins; 0 del; 14 mod

8269578: [lworld] fix AArch64 build after JDK-8267824

Reviewed-by: fparain, shade

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

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


From ngasson at openjdk.java.net  Tue Jul  6 09:13:05 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 6 Jul 2021 09:13:05 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
Message-ID: <aAI2k7yRoMrhbJnAh2177VSE4jvkhinf49bkHyB5OWU=.d6a3d6c3-673a-46b6-83df-d2cb562c8908@github.com>

On Tue, 29 Jun 2021 10:27:09 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Replace ConstantPoolCacheEntry::is_inline_type_shift with
> is_null_free_inline_type_shift and change inline_type to
> null_free_inline_type in a few other places to match x86.

Thanks @rwestrel!

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

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


From vromero at openjdk.java.net  Thu Jul  8 19:44:37 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 8 Jul 2021 19:44:37 GMT
Subject: RFR: Merge lworld
Message-ID: <qoMhpBDSgwHSdmTAb2CMv2WVjU05LQ8BenpTttytIAY=.c2e244dd-d7b3-4fee-8873-9cc82263c795@github.com>

Please review this PR that is merging branch universal-tvars with lword.

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

Commit messages:
 - Merge branch 'lworld' into universal-tvars_merge_lworld_17_19
 - 8269578: [lworld] fix AArch64 build after JDK-8267824
 - 8269792: [lworld] Duplicate/redundant CONSTANT_Class_info entry in constant pool
 - 8269274: [lworld] Withfield instruction fails to verify when operand stack contains LPrimitiveClass;
 - 8268021: [lworld] [AArch64] fix support for InlineTypeReturnedAsFields
 - Adjust testing
 - 8269279: [lworld] 8269231 causes build failures
 - 8269231: Fix 32-bit Valhalla (Zero) builds
 - 8269172: Add java.util.Objects.newIdentity method
 - 8269095: Fix Valhalla Zero build failures
 - ... and 639 more: https://git.openjdk.java.net/valhalla/compare/e8e33390...8d70bcbc

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

Changes: https://git.openjdk.java.net/valhalla/pull/473/files
  Stats: 630379 lines in 5662 files changed: 526985 ins; 80263 del; 23131 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/473.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/473/head:pull/473

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


From thartmann at openjdk.java.net  Fri Jul  9 08:54:17 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 9 Jul 2021 08:54:17 GMT
Subject: RFR: 8268553: [lworld] CI must return secondary mirror when
 accessing CONSTANT_Class with Q-signature
In-Reply-To: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
References: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
Message-ID: <JC3gRCJN92YNMqAHq3VrzbL-r9tQPSoonMa2Ynt8wlM=.57be8620-8ab1-4e84-8056-6555e4a4572f@github.com>

On Thu, 10 Jun 2021 13:01:41 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small change in CI to return the secondary mirror when accessing a CONSTANT_Class_info entry containing a Q-signature.
> This change fixes all compiler tests failures in the lqagain branch but the ones depending on intrinsics (Class::getSuperclass intrinsic and Class::isAssignableFrom intrinsics need to be fixed in a separate changeset).
> 
> Thank you,
> 
> Fred

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

> 698:     assert (klass->is_instance_klass() || klass->is_array_klass(),
> 699:             "must be an instance or array klass ");
> 700:     if (tag.is_unresolved_klass()) {

This is too strict because `klass->is_loaded()` can be true even if `tag.is_unresolved_klass()`. This leads to C2 adding uncommon traps to trigger resolution in the interpreter. However, I've observed cases were the interpreter never resolved the constant and `tag.is_unresolved_klass()` remained true, leading to continuous deoptimizations in C2 compiled code. I'm not sure if that is expected behavior or if there is a bug in the interpreter but the CI code should be fixed in any case. I'll do that with [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932).

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

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


From thartmann at openjdk.java.net  Fri Jul  9 09:05:07 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 9 Jul 2021 09:05:07 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model [v2]
In-Reply-To: <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
 <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>
Message-ID: <R4LH6m9Zlt8aNVpgFnXDVex81Ux0x6x-0KbfMtWbtvI=.e55b98f6-c9ef-4f55-8bd5-993aee5f3e90@github.com>

On Tue, 8 Jun 2021 15:09:58 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Fix all but one test to pass with the new L/Q model and the new core reflection.
>> The failing test, TestIntrinsics.java might be a real VM bug and not a test bug, but it is C2 related.
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestIntrinsics.java line 75

The test will be fixed by [JDK-8267932](https://bugs.openjdk.java.net/browse/JDK-8267932).

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

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


From thartmann at openjdk.java.net  Fri Jul  9 13:30:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 9 Jul 2021 13:30:56 GMT
Subject: RFR: 8267932: [lworld] JIT support for the L/Q model (step 2)
Message-ID: <WaxNo71Xsyej7CC_tVWPlfAkXAubmNTxCEVlf3VssbA=.5bc78db4-8a1e-4e9f-847d-86b98fbdab3d@github.com>

Remaining changes (mostly intrinsics) and some small bug fixes after [JDK-8267846](https://bugs.openjdk.java.net/browse/JDK-8267846). I also strengthened some tests.

This should fix all JIT related failures in tier1 - 3 except for [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) which is a bug in mainline.

Best regards,
Tobias

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

Commit messages:
 - More fixes
 - 8267932: [lworld] JIT support for the L/Q model (step 2)

Changes: https://git.openjdk.java.net/valhalla/pull/474/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=474&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267932
  Stats: 204 lines in 26 files changed: 87 ins; 50 del; 67 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/474.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/474/head:pull/474

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


From thartmann at openjdk.java.net  Fri Jul  9 13:44:02 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 9 Jul 2021 13:44:02 GMT
Subject: RFR: 8267932: [lworld] JIT support for the L/Q model (step 2) [v2]
In-Reply-To: <WaxNo71Xsyej7CC_tVWPlfAkXAubmNTxCEVlf3VssbA=.5bc78db4-8a1e-4e9f-847d-86b98fbdab3d@github.com>
References: <WaxNo71Xsyej7CC_tVWPlfAkXAubmNTxCEVlf3VssbA=.5bc78db4-8a1e-4e9f-847d-86b98fbdab3d@github.com>
Message-ID: <CdX-njFD-MVMNW7iDTUx_tkBjxqRTISSroF1l98N-_k=.af08388d-d49b-4a29-8314-3e7b18aba2e3@github.com>

> Remaining changes (mostly intrinsics) and some small bug fixes after [JDK-8267846](https://bugs.openjdk.java.net/browse/JDK-8267846). I also strengthened some tests.
> 
> This should fix all JIT related failures in tier1 - 3 except for [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) which is a bug in mainline.
> 
> Best regards,
> Tobias

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

  Added missing -XX:+UnlockExperimentalVMOptions

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/474/files
  - new: https://git.openjdk.java.net/valhalla/pull/474/files/08e0272d..5582c7a6

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

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

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


From thartmann at openjdk.java.net  Fri Jul  9 14:59:10 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 9 Jul 2021 14:59:10 GMT
Subject: Integrated: 8267932: [lworld] JIT support for the L/Q model (step 2)
In-Reply-To: <WaxNo71Xsyej7CC_tVWPlfAkXAubmNTxCEVlf3VssbA=.5bc78db4-8a1e-4e9f-847d-86b98fbdab3d@github.com>
References: <WaxNo71Xsyej7CC_tVWPlfAkXAubmNTxCEVlf3VssbA=.5bc78db4-8a1e-4e9f-847d-86b98fbdab3d@github.com>
Message-ID: <ZCBazFElTk3_Hl245FMxjw2TB_1OVL5u28gGeSmWbl8=.fd15aa38-affe-477f-8297-188b2264b549@github.com>

On Fri, 9 Jul 2021 13:24:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Remaining changes (mostly intrinsics) and some small bug fixes after [JDK-8267846](https://bugs.openjdk.java.net/browse/JDK-8267846). I also strengthened some tests.
> 
> This should fix all JIT related failures in tier1 - 3 except for [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) which is a bug in mainline.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: a2c88223
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a2c8822392153d5c57c11ca99745dc0ab39f9015
Stats:     204 lines in 26 files changed: 87 ins; 50 del; 67 mod

8267932: [lworld] JIT support for the L/Q model (step 2)

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

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


From vromero at openjdk.java.net  Sat Jul 10 23:47:55 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 10 Jul 2021 23:47:55 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <qoMhpBDSgwHSdmTAb2CMv2WVjU05LQ8BenpTttytIAY=.c2e244dd-d7b3-4fee-8873-9cc82263c795@github.com>
References: <qoMhpBDSgwHSdmTAb2CMv2WVjU05LQ8BenpTttytIAY=.c2e244dd-d7b3-4fee-8873-9cc82263c795@github.com>
Message-ID: <x5AY4rZpPznjOVFN7fC90e2-LK0F71jY16kHZ7zE5-M=.4a23b54f-2b7d-4bb6-b13a-6f92d5d2b2a7@github.com>

> Please review this PR that is merging branch universal-tvars with lword.

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

 - Merge branch 'lworld' into universal-tvars_merge_lworld_17_19
 - Merge lworld

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/473/files
  - new: https://git.openjdk.java.net/valhalla/pull/473/files/8d70bcbc..8d70bcbc

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

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

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


From vromero at openjdk.java.net  Sat Jul 10 23:48:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 10 Jul 2021 23:48:02 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <qoMhpBDSgwHSdmTAb2CMv2WVjU05LQ8BenpTttytIAY=.c2e244dd-d7b3-4fee-8873-9cc82263c795@github.com>
References: <qoMhpBDSgwHSdmTAb2CMv2WVjU05LQ8BenpTttytIAY=.c2e244dd-d7b3-4fee-8873-9cc82263c795@github.com>
Message-ID: <1QfxaX4cbH2yeHJw_cFux7SxIjWjGmLgCk_cuwW0_Zg=.2b97b75a-e9c3-4bc8-9351-920974252e38@github.com>

On Thu, 8 Jul 2021 19:39:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that is merging branch universal-tvars with lword.

This pull request has now been integrated.

Changeset: 9458f792
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9458f7927b99c19da97f73b86adde4717895fb81
Stats:     630379 lines in 5662 files changed: 526985 ins; 80263 del; 23131 mod

Merge lworld

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

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


From thartmann at openjdk.java.net  Mon Jul 12 06:28:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Jul 2021 06:28:56 GMT
Subject: [lworld] RFR: 8267932: [lworld] JIT support for the L/Q model (step 2)
Message-ID: <o510FMZqMzwGZYYuaDo8FMPrB-wCK6cU-bEPXROxhto=.a38c18b4-dcf7-4e68-98cd-a52ec7f82b5c@github.com>

Pushing https://github.com/openjdk/valhalla/pull/474 into the lworld branch. Includes the dependent fix for JDK-8268553 which was not yet merged into lworld.

Best regards,
Tobias

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

Commit messages:
 - 8267932: [lworld] JIT support for the L/Q model (step 2)

Changes: https://git.openjdk.java.net/valhalla/pull/475/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=475&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267932
  Stats: 217 lines in 26 files changed: 100 ins; 50 del; 67 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/475.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/475/head:pull/475

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


From thartmann at openjdk.java.net  Mon Jul 12 06:42:33 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Jul 2021 06:42:33 GMT
Subject: [lworld] Integrated: 8267932: [lworld] JIT support for the L/Q model
 (step 2)
In-Reply-To: <o510FMZqMzwGZYYuaDo8FMPrB-wCK6cU-bEPXROxhto=.a38c18b4-dcf7-4e68-98cd-a52ec7f82b5c@github.com>
References: <o510FMZqMzwGZYYuaDo8FMPrB-wCK6cU-bEPXROxhto=.a38c18b4-dcf7-4e68-98cd-a52ec7f82b5c@github.com>
Message-ID: <-C1JlCNl-S2QpVJvV6XmKPA6cXJngPL7iDp31uunV1A=.6fc453c5-195b-4b8b-97c9-68394ccbc506@github.com>

On Mon, 12 Jul 2021 06:22:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Pushing https://github.com/openjdk/valhalla/pull/474 into the lworld branch. Includes the dependent fix for JDK-8268553 which was not yet merged into lworld.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 20d81328
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/20d81328513f8a1f6e418cf3b2471fc996ad44e5
Stats:     217 lines in 26 files changed: 100 ins; 50 del; 67 mod

8267932: [lworld] JIT support for the L/Q model (step 2)

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

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


From thartmann at openjdk.java.net  Mon Jul 12 09:07:13 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Jul 2021 09:07:13 GMT
Subject: [lworld] RFR: [lworld] Re-enable testing
Message-ID: <rsx7uziTqAHY-ii0-juqhUP0bj0tGeLgkWms7en6rTc=.0454d55b-2f28-47f5-9694-f752d555646f@github.com>

Re-enable testing disabled by https://github.com/openjdk/valhalla/pull/462 after JDK-8267932 has been fixed.

Best regards,
Tobias

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

Commit messages:
 - JDK problem list
 - [lworld] Re-enable testing

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

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


From thartmann at openjdk.java.net  Mon Jul 12 09:09:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Jul 2021 09:09:42 GMT
Subject: [lworld] Integrated: [lworld] Re-enable testing
In-Reply-To: <rsx7uziTqAHY-ii0-juqhUP0bj0tGeLgkWms7en6rTc=.0454d55b-2f28-47f5-9694-f752d555646f@github.com>
References: <rsx7uziTqAHY-ii0-juqhUP0bj0tGeLgkWms7en6rTc=.0454d55b-2f28-47f5-9694-f752d555646f@github.com>
Message-ID: <nxpLthotBna36VrpoYP5ofsFtzxgYUZEeSJcOdvMc3c=.b3a5010c-e1dc-4a01-82be-bed8b5b27697@github.com>

On Mon, 12 Jul 2021 08:59:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Re-enable testing disabled by https://github.com/openjdk/valhalla/pull/462 after JDK-8267932 has been fixed.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 1e464b3c
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1e464b3c4e09880a2db6dc1d1790ac7e6dd9ba0e
Stats:     15 lines in 2 files changed: 0 ins; 15 del; 0 mod

[lworld] Re-enable testing

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

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


From thartmann at openjdk.java.net  Mon Jul 12 09:56:30 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 12 Jul 2021 09:56:30 GMT
Subject: [lworld] RFR: Convert valhalla/inlinetypes tests to new IR
 framework
In-Reply-To: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
Message-ID: <1AfJ6QbOZrsEl6VFEjm_D-Txi6abBvoJ09p7yWi9fq0=.65f43eeb-ced2-415c-8cbd-e34a652f5bb4@github.com>

On Mon, 21 Jun 2021 21:38:43 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
> which was recently integrated by Christian as part of JDK-8254129.
> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
> as they are in most cases regression tests.
> 
> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
> 
> Testing:
>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>  There 2 failed converted tests:
>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
> 
> 
> Big thanks to Christian and Tobias for advice and help during this tests conversion.
> 
> Please review the changes.
> 
> Thanks,
> Katya

Thanks a lot for taking care of this, Katya! The changes look good to me, just TestIntrinsics.java needs merging.

Please link JDK-8263024 to the PR.

Best regards,
Tobias

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

Marked as reviewed by thartmann (Committer).

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


From hseigel at openjdk.java.net  Mon Jul 12 17:23:41 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 12 Jul 2021 17:23:41 GMT
Subject: [lworld] RFR: 8269536: Fix verifier withfield test
Message-ID: <sC8RWEJJ-6xJgDawnn03wVcU-7G86rLHiUuaIHEREO0=.91d8698b-f1ed-439c-9ab9-77f345b96c86@github.com>

Please review this small change to push a test fix for VerifierInlineTypes.java  that was in branch lqagain to branch lworld.  The fix removes, from the jcod classes, improper and unneeded methods that were causing unwanted ClassFormatError exceptions. The change also removes tests that are no longer applicable.

The changes were tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.

Thanks, Harold

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

Commit messages:
 - 8269536: Fix verifier withfield test

Changes: https://git.openjdk.java.net/valhalla/pull/477/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=477&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269536
  Stats: 1492 lines in 3 files changed: 422 ins; 1042 del; 28 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/477.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/477/head:pull/477

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


From hseigel at openjdk.java.net  Mon Jul 12 17:37:09 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 12 Jul 2021 17:37:09 GMT
Subject: [lworld] Integrated: 8269536: Fix verifier withfield test
In-Reply-To: <sC8RWEJJ-6xJgDawnn03wVcU-7G86rLHiUuaIHEREO0=.91d8698b-f1ed-439c-9ab9-77f345b96c86@github.com>
References: <sC8RWEJJ-6xJgDawnn03wVcU-7G86rLHiUuaIHEREO0=.91d8698b-f1ed-439c-9ab9-77f345b96c86@github.com>
Message-ID: <olWXiZuLqbBrJFVD_QwEdFYupqxRmLJm8kHmRmOLa5Y=.0c7ed66c-89a3-4468-93b0-2c859af8a3d7@github.com>

On Mon, 12 Jul 2021 17:16:42 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to push a test fix for VerifierInlineTypes.java  that was in branch lqagain to branch lworld.  The fix removes, from the jcod classes, improper and unneeded methods that were causing unwanted ClassFormatError exceptions. The change also removes tests that are no longer applicable.
> 
> The changes were tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 7f972be9
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7f972be914a97bd29585ae00d49409660f273053
Stats:     1492 lines in 3 files changed: 422 ins; 1042 del; 28 mod

8269536: Fix verifier withfield test

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

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


From mchung at openjdk.java.net  Mon Jul 12 18:02:26 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 18:02:26 GMT
Subject: [lworld] Integrated: JDK-8270316: [lworld] enable -Xcomp run in
 test/jdk/valhalla/valuetypes/ObjectMethods.java
Message-ID: <J6fbhGkDXLVtVJ69LnpX-m-kdRadQ-sBPSTUWb5hmGU=.355a569e-e684-4ffc-a673-e81a1917d3df@github.com>

It's a follow-up since JDK-8267932 has been resolved.

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

Commit messages:
 - JDK-8270316: [lworld] enable -Xcomp run in test/jdk/valhalla/valuetypes/ObjectMethods.java

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

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


From mchung at openjdk.java.net  Mon Jul 12 18:02:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 18:02:27 GMT
Subject: [lworld] Integrated: JDK-8270316: [lworld] enable -Xcomp run in
 test/jdk/valhalla/valuetypes/ObjectMethods.java
In-Reply-To: <J6fbhGkDXLVtVJ69LnpX-m-kdRadQ-sBPSTUWb5hmGU=.355a569e-e684-4ffc-a673-e81a1917d3df@github.com>
References: <J6fbhGkDXLVtVJ69LnpX-m-kdRadQ-sBPSTUWb5hmGU=.355a569e-e684-4ffc-a673-e81a1917d3df@github.com>
Message-ID: <u29cAvntdU0IYC3IJPRm_pCKxChErdYPfYklZrvm3s8=.e5393066-479b-476b-992b-8f55bf66f618@github.com>

On Mon, 12 Jul 2021 17:54:03 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It's a follow-up since JDK-8267932 has been resolved.

This pull request has now been integrated.

Changeset: c207165b
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c207165b8606d1b4505f52be6362681d61a9fc7e
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8270316: [lworld] enable -Xcomp run in test/jdk/valhalla/valuetypes/ObjectMethods.java

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

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


From epavlova at openjdk.java.net  Tue Jul 13 06:24:39 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Tue, 13 Jul 2021 06:24:39 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
Message-ID: <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>

> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
> which was recently integrated by Christian as part of JDK-8254129.
> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
> as they are in most cases regression tests.
> 
> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
> 
> Testing:
>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>  There 2 failed converted tests:
>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
> 
> 
> Big thanks to Christian and Tobias for advice and help during this tests conversion.
> 
> Please review the changes.
> 
> Thanks,
> Katya

Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge lworld
 - Converted to new IR framework

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

Changes: https://git.openjdk.java.net/valhalla/pull/457/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=457&range=01
  Stats: 5208 lines in 23 files changed: 1020 ins; 1275 del; 2913 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/457.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/457/head:pull/457

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


From epavlova at openjdk.java.net  Tue Jul 13 06:24:40 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Tue, 13 Jul 2021 06:24:40 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <1AfJ6QbOZrsEl6VFEjm_D-Txi6abBvoJ09p7yWi9fq0=.65f43eeb-ced2-415c-8cbd-e34a652f5bb4@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <1AfJ6QbOZrsEl6VFEjm_D-Txi6abBvoJ09p7yWi9fq0=.65f43eeb-ced2-415c-8cbd-e34a652f5bb4@github.com>
Message-ID: <jFlxdeuAXp9OHlDHATXmcUcBda3m-qcPKSYQ9DNcAKU=.1e1f4b5e-dbae-457d-9b3b-4a2d70e33ff1@github.com>

On Mon, 12 Jul 2021 09:52:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge lworld
>>  - Converted to new IR framework
>
> Thanks a lot for taking care of this, Katya! The changes look good to me, just TestIntrinsics.java needs merging.
> 
> Please link JDK-8263024 to the PR.
> 
> Best regards,
> Tobias

@TobiHartmann, thanks for your review!
I did merge TestIntrinsics.java and link the bug.

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

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


From thartmann at openjdk.java.net  Tue Jul 13 08:26:09 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 13 Jul 2021 08:26:09 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
Message-ID: <HOEK520QyQRz3stUzKHDyxX89enG0Ep9rSjHrvOY6GQ=.101eed5a-a24b-46d7-92a5-03ec6fb8fd40@github.com>

On Tue, 13 Jul 2021 06:24:39 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

>> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
>> which was recently integrated by Christian as part of JDK-8254129.
>> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
>> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
>> as they are in most cases regression tests.
>> 
>> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
>> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
>> 
>> Testing:
>>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>>  There 2 failed converted tests:
>>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
>> 
>> 
>> Big thanks to Christian and Tobias for advice and help during this tests conversion.
>> 
>> Please review the changes.
>> 
>> Thanks,
>> Katya
>
> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge lworld
>  - Converted to new IR framework

Thanks, that looks good to me.

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

Marked as reviewed by thartmann (Committer).

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


From chagedorn at openjdk.java.net  Tue Jul 13 08:45:17 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 13 Jul 2021 08:45:17 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
Message-ID: <YVW0wuXwy02bb7nf7dfHfQW7L_aGe1hQEVSdFtONOw4=.72e9825e-f574-4790-8a49-47db6bcbb9bc@github.com>

On Tue, 13 Jul 2021 06:24:39 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

>> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
>> which was recently integrated by Christian as part of JDK-8254129.
>> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
>> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
>> as they are in most cases regression tests.
>> 
>> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
>> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
>> 
>> Testing:
>>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>>  There 2 failed converted tests:
>>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
>> 
>> 
>> Big thanks to Christian and Tobias for advice and help during this tests conversion.
>> 
>> Please review the changes.
>> 
>> Thanks,
>> Katya
>
> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge lworld
>  - Converted to new IR framework

Thanks a lot for your help to do the conversions! They look good overall. There are only some minor things, mostly about code style.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 979:

> 977:     }
> 978: 
> 979: 

New line can be removed

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 1369:

> 1367:     }
> 1368: 
> 1369:     @Test

Introduced whitespace can be removed

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestBasicFunctionality.java line 58:

> 56: 
> 57:     // Helper methods
> 58: 

Maybe leave that line as the comment is about multiple methods

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 119:

> 117: 
> 118:     @Run(test = "test2")
> 119:     public void test2_verifier(RunInfo info) {

`RunInfo info` can be removed

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 372:

> 370:     }
> 371: 
> 372: 

New line can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 395:

> 393:             TestFramework.assertCompiledByC2(helper_m);
> 394:         }
> 395: 

New line can be removed

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 517:

> 515: 
> 516:     @Run(test = "test23")
> 517:     public void test23_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 537:

> 535: 
> 536:     @Run(test = "test24")
> 537:     public void test24_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConvention.java line 1030:

> 1028:     }
> 1029: 
> 1030: 

New line can be removed

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 129:

> 127: 
> 128:         @ForceCompile(compLevel = C1)
> 129:         @DontInline

`DontInline` should not have been removed

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 208:

> 206:         int field = 1000;
> 207: 
> 208:         @DontInline @ForceCompile(compLevel = C1)

`DontInline` should not have been removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 209:

> 207:         public int func1(int a, int b) { return field + a + b + 300; }
> 208: 
> 209:         @DontInline @ForceCompile(CompLevel.C1_SIMPLE)

`ForceCompile` can be put on a new line.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 210:

> 208:         @DontInline @ForceCompile(compLevel = C1)
> 209:         public int func1(int a, int b)             { return field + a + b + 20; }
> 210:         @DontInline @ForceCompile(compLevel = C1)

`DontInline` should not have been removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 217:

> 215:         int field = 2000;
> 216: 
> 217:         @DontInline @ForceCompile(compLevel = C2)

`DontInline` should not have been removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 219:

> 217:         @DontInline @ForceCompile(compLevel = C2)
> 218:         public int func1(int a, int b)             { return field + a + b + 20; }
> 219:         @DontInline @ForceCompile(compLevel = C2)

`DontInline` should not have been removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 222:

> 220:         public int func1(int a, int b)             { return field + a + b + 300; }
> 221: 
> 222:         @DontInline @ForceCompile(CompLevel.C2)

`ForceCompile` can be put on a new line.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 2263:

> 2261: 
> 2262:     @ForceCompile
> 2263:     public void test107_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 2287:

> 2285:     @Run(test = "test107")
> 2286:     @Warmup(0)
> 2287:     public void run_test107_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 2298:

> 2296: 
> 2297:     @ForceCompile
> 2298:     public void test108_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 2322:

> 2320:     @Run(test = "test108")
> 2321:     @Warmup(0)
> 2322:     public void run_test108_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 2333:

> 2331: 
> 2332:     @ForceCompile
> 2333:     public void test109_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 2357:

> 2355:     @Run(test = "test109")
> 2356:     @Warmup(0)
> 2357:     public void run_test109_verifier(RunInfo info) {

`RunInfo info` can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 90:

> 88:     // Verify that Class::isAssignableFrom checks with statically known classes are folded
> 89:     @Test
> 90:     @IR(failOn = {LOADK})

Can be simplified to `failOn  = LOADK`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 126:

> 124:     // Verify that Class::getSuperclass checks with statically known classes are folded
> 125:     @Test
> 126:     @IR(failOn = {LOADK})

Can be simplified to `failOn = LOADK`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 384:

> 382: 
> 383:     @Test
> 384:     @IR(failOn = {CALL_Unsafe})

Can be simplified to `failOn = CALL_Unsafe`. There are some more of them below which could be simplified as well.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 3478:

> 3476:     // acmp doesn't need substitutability test when one input null
> 3477:     @Test
> 3478:     @IR(failOn = {SUBSTITUTABILITY_TEST})

Can be simplified to `failOn = SUBSTITUTABILITY_TEST`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorldProfiling.java line 396:

> 394:     }
> 395: 
> 396: 

New line can be removed.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorldProfiling.java line 569:

> 567:     // branch frequency profiling causes not equal branch to be optimized out
> 568:     @Test
> 569:     @IR(failOn = {SUBSTITUTABILITY_TEST})

Can be simplified to `failOn = SUBSTITUTABILITY_TEST`. There are some more of them below which could be simplified as well.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java line 124:

> 122:     // updating its elements in a loop and computing a hash.
> 123:     @Test
> 124:     @IR(failOn = {ALLOCA})

Can be simplified to `failOn = ALLOCA`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java line 2567:

> 2565:     // Test loads from vararg arrays
> 2566:     @Test
> 2567:     @IR(failOn = {LOAD_UNKNOWN_INLINE})

Can be simplified to `failOn = LOAD_UNKNOWN_INLINE`.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeField.java line 46:

> 44: 
> 45: public class TestUnloadedInlineTypeField {
> 46:     // The test only prevent loading of classes when testing with C1. Load classes

`The test only` -> `Only`?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestUnloadedInlineTypeField.java line 882:

> 880: 
> 881:     @Run(test = "test20")
> 882:     public void test20_verifier(RunInfo info) {

`RunInfo info` can be removed.

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

Changes requested by chagedorn (no project role).

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


From ngasson at openjdk.java.net  Tue Jul 13 11:14:45 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 13 Jul 2021 11:14:45 GMT
Subject: [lworld] RFR: 8264340: [lworld] [AArch64] TestLWorld.java assertion
 failure in OopFlow::build_oop_map
Message-ID: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>

This happens reliably in TestLWorld::test9() scenario 0 on AArch64:


  # A fatal error has been detected by the Java Runtime Environment:
  #
  # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
  # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
  #


The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).

The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.

Before scheduling we have a basic block like:


  R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
  ...
  R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
  ...
          6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)


But after scheduling this is transformed into:


  R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
  ...
          6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
  ...
  R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)


Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.

The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().

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

Commit messages:
 - 8264340: [lworld] [AArch64] TestLWorld.java assertion failure in OopFlow::build_oop_map

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

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


From chagedorn at openjdk.java.net  Tue Jul 13 13:03:13 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 13 Jul 2021 13:03:13 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
Message-ID: <SJ8ecQ5MyDhu4sJll_jR0YJQS-9uXUj8VREiKfatOy4=.972c475d-5dac-489b-ad11-07f65fcb6cfb@github.com>

On Tue, 13 Jul 2021 06:24:39 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

>> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
>> which was recently integrated by Christian as part of JDK-8254129.
>> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
>> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
>> as they are in most cases regression tests.
>> 
>> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
>> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
>> 
>> Testing:
>>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>>  There 2 failed converted tests:
>>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
>> 
>> 
>> Big thanks to Christian and Tobias for advice and help during this tests conversion.
>> 
>> Please review the changes.
>> 
>> Thanks,
>> Katya
>
> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge lworld
>  - Converted to new IR framework

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 3865:

> 3863:         int result = test141();
> 3864:         Asserts.assertEquals(result, 0);
> 3865:     }

I've just seen that there is one more test below (`test142`) which was not converted, yet.

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

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


From epavlova at openjdk.java.net  Tue Jul 13 23:50:35 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Tue, 13 Jul 2021 23:50:35 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <YVW0wuXwy02bb7nf7dfHfQW7L_aGe1hQEVSdFtONOw4=.72e9825e-f574-4790-8a49-47db6bcbb9bc@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
 <YVW0wuXwy02bb7nf7dfHfQW7L_aGe1hQEVSdFtONOw4=.72e9825e-f574-4790-8a49-47db6bcbb9bc@github.com>
Message-ID: <TBiiCrtE4tDHNFXrbwPxJMLhq0E6yZkuI_ff99h-OOY=.1f457755-ba21-43d0-b5e1-23558bca36d1@github.com>

On Tue, 13 Jul 2021 07:56:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge lworld
>>  - Converted to new IR framework
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorldProfiling.java line 569:
> 
>> 567:     // branch frequency profiling causes not equal branch to be optimized out
>> 568:     @Test
>> 569:     @IR(failOn = {SUBSTITUTABILITY_TEST})
> 
> Can be simplified to `failOn = SUBSTITUTABILITY_TEST`. There are some more of them below which could be simplified as well.

I actually specially kept {} so it will be more straightforward to add more nodes if needed. But I can remove {} if you prefer simplified version.

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java line 124:
> 
>> 122:     // updating its elements in a loop and computing a hash.
>> 123:     @Test
>> 124:     @IR(failOn = {ALLOCA})
> 
> Can be simplified to `failOn = ALLOCA`.

see previous comment

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java line 2567:
> 
>> 2565:     // Test loads from vararg arrays
>> 2566:     @Test
>> 2567:     @IR(failOn = {LOAD_UNKNOWN_INLINE})
> 
> Can be simplified to `failOn = LOAD_UNKNOWN_INLINE`.

see previous comment

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

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


From epavlova at openjdk.java.net  Wed Jul 14 00:03:28 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 14 Jul 2021 00:03:28 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <SJ8ecQ5MyDhu4sJll_jR0YJQS-9uXUj8VREiKfatOy4=.972c475d-5dac-489b-ad11-07f65fcb6cfb@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
 <SJ8ecQ5MyDhu4sJll_jR0YJQS-9uXUj8VREiKfatOy4=.972c475d-5dac-489b-ad11-07f65fcb6cfb@github.com>
Message-ID: <BYgzpJb8uwrfNcRe4rrE4gAIpxPuBZg79ORcOqxdbmk=.3043a494-c47f-464b-879c-a18994d5d273@github.com>

On Tue, 13 Jul 2021 13:00:29 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge lworld
>>  - Converted to new IR framework
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 3865:
> 
>> 3863:         int result = test141();
>> 3864:         Asserts.assertEquals(result, 0);
>> 3865:     }
> 
> I've just seen that there is one more test below (`test142`) which was not converted, yet.

Good catch :), converted

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

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


From epavlova at openjdk.java.net  Wed Jul 14 00:51:34 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 14 Jul 2021 00:51:34 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <YVW0wuXwy02bb7nf7dfHfQW7L_aGe1hQEVSdFtONOw4=.72e9825e-f574-4790-8a49-47db6bcbb9bc@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
 <YVW0wuXwy02bb7nf7dfHfQW7L_aGe1hQEVSdFtONOw4=.72e9825e-f574-4790-8a49-47db6bcbb9bc@github.com>
Message-ID: <rw-RqQtAQ2M803wWIObDfc97R8l9DReoETiXLMUstH4=.ed5fdaff-ed8b-42cd-a08f-722e2bb79018@github.com>

On Tue, 13 Jul 2021 07:32:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge lworld
>>  - Converted to new IR framework
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 90:
> 
>> 88:     // Verify that Class::isAssignableFrom checks with statically known classes are folded
>> 89:     @Test
>> 90:     @IR(failOn = {LOADK})
> 
> Can be simplified to `failOn  = LOADK`.

I specially kept {} so it will be more straightforward to add more nodes if needed. But I can remove {} if you prefer simplified version.

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 126:
> 
>> 124:     // Verify that Class::getSuperclass checks with statically known classes are folded
>> 125:     @Test
>> 126:     @IR(failOn = {LOADK})
> 
> Can be simplified to `failOn = LOADK`.

I actually specially kept {} so it will be more straightforward to add more nodes if needed. But I can remove {} if you prefer simplified version.

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 384:
> 
>> 382: 
>> 383:     @Test
>> 384:     @IR(failOn = {CALL_Unsafe})
> 
> Can be simplified to `failOn = CALL_Unsafe`. There are some more of them below which could be simplified as well.

see previous comment

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java line 3478:
> 
>> 3476:     // acmp doesn't need substitutability test when one input null
>> 3477:     @Test
>> 3478:     @IR(failOn = {SUBSTITUTABILITY_TEST})
> 
> Can be simplified to `failOn = SUBSTITUTABILITY_TEST`.

see previous comment

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

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


From epavlova at openjdk.java.net  Wed Jul 14 05:32:16 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 14 Jul 2021 05:32:16 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v3]
In-Reply-To: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
Message-ID: <QSB57nRl5S6gUonYnIfobCot2qBry5gTRAFHUmyyROE=.680419e7-57b8-4b9e-b9f8-64e9eae2c2ae@github.com>

> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
> which was recently integrated by Christian as part of JDK-8254129.
> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
> as they are in most cases regression tests.
> 
> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
> 
> Testing:
>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>  There 2 failed converted tests:
>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
> 
> 
> Big thanks to Christian and Tobias for advice and help during this tests conversion.
> 
> Please review the changes.
> 
> Thanks,
> Katya

Ekaterina Pavlova has updated the pull request incrementally with one additional commit since the last revision:

  Fixes based on Christian's comments

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/457/files
  - new: https://git.openjdk.java.net/valhalla/pull/457/files/63bdc6f2..1e1dbe1d

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

  Stats: 34 lines in 7 files changed: 9 ins; 5 del; 20 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/457.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/457/head:pull/457

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


From epavlova at openjdk.java.net  Wed Jul 14 05:32:18 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 14 Jul 2021 05:32:18 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v2]
In-Reply-To: <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <UBxDz8S-ReWooD61lYc6It06Fpw_9DHn9SkhWNKOQxI=.e813b66d-1ebb-4cf9-b282-586ef98d77fb@github.com>
Message-ID: <pyx-KnD0cjOksnZ2g2x7BMeNUwirq1MToF1YHYQ4Q2I=.cf48db7b-12ea-4e83-9ed5-371e3588bdee@github.com>

On Tue, 13 Jul 2021 06:24:39 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

>> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
>> which was recently integrated by Christian as part of JDK-8254129.
>> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
>> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
>> as they are in most cases regression tests.
>> 
>> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
>> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
>> 
>> Testing:
>>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>>  There 2 failed converted tests:
>>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
>> 
>> 
>> Big thanks to Christian and Tobias for advice and help during this tests conversion.
>> 
>> Please review the changes.
>> 
>> Thanks,
>> Katya
>
> Ekaterina Pavlova has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge lworld
>  - Converted to new IR framework

I did rerun compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9
and only compiler/valhalla/inlinetypes/TestIntrinsics.java failed which is known issue tracked by JDK-8239003

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

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


From ngasson at openjdk.java.net  Wed Jul 14 06:37:35 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 14 Jul 2021 06:37:35 GMT
Subject: [lworld] RFR: 8270357: [lworld] some jtreg tests disabled on AArch64
Message-ID: <_cb5hG9UlldpAJBDZybAFCedAeb3krzVGu-TKU-2DUk=.6900f7dd-b334-4126-b9a2-166a7505010d@github.com>

Several tests under runtime/valhalla and compiler/valhalla have `@requires os.simpleArch == "x64"`. They should be enabled on AArch64 too.

A couple of these tests, as well as three of the existing ones, fail on AArch64 with some variant of:


java.lang.RuntimeException: Graph for 'TestBasicFunctionality::test3' contains different number of match nodes (expected 1 but got 0):


The regex pattern these tests are looking for is specific to the x86 opto assembly output. They regex needs to be adjusted for the AArch64 format. I'll do that after #457 is merged which also touches the same files.

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

Commit messages:
 - 8270357: [lworld] some jtreg tests disabled on AArch64

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

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


From dsimms at openjdk.java.net  Wed Jul 14 06:56:35 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 14 Jul 2021 06:56:35 GMT
Subject: RFR: JDK-8269408: [lworld] [lqagain] Withfield and field
 resolution update [v2]
In-Reply-To: <XvM58DV3Faa5j1sl-RfThLk8JCV63g68x4hiqNBi1Ec=.8102fc14-21a0-42d6-af3f-dfd3934b3211@github.com>
References: <PK5JD4RiMBeI8gYhH3ejNsoEs5BxnNQ4hAcqJSdyHPE=.2374bc0e-52ff-405f-ba12-c69c1f23bf74@github.com>
 <XvM58DV3Faa5j1sl-RfThLk8JCV63g68x4hiqNBi1Ec=.8102fc14-21a0-42d6-af3f-dfd3934b3211@github.com>
Message-ID: <PMIkBBu3A4l-v-Jm36Kc5xwGIsX8SErUJFZNfJ-06h4=.3801f7c4-0320-4a99-ab39-c9d43ab1b161@github.com>

On Fri, 2 Jul 2021 17:56:35 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review those changes in the interpreter and the field resolution code.
>> 
>> With the L/Q model, field resolution must now check that putfield is applied only on identity objects and withfield is applied only on primitive objects.
>> The interpreter now performs the required null check on the receiver when executing a withfield bytecode.
>> The implementation of withfield has been reworked to remove some of the costly operations it was using (retrieving the last Java frame to be able to extract arguments of the withfield bytecode). The old version of withfield in the interpreter runtime has not been removed because it is still used by the aarch64 platform.
>> The withfield unit test has been extended to cover all kind of fields.
>> No additional test regarding field resolution has been added yet, I'll work with Harold to define and implement them. They'll be integrated in a later patch.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/lqagain' into withfield_int
>  - More efficient interpreted withfield

Looks good, one comment, on comments, the description that is in the PR is quite useful, probably should appear in code somewhere:

> The old version of withfield in the interpreter runtime has not been removed because it is still used by the aarch64 platform.

I.e. a comment on withfield vs withfield2

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

Marked as reviewed by dsimms (Committer).

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


From chagedorn at openjdk.java.net  Wed Jul 14 15:53:56 2021
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 14 Jul 2021 15:53:56 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v3]
In-Reply-To: <QSB57nRl5S6gUonYnIfobCot2qBry5gTRAFHUmyyROE=.680419e7-57b8-4b9e-b9f8-64e9eae2c2ae@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
 <QSB57nRl5S6gUonYnIfobCot2qBry5gTRAFHUmyyROE=.680419e7-57b8-4b9e-b9f8-64e9eae2c2ae@github.com>
Message-ID: <0NrjI6HnE-Fn3XBXMohDJXQsunPNXO0UaLmV5fdTYdE=.ab9c2ec6-c036-4844-8af0-c4e9f938820e@github.com>

On Wed, 14 Jul 2021 05:32:16 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

>> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
>> which was recently integrated by Christian as part of JDK-8254129.
>> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
>> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
>> as they are in most cases regression tests.
>> 
>> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
>> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
>> 
>> Testing:
>>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>>  There 2 failed converted tests:
>>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
>> 
>> 
>> Big thanks to Christian and Tobias for advice and help during this tests conversion.
>> 
>> Please review the changes.
>> 
>> Thanks,
>> Katya
>
> Ekaterina Pavlova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes based on Christian's comments

Thanks for doing the changes!

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 179:

> 177:         @DontInline
> 178:         @ForceCompile(CompLevel.C1_SIMPLE)
> 179:         public int func1(int a, int b)             { return field + a + b + 20; }

Can you also add a new line here?

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCallingConventionC1.java line 190:

> 188:         @DontInline
> 189:         @ForceCompile(CompLevel.C2)
> 190:         public int func1(int a, int b)             { return field + a + b + 20; }

And here

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

Marked as reviewed by chagedorn (no project role).

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


From epavlova at openjdk.java.net  Thu Jul 15 06:26:59 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Thu, 15 Jul 2021 06:26:59 GMT
Subject: [lworld] RFR: 8263024: Convert Valhalla tests using the old
 framework to the new framework [v4]
In-Reply-To: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
Message-ID: <myj_Ylj7vpxfFHRnYVidYaHyJ5xlba2H-GGmUx2TGTs=.3eb1a50a-36f1-46ee-b259-4c8d31a8f669@github.com>

> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
> which was recently integrated by Christian as part of JDK-8254129.
> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
> as they are in most cases regression tests.
> 
> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
> 
> Testing:
>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>  There 2 failed converted tests:
>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
> 
> 
> Big thanks to Christian and Tobias for advice and help during this tests conversion.
> 
> Please review the changes.
> 
> Thanks,
> Katya

Ekaterina Pavlova has updated the pull request incrementally with one additional commit since the last revision:

  Added new lines

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/457/files
  - new: https://git.openjdk.java.net/valhalla/pull/457/files/1e1dbe1d..059261d7

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

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

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


From sadayapalam at openjdk.java.net  Thu Jul 15 12:29:44 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 15 Jul 2021 12:29:44 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation
Message-ID: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>

Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time

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

Commit messages:
 - 8237073: [lworld] Need special handling of jlO constructor invocation

Changes: https://git.openjdk.java.net/valhalla/pull/481/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=481&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8237073
  Stats: 63 lines in 38 files changed: 18 ins; 1 del; 44 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/481.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/481/head:pull/481

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


From epavlova at openjdk.java.net  Thu Jul 15 16:08:50 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Thu, 15 Jul 2021 16:08:50 GMT
Subject: [lworld] Integrated: 8263024: Convert Valhalla tests using the old
 framework to the new framework
In-Reply-To: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
References: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>
Message-ID: <i93qC6ov1I-23GoLvF6pwlynMJRaQqVOQqiwPWZvk1g=.111f9917-8e54-4290-8013-9a707337a596@github.com>

On Mon, 21 Jun 2021 21:38:43 GMT, Ekaterina Pavlova <epavlova at openjdk.org> wrote:

> This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
> which was recently integrated by Christian as part of JDK-8254129.
> The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
> The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
> as they are in most cases regression tests.
> 
> The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
> A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.
> 
> Testing:
>  Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
>  There 2 failed converted tests:
>   compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
>   compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003
> 
> 
> Big thanks to Christian and Tobias for advice and help during this tests conversion.
> 
> Please review the changes.
> 
> Thanks,
> Katya

This pull request has now been integrated.

Changeset: aa84c4ed
Author:    Ekaterina Pavlova <epavlova at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/aa84c4ed383b6266fbdb3fddd3aded1771613dfb
Stats:     5216 lines in 23 files changed: 1026 ins; 1275 del; 2915 mod

8263024: Convert Valhalla tests using the old framework to the new framework

Reviewed-by: thartmann, chagedorn

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

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


From mchung at openjdk.java.net  Fri Jul 16 00:31:33 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Jul 2021 00:31:33 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation
In-Reply-To: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
Message-ID: <6Xq3OegIpOdIMeIoVTc3QjKvLwJ8O0i7u2ZxrGOQOXw=.c4610d90-4de8-424a-91ba-880919e063c1@github.com>

On Thu, 15 Jul 2021 12:11:15 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time

For `src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java`, I suggest to replace it with a specific class like this:


diff --git a/src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java b/src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java
index b3c149492ac..a0707150cfa 100644
--- a/src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java
+++ b/src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java
@@ -152,12 +152,14 @@ abstract class ClassSpecializer<T,K,S extends ClassSpecializer<T,K,S>.SpeciesDat
         return new IllegalArgumentException(message, cause);
     }
 
-    private static final Function<Object, Object> CREATE_RESERVATION = new Function<>() {
-        @Override
-        public Object apply(Object key) {
-            return new Object();
-        }
-    };
+    static class CacheHolder {
+        static final Function<Object, Object> CREATE = new Function<>() {
+            @Override
+            public Object apply(Object key) {
+                return new CacheHolder();
+            }
+        };
+    }
 
     public final S findSpecies(K key) {
         // Note:  Species instantiation may throw VirtualMachineError because of
@@ -180,12 +182,12 @@ abstract class ClassSpecializer<T,K,S extends ClassSpecializer<T,K,S>.SpeciesDat
         // concrete class if ever.
         // The concrete class is published via SpeciesData instance
         // returned here only after the class and species data are linked together.
-        Object speciesDataOrReservation = cache.computeIfAbsent(key, CREATE_RESERVATION);
+        Object speciesDataOrReservation = cache.computeIfAbsent(key, CacheHolder.CREATE);
         // Separating the creation of a placeholder SpeciesData instance above
         // from the loading and linking a real one below ensures we can never
         // accidentally call computeIfAbsent recursively.
         S speciesData;
-        if (speciesDataOrReservation.getClass() == Object.class) {
+        if (speciesDataOrReservation.getClass() == CacheHolder.class) {
             synchronized (speciesDataOrReservation) {
                 Object existingSpeciesData = cache.get(key);
                 if (existingSpeciesData == speciesDataOrReservation) { // won the race

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

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


From sadayapalam at openjdk.java.net  Fri Jul 16 01:01:40 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 16 Jul 2021 01:01:40 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation
In-Reply-To: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
Message-ID: <Ue1dcqDdlwM107fYHnhBAon2Ml4836ZT9vIjU2yWMOM=.626993fe-91d8-45f6-8982-7c1b64afef38@github.com>

On Thu, 15 Jul 2021 12:11:15 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time

Thanks Mandy, I will include your changes. I assume you have taken a look at the test/jdk/ changes too

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

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


From mchung at openjdk.java.net  Fri Jul 16 01:45:32 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Jul 2021 01:45:32 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation
In-Reply-To: <Ue1dcqDdlwM107fYHnhBAon2Ml4836ZT9vIjU2yWMOM=.626993fe-91d8-45f6-8982-7c1b64afef38@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
 <Ue1dcqDdlwM107fYHnhBAon2Ml4836ZT9vIjU2yWMOM=.626993fe-91d8-45f6-8982-7c1b64afef38@github.com>
Message-ID: <2mHgD2c_ehN3vNR4m58XQljhp6TOMGcfEQwZIX7bvH0=.74f40f1f-bb4d-4d7a-bf72-1c297eb4b1a9@github.com>

On Fri, 16 Jul 2021 00:58:27 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>  I assume you have taken a look at the test/jdk/ changes too

They are dynalink tests that I'm not familiar with.  I suspect it can be replaced with an instance of other class.  I will take a look.

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

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


From sadayapalam at openjdk.java.net  Fri Jul 16 05:05:10 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 16 Jul 2021 05:05:10 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation [v2]
In-Reply-To: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
Message-ID: <-JDa-8cmzRRCjmRF-4Q4cAqd8AwAy0p1rKnO6cnlCtM=.2ad88137-f3a9-4cfa-b988-b2e7fc564a2a@github.com>

> Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time

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

 - Incorporate review comments from Mandy Chung
 - Merge branch 'lworld' into JDK-8237073
 - 8237073: [lworld] Need special handling of jlO constructor invocation

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/481/files
  - new: https://git.openjdk.java.net/valhalla/pull/481/files/395f5ada..9f960b67

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

  Stats: 5227 lines in 24 files changed: 1028 ins; 1276 del; 2923 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/481.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/481/head:pull/481

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


From sadayapalam at openjdk.java.net  Fri Jul 16 08:52:31 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 16 Jul 2021 08:52:31 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
Message-ID: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>

Code changes and tests

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

Commit messages:
 - Fix white space problems
 - Fix white space problems
 - Modify several existing tests to verify behavior with reference default classes
 - 8244231: Add support for ref-default and val-default inline classes.

Changes: https://git.openjdk.java.net/valhalla/pull/482/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=482&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244231
  Stats: 3536 lines in 112 files changed: 3358 ins; 70 del; 108 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/482/head:pull/482

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


From sadayapalam at openjdk.java.net  Fri Jul 16 08:52:33 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 16 Jul 2021 08:52:33 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <9JTmD-usOem_7LxHDRsDNCFwf1j2xycP3xoXcNSEEBY=.bc53919c-ae47-41ec-9611-de88ab7af672@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

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

> 278:      * null otherwise
> 279:      */
> 280:     public ClassType asValueType() {

These various internal APIs are still crystallizing. I have a follow up ticket JDK-8268734 to evolve them to final form.

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

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


From sadayapalam at openjdk.java.net  Fri Jul 16 09:01:19 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 16 Jul 2021 09:01:19 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <naeNloxIgbRsB7PvhtrCVovvJqQ_uzViHGy77ZbRLAk=.33ebf8dc-c8fb-4c48-baf4-7f10f061e9e0@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

Recommended order of review:

Flags.java
JavacParser.java
Type.java
ClassWriter.java
ClassReader.java
Attr.java

then other files.

This order in review provide a good understanding of the work flow.

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

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


From sadayapalam at openjdk.java.net  Fri Jul 16 09:52:00 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 16 Jul 2021 09:52:00 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <b_twSgmcFFS9DtB8md4FcGOy677bqM0iEAOb_Kptnuc=.3d79833d-a7d1-4574-b246-09c946d00d73@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

(Although the title says add support for val-default classes, this is all about ref-defaul classes. The plain primitive classes we have been supporting all the while are all val-default)

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

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


From thartmann at openjdk.java.net  Fri Jul 16 11:43:08 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 16 Jul 2021 11:43:08 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation [v2]
In-Reply-To: <-JDa-8cmzRRCjmRF-4Q4cAqd8AwAy0p1rKnO6cnlCtM=.2ad88137-f3a9-4cfa-b988-b2e7fc564a2a@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
 <-JDa-8cmzRRCjmRF-4Q4cAqd8AwAy0p1rKnO6cnlCtM=.2ad88137-f3a9-4cfa-b988-b2e7fc564a2a@github.com>
Message-ID: <7zfYRDSwoSN4DDAGwt7b3ovZIH2xJR-67GNTevFwSjY=.c856a322-36dc-4172-8e8e-9a33370fea7d@github.com>

On Fri, 16 Jul 2021 05:05:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time
>
> Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Incorporate review comments from Mandy Chung
>  - Merge branch 'lworld' into JDK-8237073
>  - 8237073: [lworld] Need special handling of jlO constructor invocation

Compiler test changes look good to me.

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

Marked as reviewed by thartmann (Committer).

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


From mchung at openjdk.java.net  Fri Jul 16 17:08:30 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Jul 2021 17:08:30 GMT
Subject: [lworld] RFR: JDK-8270350: [lworld] GeneratedMethodAccessor contains
 incorrect cast
Message-ID: <y6p8hYUftWdbTj1HcPSjHNQXOep4uIUBV5vipk5fUWk=.7f7b9f14-0251-46c1-b9be-32477149443d@github.com>

This patch updates the bytecode generated for core reflection to use ReferenceType descriptor in CONSTANT_Class_info for primitive classes.   In addition, the VM classFileParser temporarily disables the class file version check for `jdk/internal/reflect` classes since it's still version 49 until JDK-8266010 is fixed.

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

Commit messages:
 - JDK-8270350: [lworld] GeneratedMethodAccessor contains incorrect cast

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

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


From hseigel at openjdk.java.net  Fri Jul 16 17:13:18 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 16 Jul 2021 17:13:18 GMT
Subject: [lworld] RFR: JDK-8270350: [lworld] GeneratedMethodAccessor
 contains incorrect cast
In-Reply-To: <y6p8hYUftWdbTj1HcPSjHNQXOep4uIUBV5vipk5fUWk=.7f7b9f14-0251-46c1-b9be-32477149443d@github.com>
References: <y6p8hYUftWdbTj1HcPSjHNQXOep4uIUBV5vipk5fUWk=.7f7b9f14-0251-46c1-b9be-32477149443d@github.com>
Message-ID: <Xq3L9RmuMV19BqtaeJY9URT1s_yJROkFZzOEEt0bEpQ=.4d213189-6de3-4c22-85d0-37eec977ca52@github.com>

On Fri, 16 Jul 2021 17:02:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This patch updates the bytecode generated for core reflection to use ReferenceType descriptor in CONSTANT_Class_info for primitive classes.   In addition, the VM classFileParser temporarily disables the class file version check for `jdk/internal/reflect` classes since it's still version 49 until JDK-8266010 is fixed.

The classFileParser.cpp changes look good.
Thanks, Harold

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

Marked as reviewed by hseigel (Committer).

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


From mchung at openjdk.java.net  Fri Jul 16 17:23:15 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Jul 2021 17:23:15 GMT
Subject: [lworld] Integrated: JDK-8270350: [lworld] GeneratedMethodAccessor
 contains incorrect cast
In-Reply-To: <y6p8hYUftWdbTj1HcPSjHNQXOep4uIUBV5vipk5fUWk=.7f7b9f14-0251-46c1-b9be-32477149443d@github.com>
References: <y6p8hYUftWdbTj1HcPSjHNQXOep4uIUBV5vipk5fUWk=.7f7b9f14-0251-46c1-b9be-32477149443d@github.com>
Message-ID: <2uh-3yJ0N50kSkFV8uXpGDSvS8kx19tEUTrRXG4Xzj8=.367e2340-d4b7-4eef-a200-5d52cc1f43fb@github.com>

On Fri, 16 Jul 2021 17:02:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This patch updates the bytecode generated for core reflection to use ReferenceType descriptor in CONSTANT_Class_info for primitive classes.   In addition, the VM classFileParser temporarily disables the class file version check for `jdk/internal/reflect` classes since it's still version 49 until JDK-8266010 is fixed.

This pull request has now been integrated.

Changeset: 6d0ecdf3
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/6d0ecdf384c261c5501f52a1359c0703069b1981
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8270350: [lworld] GeneratedMethodAccessor contains incorrect cast

Reviewed-by: hseigel

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

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


From mchung at openjdk.java.net  Fri Jul 16 18:20:13 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Jul 2021 18:20:13 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation [v2]
In-Reply-To: <-JDa-8cmzRRCjmRF-4Q4cAqd8AwAy0p1rKnO6cnlCtM=.2ad88137-f3a9-4cfa-b988-b2e7fc564a2a@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
 <-JDa-8cmzRRCjmRF-4Q4cAqd8AwAy0p1rKnO6cnlCtM=.2ad88137-f3a9-4cfa-b988-b2e7fc564a2a@github.com>
Message-ID: <_bEfBdgE3sc6vrkRc8LqHuYKalQY1O0Ow8dgFyTj_dk=.b4e019e4-5a54-4acf-82c4-694f6ac55c03@github.com>

On Fri, 16 Jul 2021 05:05:10 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time
>
> Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Incorporate review comments from Mandy Chung
>  - Merge branch 'lworld' into JDK-8237073
>  - 8237073: [lworld] Need special handling of jlO constructor invocation

test/jdk/jdk/dynalink/BeanLinkerTest.java line 186:

> 184:         final MethodType mt = MethodType.methodType(Object.class, Object.class, String.class);
> 185:         final CallSite cs = createCallSite(publicLookup, GET_PROPERTY, mt);
> 186:         Assert.assertEquals(cs.getTarget().invoke(new Object(), "class"), java.util.Objects.newIdentity().getClass());

The change looks okay but this may be unclear to the reader why the returned class is not Object.class.

An alternative fix is to define an explicit `TestObject` class:


diff --git a/test/jdk/jdk/dynalink/BeanLinkerTest.java b/test/jdk/jdk/dynalink/BeanLinkerTest.java
index fafc1be447f..f22aab8f026 100644
--- a/test/jdk/jdk/dynalink/BeanLinkerTest.java
+++ b/test/jdk/jdk/dynalink/BeanLinkerTest.java
@@ -179,11 +179,13 @@ public class BeanLinkerTest {
         this.linker = null;
     }
 
+    static class TestObject {}
+
     @Test(dataProvider = "flags")
     public void getPropertyTest(final boolean publicLookup) throws Throwable {
         final MethodType mt = MethodType.methodType(Object.class, Object.class, String.class);
         final CallSite cs = createCallSite(publicLookup, GET_PROPERTY, mt);
-        Assert.assertEquals(cs.getTarget().invoke(new Object(), "class"), Object.class);
+        Assert.assertEquals(cs.getTarget().invoke(new TestObject(), "class"), TestObject.class);
         Assert.assertEquals(cs.getTarget().invoke(new Date(), "class"), Date.class);
     }
 
@@ -191,14 +193,14 @@ public class BeanLinkerTest {
     public void getPropertyNegativeTest(final boolean publicLookup) throws Throwable {
         final MethodType mt = MethodType.methodType(Object.class, Object.class, String.class);
         final CallSite cs = createCallSite(publicLookup, GET_PROPERTY, mt);
-        Assert.assertNull(cs.getTarget().invoke(new Object(), "DOES_NOT_EXIST"));
+        Assert.assertNull(cs.getTarget().invoke(new TestObject(), "DOES_NOT_EXIST"));
     }
 
     @Test(dataProvider = "flags")
     public void getPropertyTest2(final boolean publicLookup) throws Throwable {
         final MethodType mt = MethodType.methodType(Object.class, Object.class);
         final CallSite cs = createCallSite(publicLookup, GET_PROPERTY, "class", mt);
-        Assert.assertEquals(cs.getTarget().invoke(new Object()), Object.class);
+        Assert.assertEquals(cs.getTarget().invoke(new TestObject()), TestObject.class);
         Assert.assertEquals(cs.getTarget().invoke(new Date()), Date.class);
     }
 
@@ -208,7 +210,7 @@ public class BeanLinkerTest {
         final CallSite cs = createCallSite(publicLookup, GET_PROPERTY, "DOES_NOT_EXIST", mt);
 
         try {
-            cs.getTarget().invoke(new Object());
+            cs.getTarget().invoke(new TestObject());
             throw new RuntimeException("Expected NoSuchDynamicMethodException");
         } catch (final Throwable th) {
             Assert.assertTrue(th instanceof NoSuchDynamicMethodException);

test/jdk/jdk/dynalink/TrustedDynamicLinkerFactoryTest.java line 196:

> 194:                 MethodHandles.publicLookup(), GET_PROPERTY, mt)));
> 195:         Assert.assertFalse(reachedPrelinkTransformer[0]);
> 196:         Assert.assertEquals(cs.getTarget().invoke(new Object(), "class"), java.util.Objects.newIdentity().getClass());

Similar to BeanLinkerTest.java, it's clearer to define a TestObject class to replace "new Object()" in this test.

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 05:54:23 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 05:54:23 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation [v3]
In-Reply-To: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
Message-ID: <iWCJ77BftZ3ZllMEMraxzjhJYba9Cx0KHozAWfXokeQ=.27306ece-b898-4769-87cb-dccab6c21376@github.com>

> Translate new Object() instantiations down to invovations of java.util.Objects.newIdentity() call with an informational message at compie time

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

 - Address Mandy's review comments/suggestions
 - Merge branch 'lworld' into JDK-8237073
 - Incorporate review comments from Mandy Chung
 - Merge branch 'lworld' into JDK-8237073
 - 8237073: [lworld] Need special handling of jlO constructor invocation

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/481/files
  - new: https://git.openjdk.java.net/valhalla/pull/481/files/9f960b67..6f63c0ce

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

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 05:54:29 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 05:54:29 GMT
Subject: [lworld] RFR: 8237073: [lworld] Need special handling of jlO
 constructor invocation [v2]
In-Reply-To: <_bEfBdgE3sc6vrkRc8LqHuYKalQY1O0Ow8dgFyTj_dk=.b4e019e4-5a54-4acf-82c4-694f6ac55c03@github.com>
References: <MbCpxmPB6Mu3JlTtPxsm49SQmHsKO8C4_557ld-VXng=.238739cf-505c-43be-8dca-eae73b8d2fad@github.com>
 <-JDa-8cmzRRCjmRF-4Q4cAqd8AwAy0p1rKnO6cnlCtM=.2ad88137-f3a9-4cfa-b988-b2e7fc564a2a@github.com>
 <_bEfBdgE3sc6vrkRc8LqHuYKalQY1O0Ow8dgFyTj_dk=.b4e019e4-5a54-4acf-82c4-694f6ac55c03@github.com>
Message-ID: <lv-uODhkTHdqXYY2VI4Ym_t3km-9c6773VzEmRnwno8=.1d8c5572-05aa-4d96-bf67-077f2f0c5132@github.com>

On Fri, 16 Jul 2021 18:16:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Incorporate review comments from Mandy Chung
>>  - Merge branch 'lworld' into JDK-8237073
>>  - 8237073: [lworld] Need special handling of jlO constructor invocation
>
> test/jdk/jdk/dynalink/TrustedDynamicLinkerFactoryTest.java line 196:
> 
>> 194:                 MethodHandles.publicLookup(), GET_PROPERTY, mt)));
>> 195:         Assert.assertFalse(reachedPrelinkTransformer[0]);
>> 196:         Assert.assertEquals(cs.getTarget().invoke(new Object(), "class"), java.util.Objects.newIdentity().getClass());
> 
> Similar to BeanLinkerTest.java, it's clearer to define a TestObject class to replace "new Object()" in this test.

Done!

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 06:21:05 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 06:21:05 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <GUDVSgxQPt7mYRX_kK9uhnUn4lkDVdMp7hYk2pkwyOI=.ce99ac3e-09fb-46de-a3ed-dbff85a3a33d@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1216:

> 1214:                     && (t.tsym != s.tsym ||
> 1215:                         (t.isReferenceProjection() == s.isReferenceProjection() && t.isValueProjection() == s.isValueProjection()))
> 1216:                      // Check type variable containment

This check should really be comparing that t.flavor == s.flavor. But this is causing some issues at the moment and will be followed up in JDK-8270882

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1463:

> 1461:                     && t.isReferenceProjection() == s.isReferenceProjection()
> 1462:                     && t.isValueProjection() == s.isValueProjection()
> 1463:                     && visit(getEnclosingType(t), getEnclosingType(s))

Likewise this should be checking that t.flavor == s.flavor. Will be followed up in JDK-8270882

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 06:26:29 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 06:26:29 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <YxUn-keRvbJ_XEYTqS20KZqxuT4fBS0Od1IK3sgDAQ8=.1d878e9d-e0f6-41b6-a3fd-e8a5a9941977@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2636:

> 2634:                         wantedFlavor = firstExplicitBound.getFlavor();
> 2635:                     // Todo: Handle Type variable case.
> 2636:                 }

This TODO is captured as a follow up task in JDK-8270882

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 987:

> 985:                     c.flags_field |= NOOUTERTHIS;
> 986:                 }
> 987:                 attribClass(tree.pos(), c);

This chunk purportedly introduced to serve the purpose of "avoiding further secondary errors" had outlived its purpose and is removed now. This change is not "essential" to the overall implementation and is a incidental cleanup

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 06:33:16 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 06:33:16 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <UPK-JJFow1KM06tF4-sWWZSLzjBPe3PWltLLp_nhgWA=.10e45bfe-6987-48e2-9a0e-b2c965125f9f@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 326:

> 324:                 */
> 325:                 if (env.info.inWithField && v.getKind() == ElementKind.FIELD && (v.flags() & STATIC) == 0 && v.owner.isPrimitiveClass()) {
> 326:                     if (env.enclClass.sym.outermostClass() == v.owner.outermostClass())

This is an example of a code change you will see recur several times: Earlier when we had only value default primitive classes to check if a field is a field of a primitive class it was alright to ask

types.isPrimitiveClass(v.owner.type)

With ref-default classes entering the picture if v.owner is a ref-default primitive class then v.owner.type will not
answer true for the above check. (For a ref-default primitive class Optional.val, Optional.type is 'L' type not Q type) and we need to check

owner.isPrimitiveClass()

which will answer true for both val-default and ref-default primitive classes.

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 06:49:10 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 06:49:10 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <rWUHAFo6EmCv66Wqm_F5E-BOpoOAxbllWvKHdHmtHQ4=.cec74c4e-4233-4d3a-93c3-183f4089933f@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

I have annotated the code changes with hopefully helpful comments that will help the reviewer. 
https://bugs.openjdk.java.net/browse/JDK-8270882 has various tasks deliberately deferred.

src/jdk.jdeps/share/classes/com/sun/tools/classfile/AccessFlags.java line 65:

> 63: 
> 64:     public static enum Kind { Class, InnerClass, Field, Method, JavacExtra}
> 65: 

This is an half hearted attempt to find a place for ACC_REF_DEFAULT - I don't think it belongs here really since it is not a part of the class flags. But I have stuck this in here for now - In javap code to reference ACC_REF_DEFAULT symbolically this is useful (since the compiler's definition from Flags.java is not visible there in javap). To be cleaned up in JDK-8270882

src/jdk.jdeps/share/classes/com/sun/tools/classfile/Attribute.java line 52:

> 50:     public static final String InnerClasses             = "InnerClasses";
> 51:     public static final String JavaFlags                = "JavaFlags";
> 52:     public static final String LineNumberTable          = "LineNumberTable";

The name and attribute syntax was suggested by Dan, this may incur/undergo some bikeshedding later.

src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java line 364:

> 362:         if ((attr.extendedFlags & ACC_REF_DEFAULT) != 0)
> 363:             println("ACC_REF_DEFAULT");
> 364:         indent(-1);

com.sun.tools.javac.code.Flags#ACC_REF_DEFAULT is not visible here. So com.sun.tools.classfile.AccessFlags has been enhanced to define ACC_REF_DEFAULT - but this is a stop gap

test/langtools/tools/javac/valhalla/lworld-values/CheckFinal.out line 5:

> 3: CheckFinal.java:17:13: compiler.err.cant.assign.val.to.final.var: xsf
> 4: CheckFinal.java:19:29: compiler.err.cant.inherit.from.final: CheckFinal
> 5: 4 errors

The (now deleted) attempt to avoid further secondary errors in Attr.java having outlived its purpose was actually causing additional errors to be emitted! Fixed.

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

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


From thartmann at openjdk.java.net  Mon Jul 19 08:12:08 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 19 Jul 2021 08:12:08 GMT
Subject: [lworld] RFR: 8270357: [lworld] some jtreg tests disabled on
 AArch64
In-Reply-To: <_cb5hG9UlldpAJBDZybAFCedAeb3krzVGu-TKU-2DUk=.6900f7dd-b334-4126-b9a2-166a7505010d@github.com>
References: <_cb5hG9UlldpAJBDZybAFCedAeb3krzVGu-TKU-2DUk=.6900f7dd-b334-4126-b9a2-166a7505010d@github.com>
Message-ID: <7rAyVanYhNX2UUz9u6QicgG0A07L_tpohgFnaUS2F6E=.eb42727b-3ba5-446a-82ed-f4041d4e14b6@github.com>

On Wed, 14 Jul 2021 06:32:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Several tests under runtime/valhalla and compiler/valhalla have `@requires os.simpleArch == "x64"`. They should be enabled on AArch64 too.
> 
> A couple of these tests, as well as three of the existing ones, fail on AArch64 with some variant of:
> 
> 
> java.lang.RuntimeException: Graph for 'TestBasicFunctionality::test3' contains different number of match nodes (expected 1 but got 0):
> 
> 
> The regex pattern these tests are looking for is specific to the x86 opto assembly output. They regex needs to be adjusted for the AArch64 format. I'll do that after #457 is merged which also touches the same files.

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

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


From thartmann at openjdk.java.net  Mon Jul 19 08:18:18 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 19 Jul 2021 08:18:18 GMT
Subject: [lworld] RFR: 8264340: [lworld] [AArch64] TestLWorld.java
 assertion failure in OopFlow::build_oop_map
In-Reply-To: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
References: <ffbEIYmZdjh7eJcjQN8_CUJJEEG5L4HPBbyDn9_AZw0=.14575205-141b-439c-9653-a6a56d716d51@github.com>
Message-ID: <mE_N3xA4MY2IIO-CZvAbpfkg6ODxH4GyfbDRcsqX0A4=.760cb6a6-b130-467a-9426-4554b0416605@github.com>

On Tue, 13 Jul 2021 11:08:47 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This happens reliably in TestLWorld::test9() scenario 0 on AArch64:
> 
> 
>   # A fatal error has been detected by the Java Runtime Environment:
>   #
>   # Internal Error (/mnt/nicgas01-pc/valhalla/src/hotspot/share/opto/buildOopMap.cpp:360), pid=8866, tid=8882
>   # assert(false) failed: there should be a oop in OopMap instead of a live raw oop at safepoint
>   #
> 
> 
> The crash can also be reproduced on x86 by running with -XX:+OptoScheduling (this is the default on AArch64).
> 
> The problem seems to be caused by a CheckCastPP node whose input is a raw pointer being scheduled after a SafePoint node such that the raw pointer is live in a register over the safepoint.
> 
> Before scheduling we have a basic block like:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>   R0      84  checkCastPP  ===  11  73  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
> 
> 
> But after scheduling this is transformed into:
> 
> 
>   R0      73  Phi  ===  15  74  30  [[ 72  71  70  69  68  67  84 ]]  #rawptr:BotPTR !jvms: SchedCrash$MyValue1::setX @ bci:-1 (line 27) SchedCrash::test9 @ bci:25 (line 39)
>   ...
>           6  safePoint  ===  9  0  33  0  0  7  0  78  40  0  140  135  136  139  138  141  | 164  [[ 8  4 ]]  !jvms: SchedCrash::test9 @ bci:33 (line 37)
>   ...
>   R0      84  checkCastPP  ===  11  73  | 67  68  69  70  71  72  [[ 2 ]] SchedCrash$MyValue1:NotNull:exact *  Oop:SchedCrash$MyValue1:NotNull:exact * !jvms: SchedCrash$MyValue1::<init> @ bci:65 (line 24) SchedCrash$MyValue1::setX @ bci:21 (line 27) SchedCrash::test9 @ bci:25 (line 39)
> 
> 
> Where R0 is holding the live raw pointer over the safepoint, which triggers the assertion failure.
> 
> The fix here is to add a precedence edge from any CheckCastPP with a raw pointer input to the following safepoint, which prevents them being rearranged. I'm not very familiar with this code so I can't be sure this is the correct solution, but the same logic exists in GCM's PhaseCFG::schedule_late().

Is this specific to Valhalla and if so, do you know why?

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 08:26:05 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 08:26:05 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v2]
In-Reply-To: <kUV6iIgHk2OzUHG97RHLnzcYtUyMHM3yhZaYK4UL-lY=.e77c30f2-0e48-401c-9906-3c95928f565a@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <kUV6iIgHk2OzUHG97RHLnzcYtUyMHM3yhZaYK4UL-lY=.e77c30f2-0e48-401c-9906-3c95928f565a@github.com>
Message-ID: <6uWrQ0o1al7bMN8YHKGhwPXZqPfshJ6-XQc-G3Tea8I=.ed8cf984-e173-427d-b94c-c97264fba480@github.com>

On Sun, 4 Jul 2021 19:18:51 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   [lworld] Handling poly-inference of missing arguments by simulating a synthetic method.

Hello Jesper, this latest patch is problematic. it does not properly treat Foo.default as a poly expression. As Maurizio's earlier review comments points out: 


I don't see how this approach can scale to default expression passed as method arguments - given that in that case there is no pt(). To add support for that you need to add another case/node in ArgumentAttr (see what's been done for anonymous inner classes - this should be simpler as there's no constructor call).

In other words, you want Attr.visitApply to treat your default expression method argument in a special way - by creating what we call a "deferred type" - that is a type that is not fully inferred until after overload resolution (when you DO know the pt()).


I don't see the relevant code changes in your change set - i.e there is no changes in ArgumentAttr {} - I would have expected to see a visitDefaultValue method there.

As Maurizio further pointed out earlier, in Attr.visitApply, right after arguments are attributed, the type of Foo.default as a method argument should be a deferred type . If I debug the uploaded patch, the type of Foo.default is actually Foo<T>

The problem is masked by there being only negative tests in your patch.

If I compile the following:


public primitive class X<T> {

    
    static void m(X<String> ls) { }

    public static void main(String [] args) {
        m(new X<>()); // OK
        m(X<String>.default); // OK.
        m(X.default);   // OK, BUT get an error here!
    }

}



at the line with the .default usage I get:

 error: incompatible types: X<T> cannot be converted to X<String>
        m(X.default);
           ^
  where T is a type-variable:
    T extends Object declared in class X
Note: Some messages have been simplified; recompile with -Xdiags:verbose to get full output
1 error
``` 

This shows that there is no real inference happening there.

(when a poly type argument is attributed without a target type in context, it should be typed to be DeferredType, when considered against overload candidates the positional parameter type becomes the pt() and the deferred type can now be typed to a concrete type)

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

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


From sadayapalam at openjdk.java.net  Mon Jul 19 08:30:21 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 19 Jul 2021 08:30:21 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v2]
In-Reply-To: <kUV6iIgHk2OzUHG97RHLnzcYtUyMHM3yhZaYK4UL-lY=.e77c30f2-0e48-401c-9906-3c95928f565a@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <kUV6iIgHk2OzUHG97RHLnzcYtUyMHM3yhZaYK4UL-lY=.e77c30f2-0e48-401c-9906-3c95928f565a@github.com>
Message-ID: <i_JRRP_KiaqZI3u6ZkVv0GmXq-Jo5Oa8W9uz6IuD0PY=.520ef0c4-29ec-48de-aa0c-c8de804b6f5a@github.com>

On Sun, 4 Jul 2021 19:18:51 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> Make .default a separate node type in the parser.
>> 
>> ## Issue
>> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
>> 
>> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.
>
> Jesper Steen M?ller has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   [lworld] Handling poly-inference of missing arguments by simulating a synthetic method.

A way to see this in more detail is to debug through the Attr.visitApply call corresponding to the method invocation


m(new X<>(), X.default);


in this test case:


public primitive class X<T> {

    
    static void m(X<String> ls, X<String> ls2) { }

    public static void main(String [] args) {
        m(new X<>(), X.default);
    }

}



You will see that first argument is typed to be DeferredType and second one incorrectly to be X<T\>

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

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


From hseigel at openjdk.java.net  Wed Jul 21 20:12:20 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 21 Jul 2021 20:12:20 GMT
Subject: [lworld] RFR: 8269756: [lworld] Add tests for invalid withfield
 operands
Message-ID: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>

Please review this change to add a test for various scenarios involving withfield.  The test was run locally on Linux x64 and using Mach5 tiers 1-2.

Note that the test temporarily is run with -Xint because it fails when run with -Xcomp.  -Xint will be removed once it passes with -Xcomp.

Thanks, Harold

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

Commit messages:
 - 8269756: [lworld] Add tests for invalid withfield operands

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

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


From mchung at openjdk.java.net  Thu Jul 22 01:02:17 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Jul 2021 01:02:17 GMT
Subject: [lworld] RFR: JDK-8271113: [lworld]
 java/lang/constant/MethodHandleDescTest.java fails after JDK-8247376
Message-ID: <LZjGZ-GwBUGhTGhw_NoZ8oUwWb3AEbyYqMJfy-wC5qg=.0c76c344-8b0f-4001-b466-e255c4715914@github.com>

It's a bug in the fix of JDK-8247376 that appends ".ref" in the display name if the descriptor is not Q-descriptor.  It can't determine if the class represented by the given L-descriptor string is a primitive class or not.   This patch will revert the change in ClassClass::displayName.   We will follow up if ClassDesc::displayName should return a different string for primitive reference type vs primitive value type in a separate issue.

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

Commit messages:
 - JDK-8271113: [lworld] java/lang/constant/MethodHandleDescTest.java fails after JDK-8247376

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

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


From mchung at openjdk.java.net  Thu Jul 22 01:42:02 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Jul 2021 01:42:02 GMT
Subject: [lworld] Integrated: JDK-8271113: [lworld]
 java/lang/constant/MethodHandleDescTest.java fails after JDK-8247376
In-Reply-To: <LZjGZ-GwBUGhTGhw_NoZ8oUwWb3AEbyYqMJfy-wC5qg=.0c76c344-8b0f-4001-b466-e255c4715914@github.com>
References: <LZjGZ-GwBUGhTGhw_NoZ8oUwWb3AEbyYqMJfy-wC5qg=.0c76c344-8b0f-4001-b466-e255c4715914@github.com>
Message-ID: <SZJxcO3MYDQBawxzmExtefpkchGPdWzOCvOJLEiJCeA=.d23bd934-3660-4e0f-a5cf-c6f46a5a4b54@github.com>

On Thu, 22 Jul 2021 00:55:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It's a bug in the fix of JDK-8247376 that appends ".ref" in the display name if the descriptor is not Q-descriptor.  It can't determine if the class represented by the given L-descriptor string is a primitive class or not.   This patch will revert the change in ClassClass::displayName.   We will follow up if ClassDesc::displayName should return a different string for primitive reference type vs primitive value type in a separate issue.

This pull request has now been integrated.

Changeset: 64ad8d03
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/64ad8d034e8bad29ee3b1e32db2a312c15bcc229
Stats:     4 lines in 2 files changed: 0 ins; 1 del; 3 mod

8271113: [lworld] java/lang/constant/MethodHandleDescTest.java fails after JDK-8247376

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

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


From ngasson at openjdk.java.net  Thu Jul 22 06:12:34 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 22 Jul 2021 06:12:34 GMT
Subject: [lworld] RFR: 8271017: [lworld] Implement withfield changes from
 JDK-8269408 on AArch64
Message-ID: <gSAs1oiw-SoxMqxNxtzjJ7cK1jB83k4feuye9I0Or-A=.9f150989-5df9-4f70-b816-5ffc9de3a709@github.com>

This just applies the changes in JDK-8269408 to the AArch64 port.

The old `InterpreterRuntime::withfield()` is removed as it has no more users, and I've renamed withfield2 to withfield (presumably this was the original intention?).

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

Commit messages:
 - 8271017: [lworld] Implement withfield changes from JDK-8269408 on AArch64

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 06:44:58 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 06:44:58 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
Message-ID: <wCi2L5OLy17kehLDbVfwvsGv2rRgxpGH3bzLi41xQKc=.ab799973-1f9c-4386-a67e-d546ac140bed@github.com>

On Wed, 21 Jul 2021 11:40:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Code changes and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3993:
> 
>> 3991:         Name name = typeName();
>> 3992: 
>> 3993:         if ((mods.flags & Flags.PRIMITIVE_CLASS) != 0) {
> 
> Not a code comment, but I find the syntax `primitive class Foo.val` a bit jarring to define a *reference*-favoring class.

Understand, this is directly implementing the syntax prescribed by the JEP and feedback would be welcomed there,

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 07:02:03 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 07:02:03 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <z4U3eJ2-B89Ylwi32fJ0B62zkWQtZNdBdrqUwAIInNk=.2b640e80-b29c-4269-a6f8-85643335d093@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <UPK-JJFow1KM06tF4-sWWZSLzjBPe3PWltLLp_nhgWA=.10e45bfe-6987-48e2-9a0e-b2c965125f9f@github.com>
 <z4U3eJ2-B89Ylwi32fJ0B62zkWQtZNdBdrqUwAIInNk=.2b640e80-b29c-4269-a6f8-85643335d093@github.com>
Message-ID: <b4Hk2MLnvvMO26wNNXUdp7_QkTDvLBaiJXu8cKJdyow=.075cbf85-f4fb-4cd4-b99c-2d263539c9f1@github.com>

On Wed, 21 Jul 2021 12:09:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 326:
>> 
>>> 324:                 */
>>> 325:                 if (env.info.inWithField && v.getKind() == ElementKind.FIELD && (v.flags() & STATIC) == 0 && v.owner.isPrimitiveClass()) {
>>> 326:                     if (env.enclClass.sym.outermostClass() == v.owner.outermostClass())
>> 
>> This is an example of a code change you will see recur several times: Earlier when we had only value default primitive classes to check if a field is a field of a primitive class it was alright to ask
>> 
>> types.isPrimitiveClass(v.owner.type)
>> 
>> With ref-default classes entering the picture if v.owner is a ref-default primitive class then v.owner.type will not
>> answer true for the above check. (For a ref-default primitive class Optional.val, Optional.type is 'L' type not Q type) and we need to check
>> 
>> owner.isPrimitiveClass()
>> 
>> which will answer true for both val-default and ref-default primitive classes.
>
> Yes, but again, leaving a method in `Types` called `isPrimitiveClass` which takes a type and return false when the type is derived from a primitive class seems suboptimal. See my comment on `Type::isPrimitiveClass`. I think what you want there is probably `isPrimitiveType`. or `isValueType` or something like that - stay away from `Class`.

Fair points. 

Since we already have com.sun.tools.javac.code.Type#isPrimitive it is useful to retain to "Class" somewhere in the new APIs name although perhaps not in the present form of Type#isPrimitiveClass()

Perhaps the old method should be renamed to isBasicPrimitive() and the new one should be isPrimitiveClassType()

I will carry over these comments to JDK-8268734 (Various internal Type/Symbol APIs need rationalization/adjustment)

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 07:51:08 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 07:51:08 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
Message-ID: <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>

On Wed, 21 Jul 2021 12:00:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Code changes and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1381:
> 
>> 1379:                 }
>> 1380:             }
>> 1381:             return flavor == Flavor.Q_TypeOf_L;
> 
> Shouldn't we discount primitive-default primitive classes in here? (e.g. should this code be symmetric with `isReferenceProjection`?). E.g. what about `.val` in an already primitive-default primitive class?

W.r.t the observation: "I'm also a bit unsure (and left comment) on whether isReferenceProjection and isValueProjection are implemented correctly. They do not seem to be the dual of each other at the moment (or at least do not seem to do what the javadoc says they should)."

Please take a another look! I believe they are dual of each other and do what the javadoc claims - (although as I call out below, I am open to questioning whether their behavior should be redefined)

ATM, the javadoc of isReferenceProjection() and isValueProjection() read:


    /**
     * @return true IFF the receiver is a reference projection type of a *value favoring* primitive class
     * and false otherwise. Or in other words, is this a class type non-redundantly notated with .ref ??
     */
    public boolean isReferenceProjection() {
        return false;
    }

    /**
     * @return true IFF the receiver is a value projection of a *reference favoring* primitive class type
     * and false otherwise. Or in other words, is this a class type non-redundantly notated with .val ??
     */
    public boolean isValueProjection() {
        return false;
    }



You ask of com.sun.tools.javac.code.Type.ClassType#isValueProjection

Shouldn't we discount primitive-default primitive classes in here? (e.g. should this code be symmetric with isReferenceProjection?). E.g. what about .val in an already primitive-default primitive class?


We *are* already discounting primitive-default classes, because in that case the flavor would be Q_TypeOf_Q.

The ambiguity exists only for the flavor L_TypeOf_Q - when we have a type that is an L_TypeOf_Q it could be
either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.   

Of (a) and (b) only (a) we consider to be the *reference projection* as per the javadoc.

On the other hand:

Between Q_Typeof_Q and Q_Typeof_L, only the latter is considered a value projection as per the javadoc.

(Backing up a bit it is a fair question to ask should the javadoc be defined that way - should both Q_Typeof_Q and Q_Typeof_L be considered value *projections* and should L_TypeOf_Q should *always* be considered a reference *projection* irrespective of whether the associated class is a reference default or value default ? I have chosen not to since that seems "natural" - but I am open to revisiting this if our experience proves otherwise.

Please see that this is the same issue JEP 401 grapples with by asking the question in https://openjdk.java.net/jeps/401

(Open question: should it be legal to redundantly apply .val to a standard primitive class name, or .ref to a reference-favoring primitive class name?)

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 07:54:59 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 07:54:59 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
Message-ID: <HLQwpJKLViPo2PmUs-pIN6KqGfsI2GQCvo4W99vKm1E=.0d34a792-dfee-4ef9-a439-dc7e405a5f3f@github.com>

On Wed, 21 Jul 2021 12:02:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Code changes and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1340:
> 
>> 1338: 
>> 1339:         @Override
>> 1340:         public boolean isPrimitiveClass() {
> 
> I'm not too convinced by the name of this method. The use of the word `Class` makes me think of the symbol - but here you are essentially checking if it's a value projection (regardless of whether the primitive symbol is reference-favoring or not). So the name of the method should be updated and some clarifying javadoc added too. I think this should be called `isValueType` which would then connect to `asValueType` - e.g.
> 
> 
> assert type.asValueType().isValueType() // ok

Agreed, per earlier comment, I will take up this in JDK-8268734. 

(I am a bit unsettled on using "value type" at all, since the JEP introduces the name primitive class type and we are moving away value/inline nomenclature. But I see that java.lang.Class defines a method by name asValueType)

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 08:04:04 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 08:04:04 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
Message-ID: <CFQAcz9zaOKiYbJguRur_qTEyqjDBX5bQ6Z8FNZ3r9o=.8943c9de-cb63-4669-a5a9-c5c7a001c936@github.com>

On Wed, 21 Jul 2021 13:11:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Code changes and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1366:
> 
>> 1364:             if (tsym != null) {
>> 1365:                 if (flavor == Flavor.L_TypeOf_X || tsym.isCompleted()) {
>> 1366:                     flavor = flavor.metamorphose(tsym.flags());
> 
> (Not related to this review) I think we should probably change the `metamorphose` name to a more neutral one like `update` ?

Oh, you didn't like the cute name I coined! I really liked metamorphose() since it captures that the Type starts out in larval form where not much is known about and evolves into a full blown form in stages through metamorphosis!

No matter, I am not wedded to the name,  I will add a note to JDK-8268734 to follow up

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1215:
> 
>> 1213:                 return sup.tsym == s.tsym
>> 1214:                     && (t.tsym != s.tsym ||
>> 1215:                         (t.isReferenceProjection() == s.isReferenceProjection() && t.isValueProjection() == s.isValueProjection()))
> 
> I guess this works because `asSuper` will return either:
> 
> * a supertype of `t`, in which case we now it's a reference type, so for `t` to be subtype of `s`, it must be that `t` is a reference type too
> * it returns `t` itself, in which case subtyping holds as long as `t` and `s` are the same

Right.

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 08:13:58 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 08:13:58 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <H2UJdIrOeXsYPOsoPF9zTSJF1xHKg-53WTCecqCXUl4=.cf2c79eb-b62d-41bd-b84f-a8ef7a941772@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <H2UJdIrOeXsYPOsoPF9zTSJF1xHKg-53WTCecqCXUl4=.cf2c79eb-b62d-41bd-b84f-a8ef7a941772@github.com>
Message-ID: <BIZ7LwsFlkJ2Fjjwca5IdMbGuixPqTm6edeUtnthrXU=.f291658d-0ec0-4fc3-90fc-ffe3b4908cd2@github.com>

On Wed, 21 Jul 2021 13:27:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Code changes and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4674:
> 
>> 4672:                     // reflect this.
>> 4673:                     if (sym.isPrimitiveClass()) {
>> 4674:                         if (sym.isReferenceFavoringPrimitiveClass()) {
> 
> Shouldn't we simplify this to try and use `asValueType` - probably this suggests there should be an `asReferenceType` too?

ATM, we have com.sun.tools.javac.code.Type#referenceProjection()

Again, I will use JDK-8268734 to rationalize the various internal APIs we have - while doing so, also looking at choice of terminology adopted by java.lang.Class  

But I didn't understand the comment about the simplification you are suggesting - can you clarify ?

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

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


From mcimadamore at openjdk.java.net  Thu Jul 22 10:00:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Jul 2021 10:00:00 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <BIZ7LwsFlkJ2Fjjwca5IdMbGuixPqTm6edeUtnthrXU=.f291658d-0ec0-4fc3-90fc-ffe3b4908cd2@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <H2UJdIrOeXsYPOsoPF9zTSJF1xHKg-53WTCecqCXUl4=.cf2c79eb-b62d-41bd-b84f-a8ef7a941772@github.com>
 <BIZ7LwsFlkJ2Fjjwca5IdMbGuixPqTm6edeUtnthrXU=.f291658d-0ec0-4fc3-90fc-ffe3b4908cd2@github.com>
Message-ID: <HfO_XbCeFs8rQdgKojRVdgLPGbgvMAw7dQMRQlbaN2U=.78bd56fa-c196-433b-a690-d4cc0a72f6d2@github.com>

On Thu, 22 Jul 2021 08:11:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4674:
>> 
>>> 4672:                     // reflect this.
>>> 4673:                     if (sym.isPrimitiveClass()) {
>>> 4674:                         if (sym.isReferenceFavoringPrimitiveClass()) {
>> 
>> Shouldn't we simplify this to try and use `asValueType` - probably this suggests there should be an `asReferenceType` too?
>
> ATM, we have com.sun.tools.javac.code.Type#referenceProjection()
> 
> Again, I will use JDK-8268734 to rationalize the various internal APIs we have - while doing so, also looking at choice of terminology adopted by java.lang.Class  
> 
> But I didn't understand the comment about the simplification you are suggesting - can you clarify ?

I mean - this code does a bunch of checks - and then creates a new class type with the opposite flavor/polarity. Isn't that what methods like `Type::asValueType` are supposed to do? E.g. if I have a reference-favoring primitive and I see `.val` can't I just get the type I want by calling `asValueType()` on it? If so, should we also have the dual?

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

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


From mcimadamore at openjdk.java.net  Thu Jul 22 10:09:07 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Jul 2021 10:09:07 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
Message-ID: <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>

On Thu, 22 Jul 2021 07:47:48 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> when we have a type that is an L_TypeOf_Q it could be
> either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.

This seems at odds with what the Javadoc for that flavor says:


/**
             * Reference projection type of a primitive-favoring aka primitive-default
             * plain vanilla primitive class type,
             */
            L_TypeOf_Q,


E.g. javadoc suggests that Q means primitive-default already, so there should be no need to check the tsym?

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

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


From mcimadamore at openjdk.java.net  Thu Jul 22 10:27:58 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Jul 2021 10:27:58 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
 <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
Message-ID: <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>

On Thu, 22 Jul 2021 10:06:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> W.r.t the observation: "I'm also a bit unsure (and left comment) on whether isReferenceProjection and isValueProjection are implemented correctly. They do not seem to be the dual of each other at the moment (or at least do not seem to do what the javadoc says they should)."
>> 
>> Please take a another look! I believe they are dual of each other and do what the javadoc claims - (although as I call out below, I am open to questioning whether their behavior should be redefined)
>> 
>> ATM, the javadoc of isReferenceProjection() and isValueProjection() read:
>> 
>> 
>>     /**
>>      * @return true IFF the receiver is a reference projection type of a *value favoring* primitive class
>>      * and false otherwise. Or in other words, is this a class type non-redundantly notated with .ref ??
>>      */
>>     public boolean isReferenceProjection() {
>>         return false;
>>     }
>> 
>>     /**
>>      * @return true IFF the receiver is a value projection of a *reference favoring* primitive class type
>>      * and false otherwise. Or in other words, is this a class type non-redundantly notated with .val ??
>>      */
>>     public boolean isValueProjection() {
>>         return false;
>>     }
>> 
>> 
>> 
>> You ask of com.sun.tools.javac.code.Type.ClassType#isValueProjection
>> 
>> Shouldn't we discount primitive-default primitive classes in here? (e.g. should this code be symmetric with isReferenceProjection?). E.g. what about .val in an already primitive-default primitive class?
>> 
>> 
>> We *are* already discounting primitive-default classes, because in that case the flavor would be Q_TypeOf_Q.
>> 
>> The ambiguity exists only for the flavor L_TypeOf_Q - when we have a type that is an L_TypeOf_Q it could be
>> either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.   
>> 
>> Of (a) and (b) only (a) we consider to be the *reference projection* as per the javadoc.
>> 
>> On the other hand:
>> 
>> Between Q_Typeof_Q and Q_Typeof_L, only the latter is considered a value projection as per the javadoc.
>> 
>> (Backing up a bit it is a fair question to ask should the javadoc be defined that way - should both Q_Typeof_Q and Q_Typeof_L be considered value *projections* and should L_TypeOf_Q should *always* be considered a reference *projection* irrespective of whether the associated class is a reference default or value default ? I have chosen not to since that seems "natural" - but I am open to revisiting this if our experience proves otherwise.
>> 
>> Please see that this is the same issue JEP 401 grapples with by asking the question in https://openjdk.java.net/jeps/401
>> 
>> (Open question: should it be legal to redundantly apply .val to a standard primitive class name, or .ref to a reference-favoring primitive class name?)
>
>> when we have a type that is an L_TypeOf_Q it could be
>> either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.
> 
> This seems at odds with what the Javadoc for that flavor says:
> 
> 
> /**
>              * Reference projection type of a primitive-favoring aka primitive-default
>              * plain vanilla primitive class type,
>              */
>             L_TypeOf_Q,
> 
> 
> E.g. javadoc suggests that Q means primitive-default already, so there should be no need to check the tsym?

More generally, I think I'm slightly uncomfortable by the use of the letters `Q` and `L` in the enum constants `X_TypeOf_Y`. Now, when `L` and `Q` are in the `X` position, the semantics is simple: `L` means `.ref`, `Q` means `.val`.

But when `L` and `Q` appear in the `Y` position, then it becomes messy - because the choice is no longer binary:

* the class is a primitive class or not (1 bit)
* if primitive, the class is reference-favoring or not (another bit)

Right now, it seems that you use `Q` to denote whether the class is primitive class or not, which is useful, I assume, to detect distinction between a legacy reference type (`L_TypeOf_L`) and a reference projection of a primitive class (`L_TypeOf_Q`). This distinction is, I believe an important one, as the former has identity, the latter doesn't, so type checking would probably differ.

What I'm less sure is whether you want/need different type checking rules for when `L_TypeOf_Q && reference-favoring` vs. `L_TypeOf_Q && !reference-favoring`. What you have is still an identity-less reference type - so why should it be important whether you get a redundant projection or not (which might even be disabled at some point during type checking) ?

So, back to your question, I guess I don't see why you have defined the current behavior as being "natural". To me, getting an X projection on a X-favoring primitive class is an idempotent operation, which you can repeat even 20 times, and the type-system shouldn't care. Are there places in the code where you need this sharper distinction?

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 11:13:09 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 11:13:09 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
 <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
 <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>
Message-ID: <TMi7scGc3iuikOfMJK2wxMIBAzk1PJvZjNs4Nro910Q=.e023b595-71f8-4b6e-98ed-92c51379cbbb@github.com>

On Thu, 22 Jul 2021 10:25:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> when we have a type that is an L_TypeOf_Q it could be
>>> either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.
>> 
>> This seems at odds with what the Javadoc for that flavor says:
>> 
>> 
>> /**
>>              * Reference projection type of a primitive-favoring aka primitive-default
>>              * plain vanilla primitive class type,
>>              */
>>             L_TypeOf_Q,
>> 
>> 
>> E.g. javadoc suggests that Q means primitive-default already, so there should be no need to check the tsym?
>
> More generally, I think I'm slightly uncomfortable by the use of the letters `Q` and `L` in the enum constants `X_TypeOf_Y`. Now, when `L` and `Q` are in the `X` position, the semantics is simple: `L` means `.ref`, `Q` means `.val`.
> 
> But when `L` and `Q` appear in the `Y` position, then it becomes messy - because the choice is no longer binary:
> 
> * the class is a primitive class or not (1 bit)
> * if primitive, the class is reference-favoring or not (another bit)
> 
> Right now, it seems that you use `Q` to denote whether the class is primitive class or not, which is useful, I assume, to detect distinction between a legacy reference type (`L_TypeOf_L`) and a reference projection of a primitive class (`L_TypeOf_Q`). This distinction is, I believe an important one, as the former has identity, the latter doesn't, so type checking would probably differ.
> 
> What I'm less sure is whether you want/need different type checking rules for when `L_TypeOf_Q && reference-favoring` vs. `L_TypeOf_Q && !reference-favoring`. What you have is still an identity-less reference type - so why should it be important whether you get a redundant projection or not (which might even be disabled at some point during type checking) ?
> 
> So, back to your question, I guess I don't see why you have defined the current behavior as being "natural". To me, getting an X projection on a X-favoring primitive class is an idempotent operation, which you can repeat even 20 times, and the type-system shouldn't care. Are there places in the code where you need this sharper distinction?

> > when we have a type that is an L_TypeOf_Q it could be
> > either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.
> 
> This seems at odds with what the Javadoc for that flavor says:
> 
> ```
> /**
>              * Reference projection type of a primitive-favoring aka primitive-default
>              * plain vanilla primitive class type,
>              */
>             L_TypeOf_Q,
> ```
> 
> E.g. javadoc suggests that Q means primitive-default already, so there should be no need to check the tsym?

Good catch! This is certainly a problem in the javadoc of L_TypeOf_Q and needs to be corrected. It was always the intent that L_TypeOf_Q is simply a primitive reference type.

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 11:23:01 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 11:23:01 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <HfO_XbCeFs8rQdgKojRVdgLPGbgvMAw7dQMRQlbaN2U=.78bd56fa-c196-433b-a690-d4cc0a72f6d2@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <H2UJdIrOeXsYPOsoPF9zTSJF1xHKg-53WTCecqCXUl4=.cf2c79eb-b62d-41bd-b84f-a8ef7a941772@github.com>
 <BIZ7LwsFlkJ2Fjjwca5IdMbGuixPqTm6edeUtnthrXU=.f291658d-0ec0-4fc3-90fc-ffe3b4908cd2@github.com>
 <HfO_XbCeFs8rQdgKojRVdgLPGbgvMAw7dQMRQlbaN2U=.78bd56fa-c196-433b-a690-d4cc0a72f6d2@github.com>
Message-ID: <-SJd-G3p0SLWkbOWi_cuYDJKhp27wBYV3fsvDuwg5zs=.5923c7df-6cc8-4a4d-95bf-0fb7b9b9560a@github.com>

On Thu, 22 Jul 2021 09:56:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I mean - this code does a bunch of checks - and then creates a new class type with the opposite flavor/polarity. Isn't that what methods like `Type::asValueType` are supposed to do? E.g. if I have a reference-favoring primitive and I see `.val` can't I just get the type I want by calling `asValueType()` on it? If so, should we also have the dual?

OK, understand your point and agree that this could avoid some code duplication, Will follow up. Thanks!

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 11:41:02 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 11:41:02 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <TMi7scGc3iuikOfMJK2wxMIBAzk1PJvZjNs4Nro910Q=.e023b595-71f8-4b6e-98ed-92c51379cbbb@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
 <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
 <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>
 <TMi7scGc3iuikOfMJK2wxMIBAzk1PJvZjNs4Nro910Q=.e023b595-71f8-4b6e-98ed-92c51379cbbb@github.com>
Message-ID: <EINlyh8m9xBf4X1UwQ-KrIpKw3X1X1lodAwahXVgNxU=.0227c21e-351f-4473-aaf0-318a2e22255c@github.com>

On Thu, 22 Jul 2021 11:10:23 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> More generally, I think I'm slightly uncomfortable by the use of the letters `Q` and `L` in the enum constants `X_TypeOf_Y`. Now, when `L` and `Q` are in the `X` position, the semantics is simple: `L` means `.ref`, `Q` means `.val`.
>> 
>> But when `L` and `Q` appear in the `Y` position, then it becomes messy - because the choice is no longer binary:
>> 
>> * the class is a primitive class or not (1 bit)
>> * if primitive, the class is reference-favoring or not (another bit)
>> 
>> Right now, it seems that you use `Q` to denote whether the class is primitive class or not, which is useful, I assume, to detect distinction between a legacy reference type (`L_TypeOf_L`) and a reference projection of a primitive class (`L_TypeOf_Q`). This distinction is, I believe an important one, as the former has identity, the latter doesn't, so type checking would probably differ.
>> 
>> What I'm less sure is whether you want/need different type checking rules for when `L_TypeOf_Q && reference-favoring` vs. `L_TypeOf_Q && !reference-favoring`. What you have is still an identity-less reference type - so why should it be important whether you get a redundant projection or not (which might even be disabled at some point during type checking) ?
>> 
>> So, back to your question, I guess I don't see why you have defined the current behavior as being "natural". To me, getting an X projection on a X-favoring primitive class is an idempotent operation, which you can repeat even 20 times, and the type-system shouldn't care. Are there places in the code where you need this sharper distinction?
>
>> > when we have a type that is an L_TypeOf_Q it could be
>> > either the (a) reference projection of value default primitive class or (b) the reference type of a reference default primitive class.
>> 
>> This seems at odds with what the Javadoc for that flavor says:
>> 
>> ```
>> /**
>>              * Reference projection type of a primitive-favoring aka primitive-default
>>              * plain vanilla primitive class type,
>>              */
>>             L_TypeOf_Q,
>> ```
>> 
>> E.g. javadoc suggests that Q means primitive-default already, so there should be no need to check the tsym?
> 
> Good catch! This is certainly a problem in the javadoc of L_TypeOf_Q and needs to be corrected. It was always the intent that L_TypeOf_Q is simply a primitive reference type.

> More generally, I think I'm slightly uncomfortable by the use of the letters `Q` and `L` in the enum constants `X_TypeOf_Y`. Now, when `L` and `Q` are in the `X` position, the semantics is simple: `L` means `.ref`, `Q` means `.val`.
> 
> But when `L` and `Q` appear in the `Y` position, then it becomes messy - because the choice is no longer binary:
> 
> * the class is a primitive class or not (1 bit)
> * if primitive, the class is reference-favoring or not (another bit)
> 
> Right now, it seems that you use `Q` to denote whether the class is primitive class or not, which is useful, I assume, to detect distinction between a legacy reference type (`L_TypeOf_L`) and a reference projection of a primitive class (`L_TypeOf_Q`). This distinction is, I believe an important one, as the former has identity, the latter doesn't, so type checking would probably differ.

First of all, I agree that the javadoc of com.sun.tools.javac.code.Type.ClassType.Flavor#L_TypeOf_Q is incorrect and confusing and this has cascading ripple effects into other areas when it comes to comprehension.

So let me try to clarify the intent.

L_Typeof_Q is simply a primitive reference type - whose underlying primitive class type could either be reference favoring or value favoring.

With this clarification in place, if you look at the flavors, they naturally model the details associated with the domain.

There is inherent disparity/asymmetry in the concerned flavors in that - there is always a primitive reference type available for a primitive class (whether it is reference default or value default) but the reverse is not true bringing about the asymmetry. (ie you can have a reference type without there being a primitive class type i.e the L_Typeof_L legacy flavor)

> 
> What I'm less sure is whether you want/need different type checking rules for when `L_TypeOf_Q && reference-favoring` vs. `L_TypeOf_Q && !reference-favoring`. What you have is still an identity-less reference type - so why should it be important whether you get a redundant projection or not (which might even be disabled at some point during type checking) ?
> 
> So, back to your question, I guess I don't see why you have defined the current behavior as being "natural". To me, getting an X projection on a X-favoring primitive class is an idempotent operation, which you can repeat even 20 times, and the type-system shouldn't care. Are there places in the code where you need this sharper distinction?

Let me punt the question by saying - with the admission that javadoc of L_Typeof_Q was wrong and confusing, do we agree that once that is corrected, the flavors capture and model the domain information faithfully ? I don't off the top of the head recall places where this sharper distinction is needed - but if there is consensus that the model is valid even if a bit baroque, then that is reason to preserve it till we have more experience to definitively prune what we think is valid but superfluous information captured in the abstraction.

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

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


From mcimadamore at openjdk.java.net  Thu Jul 22 11:54:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Jul 2021 11:54:00 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <EINlyh8m9xBf4X1UwQ-KrIpKw3X1X1lodAwahXVgNxU=.0227c21e-351f-4473-aaf0-318a2e22255c@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
 <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
 <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>
 <TMi7scGc3iuikOfMJK2wxMIBAzk1PJvZjNs4Nro910Q=.e023b595-71f8-4b6e-98ed-92c51379cbbb@github.com>
 <EINlyh8m9xBf4X1UwQ-KrIpKw3X1X1lodAwahXVgNxU=.0227c21e-351f-4473-aaf0-318a2e22255c@github.com>
Message-ID: <_aE90OL1xOZYyR-vbj2Z37BuLsgmwW9dvOucYbZG76g=.872ae687-2e20-419d-9038-7dbb858288de@github.com>

On Thu, 22 Jul 2021 11:37:40 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Let me punt the question by saying - with the admission that javadoc of L_Typeof_Q was wrong and confusing, do we agree that once that is corrected, the flavors capture and model the domain information faithfully ? I don't off the top of the head recall places where this sharper distinction is needed - but if there is consensus that the model is valid even if a bit baroque, then that is reason to preserve it till we have more experience to definitively prune what we think is valid but superfluous information captured in the abstraction.

While the javadoc is the main issue, the current behavior or "isReferenceProjection" and "isValueProjection" remind me of `2 + 0 + 0 != 2`, so I find it confusing.

I think perhaps the name "projection" is also misleading - as now we have primitive reference type and primitive value type, and what you really want to ask a type is in which of these two bucket it falls in. Giving too much importance as to "how" a type has been derived (e.g. redundant `.val` or `.ref` ?) smells of over-specificity which will bite us back, I believe.

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 12:07:03 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 12:07:03 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <_aE90OL1xOZYyR-vbj2Z37BuLsgmwW9dvOucYbZG76g=.872ae687-2e20-419d-9038-7dbb858288de@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
 <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
 <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>
 <TMi7scGc3iuikOfMJK2wxMIBAzk1PJvZjNs4Nro910Q=.e023b595-71f8-4b6e-98ed-92c51379cbbb@github.com>
 <EINlyh8m9xBf4X1UwQ-KrIpKw3X1X1lodAwahXVgNxU=.0227c21e-351f-4473-aaf0-318a2e22255c@github.com>
 <_aE90OL1xOZYyR-vbj2Z37BuLsgmwW9dvOucYbZG76g=.872ae687-2e20-419d-9038-7dbb858288de@github.com>
Message-ID: <bO5AzVCBe1-0pjzFMWhokAXf5U8JTFT-DPuvDpw1Lmo=.18e441a5-32a1-4f7b-8c5c-c1a707e3ae74@github.com>

On Thu, 22 Jul 2021 11:51:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Let me punt the question by saying - with the admission that javadoc of L_Typeof_Q was wrong and confusing, do we agree that once that is corrected, the flavors capture and model the domain information faithfully ? I don't off the top of the head recall places where this sharper distinction is needed - but if there is consensus that the model is valid even if a bit baroque, then that is reason to preserve it till we have more experience to definitively prune what we think is valid but superfluous information captured in the abstraction.
> 
> While the javadoc is the main issue, the current behavior or "isReferenceProjection" and "isValueProjection" remind me of `2 + 0 + 0 != 2`, so I find it confusing.
> 
> I think perhaps the name "projection" is also misleading - as now we have primitive reference type and primitive value type, and what you really want to ask a type is in which of these two bucket it falls in. Giving too much importance as to "how" a type has been derived (e.g. redundant `.val` or `.ref` ?) smells of over-specificity which will bite us back, I believe.

Alright, I will fix the javadoc issue here and carry over the crux of the comment to JDK-8268734 to be addressed comprehensively there.

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 12:58:08 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 12:58:08 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes.
In-Reply-To: <bO5AzVCBe1-0pjzFMWhokAXf5U8JTFT-DPuvDpw1Lmo=.18e441a5-32a1-4f7b-8c5c-c1a707e3ae74@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <6xS5EuBA6XusDDaSrUIHCc78uyXn-kmjKJwxqVR3J4w=.06c8538b-ca5e-4ef4-8fdd-e419d21b137b@github.com>
 <6CXvpu39KkwxBn79XTB8UUL5dwPDZ72SAa7zVQJiJVQ=.551f2dbe-8002-45de-8965-d50a2281385b@github.com>
 <B68m9pqK18BlXtWmnWHPZWyU_GHmprV3_bKuKyQe4PE=.e989f01c-43f6-42cf-9da6-d0258b87d368@github.com>
 <Ok7jjwbJaskE4Od_MGYzCC4I8CtbkEJLsZ5RiVAlJl4=.4b5b1d44-f7d9-4534-bbd8-1515bae9e639@github.com>
 <TMi7scGc3iuikOfMJK2wxMIBAzk1PJvZjNs4Nro910Q=.e023b595-71f8-4b6e-98ed-92c51379cbbb@github.com>
 <EINlyh8m9xBf4X1UwQ-KrIpKw3X1X1lodAwahXVgNxU=.0227c21e-351f-4473-aaf0-318a2e22255c@github.com>
 <_aE90OL1xOZYyR-vbj2Z37BuLsgmwW9dvOucYbZG76g=.872ae687-2e20-419d-9038-7dbb858288de@github.com>
 <bO5AzVCBe1-0pjzFMWhokAXf5U8JTFT-DPuvDpw1Lmo=.18e441a5-32a1-4f7b-8c5c-c1a707e3ae74@github.com>
Message-ID: <7pXwop-DcVP4QLnvRG-oA4lQ0SPeAqjBoQP3NOq8rck=.952872b4-f073-4b00-b6a7-c8d219311c66@github.com>

On Thu, 22 Jul 2021 12:03:49 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> > Let me punt the question by saying - with the admission that javadoc of L_Typeof_Q was wrong and confusing, do we agree that once that is corrected, the flavors capture and model the domain information faithfully ? I don't off the top of the head recall places where this sharper distinction is needed - but if there is consensus that the model is valid even if a bit baroque, then that is reason to preserve it till we have more experience to definitively prune what we think is valid but superfluous information captured in the abstraction.
> 
> While the javadoc is the main issue, the current behavior or "isReferenceProjection" and "isValueProjection" remind me of `2 + 0 + 0 != 2`, so I find it confusing.
> 
> I think perhaps the name "projection" is also misleading - as now we have primitive reference type and primitive value type, and what you really want to ask a type is in which of these two bucket it falls in. Giving too much importance as to "how" a type has been derived (e.g. redundant `.val` or `.ref` ?) smells of over-specificity which will bite us back, I believe.

In the course of discussing further to understand this point, it has been evident that the javadoc of com.sun.tools.javac.code.Type#isReferenceProjection mentioning

Or in other words, is this a class type non-redundantly notated with .ref ??


(and likewise for isValueProjection())

is not helpful in one bit and has been a source of confusion. I will clean up that part. That part of the wording tries to be helpful, but backfires perhaps

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

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


From fparain at openjdk.java.net  Thu Jul 22 13:14:22 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 22 Jul 2021 13:14:22 GMT
Subject: [lworld] Integrated: 8271141: [lworld] Remove unused jvaluetype q
 member in jvalue
Message-ID: <gRQwqsSyElJNFhzZG55YVI_KFLDHAXGwv69KfWIqTIA=.d4131ee3-a4d3-41bb-b82c-a2e4e8679037@github.com>

Simple cleanup in jvalue.

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

Commit messages:
 - Removed unused member in jvalue

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

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


From fparain at openjdk.java.net  Thu Jul 22 13:14:23 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 22 Jul 2021 13:14:23 GMT
Subject: [lworld] Integrated: 8271141: [lworld] Remove unused jvaluetype q
 member in jvalue
In-Reply-To: <gRQwqsSyElJNFhzZG55YVI_KFLDHAXGwv69KfWIqTIA=.d4131ee3-a4d3-41bb-b82c-a2e4e8679037@github.com>
References: <gRQwqsSyElJNFhzZG55YVI_KFLDHAXGwv69KfWIqTIA=.d4131ee3-a4d3-41bb-b82c-a2e4e8679037@github.com>
Message-ID: <xe8Uuttn_mdv2hPCkvL-vOga3XqLPsR4CBD8D9nXd8c=.ef79dd67-1fca-40ee-a467-23990eac243c@github.com>

On Thu, 22 Jul 2021 13:07:10 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple cleanup in jvalue.

This pull request has now been integrated.

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

8271141: [lworld] Remove unused jvaluetype q member in jvalue

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

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


From sadayapalam at openjdk.java.net  Thu Jul 22 13:23:41 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 22 Jul 2021 13:23:41 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes. [v2]
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <v-Lg5pOzOyJi4UQbhN6twFLvkkAV59OevRm_6PiHLJI=.d7cb45d2-9943-48d8-9f36-6d3d6f4e9539@github.com>

> Code changes and tests

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

 - Merge branch 'lworld' into JDK-8244231
 - Fix confusingi/unhelpful javadoc per review comments
 - Adjust tests post JDK-8237073
 - Merge branch 'lworld' into JDK-8244231
 - Fix white space problems
 - Fix white space problems
 - Modify several existing tests to verify behavior with reference default classes
 - 8244231: Add support for ref-default and val-default inline classes.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/482/files
  - new: https://git.openjdk.java.net/valhalla/pull/482/files/17d79b7e..f1100617

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

  Stats: 1338 lines in 74 files changed: 843 ins; 245 del; 250 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/482/head:pull/482

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


From fparain at openjdk.java.net  Thu Jul 22 14:10:09 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 22 Jul 2021 14:10:09 GMT
Subject: [lworld] RFR: 8269756: [lworld] Add tests for invalid withfield
 operands
In-Reply-To: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>
References: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>
Message-ID: <1RfhUlyhyJR8XshRfkPKDE7JV6_9Hmb3OH6R36QO8Lo=.69a2046f-facf-490e-a360-3faa73068388@github.com>

On Wed, 21 Jul 2021 20:05:56 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to add a test for various scenarios involving withfield.  The test was run locally on Linux x64 and using Mach5 tiers 1-2.
> 
> Note that the test temporarily is run with -Xint because it fails when run with -Xcomp.  -Xint will be removed once it passes with -Xcomp.
> 
> Thanks, Harold

Tests look good to me.
Thank you for implementing them.

Fred

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

Marked as reviewed by fparain (Committer).

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


From hseigel at openjdk.java.net  Thu Jul 22 14:36:09 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 22 Jul 2021 14:36:09 GMT
Subject: [lworld] Integrated: 8269756: [lworld] Add tests for invalid
 withfield operands
In-Reply-To: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>
References: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>
Message-ID: <HZOag1UFDXwBYWFcUQ8bc-_JZt4MJAhaAo5Kz3drfO0=.fc89a589-b729-4a31-82c5-7e54b820aa6c@github.com>

On Wed, 21 Jul 2021 20:05:56 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to add a test for various scenarios involving withfield.  The test was run locally on Linux x64 and using Mach5 tiers 1-2.
> 
> Note that the test temporarily is run with -Xint because it fails when run with -Xcomp.  -Xint will be removed once it passes with -Xcomp.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 02584ab0
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/02584ab0cc6bfbaf3cb0ce2f7331e4836996891f
Stats:     1244 lines in 2 files changed: 1244 ins; 0 del; 0 mod

8269756: [lworld] Add tests for invalid withfield operands

Reviewed-by: fparain

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

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


From hseigel at openjdk.java.net  Thu Jul 22 14:36:05 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 22 Jul 2021 14:36:05 GMT
Subject: [lworld] RFR: 8269756: [lworld] Add tests for invalid withfield
 operands
In-Reply-To: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>
References: <SRDUY9VPoyEV12RgfydF-7qJYAhjRWn1twX74Pks10Q=.8ba97181-1ebc-4f92-b805-1c6a9b3ae789@github.com>
Message-ID: <9bjUAN5T7_OHPDwc-1QHqJmToiVL0pkMuRr0HIaDYxI=.54fe06b0-528f-435a-9cd3-e72258571a4b@github.com>

On Wed, 21 Jul 2021 20:05:56 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to add a test for various scenarios involving withfield.  The test was run locally on Linux x64 and using Mach5 tiers 1-2.
> 
> Note that the test temporarily is run with -Xint because it fails when run with -Xcomp.  -Xint will be removed once it passes with -Xcomp.
> 
> Thanks, Harold

Thanks Fred for reviewing this!

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

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


From fparain at openjdk.java.net  Thu Jul 22 19:40:36 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 22 Jul 2021 19:40:36 GMT
Subject: [lworld] RFR: 8271017: [lworld] Implement withfield changes from
 JDK-8269408 on AArch64
In-Reply-To: <gSAs1oiw-SoxMqxNxtzjJ7cK1jB83k4feuye9I0Or-A=.9f150989-5df9-4f70-b816-5ffc9de3a709@github.com>
References: <gSAs1oiw-SoxMqxNxtzjJ7cK1jB83k4feuye9I0Or-A=.9f150989-5df9-4f70-b816-5ffc9de3a709@github.com>
Message-ID: <B_Te75iw-u3PcJHiG2fqcZVscc5QbtxJYRc5mK2N8Tk=.e2c71ec6-8226-48d6-83e7-835ef895ca57@github.com>

On Thu, 22 Jul 2021 06:06:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This just applies the changes in JDK-8269408 to the AArch64 port.
> 
> The old `InterpreterRuntime::withfield()` is removed as it has no more users, and I've renamed withfield2 to withfield (presumably this was the original intention?).

Changes look good to me.
Thank you for the cleanup in interpreterRuntime.cpp.

Fred

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

Marked as reviewed by fparain (Committer).

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


From fparain at openjdk.java.net  Thu Jul 22 21:19:31 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 22 Jul 2021 21:19:31 GMT
Subject: [lworld] RFR: 8271154: [lworld] CDS LoaderConstraintsTest fails after
 injection of IdentityObject
Message-ID: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>

Please review this small change in CDS LoaderConstraints test. The fix simply adds the missing IdentityObject interface to the test classlist.

Tested on all platforms with Mach5 (tiers1-3).

Thank you,

Fred

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

Commit messages:
 - Add missing IdentityObject interface to test classlist

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

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


From sadayapalam at openjdk.java.net  Fri Jul 23 01:27:12 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 23 Jul 2021 01:27:12 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes. [v3]
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <tHHKqaSNYCrqYLRicrxGzaAs6RNtcRK1TPXRmjqmQNg=.1a1b69c6-298a-47db-b78d-331366e2b1fe@github.com>

> Code changes and tests

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

 - Merge branch 'lworld' into JDK-8244231
 - Merge branch 'lworld' into JDK-8244231
 - Fix confusingi/unhelpful javadoc per review comments
 - Adjust tests post JDK-8237073
 - Merge branch 'lworld' into JDK-8244231
 - Fix white space problems
 - Fix white space problems
 - Modify several existing tests to verify behavior with reference default classes
 - 8244231: Add support for ref-default and val-default inline classes.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/482/files
  - new: https://git.openjdk.java.net/valhalla/pull/482/files/f1100617..43171c03

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

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

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


From sadayapalam at openjdk.java.net  Fri Jul 23 02:09:30 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 23 Jul 2021 02:09:30 GMT
Subject: [lworld] Integrated: 8244231: [lworld] Add support for ref-default
 and val-default inline classes.
In-Reply-To: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
Message-ID: <KxUW_PbBimrRi-Rzr2Rx1dn18EWQ3gafYf1sdTi8xEE=.0b16ac84-ac28-4575-9271-f88636a73a48@github.com>

On Fri, 16 Jul 2021 08:05:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Code changes and tests

This pull request has now been integrated.

Changeset: a4066d7a
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a4066d7a21377c03c04565fe23981d650f777a7b
Stats:     3538 lines in 112 files changed: 3358 ins; 70 del; 110 mod

8244231: [lworld] Add support for ref-default and val-default inline classes.

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

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


From sadayapalam at openjdk.java.net  Fri Jul 23 02:09:28 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 23 Jul 2021 02:09:28 GMT
Subject: [lworld] RFR: 8244231: [lworld] Add support for ref-default and
 val-default inline classes. [v3]
In-Reply-To: <tHHKqaSNYCrqYLRicrxGzaAs6RNtcRK1TPXRmjqmQNg=.1a1b69c6-298a-47db-b78d-331366e2b1fe@github.com>
References: <xZbBJi9Rd9nadGkErlGnupGJ-OzaSkjOfUE2wJlg1gM=.06800dcf-d591-41fe-b4a1-8951a57964b5@github.com>
 <tHHKqaSNYCrqYLRicrxGzaAs6RNtcRK1TPXRmjqmQNg=.1a1b69c6-298a-47db-b78d-331366e2b1fe@github.com>
Message-ID: <WhSwVY1maolGd5U1i2l6uohjk0a4YwXHvExKVLOZ4r8=.aaa8298e-5686-43c6-9a30-56996b656367@github.com>

On Fri, 23 Jul 2021 01:27:12 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Code changes and tests
>
> Srikanth Adayapalam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8244231
>  - Merge branch 'lworld' into JDK-8244231
>  - Fix confusingi/unhelpful javadoc per review comments
>  - Adjust tests post JDK-8237073
>  - Merge branch 'lworld' into JDK-8244231
>  - Fix white space problems
>  - Fix white space problems
>  - Modify several existing tests to verify behavior with reference default classes
>  - 8244231: Add support for ref-default and val-default inline classes.

Thanks Maurizio!

The confusing and unhelpful javadoc issues have been fixed.

In JDK-8268734 ("Various internal Type/Symbol APIs need rationalization/adjustment") I will follow up with a comprehensive review of all the Type and Symbol APIs - these APIs were rolled up as and when needed at widely different points in time 
and it is an useful exercise to take a step back and review them in a holistic fashion.

In JDK-8270882 (" Loose ends in reference default primitive class implementation.") I will follow up on the various known
issues that have been deliberately deferred to a later pass so as to make it more easily manageable,

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

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


From ngasson at openjdk.java.net  Fri Jul 23 06:47:28 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 23 Jul 2021 06:47:28 GMT
Subject: [lworld] RFR: 8271017: [lworld] Implement withfield changes from
 JDK-8269408 on AArch64
In-Reply-To: <B_Te75iw-u3PcJHiG2fqcZVscc5QbtxJYRc5mK2N8Tk=.e2c71ec6-8226-48d6-83e7-835ef895ca57@github.com>
References: <gSAs1oiw-SoxMqxNxtzjJ7cK1jB83k4feuye9I0Or-A=.9f150989-5df9-4f70-b816-5ffc9de3a709@github.com>
 <B_Te75iw-u3PcJHiG2fqcZVscc5QbtxJYRc5mK2N8Tk=.e2c71ec6-8226-48d6-83e7-835ef895ca57@github.com>
Message-ID: <4ks0Ll8kw21Puq14x3rNr8PKSooRX5Xv7GLj2qa6bWE=.50b411b6-160b-4b8b-b806-109675efee9b@github.com>

On Thu, 22 Jul 2021 19:37:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This just applies the changes in JDK-8269408 to the AArch64 port.
>> 
>> The old `InterpreterRuntime::withfield()` is removed as it has no more users, and I've renamed withfield2 to withfield (presumably this was the original intention?).
>
> Changes look good to me.
> Thank you for the cleanup in interpreterRuntime.cpp.
> 
> Fred

Thanks @fparain!

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

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


From jesper at selskabet.org  Fri Jul 23 10:47:24 2021
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Fri, 23 Jul 2021 12:47:24 +0200
Subject: [lworld] What is the default of a Primitive.ref variable?
Message-ID: <F561D6BA-F6E2-44C8-A590-2AF369268975@selskabet.org>

Hi list

While making a test case for bug 8210906 (making SomeClass.default a poly-expression if SomeClass is parameterized), I came across the use of .default on a reference, as in

primitive class Prim {
    int i = 42;

    public static void main(String [] args) {
        Prim.ref p = Prim.ref.default; // Does this make sense at all?
        System.out.println(p.i); // Should this NPE or print 0?
    }
}

Prim.ref is the reference projection of Prim, and is nullable, and is reference type. The default of a reference is null.
But what is Prim.ref.default? Is it even a thing? Should it be disallowed?

-Jesper

From jespersm at openjdk.java.net  Fri Jul 23 11:03:03 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Fri, 23 Jul 2021 11:03:03 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v3]
In-Reply-To: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
Message-ID: <DqF4-KRdyZF1XB_KSpkvDXoaTPx55prFpkedOEr0vqU=.a59d81bc-7461-4c5d-a14b-f22e0f5f1dba@github.com>

> Make .default a separate node type in the parser.
> 
> ## Issue
> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
> 
> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Handle default values as polytype method arguments.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/369/files
  - new: https://git.openjdk.java.net/valhalla/pull/369/files/e9289cfa..0c088269

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

  Stats: 108 lines in 5 files changed: 95 ins; 10 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/369.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/369/head:pull/369

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


From srikanth.adayapalam at oracle.com  Fri Jul 23 11:47:48 2021
From: srikanth.adayapalam at oracle.com (Srikanth Adayapalam)
Date: Fri, 23 Jul 2021 11:47:48 +0000
Subject: [lworld] What is the default of a Primitive.ref variable?
In-Reply-To: <F561D6BA-F6E2-44C8-A590-2AF369268975@selskabet.org>
References: <F561D6BA-F6E2-44C8-A590-2AF369268975@selskabet.org>
Message-ID: <MN2PR10MB3552BF3983EDE0BE051F4B6990E59@MN2PR10MB3552.namprd10.prod.outlook.com>

You could have asked the compiler ? ?

Prim.ref.default would have the same value and type that an uninitialized field of type Prim.ref would have by default.
Alternately if you do new Prim.ref[10]  the cells of the newly constructed array would have same value and type as
that of Prim.ref.default - so null.

As a result, the program you cite, should fail with NPE and it does on branch tip.

Srikanth
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.java.net> on behalf of Jesper Steen M?ller <jesper at selskabet.org>
Sent: 23 July 2021 16:17
To: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: [lworld] What is the default of a Primitive.ref variable?

Hi list

While making a test case for bug 8210906 (making SomeClass.default a poly-expression if SomeClass is parameterized), I came across the use of .default on a reference, as in

primitive class Prim {
    int i = 42;

    public static void main(String [] args) {
        Prim.ref p = Prim.ref.default; // Does this make sense at all?
        System.out.println(p.i); // Should this NPE or print 0?
    }
}

Prim.ref is the reference projection of Prim, and is nullable, and is reference type. The default of a reference is null.
But what is Prim.ref.default? Is it even a thing? Should it be disallowed?

-Jesper

From jesper at selskabet.org  Fri Jul 23 13:07:53 2021
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Fri, 23 Jul 2021 15:07:53 +0200
Subject: [lworld] What is the default of a Primitive.ref variable?
In-Reply-To: <MN2PR10MB3552BF3983EDE0BE051F4B6990E59@MN2PR10MB3552.namprd10.prod.outlook.com>
References: <F561D6BA-F6E2-44C8-A590-2AF369268975@selskabet.org>
 <MN2PR10MB3552BF3983EDE0BE051F4B6990E59@MN2PR10MB3552.namprd10.prod.outlook.com>
Message-ID: <734F415D-DB66-4B52-9863-744686315503@selskabet.org>


Thanks, Srikanth - but...

... I *did* ask the compiler, but in the context of parameterized types...

public primitive class RefDefault<T> {
    public int i = 1;

    public static void main(String [] args) {
    	RefDefault<String>.ref l = RefDefault.ref.default;
    	System.out.println(l.i);
    }
}

This gave me a syntax error at the dot in for "RefDefault<String>.ref". 

 error: improperly formed type, some parameters are missing
    	RefDefault<String>.ref l = RefDefault.ref.default;
    	                  ^

The compiler will accept RefDefault.ref<String> but that looks off to me. It that the correct form of a reference projection of RefDefault<String>? Or should I fix that in the parser?

It turns out that eliding the type from RefDefault.ref.default (as in RefDefault.ref<String> l = RefDefault.ref.default)ill give a reference to a default value. I'll fix that in bug 8210906.

-Jesper

> On 23 Jul 2021, at 13.47, Srikanth Adayapalam <srikanth.adayapalam at oracle.com> wrote:
> 
> You could have asked the compiler ? ?
> 
> Prim.ref.default would have the same value and type that an uninitialized field of type Prim.ref would have by default.
> Alternately if you do new Prim.ref[10]  the cells of the newly constructed array would have same value and type as
> that of Prim.ref.default - so null.
> 
> As a result, the program you cite, should fail with NPE and it does on branch tip.
> 
> Srikanth  
> From: valhalla-dev <valhalla-dev-retn at openjdk.java.net> on behalf of Jesper Steen M?ller <jesper at selskabet.org>
> Sent: 23 July 2021 16:17
> To: valhalla-dev <valhalla-dev at openjdk.java.net>
> Subject: [lworld] What is the default of a Primitive.ref variable?
>  
> Hi list
> 
> While making a test case for bug 8210906 (making SomeClass.default a poly-expression if SomeClass is parameterized), I came across the use of .default on a reference, as in
> 
> primitive class Prim {
>     int i = 42;
> 
>     public static void main(String [] args) {
>         Prim.ref p = Prim.ref.default; // Does this make sense at all?
>         System.out.println(p.i); // Should this NPE or print 0?
>     }
> }
> 
> Prim.ref is the reference projection of Prim, and is nullable, and is reference type. The default of a reference is null.
> But what is Prim.ref.default? Is it even a thing? Should it be disallowed?
> 
> -Jesper



From fparain at openjdk.java.net  Fri Jul 23 13:26:06 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 23 Jul 2021 13:26:06 GMT
Subject: git: openjdk/valhalla: lworld: 8271154: [lworld] CDS
 LoaderConstraintsTest fails after injection of IdentityObject
Message-ID: <65374ff1-ca84-45c0-a7d2-1c44398bdac3@openjdk.org>

Changeset: 8c112906
Author:    Frederic Parain <fparain at openjdk.org>
Date:      2021-07-23 13:25:40 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/8c1129061ccca182eda866e87c5a5693d6c3d622

8271154: [lworld] CDS LoaderConstraintsTest fails after injection of IdentityObject

Reviewed-by: hseigel

! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java



From hseigel at openjdk.java.net  Fri Jul 23 13:28:17 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 23 Jul 2021 13:28:17 GMT
Subject: [lworld] RFR: 8271154: [lworld] CDS LoaderConstraintsTest fails
 after injection of IdentityObject
In-Reply-To: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>
References: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>
Message-ID: <ssA0j_dKdnsJNhfxt056cU2wNFhn0m0PmYmWtKhhGNw=.3e0f5146-4da1-499c-8f76-00a8b669d8a3@github.com>

On Thu, 22 Jul 2021 21:13:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small change in CDS LoaderConstraints test. The fix simply adds the missing IdentityObject interface to the test classlist.
> 
> Tested on all platforms with Mach5 (tiers1-3).
> 
> Thank you,
> 
> Fred

LGTM
Harold

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

Marked as reviewed by hseigel (Committer).

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


From fparain at openjdk.java.net  Fri Jul 23 13:28:17 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 23 Jul 2021 13:28:17 GMT
Subject: [lworld] RFR: 8271154: [lworld] CDS LoaderConstraintsTest fails
 after injection of IdentityObject
In-Reply-To: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>
References: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>
Message-ID: <Sr-LKhcdIVl_sc9uqom0KV67e7ZtEkzU7raGSxR3yCk=.e362bfd9-d4e9-4d1f-8476-38362435f5da@github.com>

On Thu, 22 Jul 2021 21:13:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small change in CDS LoaderConstraints test. The fix simply adds the missing IdentityObject interface to the test classlist.
> 
> Tested on all platforms with Mach5 (tiers1-3).
> 
> Thank you,
> 
> Fred

Thanks Harold.

Fred

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

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


From fparain at openjdk.java.net  Fri Jul 23 13:28:17 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 23 Jul 2021 13:28:17 GMT
Subject: [lworld] Integrated: 8271154: [lworld] CDS LoaderConstraintsTest
 fails after injection of IdentityObject
In-Reply-To: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>
References: <WLRQ0f2Nt64_tk6YHanR1CBkkK7WsVHuabWZGlbRbIo=.2c1d3f97-4079-4e8e-8417-07b575faf1fb@github.com>
Message-ID: <ChWj77or7d5YJrpgvCqecEgupVpX84fnBISuZocuqNA=.f01d083e-58a6-4dfa-b463-8951e3473158@github.com>

On Thu, 22 Jul 2021 21:13:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small change in CDS LoaderConstraints test. The fix simply adds the missing IdentityObject interface to the test classlist.
> 
> Tested on all platforms with Mach5 (tiers1-3).
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

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

8271154: [lworld] CDS LoaderConstraintsTest fails after injection of IdentityObject

Reviewed-by: hseigel

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

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


From ngasson at openjdk.java.net  Fri Jul 23 13:54:16 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 23 Jul 2021 13:54:16 GMT
Subject: [lworld] Integrated: 8271017: [lworld] Implement withfield changes
 from JDK-8269408 on AArch64
In-Reply-To: <gSAs1oiw-SoxMqxNxtzjJ7cK1jB83k4feuye9I0Or-A=.9f150989-5df9-4f70-b816-5ffc9de3a709@github.com>
References: <gSAs1oiw-SoxMqxNxtzjJ7cK1jB83k4feuye9I0Or-A=.9f150989-5df9-4f70-b816-5ffc9de3a709@github.com>
Message-ID: <ZC8ztNzCrmcit88RdXkfkw-7V-eKkMHM25A_NtxNkuQ=.37838419-fa45-4647-80ad-8b8521645174@github.com>

On Thu, 22 Jul 2021 06:06:15 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> This just applies the changes in JDK-8269408 to the AArch64 port.
> 
> The old `InterpreterRuntime::withfield()` is removed as it has no more users, and I've renamed withfield2 to withfield (presumably this was the original intention?).

This pull request has now been integrated.

Changeset: ad0491ed
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ad0491ed1c544c2c9485ad40abbbebc6408e8ccf
Stats:     116 lines in 4 files changed: 5 ins; 105 del; 6 mod

8271017: [lworld] Implement withfield changes from JDK-8269408 on AArch64

Reviewed-by: fparain

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

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


From srikanth.adayapalam at oracle.com  Fri Jul 23 14:27:08 2021
From: srikanth.adayapalam at oracle.com (Srikanth Adayapalam)
Date: Fri, 23 Jul 2021 14:27:08 +0000
Subject: [External] : Re: [lworld] What is the default of a Primitive.ref
 variable?
In-Reply-To: <734F415D-DB66-4B52-9863-744686315503@selskabet.org>
References: <F561D6BA-F6E2-44C8-A590-2AF369268975@selskabet.org>
 <MN2PR10MB3552BF3983EDE0BE051F4B6990E59@MN2PR10MB3552.namprd10.prod.outlook.com>,
 <734F415D-DB66-4B52-9863-744686315503@selskabet.org>
Message-ID: <MN2PR10MB3552630203350100291A710E90E59@MN2PR10MB3552.namprd10.prod.outlook.com>

Hi Jesper,

The syntax of parameterized primitive types came up earlier for discussion and for good or bad, RefDefault.ref<String>  is the currently blessed syntax and not RefDefault<String>.ref

So, this is a conscious choice that stands for the moment.

There was a push earlier in the day that issues a slightly better diagnostic that what you quote:

"improperly formed type, some parameters are missing or misplaced"

Srikanth

________________________________
From: Jesper Steen M?ller <jesper at selskabet.org>
Sent: 23 July 2021 18:37
To: Srikanth Adayapalam <srikanth.adayapalam at oracle.com>
Cc: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: [External] : Re: [lworld] What is the default of a Primitive.ref variable?


Thanks, Srikanth - but...

... I *did* ask the compiler, but in the context of parameterized types...

public primitive class RefDefault<T> {
    public int i = 1;

    public static void main(String [] args) {
     RefDefault<String>.ref l = RefDefault.ref.default;
     System.out.println(l.i);
    }
}

This gave me a syntax error at the dot in for "RefDefault<String>.ref".

 error: improperly formed type, some parameters are missing
     RefDefault<String>.ref l = RefDefault.ref.default;
                       ^

The compiler will accept RefDefault.ref<String> but that looks off to me. It that the correct form of a reference projection of RefDefault<String>? Or should I fix that in the parser?

It turns out that eliding the type from RefDefault.ref.default (as in RefDefault.ref<String> l = RefDefault.ref.default)ill give a reference to a default value. I'll fix that in bug 8210906.

-Jesper

On 23 Jul 2021, at 13.47, Srikanth Adayapalam <srikanth.adayapalam at oracle.com<mailto:srikanth.adayapalam at oracle.com>> wrote:

You could have asked the compiler ? ?

Prim.ref.default would have the same value and type that an uninitialized field of type Prim.ref would have by default.
Alternately if you do new Prim.ref[10]  the cells of the newly constructed array would have same value and type as
that of Prim.ref.default - so null.

As a result, the program you cite, should fail with NPE and it does on branch tip.

Srikanth
From: valhalla-dev <valhalla-dev-retn at openjdk.java.net<mailto:valhalla-dev-retn at openjdk.java.net>> on behalf of Jesper Steen M?ller <jesper at selskabet.org<mailto:jesper at selskabet.org>>
Sent: 23 July 2021 16:17
To: valhalla-dev <valhalla-dev at openjdk.java.net<mailto:valhalla-dev at openjdk.java.net>>
Subject: [lworld] What is the default of a Primitive.ref variable?

Hi list

While making a test case for bug 8210906 (making SomeClass.default a poly-expression if SomeClass is parameterized), I came across the use of .default on a reference, as in

primitive class Prim {
    int i = 42;

    public static void main(String [] args) {
        Prim.ref p = Prim.ref.default; // Does this make sense at all?
        System.out.println(p.i); // Should this NPE or print 0?
    }
}

Prim.ref is the reference projection of Prim, and is nullable, and is reference type. The default of a reference is null.
But what is Prim.ref.default? Is it even a thing? Should it be disallowed?

-Jesper


From jespersm at openjdk.java.net  Sun Jul 25 20:04:40 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 25 Jul 2021 20:04:40 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v4]
In-Reply-To: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
Message-ID: <fHcl0TRWWcEpCmkGkIXMGh76zmBTNko-Ftqujf3GxMU=.c30bf530-d536-48ce-9335-5f652f2b7480@github.com>

> Make .default a separate node type in the parser.
> 
> ## Issue
> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
> 
> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.

Jesper Steen M?ller has updated the pull request incrementally with two additional commits since the last revision:

 - Whitespace fixes
 - Properly propagate reference projections for defaults, and add tests.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/369/files
  - new: https://git.openjdk.java.net/valhalla/pull/369/files/0c088269..131b9c7d

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

  Stats: 19 lines in 3 files changed: 11 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/369.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/369/head:pull/369

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


From jespersm at openjdk.java.net  Sun Jul 25 21:14:57 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 25 Jul 2021 21:14:57 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v5]
In-Reply-To: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
Message-ID: <SYVvRkyYyCq3EPUEeaxqf6dxkNxJimUzARsHfP5nrnI=.0d91a7ad-716c-4d82-9d03-e6615081ab62@github.com>

> Make .default a separate node type in the parser.
> 
> ## Issue
> [JDK-8211914](https://bugs.openjdk.java.net/browse/JDK-8211914): [lworld] Javac should support type inference for default value creation
> 
> Note: The Linux x86 builds in GitHub actions seem to fail with something completely unrelated to these changes.

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  Whitespace

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/369/files
  - new: https://git.openjdk.java.net/valhalla/pull/369/files/131b9c7d..f4073c40

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

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

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


From jespersm at openjdk.java.net  Sun Jul 25 21:55:31 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Sun, 25 Jul 2021 21:55:31 GMT
Subject: [lworld] RFR: Make "PrimitiveParameterizedClass.default" a poly
 expression. [v2]
In-Reply-To: <i_JRRP_KiaqZI3u6ZkVv0GmXq-Jo5Oa8W9uz6IuD0PY=.520ef0c4-29ec-48de-aa0c-c8de804b6f5a@github.com>
References: <mNXeKhGuIwvxIptnNx816ZzDOONr8r7PmDPMrKIJ9yM=.3c0a0add-0c79-4939-922a-e1752511d02d@github.com>
 <kUV6iIgHk2OzUHG97RHLnzcYtUyMHM3yhZaYK4UL-lY=.e77c30f2-0e48-401c-9906-3c95928f565a@github.com>
 <i_JRRP_KiaqZI3u6ZkVv0GmXq-Jo5Oa8W9uz6IuD0PY=.520ef0c4-29ec-48de-aa0c-c8de804b6f5a@github.com>
Message-ID: <79DiyyLSXABYAt41MnAyfJVd5Pkj723HdMLqhSc73W0=.15cb4e26-5473-4158-8578-e4bd5f5b4945@github.com>

On Mon, 19 Jul 2021 08:26:24 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   [lworld] Handling poly-inference of missing arguments by simulating a synthetic method.
>
> A way to see this in more detail is to debug through the Attr.visitApply call corresponding to the method invocation
> 
> 
> m(new X<>(), X.default);
> 
> 
> in this test case:
> 
> 
> public primitive class X<T> {
> 
>     
>     static void m(X<String> ls, X<String> ls2) { }
> 
>     public static void main(String [] args) {
>         m(new X<>(), X.default);
>     }
> 
> }
> 
> 
> 
> You will see that first argument is typed to be DeferredType and second one incorrectly to be X<T\>

Hey @sadayapalam and @mcimadamore, I think this patch is ready for review again.

I've not merged lworld (to keep a clearer history), but it still applies cleanly to the current lworld tip, so it should merge OK.

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

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


From ngasson at openjdk.java.net  Mon Jul 26 07:13:18 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 26 Jul 2021 07:13:18 GMT
Subject: [lworld] Integrated: 8270357: [lworld] some jtreg tests disabled on
 AArch64
In-Reply-To: <_cb5hG9UlldpAJBDZybAFCedAeb3krzVGu-TKU-2DUk=.6900f7dd-b334-4126-b9a2-166a7505010d@github.com>
References: <_cb5hG9UlldpAJBDZybAFCedAeb3krzVGu-TKU-2DUk=.6900f7dd-b334-4126-b9a2-166a7505010d@github.com>
Message-ID: <bVIMrRAWeCdMEVllGmzYq-fyYDSp9EGoIUQ8QXOfxg4=.69d9aa3e-e84a-45a5-9c11-38ac5c7b8eb0@github.com>

On Wed, 14 Jul 2021 06:32:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Several tests under runtime/valhalla and compiler/valhalla have `@requires os.simpleArch == "x64"`. They should be enabled on AArch64 too.
> 
> A couple of these tests, as well as three of the existing ones, fail on AArch64 with some variant of:
> 
> 
> java.lang.RuntimeException: Graph for 'TestBasicFunctionality::test3' contains different number of match nodes (expected 1 but got 0):
> 
> 
> The regex pattern these tests are looking for is specific to the x86 opto assembly output. They regex needs to be adjusted for the AArch64 format. I'll do that after #457 is merged which also touches the same files.

This pull request has now been integrated.

Changeset: 46b88b58
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/46b88b580baa1dbc25f0477c2f851145f55718a7
Stats:     8 lines in 7 files changed: 0 ins; 0 del; 8 mod

8270357: [lworld] some jtreg tests disabled on AArch64

Reviewed-by: thartmann

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

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


From thartmann at openjdk.java.net  Mon Jul 26 12:03:52 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Jul 2021 12:03:52 GMT
Subject: [lworld] RFR: 8270995: [lworld] G1BarrierSetC2::step_over_gc_barrier
 asserts with "bad barrier shape"
Message-ID: <E94IyUu7xob4YIvGiFTGgV3i2DL4xWM_kGDqanoZjfU=.fa5667d0-4061-4f26-ac4b-66eb60e823f7@github.com>

The `G1BarrierSetC2::step_over_gc_barrier` code gets confused by a `MemBarCPUOrder`, assuming it belongs to a GC barrier. However, it comes from a `MemBarStoreStore` added by `InlineTypeBaseNode::buffer` that is then transformed to a `MemBarCPUOrder` by Escape Analysis because the allocation is non-escaping (`ConnectionGraph::optimize_ideal_graph`). I don't think we need a `MemBarCPUOrder` for inline type buffer allocations, EA should simply remove it.

I've filed [JDK-8271280](https://bugs.openjdk.java.net/browse/JDK-8271280) to re-visit the barrier code.

Best regards,
Tobias

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

Commit messages:
 - 8270995: [lworld] G1BarrierSetC2::step_over_gc_barrier asserts with "bad barrier shape"

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

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


From thartmann at openjdk.java.net  Mon Jul 26 12:08:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Jul 2021 12:08:56 GMT
Subject: [lworld] Integrated: [lworld] Remove AOT tests from problem list
Message-ID: <QjPHn4K4AY8-H0iQ_AZz-en1YKoDlNu-ZksVX_8cF0M=.1f999c2d-a8af-4ec9-a49b-8ca4eb4b8571@github.com>

AOT and the corresponding tests have been removed by [JDK-8263327](https://bugs.openjdk.java.net/browse/JDK-8263327).

Best regards,
Tobias

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

Commit messages:
 - [lworld] Remove AOT tests from problem list

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

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


From thartmann at openjdk.java.net  Mon Jul 26 12:08:57 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Jul 2021 12:08:57 GMT
Subject: [lworld] Integrated: [lworld] Remove AOT tests from problem list
In-Reply-To: <QjPHn4K4AY8-H0iQ_AZz-en1YKoDlNu-ZksVX_8cF0M=.1f999c2d-a8af-4ec9-a49b-8ca4eb4b8571@github.com>
References: <QjPHn4K4AY8-H0iQ_AZz-en1YKoDlNu-ZksVX_8cF0M=.1f999c2d-a8af-4ec9-a49b-8ca4eb4b8571@github.com>
Message-ID: <io_VK2UhyqUASl0uRboogQdOFo-ebV9yNjq7HYzMMSY=.4114502d-619b-45b5-9bc3-690a1d8cfa28@github.com>

On Mon, 26 Jul 2021 12:01:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> AOT and the corresponding tests have been removed by [JDK-8263327](https://bugs.openjdk.java.net/browse/JDK-8263327).
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 7d215b66
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7d215b664e40bbf2afcf629eb277bc1d71672acb
Stats:     69 lines in 1 file changed: 0 ins; 69 del; 0 mod

[lworld] Remove AOT tests from problem list

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

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


From thartmann at openjdk.java.net  Mon Jul 26 15:30:41 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Jul 2021 15:30:41 GMT
Subject: [lworld] RFR: 8271282: [lworld] C2 compilation fails with "bad AD
 file"
Message-ID: <FzJyNTkTwGV0sg_Z8mlBbNy3G7iZJd35CjWsKEQxB48=.d0812038-abc1-4dd0-91fc-6acc2f419b31@github.com>

This is a variant of mainline issue [JDK-8269775](https://bugs.openjdk.java.net/browse/JDK-8269775). It only showed up now because it requires AVX-512 VLBW capable machines. This PR is cherry-picking the fixes for [JDK-8269580](https://bugs.openjdk.java.net/browse/JDK-8269580) and [JDK-8269775](https://bugs.openjdk.java.net/browse/JDK-8269775) and adjusts them to Valhalla specific changes.

Best regards,
Tobias

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

Commit messages:
 - 8271282: [lworld] C2 compilation fails with "bad AD file"

Changes: https://git.openjdk.java.net/valhalla/pull/497/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=497&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271282
  Stats: 31 lines in 2 files changed: 5 ins; 12 del; 14 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/497.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/497/head:pull/497

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


From thartmann at openjdk.java.net  Mon Jul 26 19:10:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 26 Jul 2021 19:10:56 GMT
Subject: [lworld] Integrated: 8271282: [lworld] C2 compilation fails with "bad
 AD file"
In-Reply-To: <FzJyNTkTwGV0sg_Z8mlBbNy3G7iZJd35CjWsKEQxB48=.d0812038-abc1-4dd0-91fc-6acc2f419b31@github.com>
References: <FzJyNTkTwGV0sg_Z8mlBbNy3G7iZJd35CjWsKEQxB48=.d0812038-abc1-4dd0-91fc-6acc2f419b31@github.com>
Message-ID: <MOgmmkrfTKWm1f2jlV6HoMnc5i7ocjNoTknmcWjuaNQ=.5ceaf523-bdad-49ee-81ea-228279501016@github.com>

On Mon, 26 Jul 2021 15:24:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is a variant of mainline issue [JDK-8269775](https://bugs.openjdk.java.net/browse/JDK-8269775). It only showed up now because it requires AVX-512 VLBW capable machines. This PR is cherry-picking the fixes for [JDK-8269580](https://bugs.openjdk.java.net/browse/JDK-8269580) and [JDK-8269775](https://bugs.openjdk.java.net/browse/JDK-8269775) and adjusts them to Valhalla specific changes.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: ae5fc42b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ae5fc42bd10549a582d9850fd5e306754a298db0
Stats:     31 lines in 2 files changed: 5 ins; 12 del; 14 mod

8271282: [lworld] C2 compilation fails with "bad AD file"

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

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


From fparain at openjdk.java.net  Tue Jul 27 00:23:17 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 27 Jul 2021 00:23:17 GMT
Subject: [lworld] RFR: 8271229: [lworld] Test
 serviceability/sa/ClhsdbDumpclass.java fails with unexpected end of file
Message-ID: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>

Please review those changes fixing the HotSpot agent to correctly dump classes even in presence of injected interfaces.
Fix failures of serviceability/sa/ClhsdbDumpclass.java on all platforms (tested with Mach5, tiers 1 to 3).

Thank you,

Fred

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

Commit messages:
 - Fix injected interfaces in class writer

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

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


From amenkov at openjdk.java.net  Tue Jul 27 01:28:14 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 27 Jul 2021 01:28:14 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event: new_value is
 invalid for Q objects
Message-ID: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>

The fix adds handling of Q-type fields the same way as L-type

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

Commit messages:
 - Fixed tabs
 - Removed trailing spaces
 - Fixed FieldModification event for Q-type fields

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

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


From thartmann at openjdk.java.net  Tue Jul 27 06:42:28 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 06:42:28 GMT
Subject: [lworld] RFR: 8270995: [lworld]
 G1BarrierSetC2::step_over_gc_barrier asserts with "bad barrier shape" [v2]
In-Reply-To: <E94IyUu7xob4YIvGiFTGgV3i2DL4xWM_kGDqanoZjfU=.fa5667d0-4061-4f26-ac4b-66eb60e823f7@github.com>
References: <E94IyUu7xob4YIvGiFTGgV3i2DL4xWM_kGDqanoZjfU=.fa5667d0-4061-4f26-ac4b-66eb60e823f7@github.com>
Message-ID: <x4bf5cPT8x0uDpKLOZopYZLyAYlW7usQG-7CHDCYFFY=.b921888d-c79c-486c-a013-ab9752f62299@github.com>

> The `G1BarrierSetC2::step_over_gc_barrier` code gets confused by a `MemBarCPUOrder`, assuming it belongs to a GC barrier. However, it comes from a `MemBarStoreStore` added by `InlineTypeBaseNode::buffer` that is then transformed to a `MemBarCPUOrder` by Escape Analysis because the allocation is non-escaping (`ConnectionGraph::optimize_ideal_graph`). I don't think we need a `MemBarCPUOrder` for inline type buffer allocations, EA should simply remove it.
> 
> I've filed [JDK-8271280](https://bugs.openjdk.java.net/browse/JDK-8271280) to re-visit the barrier code.
> 
> Best regards,
> Tobias

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

 - Merge branch 'lworld' into JDK-8270995
 - 8270995: [lworld] G1BarrierSetC2::step_over_gc_barrier asserts with "bad barrier shape"

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/495/files
  - new: https://git.openjdk.java.net/valhalla/pull/495/files/c8c1feda..676b45a1

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

  Stats: 100 lines in 3 files changed: 5 ins; 81 del; 14 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/495.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/495/head:pull/495

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


From thartmann at openjdk.java.net  Tue Jul 27 08:06:08 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 08:06:08 GMT
Subject: [lworld] Integrated: 8270995: [lworld]
 G1BarrierSetC2::step_over_gc_barrier asserts with "bad barrier shape"
In-Reply-To: <E94IyUu7xob4YIvGiFTGgV3i2DL4xWM_kGDqanoZjfU=.fa5667d0-4061-4f26-ac4b-66eb60e823f7@github.com>
References: <E94IyUu7xob4YIvGiFTGgV3i2DL4xWM_kGDqanoZjfU=.fa5667d0-4061-4f26-ac4b-66eb60e823f7@github.com>
Message-ID: <HFJbzFwW43w3Ea8eyKzCpiVPPoS0u_WmhzVLL6DbENk=.78a319e2-14ef-4ba1-80c0-e90eeaac5de1@github.com>

On Mon, 26 Jul 2021 11:56:47 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The `G1BarrierSetC2::step_over_gc_barrier` code gets confused by a `MemBarCPUOrder`, assuming it belongs to a GC barrier. However, it comes from a `MemBarStoreStore` added by `InlineTypeBaseNode::buffer` that is then transformed to a `MemBarCPUOrder` by Escape Analysis because the allocation is non-escaping (`ConnectionGraph::optimize_ideal_graph`). I don't think we need a `MemBarCPUOrder` for inline type buffer allocations, EA should simply remove it.
> 
> I've filed [JDK-8271280](https://bugs.openjdk.java.net/browse/JDK-8271280) to re-visit the barrier code.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 61602384
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/616023843b10876dcd3b0e3dd49534b6e48b274f
Stats:     106 lines in 3 files changed: 95 ins; 5 del; 6 mod

8270995: [lworld] G1BarrierSetC2::step_over_gc_barrier asserts with "bad barrier shape"

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

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


From thartmann at openjdk.java.net  Tue Jul 27 09:01:00 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 09:01:00 GMT
Subject: [lworld] Integrated: [lworld] Problemlist TestNativeClone until
 8270098 is fixed
Message-ID: <cWeTzx9G96k2HXq4C_mUDGUuL8TSIibW3WEzIiveh3s=.e365a8c7-148f-4042-8451-9befe621bfd6@github.com>

Problem listing the test until mainline bug [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) is fixed.

Best regards,
Tobias

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

Commit messages:
 - [lworld] Problemlist TestNativeClone until 8270098 is fixed

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

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


From thartmann at openjdk.java.net  Tue Jul 27 09:01:00 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 09:01:00 GMT
Subject: [lworld] Integrated: [lworld] Problemlist TestNativeClone until
 8270098 is fixed
In-Reply-To: <cWeTzx9G96k2HXq4C_mUDGUuL8TSIibW3WEzIiveh3s=.e365a8c7-148f-4042-8451-9befe621bfd6@github.com>
References: <cWeTzx9G96k2HXq4C_mUDGUuL8TSIibW3WEzIiveh3s=.e365a8c7-148f-4042-8451-9befe621bfd6@github.com>
Message-ID: <aV-Cf-QyzMTWRFewWKV1aerTLRVpg6bxfJHUgbZbyk8=.c9d14f14-c7a1-48dc-aac6-d3ed53e8d261@github.com>

On Tue, 27 Jul 2021 08:53:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Problem listing the test until mainline bug [JDK-8270098](https://bugs.openjdk.java.net/browse/JDK-8270098) is fixed.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

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

[lworld] Problemlist TestNativeClone until 8270098 is fixed

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

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


From sadayapalam at openjdk.java.net  Tue Jul 27 10:18:20 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 27 Jul 2021 10:18:20 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
Message-ID: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>

Adjust meaning of type name in class literal expressions. Adjust tests accordingly

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

Commit messages:
 - 8269956: [lworld] javac should generate `ldc LPoint;` for class literal Point.class

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

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


From sadayapalam at openjdk.java.net  Tue Jul 27 11:42:48 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 27 Jul 2021 11:42:48 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <8J4Se5CutPomhpo3Q6bgPpz8vRL7bC87iT_-yyA4eEo=.466787f9-7f1b-4d26-8354-3c9863bfbb34@github.com>

On Tue, 27 Jul 2021 10:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

Yes, tier1,2,3 were run to identify failing tests and fixes have been provided. Thanks!

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

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


From dsimms at openjdk.java.net  Tue Jul 27 11:42:48 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 27 Jul 2021 11:42:48 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <LRwcEOzDuxShzxobajwWpfSk29RZ2mNm7rHk4L-1xtk=.66d88835-d662-4326-ae76-6ad535708f59@github.com>

On Tue, 27 Jul 2021 10:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

Runtime tests look okay, assuming they ran ?

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

Marked as reviewed by dsimms (Committer).

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


From thartmann at openjdk.java.net  Tue Jul 27 12:07:40 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 12:07:40 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <TXYZ7RP0q_CBgY47WY8_n4ZAMQ6lmEkjuDqTaK0bpdU=.36def428-79a7-4791-82dc-6038ba8f72b4@github.com>

On Tue, 27 Jul 2021 10:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

JIT compiler test changes look good to me but why are the changes to the classes passed to `addHelperClasses` necessary? The method is used to let the test framework know about classes that have compile command annotations like `@ForceInline`.

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

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


From sadayapalam at openjdk.java.net  Tue Jul 27 12:26:43 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 27 Jul 2021 12:26:43 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <DmW9s9SPffV6DnLzTeN6zy00_TYzEos344TDioYT8bM=.23cc752e-dee8-4ee4-a107-b22c752c3e41@github.com>

On Tue, 27 Jul 2021 10:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

I can restore them. In some case these changes came about because of mechanical search and replace.

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

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


From dsimms at openjdk.java.net  Tue Jul 27 12:29:41 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 27 Jul 2021 12:29:41 GMT
Subject: [lworld] RFR: 8271229: [lworld] Test
 serviceability/sa/ClhsdbDumpclass.java fails with unexpected end of file
In-Reply-To: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>
References: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>
Message-ID: <Ev1kUTy-hH8vdwGymjxQ4iNjTMSxLr1jVFu6EkOt_rc=.bae1cec1-7a04-43a5-93dd-8ea3c47cddc2@github.com>

On Tue, 27 Jul 2021 00:17:16 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing the HotSpot agent to correctly dump classes even in presence of injected interfaces.
> Fix failures of serviceability/sa/ClhsdbDumpclass.java on all platforms (tested with Mach5, tiers 1 to 3).
> 
> Thank you,
> 
> Fred

Looks good

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

Marked as reviewed by dsimms (Committer).

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


From thartmann at openjdk.java.net  Tue Jul 27 12:33:49 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 12:33:49 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <d5Ou-qPIKFbT7hnOHc-iZuXgjavotTWZfGpvP8jGnLQ=.cf83d87e-1c4a-4534-bfb9-f279b3dcc179@github.com>

On Tue, 27 Jul 2021 10:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

Yes, please do so for consistency. Thanks!

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

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


From fparain at openjdk.java.net  Tue Jul 27 12:41:49 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 27 Jul 2021 12:41:49 GMT
Subject: [lworld] RFR: 8271229: [lworld] Test
 serviceability/sa/ClhsdbDumpclass.java fails with unexpected end of file
In-Reply-To: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>
References: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>
Message-ID: <vVIvOz7MSwOyrUn1LhqkiEutLreVsIEBl43FBil10tk=.873fd8c7-44f4-4328-b532-5b2e7d494808@github.com>

On Tue, 27 Jul 2021 00:17:16 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing the HotSpot agent to correctly dump classes even in presence of injected interfaces.
> Fix failures of serviceability/sa/ClhsdbDumpclass.java on all platforms (tested with Mach5, tiers 1 to 3).
> 
> Thank you,
> 
> Fred

Thanks for the review!

Fred

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

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


From fparain at openjdk.java.net  Tue Jul 27 12:41:49 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 27 Jul 2021 12:41:49 GMT
Subject: [lworld] Integrated: 8271229: [lworld] Test
 serviceability/sa/ClhsdbDumpclass.java fails with unexpected end of file
In-Reply-To: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>
References: <_YeTSP2RaCPYH-ms3pQl4zMHD38KkHwqdXdB9oYPhbM=.82b29cbe-be47-443a-a5ed-2ea1cd1a63b6@github.com>
Message-ID: <Wum4-M1PHw12ahWgX5OzUBBMGS9aRsVU2hNHsVhgmUA=.3abd2044-8449-44f4-9dca-5dc8ae2866c4@github.com>

On Tue, 27 Jul 2021 00:17:16 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review those changes fixing the HotSpot agent to correctly dump classes even in presence of injected interfaces.
> Fix failures of serviceability/sa/ClhsdbDumpclass.java on all platforms (tested with Mach5, tiers 1 to 3).
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

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

8271229: [lworld] Test serviceability/sa/ClhsdbDumpclass.java fails with unexpected end of file

Reviewed-by: dsimms

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

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


From sadayapalam at openjdk.java.net  Tue Jul 27 12:50:20 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 27 Jul 2021 12:50:20 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

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

  Address review comments (reinstate original code by backing out unneeded calls to asValueType() in addHelperClasses method invocation)

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/501/files
  - new: https://git.openjdk.java.net/valhalla/pull/501/files/eb0ce6d7..421e3d2e

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

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

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


From sadayapalam at openjdk.java.net  Tue Jul 27 12:50:22 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 27 Jul 2021 12:50:22 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class
In-Reply-To: <d5Ou-qPIKFbT7hnOHc-iZuXgjavotTWZfGpvP8jGnLQ=.cf83d87e-1c4a-4534-bfb9-f279b3dcc179@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <d5Ou-qPIKFbT7hnOHc-iZuXgjavotTWZfGpvP8jGnLQ=.cf83d87e-1c4a-4534-bfb9-f279b3dcc179@github.com>
Message-ID: <AEqByUi6yGVMNtGckf9L9v_HefTtB_dhhi8cY3IoaVw=.0b37dd46-6a74-4af8-ba41-2cb5ee89111c@github.com>

On Tue, 27 Jul 2021 12:31:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Yes, please do so for consistency. Thanks!

Done, Take a look, TIA.

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

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


From sadayapalam at openjdk.java.net  Tue Jul 27 12:54:48 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 27 Jul 2021 12:54:48 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
Message-ID: <bTduwfX23ohBj8Ffys_cIO4LGguN_GmnY66PhEDcCm8=.565d2caf-aeac-4d8a-afb5-88b52a34611d@github.com>

On Tue, 27 Jul 2021 12:50:20 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Adjust meaning of type name in class literal expressions. Adjust tests accordingly
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments (reinstate original code by backing out unneeded calls to asValueType() in addHelperClasses method invocation)

test/jdk/valhalla/valuetypes/StaticFactoryMethodHandleTest.java line 69:

> 67:         MethodType mtype0 = MethodType.methodType(DefaultConstructor.class.asValueType());
> 68:         MethodHandle mh0 = staticInitFactory(DefaultConstructor.val.class, mtype0);
> 69:         DefaultConstructor o0 = (DefaultConstructor)mh0.invokeExact();

While the preferred change is go from Point.class to Point.class.asValueType(), here is one of the few places I had to resort to Point.val.class - This is because we don't have a spec for Class#asValueType() similar to Object#getClass() where the compiler munges the return type of the method. As a result, code won't compile unless I change it to Point.val.class format

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

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


From thartmann at openjdk.java.net  Tue Jul 27 13:03:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 13:03:42 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
Message-ID: <AY_R1_GS7uYpWD7y3ifzJZM6sfTGIU1-LY14aI9cDKA=.fb6e1775-2509-4afe-8706-aacd581cbad3@github.com>

On Tue, 27 Jul 2021 12:50:20 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Adjust meaning of type name in class literal expressions. Adjust tests accordingly
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments (reinstate original code by backing out unneeded calls to asValueType() in addHelperClasses method invocation)

Looks good.

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

Marked as reviewed by thartmann (Committer).

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


From thartmann at openjdk.java.net  Tue Jul 27 15:23:02 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 27 Jul 2021 15:23:02 GMT
Subject: [lworld] RFR: 8271330: [lworld] SIGSEGV in
 MemNode::find_previous_store
Message-ID: <j7-WUuzF03El8wnXSW-fImv4X4jTayCr-x8liZQTPYY=.f7b1d97d-2966-400e-b736-5e7659e93512@github.com>

Another bug that showed up now because it requires AVX-512 VLBW capable machines (and we added them to our test infra only recently). The problem is that default value store elimination to inline type arrays introduced by [JDK-8189802](https://bugs.openjdk.java.net/browse/JDK-8189802) invokes `MemNode::find_previous_store` on non-zero stores which confused `ClearArrayNode::step_through`.

This patch disables the code for now. I've filed [JDK-8271339](https://bugs.openjdk.java.net/browse/JDK-8271339) to re-enable it.

Best regards,
Tobias

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

Commit messages:
 - 8271330: [lworld] SIGSEGV in MemNode::find_previous_store

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

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


From mchung at openjdk.java.net  Tue Jul 27 17:17:44 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Jul 2021 17:17:44 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
Message-ID: <T3pSIf468KhJf8qHdPcuZyBKPnuE-oo-xBn9zx0GmFU=.b4fcac36-2120-4737-9ee4-01b66b5a9ccd@github.com>

On Tue, 27 Jul 2021 12:50:20 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Adjust meaning of type name in class literal expressions. Adjust tests accordingly
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments (reinstate original code by backing out unneeded calls to asValueType() in addHelperClasses method invocation)

Looks okay.

test/jdk/valhalla/valuetypes/PrimitiveTypeConversionTest.java line 64:

> 62:     public static void primitiveWidening() throws Throwable {
> 63:         MethodHandles.Lookup lookup = MethodHandles.lookup();
> 64:         MethodHandle mh1 = lookup.findStatic(PrimitiveTypeConversionTest.class, "narrow", methodType(Value.class.asValueType(), Value.ref.class));

Suggestion:

        MethodHandle mh1 = lookup.findStatic(PrimitiveTypeConversionTest.class, "narrow", methodType(Value.class.asValueType(), Value.class.asPrimaryType()));


This change will be needed anyway if it's decided to disallow `Value.ref.class` and `Value.val.class`.  We can wait until that discussion is resolved.

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

Marked as reviewed by mchung (Committer).

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


From mchung at openjdk.java.net  Tue Jul 27 17:17:45 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Jul 2021 17:17:45 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <bTduwfX23ohBj8Ffys_cIO4LGguN_GmnY66PhEDcCm8=.565d2caf-aeac-4d8a-afb5-88b52a34611d@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
 <bTduwfX23ohBj8Ffys_cIO4LGguN_GmnY66PhEDcCm8=.565d2caf-aeac-4d8a-afb5-88b52a34611d@github.com>
Message-ID: <loKQLzJMHP_2x9qJwnD3FtNlWWD8DVfrfZcrHxip0QI=.ec09009b-fa68-41f6-9a2a-e604b9061f3c@github.com>

On Tue, 27 Jul 2021 12:51:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments (reinstate original code by backing out unneeded calls to asValueType() in addHelperClasses method invocation)
>
> test/jdk/valhalla/valuetypes/StaticFactoryMethodHandleTest.java line 69:
> 
>> 67:         MethodType mtype0 = MethodType.methodType(DefaultConstructor.class.asValueType());
>> 68:         MethodHandle mh0 = staticInitFactory(DefaultConstructor.val.class, mtype0);
>> 69:         DefaultConstructor o0 = (DefaultConstructor)mh0.invokeExact();
> 
> While the preferred change is go from Point.class to Point.class.asValueType(), here is one of the few places I had to resort to Point.val.class - This is because we don't have a spec for Class#asValueType() similar to Object#getClass() where the compiler munges the return type of the method. As a result, code won't compile unless I change it to Point.val.class format

What special treatment of `Object#getClass` in javac?

It's fine with this temporary workaround.  FYI.  The discussion about disallowing`Point.val.class` and `Point.ref.class` syntax to obtain the primitive value type mirror but use the `Class` API instead is relevant here.

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

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


From mchung at openjdk.java.net  Tue Jul 27 17:20:47 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Jul 2021 17:20:47 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
Message-ID: <D9BkO6ndokd1pmcnke5byufqpip7wEYAyLaopyhjpeI=.15caeb95-dcb9-4e6a-b0b1-2d4a953f984c@github.com>

On Tue, 27 Jul 2021 12:50:20 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Adjust meaning of type name in class literal expressions. Adjust tests accordingly
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments (reinstate original code by backing out unneeded calls to asValueType() in addHelperClasses method invocation)

The `test/jdk/java/lang/invoke/VarHandles` tests are generated from a template.  The template should be updated instead of those tests.   I'll change the templates to replace those test changes after you push this PR.

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

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


From fparain at openjdk.java.net  Tue Jul 27 20:55:51 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 27 Jul 2021 20:55:51 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects
In-Reply-To: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
Message-ID: <oDncPe8Hg2RvukeDVw_ccYb7rs2suD29NUC0eoipSX4=.485b4f36-0ad2-4c35-8cc5-45a7ca480b2c@github.com>

On Tue, 27 Jul 2021 01:06:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds handling of Q-type fields the same way as L-type

Hi Alex,

Thank you for fixing this. Overall, looks good to me.

Many of the tests related to the FieldModification event are still not working (they are commented with a KNOWN ISSUE comment) because the withfield bytecode still doesn't support JVMTI FieldModification event. Do you have a CR to track this issue?

Regards,

Fred

test/hotspot/jtreg/serviceability/jvmti/Valhalla/FieldAccessModify/libFieldAccessModify.cpp line 139:

> 137:     // For FieldModification event print current value.
> 138:     // Note: this will cause FieldAccess event.
> 139:     if (modified) {

It would be cleaner to have modified be declared as a bool, or to re-write the test to modified == 1.

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

Marked as reviewed by fparain (Committer).

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


From amenkov at openjdk.java.net  Wed Jul 28 00:00:07 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 28 Jul 2021 00:00:07 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects
In-Reply-To: <oDncPe8Hg2RvukeDVw_ccYb7rs2suD29NUC0eoipSX4=.485b4f36-0ad2-4c35-8cc5-45a7ca480b2c@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
 <oDncPe8Hg2RvukeDVw_ccYb7rs2suD29NUC0eoipSX4=.485b4f36-0ad2-4c35-8cc5-45a7ca480b2c@github.com>
Message-ID: <qdHPlP8o0p45GQUNJVDLnDf2lDRGKNpp5bFtIyWL6EM=.7757eebb-51e3-4e67-b3ee-a964e046d395@github.com>

On Tue, 27 Jul 2021 20:12:01 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> The fix adds handling of Q-type fields the same way as L-type
>
> test/hotspot/jtreg/serviceability/jvmti/Valhalla/FieldAccessModify/libFieldAccessModify.cpp line 139:
> 
>> 137:     // For FieldModification event print current value.
>> 138:     // Note: this will cause FieldAccess event.
>> 139:     if (modified) {
> 
> It would be cleaner to have modified be declared as a bool, or to re-write the test to modified == 1.

> Many of the tests related to the FieldModification event are still not working (they are commented with a KNOWN ISSUE comment) because the withfield bytecode still doesn't support JVMTI FieldModification event. Do you have a CR to track this issue?

Filed JDK-8271355

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

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


From amenkov at openjdk.java.net  Wed Jul 28 00:00:08 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 28 Jul 2021 00:00:08 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects
In-Reply-To: <qdHPlP8o0p45GQUNJVDLnDf2lDRGKNpp5bFtIyWL6EM=.7757eebb-51e3-4e67-b3ee-a964e046d395@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
 <oDncPe8Hg2RvukeDVw_ccYb7rs2suD29NUC0eoipSX4=.485b4f36-0ad2-4c35-8cc5-45a7ca480b2c@github.com>
 <qdHPlP8o0p45GQUNJVDLnDf2lDRGKNpp5bFtIyWL6EM=.7757eebb-51e3-4e67-b3ee-a964e046d395@github.com>
Message-ID: <jXVga8tDW4uRx0SYZjhJ6Tv9VZPbvgL8GuAMFT7SDL8=.31cbf324-3e84-4267-974c-496b09dbc982@github.com>

On Tue, 27 Jul 2021 23:55:54 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/Valhalla/FieldAccessModify/libFieldAccessModify.cpp line 139:
>> 
>>> 137:     // For FieldModification event print current value.
>>> 138:     // Note: this will cause FieldAccess event.
>>> 139:     if (modified) {
>> 
>> It would be cleaner to have modified be declared as a bool, or to re-write the test to modified == 1.
>
>> Many of the tests related to the FieldModification event are still not working (they are commented with a KNOWN ISSUE comment) because the withfield bytecode still doesn't support JVMTI FieldModification event. Do you have a CR to track this issue?
> 
> Filed JDK-8271355

> It would be cleaner to have modified be declared as a bool, or to re-write the test to modified == 1.

C-style detected :)
Will fix it.

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

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


From amenkov at openjdk.java.net  Wed Jul 28 00:38:21 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 28 Jul 2021 00:38:21 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects [v2]
In-Reply-To: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
Message-ID: <fXVOBscdBirZGL4jsDgiUt6jcuqVV9icmL-0ylUEkY8=.4a3cd7cb-5bfe-4930-a34e-5a4ce77e7f84@github.com>

> The fix adds handling of Q-type fields the same way as L-type

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  Replaced int with bool for boolean argument

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/499/files
  - new: https://git.openjdk.java.net/valhalla/pull/499/files/4f1bedb9..25daf4c6

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

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

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


From sadayapalam at openjdk.java.net  Wed Jul 28 00:47:47 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 28 Jul 2021 00:47:47 GMT
Subject: [lworld] RFR: 8269956: [lworld] javac should generate `ldc LPoint;
 ` for class literal Point.class [v2]
In-Reply-To: <D9BkO6ndokd1pmcnke5byufqpip7wEYAyLaopyhjpeI=.15caeb95-dcb9-4e6a-b0b1-2d4a953f984c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
 <KAvrwsW0sSVlW32K2tZrWd9n84UiaqrWprMAZOP8Pss=.c5efe4ee-0bae-44b9-a835-d921d5898651@github.com>
 <D9BkO6ndokd1pmcnke5byufqpip7wEYAyLaopyhjpeI=.15caeb95-dcb9-4e6a-b0b1-2d4a953f984c@github.com>
Message-ID: <MZ0iY2i0eiV9Qnxwnm-7Uwq1Xcjc0b0c-LVe8zJQPhg=.b05b5cef-f2f3-42c3-a7ba-9379942cbf85@github.com>

On Tue, 27 Jul 2021 17:17:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> The `test/jdk/java/lang/invoke/VarHandles` tests are generated from X-VarHandle*.template files. The templates should be updated and regenerate those tests rather than editing the generated tests. I'll change the templates to replace those test changes after you push this PR.

Thanks!

(See the javadoc for Object#getClass() regarding the actual result type)

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

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


From sadayapalam at openjdk.java.net  Wed Jul 28 00:47:50 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 28 Jul 2021 00:47:50 GMT
Subject: [lworld] Integrated: 8269956: [lworld] javac should generate `ldc
 LPoint; ` for class literal Point.class
In-Reply-To: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
References: <eMbpVEhslyc96PB120b8n_pFd1QZg0zuoZ1pqlNf9Mo=.6d11ad31-ce27-467e-8577-8c62f887c57c@github.com>
Message-ID: <TxucQaa1QkNpoE07vNEiJwB5OezD4WBFAa6AvNmi8H4=.73a91953-a68c-4ab2-8f35-7298a905ca54@github.com>

On Tue, 27 Jul 2021 10:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust meaning of type name in class literal expressions. Adjust tests accordingly

This pull request has now been integrated.

Changeset: 8c1359af
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8c1359afd08b7370ed5436f98924c592e139138e
Stats:     359 lines in 31 files changed: 106 ins; 0 del; 253 mod

8269956: [lworld] javac should generate `ldc LPoint;` for class literal Point.class

Reviewed-by: dsimms, thartmann, mchung

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

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


From thartmann at openjdk.java.net  Wed Jul 28 05:38:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 05:38:47 GMT
Subject: [lworld] Integrated: 8271330: [lworld] SIGSEGV in
 MemNode::find_previous_store
In-Reply-To: <j7-WUuzF03El8wnXSW-fImv4X4jTayCr-x8liZQTPYY=.f7b1d97d-2966-400e-b736-5e7659e93512@github.com>
References: <j7-WUuzF03El8wnXSW-fImv4X4jTayCr-x8liZQTPYY=.f7b1d97d-2966-400e-b736-5e7659e93512@github.com>
Message-ID: <yGElkJ_LYLP34Rk8jScZD9C4CZEzrGitci20qTKaPzY=.2616cc9f-c551-4330-ad48-73c3169d6fe1@github.com>

On Tue, 27 Jul 2021 15:16:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Another bug that showed up now because it requires AVX-512 VLBW capable machines (and we added them to our test infra only recently). The problem is that default value store elimination to inline type arrays introduced by [JDK-8189802](https://bugs.openjdk.java.net/browse/JDK-8189802) invokes `MemNode::find_previous_store` on non-zero stores which confused `ClearArrayNode::step_through`.
> 
> This patch disables the code for now. I've filed [JDK-8271339](https://bugs.openjdk.java.net/browse/JDK-8271339) to re-enable it.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 92f9ea9f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/92f9ea9fa44b7bcf442278adf5d223f29b1f1846
Stats:     10 lines in 1 file changed: 0 ins; 8 del; 2 mod

8271330: [lworld] SIGSEGV in MemNode::find_previous_store

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

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


From thartmann at openjdk.java.net  Wed Jul 28 07:28:54 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 07:28:54 GMT
Subject: [lworld] RFR: 8271324: [lworld] java/foreign/* tests fail with
 "guarantee(sect->end() <= tend) failed: sanity"
Message-ID: <odTUW4MFv4lqYGGZk2LPJIMCDtsPRTZkMPIgI4COaVY=.1f2154c1-4569-4ec2-8cc4-dd8a36b5d4bf@github.com>

We hit an assert because the code generated for "upcall_stub_linkToNative" does not fit into the code buffer. That's because we are currently saving all registers before the slow call in the GC barriers:
https://github.com/openjdk/valhalla/blob/8efeb68ef0594c2c7c20bc2e45c112d6ef623b2b/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#L206-L211

https://github.com/openjdk/valhalla/blob/8efeb68ef0594c2c7c20bc2e45c112d6ef623b2b/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#L332-L337

I've doubled the buffer size to be on the safe side and filed [JDK-8271370](https://bugs.openjdk.java.net/browse/JDK-8271370) to investigate if we can avoid saving all registers in all cases.

Thanks,
Tobias

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

Commit messages:
 - 8271324: [lworld] java/foreign/* tests fail with "guarantee(sect->end() <= tend) failed: sanity"

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

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


From thartmann at openjdk.java.net  Wed Jul 28 08:07:55 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 08:07:55 GMT
Subject: [lworld] Integrated: 8271324: [lworld] java/foreign/* tests fail with
 "guarantee(sect->end() <= tend) failed: sanity"
In-Reply-To: <odTUW4MFv4lqYGGZk2LPJIMCDtsPRTZkMPIgI4COaVY=.1f2154c1-4569-4ec2-8cc4-dd8a36b5d4bf@github.com>
References: <odTUW4MFv4lqYGGZk2LPJIMCDtsPRTZkMPIgI4COaVY=.1f2154c1-4569-4ec2-8cc4-dd8a36b5d4bf@github.com>
Message-ID: <Bxre0LlyHDACl81U-ZvE1Ox27vLyE-J_CS3gr0_eJp0=.a5864250-81c7-4896-b9d9-6d81ac43cd8b@github.com>

On Wed, 28 Jul 2021 07:24:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit an assert because the code generated for "upcall_stub_linkToNative" does not fit into the code buffer. That's because we are currently saving all registers before the slow call in the GC barriers:
> https://github.com/openjdk/valhalla/blob/8efeb68ef0594c2c7c20bc2e45c112d6ef623b2b/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#L206-L211
> 
> https://github.com/openjdk/valhalla/blob/8efeb68ef0594c2c7c20bc2e45c112d6ef623b2b/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#L332-L337
> 
> I've doubled the buffer size to be on the safe side and filed [JDK-8271370](https://bugs.openjdk.java.net/browse/JDK-8271370) to investigate if we can avoid saving all registers in all cases.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 7ac76624
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7ac76624ae0a89d33adb46660025f996883f2798
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8271324: [lworld] java/foreign/* tests fail with "guarantee(sect->end() <= tend) failed: sanity"

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

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


From thartmann at openjdk.java.net  Wed Jul 28 09:49:58 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 09:49:58 GMT
Subject: [lworld] RFR: 8271380: [lworld] Intrinsify
 j.l.Class::asPrimaryType/asValueType
Message-ID: <IQ4HXQ7aw6nrtqjPDCYAhXqRaNFD-mFRc-hX0aA6FOs=.dca0dabe-e295-4960-b507-62a5c632f0db@github.com>

`TestIntrinsics.java` fails after [JDK-8269956](https://bugs.openjdk.java.net/browse/JDK-8269956) which replace some usages of `MyValue.class` by `MyValue.class.asValueType()`. The problem is that `asValueType()` is not always inlined by C2 and therefore IR verification fails.

This patch intrinsifies the methods similar to what we did in old L/Q world (https://github.com/openjdk/valhalla/commit/e895128f). I've also modified the test to consistently use `asPrimaryType`/`asValueType`.

Thanks,
Tobias

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

Commit messages:
 - 8271380: [lworld] Intrinsify j.l.Class::asPrimaryType/asValueType

Changes: https://git.openjdk.java.net/valhalla/pull/504/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=504&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271380
  Stats: 128 lines in 9 files changed: 85 ins; 0 del; 43 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/504.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/504/head:pull/504

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


From sadayapalam at openjdk.java.net  Wed Jul 28 11:48:05 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 28 Jul 2021 11:48:05 GMT
Subject: [lworld] Integrated: 8271389: [lworld] Improve typing of
 primitiveObject.getClass()
Message-ID: <cxGQrsGTASk5x87odx2L531Q9w_G5oLn-Sx0KYo1bZI=.751c6097-8d11-46f9-b200-23111bb7f13b@github.com>

Static type of getClass() should align with behavior of method which always returns the primary mirror.

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

Commit messages:
 - 8271389: [lworld] Improve typing of primitiveObject.getClass()

Changes: https://git.openjdk.java.net/valhalla/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=505&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271389
  Stats: 70 lines in 6 files changed: 43 ins; 13 del; 14 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/505/head:pull/505

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


From sadayapalam at openjdk.java.net  Wed Jul 28 11:48:08 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 28 Jul 2021 11:48:08 GMT
Subject: [lworld] Integrated: 8271389: [lworld] Improve typing of
 primitiveObject.getClass()
In-Reply-To: <cxGQrsGTASk5x87odx2L531Q9w_G5oLn-Sx0KYo1bZI=.751c6097-8d11-46f9-b200-23111bb7f13b@github.com>
References: <cxGQrsGTASk5x87odx2L531Q9w_G5oLn-Sx0KYo1bZI=.751c6097-8d11-46f9-b200-23111bb7f13b@github.com>
Message-ID: <YsyiX0i2qW6fq6dUArXiEyYpgBqkX6T8Tu1lIamckRc=.b4afe818-962f-49d3-9cfb-93831f35a55e@github.com>

On Wed, 28 Jul 2021 11:41:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Static type of getClass() should align with behavior of method which always returns the primary mirror.

This pull request has now been integrated.

Changeset: 22761111
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/227611116c706c13d3f367dd51e9fe231b37aad7
Stats:     70 lines in 6 files changed: 43 ins; 13 del; 14 mod

8271389: [lworld] Improve typing of primitiveObject.getClass()

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

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


From thartmann at openjdk.java.net  Wed Jul 28 11:49:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 11:49:48 GMT
Subject: [lworld] Integrated: 8271380: [lworld] Intrinsify
 j.l.Class::asPrimaryType/asValueType
In-Reply-To: <IQ4HXQ7aw6nrtqjPDCYAhXqRaNFD-mFRc-hX0aA6FOs=.dca0dabe-e295-4960-b507-62a5c632f0db@github.com>
References: <IQ4HXQ7aw6nrtqjPDCYAhXqRaNFD-mFRc-hX0aA6FOs=.dca0dabe-e295-4960-b507-62a5c632f0db@github.com>
Message-ID: <5qB9NOAfN9tYWa8kPUVjik0xp4t6KVDqkkTYq74Uduw=.c33a98fb-978c-4848-9ae1-36d66ee1aafc@github.com>

On Wed, 28 Jul 2021 09:43:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `TestIntrinsics.java` fails after [JDK-8269956](https://bugs.openjdk.java.net/browse/JDK-8269956) which replace some usages of `MyValue.class` by `MyValue.class.asValueType()`. The problem is that `asValueType()` is not always inlined by C2 and therefore IR verification fails.
> 
> This patch intrinsifies the methods similar to what we did in old L/Q world (https://github.com/openjdk/valhalla/commit/e895128f). I've also modified the test to consistently use `asPrimaryType`/`asValueType`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: bebb40f5
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bebb40f5dc00b40f1fcdb68f9cebbd7bb597095d
Stats:     128 lines in 9 files changed: 85 ins; 0 del; 43 mod

8271380: [lworld] Intrinsify j.l.Class::asPrimaryType/asValueType

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

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


From fparain at openjdk.java.net  Wed Jul 28 12:54:45 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 28 Jul 2021 12:54:45 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects [v2]
In-Reply-To: <fXVOBscdBirZGL4jsDgiUt6jcuqVV9icmL-0ylUEkY8=.4a3cd7cb-5bfe-4930-a34e-5a4ce77e7f84@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
 <fXVOBscdBirZGL4jsDgiUt6jcuqVV9icmL-0ylUEkY8=.4a3cd7cb-5bfe-4930-a34e-5a4ce77e7f84@github.com>
Message-ID: <8gVubauB9H_osiK4GFFcKn04ZqHJuUwuD7vs4-DvUD4=.3470cb0e-5576-464a-ac74-bde6bf8a73f1@github.com>

On Wed, 28 Jul 2021 00:38:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix adds handling of Q-type fields the same way as L-type
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced int with bool for boolean argument

Thank you for the changes.

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

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


From david.simms at oracle.com  Wed Jul 28 13:14:21 2021
From: david.simms at oracle.com (David Simms)
Date: Wed, 28 Jul 2021 15:14:21 +0200
Subject: CFV: New Valhalla Committer: Alex Menkov
Message-ID: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>

I hereby nominate Alex Menkov to Valhalla Committer.

Alex is a member of the serviceability group and actively working on 
Hotspot, as well as a reviewer for the JDK.

Votes are due by 2021-08-11 13:15Z.

Only current Valhalla Committers [1] are eligible to vote
on this nomination.? Votes must be cast in the open by replying
to this mailing list.

For Lazy Consensus voting instructions, see [2].

David Simms

[1] https://openjdk.java.net/census
[2] https://openjdk.java.net/projects/#committer-vote



From frederic.parain at oracle.com  Wed Jul 28 13:15:44 2021
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 28 Jul 2021 13:15:44 +0000
Subject: CFV: New Valhalla Committer: Alex Menkov
In-Reply-To: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
References: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
Message-ID: <9C7340CC-310E-4D0B-9160-F729BFDB323B@oracle.com>

Vote: yes

Fred


> On Jul 28, 2021, at 9:14 AM, David Simms <david.simms at oracle.com> wrote:
> 
> I hereby nominate Alex Menkov to Valhalla Committer.
> 
> Alex is a member of the serviceability group and actively working on Hotspot, as well as a reviewer for the JDK.
> 
> Votes are due by 2021-08-11 13:15Z.
> 
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> David Simms
> 
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 



From david.simms at oracle.com  Wed Jul 28 13:16:48 2021
From: david.simms at oracle.com (David Simms)
Date: Wed, 28 Jul 2021 15:16:48 +0200
Subject: CFV: New Valhalla Committer: Alex Menkov
In-Reply-To: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
References: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
Message-ID: <5393d7d3-2fc1-6072-9e03-258cee246098@oracle.com>


Vote: Yes

Simms

On 2021-07-28 15:14, David Simms wrote:
> I hereby nominate Alex Menkov to Valhalla Committer.
>
> Alex is a member of the serviceability group and actively working on 
> Hotspot, as well as a reviewer for the JDK.
>
> Votes are due by 2021-08-11 13:15Z.
>
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> David Simms
>
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>



From tobias.hartmann at oracle.com  Wed Jul 28 13:25:08 2021
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Wed, 28 Jul 2021 15:25:08 +0200
Subject: CFV: New Valhalla Committer: Alex Menkov
In-Reply-To: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
References: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
Message-ID: <f60a0898-160a-5891-1bbf-d8a550aa0ecb@oracle.com>

Vote: yes

Best regards,
Tobias

On 28.07.21 15:14, David Simms wrote:
> I hereby nominate Alex Menkov to Valhalla Committer.
> 
> Alex is a member of the serviceability group and actively working on Hotspot, as well as a reviewer
> for the JDK.
> 
> Votes are due by 2021-08-11 13:15Z.
> 
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.? Votes must be cast in the open by replying
> to this mailing list.
> 
> For Lazy Consensus voting instructions, see [2].
> 
> David Simms
> 
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
> 


From harold.seigel at oracle.com  Wed Jul 28 13:33:40 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Wed, 28 Jul 2021 09:33:40 -0400
Subject: CFV: New Valhalla Committer: Alex Menkov
In-Reply-To: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
References: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
Message-ID: <0d66c203-1961-4d7a-7df1-058a130f8d26@oracle.com>

Vote: Yes

Harold

On 7/28/2021 9:14 AM, David Simms wrote:
> I hereby nominate Alex Menkov to Valhalla Committer.
>
> Alex is a member of the serviceability group and actively working on 
> Hotspot, as well as a reviewer for the JDK.
>
> Votes are due by 2021-08-11 13:15Z.
>
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> David Simms
>
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>


From thartmann at openjdk.java.net  Wed Jul 28 14:11:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 14:11:05 GMT
Subject: [lworld] RFR: 8271397: [lworld] SIGSEGV in ciKlass::is_subtype_of
Message-ID: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>

This should fix an extremely intermittent crash (only happened once) in `ciKlass::is_subtype_of`. Similar to the checks in `Parse::do_checkcast`, we need to check for `klass->is_loaded()` before calling `is_subtype_of(klass)` in type flow analysis.

Best regards,
Tobias

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

Commit messages:
 - 8271397: [lworld] SIGSEGV in ciKlass::is_subtype_of
 - 8271397: [lworld] SIGSEGV in ciKlass::is_subtype_of

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

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


From roger.riggs at oracle.com  Wed Jul 28 14:25:38 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 28 Jul 2021 10:25:38 -0400
Subject: CFV: New Valhalla Committer: Alex Menkov
In-Reply-To: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
References: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
Message-ID: <40c3468f-69da-4df2-68d7-a033dcf6b2d1@oracle.com>

Vote: Yes

On 7/28/21 9:14 AM, David Simms wrote:
> I hereby nominate Alex Menkov to Valhalla Committer. 



From lois.foltan at oracle.com  Wed Jul 28 14:59:18 2021
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 28 Jul 2021 10:59:18 -0400
Subject: CFV: New Valhalla Committer: Alex Menkov
In-Reply-To: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
References: <a8ba9468-7b37-6d76-6f9b-826b9f4b2718@oracle.com>
Message-ID: <a018976a-d271-d61b-74bc-485b49b2cc99@oracle.com>

Vote: yes

Lois

On 7/28/2021 9:14 AM, David Simms wrote:
> I hereby nominate Alex Menkov to Valhalla Committer.
>
> Alex is a member of the serviceability group and actively working on 
> Hotspot, as well as a reviewer for the JDK.
>
> Votes are due by 2021-08-11 13:15Z.
>
> Only current Valhalla Committers [1] are eligible to vote
> on this nomination.? Votes must be cast in the open by replying
> to this mailing list.
>
> For Lazy Consensus voting instructions, see [2].
>
> David Simms
>
> [1] https://openjdk.java.net/census
> [2] https://openjdk.java.net/projects/#committer-vote
>



From fparain at openjdk.java.net  Wed Jul 28 15:03:47 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 28 Jul 2021 15:03:47 GMT
Subject: [lworld] RFR: 8271397: [lworld] SIGSEGV in ciKlass::is_subtype_of
In-Reply-To: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>
References: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>
Message-ID: <_HCQds8tSLtvQXGKEiqhjF7HD8xUFzWUzWUMWZyyQFw=.f154e3d9-bd7d-4b64-8e6c-702e6789569c@github.com>

On Wed, 28 Jul 2021 14:04:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This should fix an extremely intermittent crash (only happened once) in `ciKlass::is_subtype_of`. Similar to the checks in `Parse::do_checkcast`, we need to check for `klass->is_loaded()` before calling `is_subtype_of(klass)` in type flow analysis.
> 
> Best regards,
> Tobias

Marked as reviewed by fparain (Committer).

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

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


From thartmann at openjdk.java.net  Wed Jul 28 15:09:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 15:09:51 GMT
Subject: [lworld] RFR: 8271397: [lworld] SIGSEGV in ciKlass::is_subtype_of
In-Reply-To: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>
References: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>
Message-ID: <SwiRa3UpMd0sQuoHP8jO-_RXSh9iQet6n5Ga6newgso=.30747788-e7b5-4960-b854-04998dcf5cd3@github.com>

On Wed, 28 Jul 2021 14:04:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This should fix an extremely intermittent crash (only happened once) in `ciKlass::is_subtype_of`. Similar to the checks in `Parse::do_checkcast`, we need to check for `klass->is_loaded()` before calling `is_subtype_of(klass)` in type flow analysis.
> 
> Best regards,
> Tobias

Thanks for the review, Frederic!

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

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


From thartmann at openjdk.java.net  Wed Jul 28 15:33:42 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 28 Jul 2021 15:33:42 GMT
Subject: [lworld] Integrated: 8271397: [lworld] SIGSEGV in
 ciKlass::is_subtype_of
In-Reply-To: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>
References: <0cDZziHsQBngHYLdOeop39AU9zSZJJmU5pFX3FzoUAY=.e21ade08-7021-4c4d-8760-cdbcc58809d4@github.com>
Message-ID: <NuQgNrqao5PIu7PrUhnj-aPO0rBtSYa8QFm0goxJt20=.e48ae5a2-6851-45c8-994b-b513f36cc373@github.com>

On Wed, 28 Jul 2021 14:04:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This should fix an extremely intermittent crash (only happened once) in `ciKlass::is_subtype_of`. Similar to the checks in `Parse::do_checkcast`, we need to check for `klass->is_loaded()` before calling `is_subtype_of(klass)` in type flow analysis.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

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

8271397: [lworld] SIGSEGV in ciKlass::is_subtype_of

Reviewed-by: fparain

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

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


From amenkov at openjdk.java.net  Wed Jul 28 19:44:46 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 28 Jul 2021 19:44:46 GMT
Subject: [lworld] RFR: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects [v2]
In-Reply-To: <8gVubauB9H_osiK4GFFcKn04ZqHJuUwuD7vs4-DvUD4=.3470cb0e-5576-464a-ac74-bde6bf8a73f1@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
 <fXVOBscdBirZGL4jsDgiUt6jcuqVV9icmL-0ylUEkY8=.4a3cd7cb-5bfe-4930-a34e-5a4ce77e7f84@github.com>
 <8gVubauB9H_osiK4GFFcKn04ZqHJuUwuD7vs4-DvUD4=.3470cb0e-5576-464a-ac74-bde6bf8a73f1@github.com>
Message-ID: <KrmuBqjfL4NX0P09hnHQy_yyQ6n-ut114FtfL5oaLwk=.6ac165b7-62ba-450e-bea5-e9e6381f4e11@github.com>

On Wed, 28 Jul 2021 12:52:16 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced int with bool for boolean argument
>
> Thank you for the changes.

@fparain could you please sponsor the fix

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

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


From amenkov at openjdk.java.net  Thu Jul 29 06:17:02 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 29 Jul 2021 06:17:02 GMT
Subject: [lworld] Integrated: 8271309: [lworld] FieldModification event:
 new_value is invalid for Q objects
In-Reply-To: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
References: <W5uNPLORC4JNpQUYAnk8-46ZK7iGbJAdqfPw2N8EQHY=.5713f4d8-da4d-4350-8e65-7605b94fd51d@github.com>
Message-ID: <2YxfZ41QhT8-RsxzGHGY1_YBZJvDVabMJeM3BjWCYsI=.80d54585-4d2f-4da1-b442-998e08fc3260@github.com>

On Tue, 27 Jul 2021 01:06:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix adds handling of Q-type fields the same way as L-type

This pull request has now been integrated.

Changeset: 12823808
Author:    Alex Menkov <amenkov at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/128238081fde5ce62aa64061562e20c76843ccf7
Stats:     558 lines in 3 files changed: 557 ins; 0 del; 1 mod

8271309: [lworld] FieldModification event: new_value is invalid for Q objects

Reviewed-by: fparain

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

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


From thartmann at openjdk.java.net  Thu Jul 29 16:11:04 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 29 Jul 2021 16:11:04 GMT
Subject: [lworld] RFR: 8271486: [lworld] Memory corruption due to out of bound
 access in MacroAssembler::move_helper
Message-ID: <o9AkXikBf-1xldYhOvLr0ntD0EWiznkqlimzLe2sIcU=.b3d64cd7-8f93-4b0c-8c75-eef6a000d513@github.com>

While debugging weird crashes that only showed up when merging current mainline with lworld, I've noticed that we are writing outside of the `reg_state` array in `MacroAssembler::move_helper` because `from->value()` is `-1` (`OptoReg::BAD_REG`): 
https://github.com/openjdk/valhalla/blob/3c399d9f7f36903e4c2583c16b0080e01181114a/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L5794-L5797

The register is invalid because it belongs to the second half of a `T_LONG` or `T_DOUBLE` argument in the calling convention and should simply be ignored. I've also added asserts to catch similar issues in the future.

Thanks,
Tobias

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

Commit messages:
 - 8271486: [lworld] Memory corruption due to out of bound access in MacroAssembler::move_helper

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

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


From thartmann at openjdk.java.net  Thu Jul 29 17:47:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 29 Jul 2021 17:47:46 GMT
Subject: [lworld] Integrated: 8271486: [lworld] Memory corruption due to out
 of bound access in MacroAssembler::move_helper
In-Reply-To: <o9AkXikBf-1xldYhOvLr0ntD0EWiznkqlimzLe2sIcU=.b3d64cd7-8f93-4b0c-8c75-eef6a000d513@github.com>
References: <o9AkXikBf-1xldYhOvLr0ntD0EWiznkqlimzLe2sIcU=.b3d64cd7-8f93-4b0c-8c75-eef6a000d513@github.com>
Message-ID: <rewRVgOA5JpA2QKyqhg6FI_FQUBN25BL3-ZAf5gKLcc=.ad4dd9cc-6f3c-4e5d-8ef3-9b9ece49bd11@github.com>

On Thu, 29 Jul 2021 16:04:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> While debugging weird crashes that only showed up when merging current mainline with lworld, I've noticed that we are writing outside of the `reg_state` array in `MacroAssembler::move_helper` because `from->value()` is `-1` (`OptoReg::BAD_REG`): 
> https://github.com/openjdk/valhalla/blob/3c399d9f7f36903e4c2583c16b0080e01181114a/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L5794-L5797
> 
> The register is invalid because it belongs to the second half of a `T_LONG` or `T_DOUBLE` argument in the calling convention and should simply be ignored. I've also added asserts to catch similar issues in the future.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 233d7bbb
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/233d7bbb84a874d96e35657ff533d9c5903fbea6
Stats:     14 lines in 3 files changed: 11 ins; 0 del; 3 mod

8271486: [lworld] Memory corruption due to out of bound access in MacroAssembler::move_helper

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

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


From thartmann at openjdk.java.net  Fri Jul 30 07:17:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Jul 2021 07:17:05 GMT
Subject: [lworld] RFR: 8271531: [lworld] Implicit null check optimization does
 not hoist constant load input
Message-ID: <T1KU2NC73ux5HHr5W1sMgM2toxd0Zci0DEr6rykcBq4=.1d410478-a504-4098-892f-5ef029b5ebb0@github.com>

[JDK-8231561](https://bugs.openjdk.java.net/browse/JDK-8231561) added support for hoisting constant load inputs during C2's implicit null check optimization, assuming that it's only required if `!is_decoden`. However,  the following `andL` has both a `decodeHeapOop_not_null` val input and a `loadConUL32`  that needs to be hoisted:


 239  loadConUL32  ===  1  [[ 238 ]] #5/0x0000000000000005
 245  decodeHeapOop_not_null  === _  208  [[ 246  238  228  250 ]] java/lang/Object:NotNull *  ...
 238  andL_rReg_mem_0  ===  1041  133  245  239  [[ 240  237 ]]


The fix is to simply always check for constant loads inputs that require hoisting.

Best regards,
Tobias

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

Commit messages:
 - 8271531: [lworld] Implicit null check optimization does not hoist constant load input

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

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


From dsimms at openjdk.java.net  Fri Jul 30 07:28:13 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 30 Jul 2021 07:28:13 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <YpyaHdMJBnuN6aVJ-eMcfdEsbf1x00UXhyG9blQ9uns=.023d7e90-bdfd-4126-96e0-684c998a564f@github.com>

Merge tag 'jdk-18+7'

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

Commit messages:
 - Merge remote-tracking branch 'origin/lworld' into lworld_merge_jdk_18_6
 - Reciever type could be null for JDK-8268371 change
 - Biased Lock testing referenced in test config
 - Merge tag 'jdk-18+7' into lworld_merge_jdk_18_6
 - 8271014: Refactor HeapShared::is_archived_object()
 - 8270949: Make dynamically generated classes with the class file version of the current release
 - 8269849: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
 - 8270991: G1 Full GC always performs heap verification after JDK-8269295
 - 8270820: remove unused stiFileTableIndex from SDE.c
 - 8270147: Increase stride size allowing unrolling more loops
 - ... and 457 more: https://git.openjdk.java.net/valhalla/compare/233d7bbb...0d817ed7

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

Changes: https://git.openjdk.java.net/valhalla/pull/509/files
  Stats: 77842 lines in 1519 files changed: 38139 ins; 33036 del; 6667 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/509.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/509/head:pull/509

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


From thartmann at openjdk.java.net  Fri Jul 30 07:48:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Jul 2021 07:48:05 GMT
Subject: [lworld] RFR: 8271535: [lworld] TestLWorld fails during IR
 verification because method is not inlined
Message-ID: <NNkhbSFfnH23EcIgtD5PoxWAx7cNbn_m88gvkx6G7wg=.09cce295-ec21-46b0-8a49-888c7eb26e39@github.com>

In rare cases, some methods are not inlined, leading to IR verification failures. The fix is to add `@ForceInline` statements.

Best regards,
Tobias

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

Commit messages:
 - 8271535: [lworld] TestLWorld fails during IR verification because method is not inlined

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

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


From dsimms at openjdk.java.net  Fri Jul 30 07:55:48 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 30 Jul 2021 07:55:48 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <YpyaHdMJBnuN6aVJ-eMcfdEsbf1x00UXhyG9blQ9uns=.023d7e90-bdfd-4126-96e0-684c998a564f@github.com>
References: <YpyaHdMJBnuN6aVJ-eMcfdEsbf1x00UXhyG9blQ9uns=.023d7e90-bdfd-4126-96e0-684c998a564f@github.com>
Message-ID: <MhlVCyiKPSw9lnxAjSdt1FDB_KmWqeyF_4ZKLUr2L6w=.a4b6cdf4-e74b-4204-a0f5-2f7fd8fb6fe5@github.com>

On Fri, 30 Jul 2021 07:18:54 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+7'

This pull request has now been integrated.

Changeset: 0e3418df
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0e3418df579fa7d2c6f56b4064656a8223f362db
Stats:     77842 lines in 1519 files changed: 38139 ins; 33036 del; 6667 mod

Merge jdk

Merge tag 'jdk-18+7'

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

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


From thartmann at openjdk.java.net  Fri Jul 30 08:24:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Jul 2021 08:24:46 GMT
Subject: [lworld] Integrated: 8271531: [lworld] Implicit null check
 optimization does not hoist constant load input
In-Reply-To: <T1KU2NC73ux5HHr5W1sMgM2toxd0Zci0DEr6rykcBq4=.1d410478-a504-4098-892f-5ef029b5ebb0@github.com>
References: <T1KU2NC73ux5HHr5W1sMgM2toxd0Zci0DEr6rykcBq4=.1d410478-a504-4098-892f-5ef029b5ebb0@github.com>
Message-ID: <5lt5PLsw_dgXF20z2dtkZrgIyKd3ZxZ-skZzKp5pRXY=.042cc100-739e-497c-8d7a-5a69e9bfce20@github.com>

On Fri, 30 Jul 2021 07:08:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8231561](https://bugs.openjdk.java.net/browse/JDK-8231561) added support for hoisting constant load inputs during C2's implicit null check optimization, assuming that it's only required if `!is_decoden`. However,  the following `andL` has both a `decodeHeapOop_not_null` val input and a `loadConUL32`  that needs to be hoisted:
> 
> 
>  239  loadConUL32  ===  1  [[ 238 ]] #5/0x0000000000000005
>  245  decodeHeapOop_not_null  === _  208  [[ 246  238  228  250 ]] java/lang/Object:NotNull *  ...
>  238  andL_rReg_mem_0  ===  1041  133  245  239  [[ 240  237 ]]
> 
> 
> The fix is to simply always check for constant loads inputs that require hoisting.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 6699537a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/6699537ae0f4d32627c7d7c931071caaa5f0273b
Stats:     17 lines in 1 file changed: 0 ins; 0 del; 17 mod

8271531: [lworld] Implicit null check optimization does not hoist constant load input

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

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


From dsimms at openjdk.java.net  Fri Jul 30 08:44:36 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 30 Jul 2021 08:44:36 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <etRHz-jAl2BZXmYF08XUSFP1fvsVQi3ApNSx-vKJcYY=.f1eca1ee-b797-4252-a14d-d5e63d49346e@github.com>

Merge tag 'jdk-18+8'

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

Commit messages:
 - Merge tag 'jdk-18+8' into lworld_merge_jdk_18_8
 - 8270086: ARM32-softfp: Do not load CONSTANT_double using the condy helper methods in the interpreter
 - 8270901: Typo PHASE_CPP in CompilerPhaseType
 - 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation optimization
 - 8266510: Nimbus JTree default tree cell renderer does not use selected text color
 - 8266054: VectorAPI rotate operation optimization
 - 8271118: C2: StressGCM should have higher priority than frequency-based policy
 - 8271323: [TESTBUG] serviceability/sa/ClhsdbCDSCore.java fails with -XX:TieredStopAtLevel=1
 - 8261236: C2: ClhsdbJstackXcompStress test fails when StressGCM is enabled
 - Merge
 - ... and 97 more: https://git.openjdk.java.net/valhalla/compare/0e3418df...0532293b

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

Changes: https://git.openjdk.java.net/valhalla/pull/511/files
  Stats: 5740 lines in 226 files changed: 3050 ins; 915 del; 1775 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/511.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/511/head:pull/511

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


From thartmann at openjdk.java.net  Fri Jul 30 09:38:59 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Jul 2021 09:38:59 GMT
Subject: [lworld] Integrated: 8271535: [lworld] TestLWorld fails during IR
 verification because method is not inlined
In-Reply-To: <NNkhbSFfnH23EcIgtD5PoxWAx7cNbn_m88gvkx6G7wg=.09cce295-ec21-46b0-8a49-888c7eb26e39@github.com>
References: <NNkhbSFfnH23EcIgtD5PoxWAx7cNbn_m88gvkx6G7wg=.09cce295-ec21-46b0-8a49-888c7eb26e39@github.com>
Message-ID: <F7K_0e-Y5y0oH958wiKXLK-KibOI89HCQThCG8_qVjY=.cf56db2a-50d7-42ab-b22b-f8bb10112e04@github.com>

On Fri, 30 Jul 2021 07:41:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In rare cases, some methods are not inlined, leading to IR verification failures. The fix is to add `@ForceInline` statements.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

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

8271535: [lworld] TestLWorld fails during IR verification because method is not inlined

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

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


From thartmann at openjdk.java.net  Fri Jul 30 09:40:11 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Jul 2021 09:40:11 GMT
Subject: [lworld] RFR: 8271544: [lworld] GraphBuilder::withfield should handle
 identity class holder
Message-ID: <gziwrMm2TQmlUZQaNwFED8YZqftxcvJ2mXQ0TBpJDmQ=.793ca6dd-171f-44f0-b57a-06b0d04d0777@github.com>

The test added by [8269756](https://bugs.openjdk.java.net/browse/JDK-8269756) asserts in `GraphBuilder::withfield` because the holder klass is not an inline klass. C1 should handle that edge case by deoptimizing.

Best regards,
Tobias

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

Commit messages:
 - No need to initialize field
 - 8271544: [lworld] GraphBuilder::withfield should handle identity class holder

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

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


From dsimms at openjdk.java.net  Fri Jul 30 09:43:43 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 30 Jul 2021 09:43:43 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <etRHz-jAl2BZXmYF08XUSFP1fvsVQi3ApNSx-vKJcYY=.f1eca1ee-b797-4252-a14d-d5e63d49346e@github.com>
References: <etRHz-jAl2BZXmYF08XUSFP1fvsVQi3ApNSx-vKJcYY=.f1eca1ee-b797-4252-a14d-d5e63d49346e@github.com>
Message-ID: <ImWlXdn7FdieBpFoHzOUthDhJMKmL8gtbrP8ytFeIk4=.a25d5dac-a938-4a67-8bc2-6a8aeaacfa76@github.com>

On Fri, 30 Jul 2021 08:37:08 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+8'

This pull request has now been integrated.

Changeset: 2ca8eba4
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2ca8eba42e826e08439e4575dcbc6de3621c0395
Stats:     5740 lines in 226 files changed: 3050 ins; 915 del; 1775 mod

Merge jdk

Merge tag 'jdk-18+8'

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

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


From thartmann at openjdk.java.net  Fri Jul 30 11:02:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 30 Jul 2021 11:02:45 GMT
Subject: [lworld] Integrated: 8271544: [lworld] GraphBuilder::withfield should
 handle identity class holder
In-Reply-To: <gziwrMm2TQmlUZQaNwFED8YZqftxcvJ2mXQ0TBpJDmQ=.793ca6dd-171f-44f0-b57a-06b0d04d0777@github.com>
References: <gziwrMm2TQmlUZQaNwFED8YZqftxcvJ2mXQ0TBpJDmQ=.793ca6dd-171f-44f0-b57a-06b0d04d0777@github.com>
Message-ID: <57QYve5mmTnjm0xIFTy89PFxNwXwJvTxHAd9BxgbFMY=.982cf05d-0e54-4e8f-b387-4d38eea97495@github.com>

On Fri, 30 Jul 2021 09:33:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The test added by [8269756](https://bugs.openjdk.java.net/browse/JDK-8269756) asserts in `GraphBuilder::withfield` because the holder klass is not an inline klass. C1 should handle that edge case by deoptimizing.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: bdf27993
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bdf27993723b0c9057db9a148a629b034ba3eb08
Stats:     36 lines in 3 files changed: 32 ins; 1 del; 3 mod

8271544: [lworld] GraphBuilder::withfield should handle identity class holder

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

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


From hseigel at openjdk.java.net  Fri Jul 30 13:30:54 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 30 Jul 2021 13:30:54 GMT
Subject: [lworld] RFR: 8271508: [lworld] disallow primitive classes with
 super_class of 0
Message-ID: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>

Please review this small fix for valhalla bug JDK-8271508.  The fix was tested with a new regression test, with JCK lang and VM, mach5 tiers 1-2 on Linux, Mac OS, and WIndows, and mach5 tiers 3-5 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8271508: [lworld] disallow primitive classes with super_class of 0

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

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


From dsimms at openjdk.java.net  Fri Jul 30 14:06:50 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 30 Jul 2021 14:06:50 GMT
Subject: [lworld] RFR: 8271508: [lworld] disallow primitive classes with
 super_class of 0
In-Reply-To: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>
References: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>
Message-ID: <vv3xpnG6IVkQMCh-620amLYmoc6-tUU6G0O9r7SwL5w=.aa18971b-53c0-41ef-9e33-837f2f961861@github.com>

On Fri, 30 Jul 2021 13:25:13 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for valhalla bug JDK-8271508.  The fix was tested with a new regression test, with JCK lang and VM, mach5 tiers 1-2 on Linux, Mac OS, and WIndows, and mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Looks good

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

Marked as reviewed by dsimms (Committer).

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


From hseigel at openjdk.java.net  Fri Jul 30 14:21:47 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 30 Jul 2021 14:21:47 GMT
Subject: [lworld] RFR: 8271508: [lworld] disallow primitive classes with
 super_class of 0
In-Reply-To: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>
References: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>
Message-ID: <kLZ2Ft9I5lRdb4YqfohoM-pMwVH-k5TtI83bgDEmi60=.26006efb-2930-482c-8db0-8733c91cb6b1@github.com>

On Fri, 30 Jul 2021 13:25:13 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for valhalla bug JDK-8271508.  The fix was tested with a new regression test, with JCK lang and VM, mach5 tiers 1-2 on Linux, Mac OS, and WIndows, and mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Thanks David for reviewing this!

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

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


From hseigel at openjdk.java.net  Fri Jul 30 14:21:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 30 Jul 2021 14:21:48 GMT
Subject: [lworld] Integrated: 8271508: [lworld] disallow primitive classes
 with super_class of 0
In-Reply-To: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>
References: <3eGxAqROpWKWRqhQ3aGuwjkV3mNK8dZJAtWeVkXZXvs=.3b80dbd0-2673-456c-a85f-3419c2e2b4c5@github.com>
Message-ID: <UtO_Hnc7IfeiF5EU6ihe6mRCCDZ7-VQWnUQOnyKf9FE=.ce69bdfa-4cc3-4341-a9f6-92a111d3bfad@github.com>

On Fri, 30 Jul 2021 13:25:13 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small fix for valhalla bug JDK-8271508.  The fix was tested with a new regression test, with JCK lang and VM, mach5 tiers 1-2 on Linux, Mac OS, and WIndows, and mach5 tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 44784e4c
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/44784e4cdfcf3156c33b0e62ac6b639ccd8a91b4
Stats:     87 lines in 3 files changed: 80 ins; 2 del; 5 mod

8271508: [lworld] disallow primitive classes with super_class of 0

Reviewed-by: dsimms

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

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


From hseigel at openjdk.java.net  Fri Jul 30 17:20:56 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 30 Jul 2021 17:20:56 GMT
Subject: [lworld] RFR: 8271536: [lworld] VerifyError in
 hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
Message-ID: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>

Please review this fix for JDK-8271536.  The fix throws a ClassFormatError exception for methods named <init> if they have a non-void function return type that is a basic primitive type, such as D or I regardless of the setting of EnableValhalla..  Note that additional changes may be needed in the future depending on how method <init> and possibly <new> are defined in future JVM Specs.

The fix was tested by running the JCK lang and VM tests and Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.

Thanks, Harold

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

Commit messages:
 - 8271536: [lworld] VerifyError in hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java

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

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


From fparain at openjdk.java.net  Fri Jul 30 17:20:56 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 30 Jul 2021 17:20:56 GMT
Subject: [lworld] RFR: 8271536: [lworld] VerifyError in
 hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
In-Reply-To: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>
References: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>
Message-ID: <AO6M8BjzKCQYBIcxAdZOZ6bBFY3sXLTPNY1ccQcGyHU=.328b91e8-64f7-436c-9bf5-c67bdaa62d0d@github.com>

On Fri, 30 Jul 2021 17:14:42 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8271536.  The fix throws a ClassFormatError exception for methods named <init> if they have a non-void function return type that is a basic primitive type, such as D or I regardless of the setting of EnableValhalla..  Note that additional changes may be needed in the future depending on how method <init> and possibly <new> are defined in future JVM Specs.
> 
> The fix was tested by running the JCK lang and VM tests and Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From hseigel at openjdk.java.net  Fri Jul 30 17:27:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 30 Jul 2021 17:27:44 GMT
Subject: [lworld] RFR: 8271536: [lworld] VerifyError in
 hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
In-Reply-To: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>
References: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>
Message-ID: <0L9xfMEod238soIypnVmmptmF_VjozAMcdnPQ-TMYU8=.473bbc9c-9a69-450c-b321-9a68c297fd03@github.com>

On Fri, 30 Jul 2021 17:14:42 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8271536.  The fix throws a ClassFormatError exception for methods named <init> if they have a non-void function return type that is a basic primitive type, such as D or I regardless of the setting of EnableValhalla..  Note that additional changes may be needed in the future depending on how method <init> and possibly <new> are defined in future JVM Specs.
> 
> The fix was tested by running the JCK lang and VM tests and Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

Thanks Fred for the review and off-line discussion!

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

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


From hseigel at openjdk.java.net  Fri Jul 30 17:27:45 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 30 Jul 2021 17:27:45 GMT
Subject: [lworld] Integrated: 8271536: [lworld] VerifyError in
 hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java
In-Reply-To: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>
References: <whX0zD6SWj1r1tSllCmFZmFCwyPw4FAu2SKBbOjCmrU=.35e22837-51ca-4103-b2c6-e5176edab162@github.com>
Message-ID: <w0oJd8D9v78LPwuQDhNOly3Jtkg2eHvTHo902QuZVIE=.32a0ff59-2743-4636-9e00-c035298e0c60@github.com>

On Fri, 30 Jul 2021 17:14:42 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8271536.  The fix throws a ClassFormatError exception for methods named <init> if they have a non-void function return type that is a basic primitive type, such as D or I regardless of the setting of EnableValhalla..  Note that additional changes may be needed in the future depending on how method <init> and possibly <new> are defined in future JVM Specs.
> 
> The fix was tested by running the JCK lang and VM tests and Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: ecca7a00
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ecca7a000cc9aa7a18f512b00d2d371f8f944de7
Stats:     8 lines in 1 file changed: 5 ins; 0 del; 3 mod

8271536: [lworld] VerifyError in hotspot/jtreg/runtime/classFileParserBug/NameAndTypeSig.java

Reviewed-by: fparain

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

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