From brian.goetz at oracle.com  Sat Aug  1 15:01:34 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 1 Aug 2020 11:01:34 -0400
Subject: Fwd: no good default responsibility
In-Reply-To: <CAM-fARdLh8w__WdVCyOsuJDsZLDSmwa6v+7f3tsEvHiM_s3isQ@mail.gmail.com>
References: <CAM-fARdLh8w__WdVCyOsuJDsZLDSmwa6v+7f3tsEvHiM_s3isQ@mail.gmail.com>
Message-ID: <d3b4851b-22e3-de11-ac34-4408a7e077e6@oracle.com>

This was received on the -spec-comments list but wasn't really on-topic 
for that list.? Moving to amber-dev.? (It is technically slightly 
outside the charter for -dev too, but it is such a reasonable and 
constructively asked question, that it is better to allow it.)


One of the reasons this conversation has been so difficult is that it is 
not always obvious where the boundary of responsibility between VM, 
language, and developer ought to be.

<digression>
C took the position of not initializing variables for you.? You can 
imagine the discussion; "why should the compiler overwrite this with 
zeros, when it is really the developer's responsibility to put valid 
data there?? And it would be inefficient to write it with zeros, and 
then have the developer immediately overwrite it 99.9% of the time. 
Let's make this the developer's responsibility."

In 1972, this might have been a reasonable position; computers were 
pretty slow, and redundantly initializing memory just because some lazy 
programmer forgot to initialize their variables was viewed as an 
unaffordable luxury.? (Worse, you can easily imagine someone arguing the 
moral hazard here: "this will just encourage programmers to be lazy, 
knowing that the language will save them!")? And, there were only about 
six (exaggerating for effect) programmers in the world, and they were 
all super-careful, since they had learned to program by writing their 
programs on Fortran coding sheets and quadruple-checking them at the 
desk before they dared to consume any machine time.

In hindsight, this didn't go very well (e.g., buffer overruns.)? The 
moral of the story is, it's easy to convince oneself that the 
responsibility belongs on one specific side of the line, but sometimes 
things have a way of not staying within the boxes you draw for them.
</digression>

It is easy to call these "business logic constraints" and say that it is 
not the VMs (or languages) problem, but if the language becomes so 
unreliable that it is hard to code correctly, then we will have the same 
problem C has with buffer overruns; while it is theoretically possible 
to prevent them by good practices, in practice, it does not seem to be, 
and so C gets tarred with the "C is insecure" brush.? We don't want Java 
tarred with that brush, so it is worth spending what might seem like an 
exorbitant amount of time puzzling through the right way to handle 
this.? And our thinking may evolve over time, as it has here.

Let's say we have a class:

 ??? inline record StringHolder(String s) {
 ??????? String s;

 ??????? int length() { return s.length(); }
 ??? }

If we have an uninitialized StringHolder, and someone passes that to 
some other method, and then that method calls lenght() on it, it will 
NPE.? Just as with the buffer overrun, it is unreasonable to expect that 
every developer will remember to check for nulls in methods like 
length().? (And, we wouldn't want them to; that would be a waste.)

What we want to do is help developers model their domains accurately.? 
For many domains (e.g., numbers), a zero default is entirely sensible, 
and our job is done.? But for some domains, there really is no good 
default.? So what should happen?? Let the nulls fly, and assume that 
they will be caught by an NPE eventually?? As much as `null` is 
considered by many to be a mistake, Java's fail-fast behavior with null 
dereference is clearly a feature, not a bug.? Having an exception at the 
precise point where the bad data was consumed is a good thing, rather 
than letting it flow into some other calculation and maybe blow up far 
away.? So the question being considered is whether we should work harder 
to align (in the case that the default is considered no good) 
default-dereference with null-dereference, and catch the error in the 
above code before the call to length().

Your conclusion: "maybe it is best to just keep the zero default", might 
in fact be the right answer in the end.? But enough people are 
uncomfortable enough about this, that it's worth discussing it more.




-------- Forwarded Message --------
Subject: 	no good default responsibility
Date: 	Fri, 31 Jul 2020 23:25:04 -0400
From: 	Jack Ammo <jackammo77 at gmail.com>
To: 	valhalla-spec-comments at openjdk.java.net



i have a question about the issue. is it the jvm's responsibility to deal
with initializing inline objects to a "valid" state or is it the compiler's
responsibility to enforce the business logic of what is and isnt a valid
state for the inline object?

in my view, the "good default" problem is really the language's problem and
by extension, the language's compilers' problem. the jvm doesn't define
what the purpose or usage is for a Date object or a String object or an
int. it doesn't say if an empty String is valid for a name field or if -1
is valid for count field. Those are business logic constraints, no?

Maybe it's best for the jvm to just keep the all zero default, and if the
compiler wishes, it can immediately reassign the appropriate default as
needed. As long the inline object can be re-assigned cheaply, maybe that's
as far as the jvm needs to go?


From sadayapalam at openjdk.java.net  Mon Aug  3 04:45:37 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 Aug 2020 04:45:37 GMT
Subject: [lworld] RFR: JDK-8244315 [lworld] The hierarchy between V$ref
 and V$val must be sealed
In-Reply-To: <vTZLiXcBT2sTrAMhcxdYP9Y2AxCwTiWzysJnczPUNJo=.54ac6d99-233a-4ed3-856e-09684cdf838f@github.com>
References: <vTZLiXcBT2sTrAMhcxdYP9Y2AxCwTiWzysJnczPUNJo=.54ac6d99-233a-4ed3-856e-09684cdf838f@github.com>
Message-ID: <BtA2WLZaMJ4nAgg42uZq4-9X6lq7mFoqghhxvQBQaq8=.5369ef46-d51b-4561-a92d-caa690e6ad20@github.com>

On Wed, 29 Jul 2020 17:10:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> - Remove final flag from V$ref.
> - Set V$ref as SEALED.
> - Add value V$val to list of V$ref's permitted classes.
> 
> Test ensures that the permitted classes of Point$ref is exactly Point$val ("Point").

Looks good, Let me know if you have trouble integrating this.

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

Marked as reviewed by sadayapalam (Committer).

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


From sadayapalam at openjdk.java.net  Mon Aug  3 05:20:04 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 Aug 2020 05:20:04 GMT
Subject: [lworld] RFR: JDK-8244314 [lworld] V.ref and V.val are supposed
 to be nest mates
In-Reply-To: <gRHOV5idDviiPfMryZn6SVw4jz92qywDaqVPu0uP05I=.75bc97e5-74dc-41b6-b90c-e8f665cc60a7@github.com>
References: <gRHOV5idDviiPfMryZn6SVw4jz92qywDaqVPu0uP05I=.75bc97e5-74dc-41b6-b90c-e8f665cc60a7@github.com>
Message-ID: <vzJhA9dgTHJ4RRsWsV7D3QBkbO-VnpP_OdZT5fdH2GI=.7893f56b-42f1-4391-be10-6685d5d7d384@github.com>

On Wed, 29 Jul 2020 17:17:13 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> - Reworked nest list to use LinkedHashSet (had unnecessary step.)
> - Only attempt to add nested members if set is non-empty.
> - If top level and an inline class don't use as host, use referenceProjection instead.
> - If top level and an inline class do add as a nest member.
> 
> Test ensures that the correct host (Point$ref)  is selected and that nest members are exactly just Point$val ("Point").

Looks good, Thanks Jim!

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

Marked as reviewed by sadayapalam (Committer).

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


From thartmann at openjdk.java.net  Mon Aug  3 06:51:43 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 3 Aug 2020 06:51:43 GMT
Subject: [lworld] RFR: 8250234: [lworld] [lw3]
 jdk/valhalla/valuetypes/SubstitutabilityTest.java fails with C1
In-Reply-To: <350jmQMh9Fy4KPxlCkMczLiggZHR3J9bwjana-Aqj58=.8ccbed77-0872-4d77-8235-dbc8cdcc0e71@github.com>
References: <350jmQMh9Fy4KPxlCkMczLiggZHR3J9bwjana-Aqj58=.8ccbed77-0872-4d77-8235-dbc8cdcc0e71@github.com>
Message-ID: <sxh-aurgm7jk5AebI61Zf3wkEuUjJpGrUC_rdQC7B8E=.471ad905-71de-457c-9e2e-ab6d8e0fe7f2@github.com>

On Fri, 31 Jul 2020 14:10:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small changes to fix a bug in C1 transformations which cause an acmp involving inline types to be
> translated into a pointer comparison instead of a substitutability test. The patch also includes a few fixes in C1
> debugging features.
> Thank you.
> 
> Fred

Looks good to me. Thanks for fixing!

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

Marked as reviewed by thartmann (Committer).

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


From sadayapalam at openjdk.java.net  Mon Aug  3 08:12:00 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 Aug 2020 08:12:00 GMT
Subject: [lworld] Integrated: 8222784: [lworld] Remove stale compiler option:
 -XDallowGenericsOverValues
Message-ID: <qZYxIm1HFCRPh2R-N_o4gcedc3hPW6fhPHYSWqR5Oks=.9e8cd73a-fc44-422f-a002-240c1aea527d@github.com>

Update tests not to use this garbage collected option

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

Commit messages:
 - 8222784: [lworld] Remove stale compiler option: -XDallowGenericsOverValues

Changes: https://git.openjdk.java.net/valhalla/pull/129/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/129/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8222784
  Stats: 52 lines in 3 files changed: 50 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/129.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/129/head:pull/129

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


From sadayapalam at openjdk.java.net  Mon Aug  3 08:12:00 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 Aug 2020 08:12:00 GMT
Subject: [lworld] Integrated: 8222784: [lworld] Remove stale compiler option:
 -XDallowGenericsOverValues
In-Reply-To: <qZYxIm1HFCRPh2R-N_o4gcedc3hPW6fhPHYSWqR5Oks=.9e8cd73a-fc44-422f-a002-240c1aea527d@github.com>
References: <qZYxIm1HFCRPh2R-N_o4gcedc3hPW6fhPHYSWqR5Oks=.9e8cd73a-fc44-422f-a002-240c1aea527d@github.com>
Message-ID: <16d8qTX33OPMWvii5-Y0d86qAE_PFiNUZJeg3luxeTE=.e585b1b7-9c3f-4fdc-bb14-fe8750ac9280@github.com>

On Mon, 3 Aug 2020 07:53:32 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Update tests not to use this garbage collected option

This pull request has now been integrated.

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

8222784: [lworld] Remove stale compiler option: -XDallowGenericsOverValues

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

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


From thartmann at openjdk.java.net  Mon Aug  3 10:05:47 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 3 Aug 2020 10:05:47 GMT
Subject: [lworld] RFR: 8250951: [lworld] Escape analysis fails due to oop
 access to flat array
Message-ID: <0cndGM219BqxP7cbJAV7rWZYKpB03tYmNLmFZZK7VRs=.ed801dc2-5802-4f34-aa16-3ee1ffb3f7dd@github.com>

When storing null, C2 should only mark array as not-flat after the null-check.

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

Commit messages:
 - 8250951: [lworld] Escape analysis fails due to oop access to flat array

Changes: https://git.openjdk.java.net/valhalla/pull/130/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/130/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250951
  Stats: 13 lines in 1 file changed: 4 ins; 2 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/130/head:pull/130

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


From thartmann at openjdk.java.net  Mon Aug  3 10:44:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 3 Aug 2020 10:44:18 GMT
Subject: [lworld] Integrated: 8250951: [lworld] Escape analysis fails due to
 oop access to flat array
In-Reply-To: <0cndGM219BqxP7cbJAV7rWZYKpB03tYmNLmFZZK7VRs=.ed801dc2-5802-4f34-aa16-3ee1ffb3f7dd@github.com>
References: <0cndGM219BqxP7cbJAV7rWZYKpB03tYmNLmFZZK7VRs=.ed801dc2-5802-4f34-aa16-3ee1ffb3f7dd@github.com>
Message-ID: <LK_wBQh3QBpUJcOTMHXim1jcJ1pb5-n_E8-Et7CZ4xk=.c4c0d4a6-c4e2-4244-9873-b8c259340a90@github.com>

On Mon, 3 Aug 2020 09:45:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When storing null, C2 should only mark array as not-flat after the null-check.

This pull request has now been integrated.

Changeset: 6e6d0c71
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/6e6d0c71
Stats:     13 lines in 1 file changed: 2 ins; 4 del; 7 mod

8250951: [lworld] Escape analysis fails due to oop access to flat array

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

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


From sadayapalam at openjdk.java.net  Tue Aug  4 10:52:58 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 4 Aug 2020 10:52:58 GMT
Subject: [lworld] Integrated: 8221323: [lworld] Javac should support class
 literals for projection types.
Message-ID: <0z2AO5CTiMlpgcoKK5gsSq-qadImiiXDTI4tYn-oV10=.b00d5535-1601-4b25-88b9-eb75a05e849c@github.com>

Allow V.class, V.ref.class and V.val.class

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

Commit messages:
 - 8221323: [lworld] Javac should support class literals for projection types.

Changes: https://git.openjdk.java.net/valhalla/pull/132/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/132/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8221323
  Stats: 52 lines in 4 files changed: 50 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/132/head:pull/132

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


From sadayapalam at openjdk.java.net  Tue Aug  4 10:52:58 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 4 Aug 2020 10:52:58 GMT
Subject: [lworld] Integrated: 8221323: [lworld] Javac should support class
 literals for projection types.
In-Reply-To: <0z2AO5CTiMlpgcoKK5gsSq-qadImiiXDTI4tYn-oV10=.b00d5535-1601-4b25-88b9-eb75a05e849c@github.com>
References: <0z2AO5CTiMlpgcoKK5gsSq-qadImiiXDTI4tYn-oV10=.b00d5535-1601-4b25-88b9-eb75a05e849c@github.com>
Message-ID: <UMv7BgGF5eDgCtGEFbFUhpdr34D6t8qJhF9b6iiN4qM=.a02d7744-b52f-478d-8fff-36b7cf10a770@github.com>

On Tue, 4 Aug 2020 10:39:14 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Allow V.class, V.ref.class and V.val.class

This pull request has now been integrated.

Changeset: 72b3046c
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/72b3046c
Stats:     52 lines in 4 files changed: 0 ins; 50 del; 2 mod

8221323: [lworld] Javac should support class literals for projection types.

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

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


From jlaskey at openjdk.java.net  Tue Aug  4 11:57:24 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 4 Aug 2020 11:57:24 GMT
Subject: [lworld] Integrated: JDK-8244314 [lworld] V.ref and V.val are
 supposed to be nest mates
In-Reply-To: <gRHOV5idDviiPfMryZn6SVw4jz92qywDaqVPu0uP05I=.75bc97e5-74dc-41b6-b90c-e8f665cc60a7@github.com>
References: <gRHOV5idDviiPfMryZn6SVw4jz92qywDaqVPu0uP05I=.75bc97e5-74dc-41b6-b90c-e8f665cc60a7@github.com>
Message-ID: <bE9mNY00DQkBT6kxdnvMqxemGaEdYVE0LpQXuQ7devM=.c13076e4-a790-4ea7-84f8-d22345e1a1d6@github.com>

On Wed, 29 Jul 2020 17:17:13 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> - Reworked nest list to use LinkedHashSet (had unnecessary step.)
> - Only attempt to add nested members if set is non-empty.
> - If top level and an inline class don't use as host, use referenceProjection instead.
> - If top level and an inline class do add as a nest member.
> 
> Test ensures that the correct host (Point$ref)  is selected and that nest members are exactly just Point$val ("Point").

This pull request has now been integrated.

Changeset: 5305fbdd
Author:    Jim Laskey <jlaskey at openjdk.org>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/5305fbdd
Stats:     85 lines in 2 files changed: 2 ins; 72 del; 11 mod

8244314: [lworld] V.ref and V.val are supposed to be nest mates

Reviewed-by: sadayapalam

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

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


From thartmann at openjdk.java.net  Tue Aug  4 12:37:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 4 Aug 2020 12:37:07 GMT
Subject: [lworld] RFR: 8250962: [lworld] C2 should not replace redundant
 scalar replaceable allocations
Message-ID: <2LzkNdX6SMWu0mYzSdN0yjGEpHcc1MXy1FClM8cwvXI=.2178bfb1-b0e9-49a7-8170-f7c48d75a3bd@github.com>

When searching for multiple allocations of an inline type, ignore scalar replaceable ones because they will be removed
anyway and changing the memory chain will confuse other optimizations.

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

Commit messages:
 - 8250962: [lworld] C2 should not replace redundant scalar replaceable allocations

Changes: https://git.openjdk.java.net/valhalla/pull/133/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/133/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250962
  Stats: 9 lines in 1 file changed: 2 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/133.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/133/head:pull/133

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


From thartmann at openjdk.java.net  Tue Aug  4 12:44:10 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 4 Aug 2020 12:44:10 GMT
Subject: [lworld] RFR: 8242453: [lworld] C2 compilation fails with assert
 'correct memory chain'
Message-ID: <o0kBsdRyt2-GDtd9Trn8QF_sdXjqQwrgq8rKXRb5gkM=.13fa1afe-eec9-4b6d-a67e-d58212285d97@github.com>

Relax the assert in MemNode::optimize_memory_chain because loads from a non-flat array can be pushed through an
arraycopy from a flat array (see LoadNode::can_see_arraycopy_value) and end up with an inconsistent memory input (oop
load from flat array). The checks emitted for the arraycopy will catch this and the load will be removed but
optimize_memory_chain() can still be executed before that happens.

Other options to fix this will be evaluated with JDK-8251039.

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

Commit messages:
 - 8242453: [lworld] C2 compilation fails with assert 'correct memory chain'

Changes: https://git.openjdk.java.net/valhalla/pull/134/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/134/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242453
  Stats: 70 lines in 5 files changed: 50 ins; 5 del; 15 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/134.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/134/head:pull/134

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


From jlaskey at openjdk.java.net  Tue Aug  4 13:10:30 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 4 Aug 2020 13:10:30 GMT
Subject: [lworld] Integrated: JDK-8244315 [lworld] The hierarchy between V$ref
 and V$val must be sealed
In-Reply-To: <vTZLiXcBT2sTrAMhcxdYP9Y2AxCwTiWzysJnczPUNJo=.54ac6d99-233a-4ed3-856e-09684cdf838f@github.com>
References: <vTZLiXcBT2sTrAMhcxdYP9Y2AxCwTiWzysJnczPUNJo=.54ac6d99-233a-4ed3-856e-09684cdf838f@github.com>
Message-ID: <Tt5-OgKeVDGWXuF03ixoxNcOm3QW6waOtm6FxFn_WFg=.bf6180de-2176-4205-9882-2fc27e219016@github.com>

On Wed, 29 Jul 2020 17:10:15 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> - Remove final flag from V$ref.
> - Set V$ref as SEALED.
> - Add value V$val to list of V$ref's permitted classes.
> 
> Test ensures that the permitted classes of Point$ref is exactly Point$val ("Point").

This pull request has now been integrated.

Changeset: e473d9d4
Author:    Jim Laskey <jlaskey at openjdk.org>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e473d9d4
Stats:     51 lines in 2 files changed: 0 ins; 50 del; 1 mod

8244315: [lworld] The hierarchy between V$ref and V$val must be sealed

Reviewed-by: sadayapalam

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

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


From thartmann at openjdk.java.net  Tue Aug  4 14:01:44 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 4 Aug 2020 14:01:44 GMT
Subject: [lworld] Integrated: 8250962: [lworld] C2 should not replace
 redundant scalar replaceable allocations
In-Reply-To: <2LzkNdX6SMWu0mYzSdN0yjGEpHcc1MXy1FClM8cwvXI=.2178bfb1-b0e9-49a7-8170-f7c48d75a3bd@github.com>
References: <2LzkNdX6SMWu0mYzSdN0yjGEpHcc1MXy1FClM8cwvXI=.2178bfb1-b0e9-49a7-8170-f7c48d75a3bd@github.com>
Message-ID: <3HXdaUmnrHCWuOUHrgPkNrSbpP0J11xpdvuh-ew5SF4=.20c9ba32-1bc0-4c39-b010-9a2e2858221a@github.com>

On Tue, 4 Aug 2020 12:31:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When searching for multiple allocations of an inline type, ignore scalar replaceable ones because they will be removed
> anyway and changing the memory chain will confuse other optimizations.

This pull request has now been integrated.

Changeset: ef1a221f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ef1a221f
Stats:     9 lines in 1 file changed: 1 ins; 2 del; 6 mod

8250962: [lworld] C2 should not replace redundant scalar replaceable allocations

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

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


From thartmann at openjdk.java.net  Tue Aug  4 14:22:45 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 4 Aug 2020 14:22:45 GMT
Subject: [lworld] Integrated: 8242453: [lworld] C2 compilation fails with
 assert 'correct memory chain'
In-Reply-To: <o0kBsdRyt2-GDtd9Trn8QF_sdXjqQwrgq8rKXRb5gkM=.13fa1afe-eec9-4b6d-a67e-d58212285d97@github.com>
References: <o0kBsdRyt2-GDtd9Trn8QF_sdXjqQwrgq8rKXRb5gkM=.13fa1afe-eec9-4b6d-a67e-d58212285d97@github.com>
Message-ID: <uMNngMWjDSaDFaw69uc2nrdOSjZyiB4X0OLRkZ-nwbU=.20be6684-1a30-4323-bbf8-35c9ad8ec664@github.com>

On Tue, 4 Aug 2020 12:39:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Relax the assert in MemNode::optimize_memory_chain because loads from a non-flat array can be pushed through an
> arraycopy from a flat array (see LoadNode::can_see_arraycopy_value) and end up with an inconsistent memory input (oop
> load from flat array). The checks emitted for the arraycopy will catch this and the load will be removed but
> optimize_memory_chain() can still be executed before that happens.  Other options to fix this will be evaluated with
> JDK-8251039.

This pull request has now been integrated.

Changeset: 448aaa0a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/448aaa0a
Stats:     70 lines in 5 files changed: 5 ins; 50 del; 15 mod

8242453: [lworld] C2 compilation fails with assert 'correct memory chain'

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

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


From jlaskey at openjdk.java.net  Tue Aug  4 17:57:14 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 4 Aug 2020 17:57:14 GMT
Subject: [lworld] RFR: JDK 8251107 [lworld] test
 lworld-values/TopInterfaceNegativeTest.java needs scrubbing
Message-ID: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>

Test was somewhat out of date and still using InlineObject.

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

Commit messages:
 - JDK-8251107 [lworld] test lworld-values/TopInterfaceNegativeTest.java needs scrubbing
 - JDK-8251107 [lworld] test lworld-values/TopInterfaceNegativeTest.java needs scrubbing

Changes: https://git.openjdk.java.net/valhalla/pull/135/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/135/webrev.00
  Stats: 15 lines in 2 files changed: 1 ins; 7 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/135.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/135/head:pull/135

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


From sadayapalam at openjdk.java.net  Wed Aug  5 05:10:45 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 Aug 2020 05:10:45 GMT
Subject: [lworld] RFR: JDK 8251107 [lworld] test
 lworld-values/TopInterfaceNegativeTest.java needs scrubbing
In-Reply-To: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>
References: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>
Message-ID: <isbxm-5vn3ujFIekQGVrzjQd41lH-c_RtDUF7kr8e4o=.5144938d-3cf7-415a-a4aa-049246d44f15@github.com>

On Tue, 4 Aug 2020 17:49:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Test was somewhat out of date and still using InlineObject.

I think the test still using the withdrawn InlineObject is a red herring. The golden files account for this already and
capture suitable errors for those uses of the non-existent interface.

The real trouble is due to an error NOT being emitted in line 33 of the TopInterfaceNegativeTest.java:

Given:

static inline class V2 implements InlineObject {}

void foo(V2 v) {
        if (v instanceof IdentityObject)  // line 33
            throw new AssertionError("Expected inline object but found identity object");
    }

v instanceof IdentityObject is patently false and can be ascertained at compile time to be patently false thereby
resulting an error message:

TopInterfaceNegativeTest.java:33:13: compiler.err.prob.found.req: (compiler.misc.inconvertible.types:
TopInterfaceNegativeTest.V2, java.lang.IdentityObject)

Given 'v' is type V2 and that is a final class, we known all the interfaces implemented by v and so can evaluate at
compile time whether the instanceof is patently bogus -

Now with the change for sealing of projections, this error is not emitted anymore and that is the reason for the
failure.

The error is valid and should be restored.

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

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


From sadayapalam at openjdk.java.net  Wed Aug  5 05:15:26 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 Aug 2020 05:15:26 GMT
Subject: [lworld] RFR: JDK 8251107 [lworld] test
 lworld-values/TopInterfaceNegativeTest.java needs scrubbing
In-Reply-To: <isbxm-5vn3ujFIekQGVrzjQd41lH-c_RtDUF7kr8e4o=.5144938d-3cf7-415a-a4aa-049246d44f15@github.com>
References: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>
 <isbxm-5vn3ujFIekQGVrzjQd41lH-c_RtDUF7kr8e4o=.5144938d-3cf7-415a-a4aa-049246d44f15@github.com>
Message-ID: <JHrzVIVvuGfe9R1MSAFA8vS5_0ABPfmeLKAXabM-dG0=.3fe507d5-9785-4605-bc18-24a157221425@github.com>

On Wed, 5 Aug 2020 05:08:27 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Test was somewhat out of date and still using InlineObject.
>
> I think the test still using the withdrawn InlineObject is a red herring. The golden files account for this already and
> capture suitable errors for those uses of the non-existent interface.
> The real trouble is due to an error NOT being emitted in line 33 of the TopInterfaceNegativeTest.java:
> 
> Given:
> 
> static inline class V2 implements InlineObject {}
> 
> void foo(V2 v) {
>         if (v instanceof IdentityObject)  // line 33
>             throw new AssertionError("Expected inline object but found identity object");
>     }
> 
> v instanceof IdentityObject is patently false and can be ascertained at compile time to be patently false thereby
> resulting an error message:
> TopInterfaceNegativeTest.java:33:13: compiler.err.prob.found.req: (compiler.misc.inconvertible.types:
> TopInterfaceNegativeTest.V2, java.lang.IdentityObject)
> Given 'v' is type V2 and that is a final class, we known all the interfaces implemented by v and so can evaluate at
> compile time whether the instanceof is patently bogus -
> Now with the change for sealing of projections, this error is not emitted anymore and that is the reason for the
> failure.
> The error is valid and should be restored.

Here is a smaller test case: without the change for sealing this elicits an error

public inline class X {
    boolean b = new X() instanceof IdentityObject;
}

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

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


From sadayapalam at openjdk.java.net  Wed Aug  5 05:48:45 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 Aug 2020 05:48:45 GMT
Subject: [lworld] RFR: JDK 8251107 [lworld] test
 lworld-values/TopInterfaceNegativeTest.java needs scrubbing
In-Reply-To: <JHrzVIVvuGfe9R1MSAFA8vS5_0ABPfmeLKAXabM-dG0=.3fe507d5-9785-4605-bc18-24a157221425@github.com>
References: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>
 <isbxm-5vn3ujFIekQGVrzjQd41lH-c_RtDUF7kr8e4o=.5144938d-3cf7-415a-a4aa-049246d44f15@github.com>
 <JHrzVIVvuGfe9R1MSAFA8vS5_0ABPfmeLKAXabM-dG0=.3fe507d5-9785-4605-bc18-24a157221425@github.com>
Message-ID: <fZBExECrpHev0vohfKeAEbcpjCy2me20CR1uuisbVXk=.624b5784-ec61-4d41-9746-3497c6f699c0@github.com>

On Wed, 5 Aug 2020 05:13:07 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> I think the test still using the withdrawn InlineObject is a red herring. The golden files account for this already and
>> capture suitable errors for those uses of the non-existent interface.
>> The real trouble is due to an error NOT being emitted in line 33 of the TopInterfaceNegativeTest.java:
>> 
>> Given:
>> 
>> static inline class V2 implements InlineObject {}
>> 
>> void foo(V2 v) {
>>         if (v instanceof IdentityObject)  // line 33
>>             throw new AssertionError("Expected inline object but found identity object");
>>     }
>> 
>> v instanceof IdentityObject is patently false and can be ascertained at compile time to be patently false thereby
>> resulting an error message:
>> TopInterfaceNegativeTest.java:33:13: compiler.err.prob.found.req: (compiler.misc.inconvertible.types:
>> TopInterfaceNegativeTest.V2, java.lang.IdentityObject)
>> Given 'v' is type V2 and that is a final class, we known all the interfaces implemented by v and so can evaluate at
>> compile time whether the instanceof is patently bogus -
>> Now with the change for sealing of projections, this error is not emitted anymore and that is the reason for the
>> failure.
>> The error is valid and should be restored.
>
> Here is a smaller test case: without the change for sealing this elicits an error
> 
> public inline class X {
>     boolean b = new X() instanceof IdentityObject;
> }

Here is some analysis:

Earlier on, the reference projection type was incorrectly being marked as final. The fix for JDK- 8244315 correctly
removes the final modifier from V$ref.class.

While compiling the expression new X() instanceof IdentityObject we ask if X is castable to IdentityObject - if not
reject the instanceof as being implausible.

In isCastable TypeRelation visitor, in visitClassType visitor method circa line 1754 in Types.java is this crucial
block of code:

                 if (isValue(t)) {
                        // (s) Value ? == (s) Value.ref
                        t = t.referenceProjection();
                    }
This basically says whether a value instance is castable to type S is to be answered by asking whether its reference
projection is castable to S.  This switch is needed because down below we are going to be checking subtyping
relationships and inlines types are islands - they will answer false to any subtyping question - inline types are not
subtypes of j.l.O; they are not even subtypes of the interfaces they implement !!!

Reference: http://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
nterfaces
Historically, for a class to implement an interface meant several things:

Conformance. The class has, as members, all the members of the interface.
Transitivity. Any subclasses of this class also implement the interface.
Subtyping. The class type is a subtype of the interface type.
We need to refine this last bullet, subtyping, in a small way to support inline classes; we say that the reference
projection of the inline class is a subtype of the interface type. (Identity class types are their own reference
projection, so this statement holds for all classes.) Similarly, if an inline class extends an abstract class, this
means that the reference projection is a subtype of the abstract class.
 
Now we have effectively transformed the question of whether X implements IdentityObject into whether X$ref implements
IdentityObject

And X$ref being final earlier (incorrectly) vs being non-final class now makes a material difference down below in this
block, circa  line 1818 in Types.java:
// Sidecast
                    if (s.hasTag(CLASS)) {
                        if ((s.tsym.flags() & INTERFACE) != 0) {
                            return ((t.tsym.flags() & FINAL) == 0)
                                ? sideCast(t, s, warnStack.head)
                                : sideCastFinal(t, s, warnStack.head);
                        } else if ((t.tsym.flags() & INTERFACE) != 0) {
                            return ((s.tsym.flags() & FINAL) == 0)
                                ? sideCast(t, s, warnStack.head)
                                : sideCastFinal(t, s, warnStack.head);
                        } else {
                            // unrelated class types
                            return false;
                        }
                    }


What used to be checked with sideCastFinal now gets checked with sideCast yielding a different result.

The key to the fix may be to take advantage of the fact that the set of interfaces implemented by the reference
projection is identical to that of the value projection.

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

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


From thartmann at openjdk.java.net  Wed Aug  5 08:48:58 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 5 Aug 2020 08:48:58 GMT
Subject: [lworld] Integrated: 8250877: [lworld] Remove special acmp handling
 for isSubstitutable0 method in the JIT
In-Reply-To: <m7686gF3T0oKCiAHLDCRrMBxqUEMQCwjAl5nZpPQWVE=.b4903d3b-8309-4128-bf79-7bbc352b4ac9@github.com>
References: <m7686gF3T0oKCiAHLDCRrMBxqUEMQCwjAl5nZpPQWVE=.b4903d3b-8309-4128-bf79-7bbc352b4ac9@github.com>
Message-ID: <p-aThP9NhVAE6QErZUuphqvpiEIp2pa7CfYzX4-xYfE=.3b44add6-e40b-447a-8812-16846373f446@github.com>

On Fri, 31 Jul 2020 08:35:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The isSubstitutable0 Java method called by the VM to perform a substitutability test does not perform == on its
> arguments. Special casing can be removed from the JIT.

This pull request has now been integrated.

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

8250877: [lworld] Remove special acmp handling for isSubstitutable0 method in the JIT

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

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


From dsimms at openjdk.java.net  Wed Aug  5 11:39:13 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 5 Aug 2020 11:39:13 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types
Message-ID: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>

Use ValueBootstrapMethods for Object::hashCode()

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

Commit messages:
 - 8244975: [lworld] Investigate if VM can implement Object::hashCode by calling ValueBootstrapMethods for inline types

Changes: https://git.openjdk.java.net/valhalla/pull/136/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/136/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244975
  Stats: 77 lines in 7 files changed: 70 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/136/head:pull/136

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


From fparain at openjdk.java.net  Wed Aug  5 13:19:30 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 5 Aug 2020 13:19:30 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible
Message-ID: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>

Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
The CR linked below contains a more detailed description of the optimization:

CR: https://bugs.openjdk.java.net/browse/JDK-8251046

A rudimentary benchmark shows encouraging numbers:
Measuring inline type creation time with -XX:TieredStopAtLevel=1
Inline class Point has two int fields.
Inline class Rectangle has four int fields.

Without the optimization:
Benchmark                                Mode  Samples   Score  Score error  Units
o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op

With the optimization:
Benchmark                                Mode  Samples  Score  Score error  Units
o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op

Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).

Thank you,

Fred

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

Commit messages:
 - Remove macros and add unit test
 - Add case of two aloads
 - Rebase needed renaming
 - Optimize the dup_x2/pop pattern
 - Optimize withfield with larva state
 - Fixing C1 debug features

Changes: https://git.openjdk.java.net/valhalla/pull/137/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/137/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251046
  Stats: 232 lines in 5 files changed: 147 ins; 57 del; 28 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/137/head:pull/137

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


From mchung at openjdk.java.net  Wed Aug  5 19:39:40 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 5 Aug 2020 19:39:40 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <Ga__Nx6jzmkiYMNpuPcrb1y0nD5HkR-6dZwugif2zGk=.5a31ea71-1252-424b-9c67-cc22ed6863ab@github.com>

On Wed, 5 Aug 2020 11:32:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use ValueBootstrapMethods for Object::hashCode()

src/java.base/share/classes/java/lang/invoke/ValueBootstrapMethods.java line 486:

> 485:         @Override protected MethodHandle computeValue(Class<?> type) {
> 486:             return MethodHandleBuilder.hashCodeForType(type);
> 487:         }

@MrSimms thanks for working on this.

I expect this to call the existing `hashCodeInvoker` if the type is an inline type.   `hashCodeForType` is the method
handle invoking `java.util.Objects::hashCode`.   The existing `hashCodeInvoker` should be changed to take `Class<?>
type` once javac no longer generates `equals` and `hashCode` method for inline type.

Maybe I should take this patch and make the coordinated changes??

src/hotspot/share/runtime/globals.hpp line 2474:

> 2473:                                                                             \
> 2474:   product(bool, InlineTypeIHashCodeViaMethod, true,                         \
> 2475:          "Use generated hashCode for identity hash code")                   \

Do you anticipate this VM flag is needed?

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

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


From github.com+828220+forax at openjdk.java.net  Wed Aug  5 19:56:35 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 5 Aug 2020 19:56:35 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <5Fg-Dqqn6uWzqpZ7zQDKdiT2KvW7Br9nJ5jX61bkQHU=.78b8f136-1565-4050-a63d-21eca2d5394c@github.com>

On Wed, 5 Aug 2020 11:32:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use ValueBootstrapMethods for Object::hashCode()

src/java.base/share/classes/java/lang/invoke/ValueBootstrapMethods.java line 480:

> 479:
> 480:     static <T> MethodHandle hashCodeInvoker(Class<T> type) {
> 481:         return HASHCODE_METHOD_HANDLES.get(type);

the type parameter is not needed, can be:
static MethodHandle hashCodeInvoker(Class<?> type) {

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

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


From thartmann at openjdk.java.net  Thu Aug  6 14:11:43 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 Aug 2020 14:11:43 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible
In-Reply-To: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
Message-ID: <TD2P4Cqi6gZZ_LECxkXu4p_mCVXcjsqOoxq661rAWEc=.aec77ccc-a4f4-41fc-9b61-4b7d3aefe095@github.com>

On Wed, 5 Aug 2020 13:14:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
> The CR linked below contains a more detailed description of the optimization:
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8251046
> 
> A rudimentary benchmark shows encouraging numbers:
> Measuring inline type creation time with -XX:TieredStopAtLevel=1
> Inline class Point has two int fields.
> Inline class Rectangle has four int fields.
> 
> Without the optimization:
> Benchmark                                Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op
> 
> With the optimization:
> Benchmark                                Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op
> 
> Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).
> 
> Thank you,
> 
> Fred

Overall looks good to me, nice improvement! I've added some comments to the code.

src/hotspot/share/c1/c1_Instruction.cpp line 422:

> 421:
> 422:   StoreField::StoreField(Value obj, int offset, ciField* field, Value value, bool is_static,
> 423:              ValueStack* state_before, bool needs_patching)

Indentation should be fixed.

src/hotspot/share/c1/c1_Instruction.cpp line 438:

> 437:
> 438:   StoreIndexed::StoreIndexed(Value array, Value index, Value length, BasicType elt_type, Value value, ValueStack*
> state_before, 439:                bool check_boolean, bool mismatched)

Indentation should be fixed.

src/hotspot/share/c1/c1_GraphBuilder.cpp line 1107:

> 1106:       { Value w = state()->raw_pop();
> 1107:         NewInlineTypeInstance::update_stack_count(w);
> 1108:       }

Wouldn't it be cleaner to use virtual calls on the Value class here?

src/hotspot/share/c1/c1_Instruction.hpp line 1419:

> 1418:   virtual void set_not_larva_anymore() {
> 1419:     _in_larval_state = false; }
> 1420:

No newline needed after "{" or add newline before "}" as well.

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

Changes requested by thartmann (Committer).

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


From jlaskey at openjdk.java.net  Thu Aug  6 16:05:14 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 6 Aug 2020 16:05:14 GMT
Subject: [lworld] Withdrawn: JDK 8251107 [lworld] test
 lworld-values/TopInterfaceNegativeTest.java needs scrubbing
In-Reply-To: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>
References: <8V1IqfLs7N0Dh3e715-AbUcd052jAedNm3ggWqNNQPE=.382cf397-af56-4b45-b4d2-eb81c000c4ec@github.com>
Message-ID: <OHQzqPpui4KymzXWMWt0GvdPszU_J2MpQ4zTHehwr-Q=.bbf87694-00db-4ddf-bbfc-767bf3faf5c1@github.com>

On Tue, 4 Aug 2020 17:49:18 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Test was somewhat out of date and still using InlineObject.

This pull request has been closed without being integrated.

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

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


From dsimms at openjdk.java.net  Fri Aug  7 23:16:56 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 7 Aug 2020 23:16:56 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v2]
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>

> Use ValueBootstrapMethods for Object::hashCode()

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  change javac not to generate equals/hashCode

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/136/files
  - new: https://git.openjdk.java.net/valhalla/pull/136/files/302cad6b..79e9cbcc

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/136/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/136/webrev.00-01

  Stats: 202 lines in 6 files changed: 52 ins; 112 del; 38 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/136/head:pull/136

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


From sadayapalam at openjdk.java.net  Mon Aug 10 06:34:11 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 06:34:11 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v2]
In-Reply-To: <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
Message-ID: <xYAGTwtP2SoMpFpyIQKq_N2nBigmosNywqlFKmQefFI=.4f9e636d-9162-4119-94ef-9031cf024767@github.com>

On Fri, 7 Aug 2020 23:16:56 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Use ValueBootstrapMethods for Object::hashCode()
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change javac not to generate equals/hashCode

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1118:

> 1117:
> 1118:             switch (methodDecl.name.toString()) {
> 1119:                 case "toString":

This switch and the case "toString" should be deleted since it is completely unnecessary. Earlier switch would ensure
that the only way control can flow into this point is when the method concerned is toString() so the check is redundant

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

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


From sadayapalam at openjdk.java.net  Mon Aug 10 06:41:29 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 06:41:29 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v2]
In-Reply-To: <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
Message-ID: <tOOR8-RlmQ2f_BRg4o57JumQy-6NSbOYJYJayIaFQr4=.c447d045-f00a-42e0-842f-b474c383ecb2@github.com>

On Fri, 7 Aug 2020 23:16:56 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Use ValueBootstrapMethods for Object::hashCode()
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change javac not to generate equals/hashCode

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1176:

> 1175:                         final List<Type> parameterTypes = methodDecl.sym.type.getParameterTypes();
> 1176:                         switch (parameterTypes.size()) {
> 1177:                             case 0:

I think this switch should be replaced with if (parameterTypes.size() == 0) - with only one case it reads off to use a
switch.

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

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


From sadayapalam at openjdk.java.net  Mon Aug 10 06:44:36 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 06:44:36 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v2]
In-Reply-To: <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
Message-ID: <mct1vu5_FAflhAEKygAsaT0w4Kh-F7xUkJ6nbWgWOsM=.a456ebac-3e59-46ad-b15a-a356a277cafd@github.com>

On Fri, 7 Aug 2020 23:16:56 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Use ValueBootstrapMethods for Object::hashCode()
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change javac not to generate equals/hashCode

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1196:

> 1195:
> 1196:             if (requireToString) {
> 1197:                 // public String toString() { throw new RuntimeException(message); }

The two statements preceding if (requireToString) viz
make.at(tree.pos);
            // Make a body comprising { throw new RuntimeException(""Internal error: This method must have been replaced by
            javac"); } JCBlock body = make.Block(Flags.SYNTHETIC, List.of(make.Throw(
                    make.NewClass(null,
                            null,
                            make.Ident(names.fromString("RuntimeException")),
                            List.of(make.Literal(CLASS, "Internal error: This method must have been replaced by javac")),
                            null))));

should be folded into the if (requireToString) itself for better readability and encapsulation

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

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


From dsimms at openjdk.java.net  Mon Aug 10 08:31:04 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 Aug 2020 08:31:04 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v2]
In-Reply-To: <tOOR8-RlmQ2f_BRg4o57JumQy-6NSbOYJYJayIaFQr4=.c447d045-f00a-42e0-842f-b474c383ecb2@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <Nn9PM5jiv75iqydHNcehH0cqmyvXtsNk2eO6ptJlpu0=.17391fa1-2f3b-49d0-b406-5c3d9d326aec@github.com>
 <tOOR8-RlmQ2f_BRg4o57JumQy-6NSbOYJYJayIaFQr4=.c447d045-f00a-42e0-842f-b474c383ecb2@github.com>
Message-ID: <4T1mFWe8cCumdMfUF4LPZ-jxF8sqPlu9UxNELiULmYE=.dab593a4-0668-46a8-9af2-33e8cf06416b@github.com>

On Mon, 10 Aug 2020 06:39:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> David Simms has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change javac not to generate equals/hashCode
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1176:
> 
>> 1175:                         final List<Type> parameterTypes = methodDecl.sym.type.getParameterTypes();
>> 1176:                         switch (parameterTypes.size()) {
>> 1177:                             case 0:
> 
> I think this switch should be replaced with if (parameterTypes.size() == 0) - with only one case it reads off to use a
> switch.

Applied comments, thanks !

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java line 1196:
> 
>> 1195:
>> 1196:             if (requireToString) {
>> 1197:                 // public String toString() { throw new RuntimeException(message); }
> 
> The two statements preceding if (requireToString) viz
> make.at(tree.pos);
>             // Make a body comprising { throw new RuntimeException(""Internal error: This method must have been replaced by
>             javac"); } JCBlock body = make.Block(Flags.SYNTHETIC, List.of(make.Throw(
>                     make.NewClass(null,
>                             null,
>                             make.Ident(names.fromString("RuntimeException")),
>                             List.of(make.Literal(CLASS, "Internal error: This method must have been replaced by javac")),
>                             null))));
> 
> should be folded into the if (requireToString) itself for better readability and encapsulation

Applied comments, thanks !

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

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


From dsimms at openjdk.java.net  Mon Aug 10 08:30:59 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 Aug 2020 08:30:59 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v3]
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <iXCSWowYb7Tozbd7Q2O_CpRzDBw9qmIj_EKvFJTgBBo=.10e715fe-7a5d-48fd-bb58-faed52806986@github.com>

> Use ValueBootstrapMethods for Object::hashCode()

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

 - Srikanth's comments on redundant code applied
 - invokeHashCode renamed inlineObjectHashCode
 - Remove InlineTypeIHashCodeViaMethod option
 - Remove whitespace

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/136/files
  - new: https://git.openjdk.java.net/valhalla/pull/136/files/79e9cbcc..c9f96b1d

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/136/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/136/webrev.01-02

  Stats: 46 lines in 10 files changed: 8 ins; 21 del; 17 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/136.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/136/head:pull/136

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


From sadayapalam at openjdk.java.net  Mon Aug 10 09:05:56 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 09:05:56 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v3]
In-Reply-To: <iXCSWowYb7Tozbd7Q2O_CpRzDBw9qmIj_EKvFJTgBBo=.10e715fe-7a5d-48fd-bb58-faed52806986@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <iXCSWowYb7Tozbd7Q2O_CpRzDBw9qmIj_EKvFJTgBBo=.10e715fe-7a5d-48fd-bb58-faed52806986@github.com>
Message-ID: <SkjYIAuZdZTCOH1KfJPx6egnetIJv4oPPqCvL_gIJqU=.8b750fd9-b22f-4677-a25a-11d335e1921d@github.com>

On Mon, 10 Aug 2020 08:30:59 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Use ValueBootstrapMethods for Object::hashCode()
>
> David Simms has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Srikanth's comments on redundant code applied
>  - invokeHashCode renamed inlineObjectHashCode
>  - Remove InlineTypeIHashCodeViaMethod option
>  - Remove whitespace

+1 for javac changes, assuming tests are all green

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

Marked as reviewed by sadayapalam (Committer).

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


From sadayapalam at openjdk.java.net  Mon Aug 10 09:25:22 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 09:25:22 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v3]
In-Reply-To: <SkjYIAuZdZTCOH1KfJPx6egnetIJv4oPPqCvL_gIJqU=.8b750fd9-b22f-4677-a25a-11d335e1921d@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <iXCSWowYb7Tozbd7Q2O_CpRzDBw9qmIj_EKvFJTgBBo=.10e715fe-7a5d-48fd-bb58-faed52806986@github.com>
 <SkjYIAuZdZTCOH1KfJPx6egnetIJv4oPPqCvL_gIJqU=.8b750fd9-b22f-4677-a25a-11d335e1921d@github.com>
Message-ID: <ns8O2wC6guZBY-0qL7WJkWWx_lJhB6jwaDvR2Ep730c=.64d93754-62f1-4e78-9f1e-7b1cc4698ebe@github.com>

On Mon, 10 Aug 2020 09:03:37 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> David Simms has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Srikanth's comments on redundant code applied
>>  - invokeHashCode renamed inlineObjectHashCode
>>  - Remove InlineTypeIHashCodeViaMethod option
>>  - Remove whitespace
>
> +1 for javac changes, assuming tests are all green

There will be follow on work taken up independently for JDK-8244560 - There is still some discussion that needs to
happen for the right behavior when an inline type also happens to be a record, but that can be tackled separately as a
javac work item

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

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


From dsimms at openjdk.java.net  Mon Aug 10 10:39:19 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 Aug 2020 10:39:19 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v3]
In-Reply-To: <SkjYIAuZdZTCOH1KfJPx6egnetIJv4oPPqCvL_gIJqU=.8b750fd9-b22f-4677-a25a-11d335e1921d@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <iXCSWowYb7Tozbd7Q2O_CpRzDBw9qmIj_EKvFJTgBBo=.10e715fe-7a5d-48fd-bb58-faed52806986@github.com>
 <SkjYIAuZdZTCOH1KfJPx6egnetIJv4oPPqCvL_gIJqU=.8b750fd9-b22f-4677-a25a-11d335e1921d@github.com>
Message-ID: <XHRawZj-3eqPPCXxM9JqJEruajFa2DuXB13D4lpDZjQ=.954b8a46-d0f1-4937-b3c1-a6562e55b3f2@github.com>

On Mon, 10 Aug 2020 09:03:37 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> +1 for javac changes, assuming tests are all green

Looks like I did break something:
`ValueModifierTest.java:16:28: compiler.err.override.meth: (compiler.misc.cant.override: toString(),
compiler.misc.anonymous.class: ValueModifierTest$3, toString(), value), final`

rather than .out file:

`ValueModifierTest.java:16:28: compiler.err.override.meth: (compiler.misc.cant.override: hashCode(),
compiler.misc.anonymous.class: ValueModifierTest$3, hashCode(), value), final`

Not sure I completely understand the test...ahh, yeah I do, no longer generate hashCode, but toString was

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

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


From dsimms at openjdk.java.net  Mon Aug 10 10:45:19 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 Aug 2020 10:45:19 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v4]
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <ZCC4HNW6UBiRpyyI9S_TcwBgByaLuPVSSvOf0IXx0ew=.821bbf80-1a2e-4632-9445-d70854239e90@github.com>

> Use ValueBootstrapMethods for Object::hashCode()

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Adjust test, no longer generating hashCode()

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/136/files
  - new: https://git.openjdk.java.net/valhalla/pull/136/files/c9f96b1d..bef769e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/136/webrev.03
 - incr: https://webrevs.openjdk.java.net/valhalla/136/webrev.02-03

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

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


From sadayapalam at openjdk.java.net  Mon Aug 10 11:17:05 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 11:17:05 GMT
Subject: [lworld] Integrated: 8251116: [lworld] test
 lworld-values/ValuesAsRefs.java failing.
Message-ID: <EBXmEcHIgH_W-9ooA1qFIBECQb-d1IE01xTEf6xTr1o=.af706fe5-19d6-4a92-8944-c0f0157c6479@github.com>

Fix incorrect error reporting

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

Commit messages:
 - 8251116:  test lworld-values/ValuesAsRefs.java failing

Changes: https://git.openjdk.java.net/valhalla/pull/138/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/138/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251116
  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/138.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/138/head:pull/138

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


From sadayapalam at openjdk.java.net  Mon Aug 10 11:17:06 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 11:17:06 GMT
Subject: [lworld] Integrated: 8251116: [lworld] test
 lworld-values/ValuesAsRefs.java failing.
In-Reply-To: <EBXmEcHIgH_W-9ooA1qFIBECQb-d1IE01xTEf6xTr1o=.af706fe5-19d6-4a92-8944-c0f0157c6479@github.com>
References: <EBXmEcHIgH_W-9ooA1qFIBECQb-d1IE01xTEf6xTr1o=.af706fe5-19d6-4a92-8944-c0f0157c6479@github.com>
Message-ID: <TITk_uf1sYDfFEt-t0gWMwyIuzia6Mf9Q_J99oXfNUE=.461bdef8-04b3-41fb-82b9-f3438251acb9@github.com>

On Mon, 10 Aug 2020 11:05:33 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Fix incorrect error reporting

This pull request has now been integrated.

Changeset: 349b22a3
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/349b22a3
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8251116: [lworld] test lworld-values/ValuesAsRefs.java failing.

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

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


From sadayapalam at openjdk.java.net  Mon Aug 10 12:26:09 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 12:26:09 GMT
Subject: [lworld] Integrated: 8251107: [lworld] test
 lworld-values/TopInterfaceNegativeTest.java is failing
Message-ID: <2vpxwPDbK1Nw9kQ7gk_offN4NmG3myeRcC3QJzmoAAs=.4efe4d56-74f0-44b5-8bf6-fde0e1462fef@github.com>

Fix problems exposed by sealing

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

Commit messages:
 - 8251107: test lworld-values/TopInterfaceNegativeTest.java is failing

Changes: https://git.openjdk.java.net/valhalla/pull/139/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/139/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251107
  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/139.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/139/head:pull/139

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


From sadayapalam at openjdk.java.net  Mon Aug 10 12:26:10 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Aug 2020 12:26:10 GMT
Subject: [lworld] Integrated: 8251107: [lworld] test
 lworld-values/TopInterfaceNegativeTest.java is failing
In-Reply-To: <2vpxwPDbK1Nw9kQ7gk_offN4NmG3myeRcC3QJzmoAAs=.4efe4d56-74f0-44b5-8bf6-fde0e1462fef@github.com>
References: <2vpxwPDbK1Nw9kQ7gk_offN4NmG3myeRcC3QJzmoAAs=.4efe4d56-74f0-44b5-8bf6-fde0e1462fef@github.com>
Message-ID: <RcBk722DHTIcKhAvllbr-V-ie-dOzrDi3qpTAb52zFE=.f9656981-c0af-47a8-9f32-80a4f8329d7d@github.com>

On Mon, 10 Aug 2020 12:19:35 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Fix problems exposed by sealing

This pull request has now been integrated.

Changeset: 660aa19e
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/660aa19e
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8251107: [lworld] test lworld-values/TopInterfaceNegativeTest.java is failing

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

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


From fparain at openjdk.java.net  Mon Aug 10 15:01:07 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:01:07 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v2]
In-Reply-To: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
Message-ID: <vYMxpX0k90wbSFPd2DsaYr2L84Kd-mtI1gziHTEIWjY=.038ec53b-9647-4d5b-80d7-fa0436dc0b74@github.com>

> Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
> The CR linked below contains a more detailed description of the optimization:
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8251046
> 
> A rudimentary benchmark shows encouraging numbers:
> Measuring inline type creation time with -XX:TieredStopAtLevel=1
> Inline class Point has two int fields.
> Inline class Rectangle has four int fields.
> 
> Without the optimization:
> Benchmark                                Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op
> 
> With the optimization:
> Benchmark                                Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op
> 
> Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor larva update methods
 - Fixes from review feedback

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/137/files
  - new: https://git.openjdk.java.net/valhalla/pull/137/files/3b486e32..c30c64a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/137/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/137/webrev.00-01

  Stats: 36 lines in 4 files changed: 13 ins; 3 del; 20 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/137.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/137/head:pull/137

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


From fparain at openjdk.java.net  Mon Aug 10 15:01:50 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:01:50 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v2]
In-Reply-To: <TD2P4Cqi6gZZ_LECxkXu4p_mCVXcjsqOoxq661rAWEc=.aec77ccc-a4f4-41fc-9b61-4b7d3aefe095@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
 <TD2P4Cqi6gZZ_LECxkXu4p_mCVXcjsqOoxq661rAWEc=.aec77ccc-a4f4-41fc-9b61-4b7d3aefe095@github.com>
Message-ID: <_42C6kQunzkKaFGo4iHnt-2cS5vyP9-VSA2qYlDMFLw=.6b1a0b8a-01ee-45ab-a612-00a505235cda@github.com>

On Thu, 6 Aug 2020 14:09:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor larva update methods
>>  - Fixes from review feedback
>
> Overall looks good to me, nice improvement! I've added some comments to the code.

Hi Tobias!
Thank you for your feedback.
Code formatting has been fixed.
Adding virtual calls to the Value class forced to add null checks everywhere, so instead, updates of the inline type
larvae are now performed in methods of the GraphBuilder class, encapsulating the null check.

Regards,

Fred

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

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


From fparain at openjdk.java.net  Mon Aug 10 15:14:17 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:14:17 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v3]
In-Reply-To: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
Message-ID: <WN6GuVmbuue_i_AVWhbl9_wyG32g3ILQ55ZT1s015cY=.80108193-fb4e-4d71-b44f-b08eb83382c4@github.com>

> Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
> The CR linked below contains a more detailed description of the optimization:
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8251046
> 
> A rudimentary benchmark shows encouraging numbers:
> Measuring inline type creation time with -XX:TieredStopAtLevel=1
> Inline class Point has two int fields.
> Inline class Rectangle has four int fields.
> 
> Without the optimization:
> Benchmark                                Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op
> 
> With the optimization:
> Benchmark                                Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op
> 
> Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).
> 
> Thank you,
> 
> Fred

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

  Fix indentation

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/137/files
  - new: https://git.openjdk.java.net/valhalla/pull/137/files/c30c64a0..88bd48e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/137/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/137/webrev.01-02

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

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


From thartmann at openjdk.java.net  Mon Aug 10 15:34:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 10 Aug 2020 15:34:33 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v4]
In-Reply-To: <-52MFO_jp0g02UNYpPlfBUJenbtXbzw8KUPYDD9SnP8=.0749a52f-e9da-4c59-b3f3-f7979487623b@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
 <-52MFO_jp0g02UNYpPlfBUJenbtXbzw8KUPYDD9SnP8=.0749a52f-e9da-4c59-b3f3-f7979487623b@github.com>
Message-ID: <SKTXWEH6bGhRLdtW_wKLe9u3SJz3G0UieAOsVhnIdhs=.e3343343-82ad-4900-bf00-4d7ce2456ff8@github.com>

On Mon, 10 Aug 2020 15:17:35 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
>> The CR linked below contains a more detailed description of the optimization:
>> 
>> CR: https://bugs.openjdk.java.net/browse/JDK-8251046
>> 
>> A rudimentary benchmark shows encouraging numbers:
>> Measuring inline type creation time with -XX:TieredStopAtLevel=1
>> Inline class Point has two int fields.
>> Inline class Rectangle has four int fields.
>> 
>> Without the optimization:
>> Benchmark                                Mode  Samples   Score  Score error  Units
>> o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
>> o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op
>> 
>> With the optimization:
>> Benchmark                                Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
>> o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op
>> 
>> Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix method indentation

Looks good to me. Thanks for making these changes!

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

Marked as reviewed by thartmann (Committer).

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


From fparain at openjdk.java.net  Mon Aug 10 15:34:29 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:34:29 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v4]
In-Reply-To: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
Message-ID: <-52MFO_jp0g02UNYpPlfBUJenbtXbzw8KUPYDD9SnP8=.0749a52f-e9da-4c59-b3f3-f7979487623b@github.com>

> Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
> The CR linked below contains a more detailed description of the optimization:
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8251046
> 
> A rudimentary benchmark shows encouraging numbers:
> Measuring inline type creation time with -XX:TieredStopAtLevel=1
> Inline class Point has two int fields.
> Inline class Rectangle has four int fields.
> 
> Without the optimization:
> Benchmark                                Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op
> 
> With the optimization:
> Benchmark                                Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op
> 
> Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).
> 
> Thank you,
> 
> Fred

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

  Fix method indentation

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/137/files
  - new: https://git.openjdk.java.net/valhalla/pull/137/files/88bd48e4..8d91e615

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/137/webrev.03
 - incr: https://webrevs.openjdk.java.net/valhalla/137/webrev.02-03

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

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


From fparain at openjdk.java.net  Mon Aug 10 15:34:35 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:34:35 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v4]
In-Reply-To: <N54LP3bCCOJr4Nk_iBcjeBEfEIMbjbebnTWTwOQJxhY=.cb43a7d9-19da-4ccc-86c4-6441c3e99c2a@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
 <-52MFO_jp0g02UNYpPlfBUJenbtXbzw8KUPYDD9SnP8=.0749a52f-e9da-4c59-b3f3-f7979487623b@github.com>
 <SKTXWEH6bGhRLdtW_wKLe9u3SJz3G0UieAOsVhnIdhs=.e3343343-82ad-4900-bf00-4d7ce2456ff8@github.com>
 <N54LP3bCCOJr4Nk_iBcjeBEfEIMbjbebnTWTwOQJxhY=.cb43a7d9-19da-4ccc-86c4-6441c3e99c2a@github.com>
Message-ID: <H5SFV4uw4o8npJMHM3BGspVVzGkEdBxw4lkgKD-5PCg=.d9d71b7a-2756-4cf3-aac1-3da51a834391@github.com>

On Mon, 10 Aug 2020 15:16:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Looks good to me. Thanks for making these changes!
>
> Thanks Tobias!
> 
> Fred

/integrate

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

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


From fparain at openjdk.java.net  Mon Aug 10 15:34:34 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:34:34 GMT
Subject: [lworld] RFR: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible [v4]
In-Reply-To: <SKTXWEH6bGhRLdtW_wKLe9u3SJz3G0UieAOsVhnIdhs=.e3343343-82ad-4900-bf00-4d7ce2456ff8@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
 <-52MFO_jp0g02UNYpPlfBUJenbtXbzw8KUPYDD9SnP8=.0749a52f-e9da-4c59-b3f3-f7979487623b@github.com>
 <SKTXWEH6bGhRLdtW_wKLe9u3SJz3G0UieAOsVhnIdhs=.e3343343-82ad-4900-bf00-4d7ce2456ff8@github.com>
Message-ID: <N54LP3bCCOJr4Nk_iBcjeBEfEIMbjbebnTWTwOQJxhY=.cb43a7d9-19da-4ccc-86c4-6441c3e99c2a@github.com>

On Mon, 10 Aug 2020 15:15:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix method indentation
>
> Looks good to me. Thanks for making these changes!

Thanks Tobias!

Fred

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

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


From fparain at openjdk.java.net  Mon Aug 10 15:34:36 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 10 Aug 2020 15:34:36 GMT
Subject: [lworld] Integrated: 8251046: [lworld] [lw3] C1 should avoid heap
 allocations in withfield when possible
In-Reply-To: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
References: <TOjBQk3lPw3Tot9CUPikn3tYK7gY7s_oMxG3pMliOCE=.4c2e11bd-7332-4bfd-8fd5-84e62f5bedd9@github.com>
Message-ID: <oKk1-AZ_HHipDDJu7YbEs2jBGURluphhb0PFAdrTOG8=.d54c29fe-f284-40f0-82a2-dd3dc05d704b@github.com>

On Wed, 5 Aug 2020 13:14:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch which reduces the number of heap allocations when executing the withfield bytecode with C1.
> The CR linked below contains a more detailed description of the optimization:
> 
> CR: https://bugs.openjdk.java.net/browse/JDK-8251046
> 
> A rudimentary benchmark shows encouraging numbers:
> Measuring inline type creation time with -XX:TieredStopAtLevel=1
> Inline class Point has two int fields.
> Inline class Rectangle has four int fields.
> 
> Without the optimization:
> Benchmark                                Mode  Samples   Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200   7.573        0.027  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  21.387        0.067  ns/op
> 
> With the optimization:
> Benchmark                                Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testPointCreation        avgt      200  5.284        0.014  ns/op
> o.s.MyBenchmark.testRectangleCreation    avgt      200  7.750        0.082  ns/op
> 
> Tested manually and with Mach5, tiers 1 to 3 (with Tobias' changes enabling more C1 testing).
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 59d8f6b4
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/59d8f6b4
Stats:     240 lines in 6 files changed: 55 ins; 155 del; 30 mod

8251046: [lworld] [lw3] C1 should avoid heap allocations in withfield when possible

Reviewed-by: thartmann

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

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


From mchung at openjdk.java.net  Mon Aug 10 20:01:37 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 10 Aug 2020 20:01:37 GMT
Subject: [lworld] RFR: [lworld] clean up VarHandle support for inline type
Message-ID: <hC0aRXMON2LT4LlT_qLHspKXFer1nwhEAbg1DPZssFA=.81778ea4-2066-4510-83db-25ba8dfe8424@github.com>

`InlineAccessor` and `StaticInlineAccessor` are no longer needed because `Class::cast` will ensure the given object is
non-null if it's an inline object.

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

Commit messages:
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lw3-fixes
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lw3-fixes
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lw3-fixes
 - clean up
 - Merge
 - check if both arguments are null
 - Merge
 - [lworld] ValueBootstrapMethods::isSubstitutable0 should do null check and type check
 - Merge
 - Merge
 - ... and 2 more: https://git.openjdk.java.net/valhalla/compare/59d8f6b4...99b7c201

Changes: https://git.openjdk.java.net/valhalla/pull/140/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/140/webrev.00
  Stats: 48 lines in 1 file changed: 0 ins; 46 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/140.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/140/head:pull/140

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


From mchung at openjdk.java.net  Mon Aug 10 20:27:42 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 10 Aug 2020 20:27:42 GMT
Subject: [lworld] Integrated: [lworld] clean up VarHandle support for inline
 type
In-Reply-To: <hC0aRXMON2LT4LlT_qLHspKXFer1nwhEAbg1DPZssFA=.81778ea4-2066-4510-83db-25ba8dfe8424@github.com>
References: <hC0aRXMON2LT4LlT_qLHspKXFer1nwhEAbg1DPZssFA=.81778ea4-2066-4510-83db-25ba8dfe8424@github.com>
Message-ID: <ITNyLitTM46w_Ye59mns-G3y4nRhobHJFVt0TSEcpqw=.9fb227f7-4667-445e-846e-d7ad406a8ee7@github.com>

On Mon, 10 Aug 2020 19:54:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `InlineAccessor` and `StaticInlineAccessor` are no longer needed because `Class::cast` will ensure the given object is
> non-null if it's an inline object.

This pull request has now been integrated.

Changeset: 67a019a5
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/67a019a5
Stats:     48 lines in 1 file changed: 46 ins; 0 del; 2 mod

[lworld] clean up VarHandle support for inline type

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

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


From dsimms at openjdk.java.net  Mon Aug 10 23:56:57 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 10 Aug 2020 23:56:57 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v5]
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <eJA-0hHBR2YuAM_fADxnfCv4UGuW6JulQtnjA97bTno=.4fa41f72-af99-4bd1-acec-40355b93a7d1@github.com>

> Use ValueBootstrapMethods for Object::hashCode()

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  more clean up to javac Gen::synthesizeValueMethod

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/136/files
  - new: https://git.openjdk.java.net/valhalla/pull/136/files/bef769e8..37cdaed3

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/136/webrev.04
 - incr: https://webrevs.openjdk.java.net/valhalla/136/webrev.03-04

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

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


From mchung at openjdk.java.net  Tue Aug 11 00:00:34 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 Aug 2020 00:00:34 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v5]
In-Reply-To: <eJA-0hHBR2YuAM_fADxnfCv4UGuW6JulQtnjA97bTno=.4fa41f72-af99-4bd1-acec-40355b93a7d1@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <eJA-0hHBR2YuAM_fADxnfCv4UGuW6JulQtnjA97bTno=.4fa41f72-af99-4bd1-acec-40355b93a7d1@github.com>
Message-ID: <OvYlc6IrWeFBW39K7awE3wWr0VMWdfVLlwFQeRtLtRE=.5052d656-6b0b-4c75-8742-694377f8d988@github.com>

On Mon, 10 Aug 2020 23:56:57 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Use ValueBootstrapMethods for Object::hashCode()
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more clean up to javac Gen::synthesizeValueMethod

approved

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

Marked as reviewed by mchung (Committer).

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


From mchung at openjdk.java.net  Tue Aug 11 00:00:35 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 11 Aug 2020 00:00:35 GMT
Subject: [lworld] RFR: 8244975: [lworld] Investigate if VM can implement
 Object::hashCode by calling ValueBootstrapMethods for inline types [v3]
In-Reply-To: <XHRawZj-3eqPPCXxM9JqJEruajFa2DuXB13D4lpDZjQ=.954b8a46-d0f1-4937-b3c1-a6562e55b3f2@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
 <iXCSWowYb7Tozbd7Q2O_CpRzDBw9qmIj_EKvFJTgBBo=.10e715fe-7a5d-48fd-bb58-faed52806986@github.com>
 <SkjYIAuZdZTCOH1KfJPx6egnetIJv4oPPqCvL_gIJqU=.8b750fd9-b22f-4677-a25a-11d335e1921d@github.com>
 <XHRawZj-3eqPPCXxM9JqJEruajFa2DuXB13D4lpDZjQ=.954b8a46-d0f1-4937-b3c1-a6562e55b3f2@github.com>
Message-ID: <cDA9aQ6XN3vLeVJU3NM7RhAVhnn9_SdyuQh434gW8nM=.f3008db9-c3f1-42f4-b931-470b17f33d56@github.com>

On Mon, 10 Aug 2020 10:36:57 GMT, David Simms <dsimms at openjdk.org> wrote:

>> +1 for javac changes, assuming tests are all green
>
>> +1 for javac changes, assuming tests are all green
> 
> Looks like I did break something:
> `ValueModifierTest.java:16:28: compiler.err.override.meth: (compiler.misc.cant.override: toString(),
> compiler.misc.anonymous.class: ValueModifierTest$3, toString(), value), final`
> rather than .out file:
> 
> `ValueModifierTest.java:16:28: compiler.err.override.meth: (compiler.misc.cant.override: hashCode(),
> compiler.misc.anonymous.class: ValueModifierTest$3, hashCode(), value), final`
> Not sure I completely understand the test...ahh, yeah I do, no longer generate hashCode, but toString was

This looks good to me.  I made a small clean up on javac `Gen::synthesizeValueMethod` method to remove the switch
statement.

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

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


From dsimms at openjdk.java.net  Tue Aug 11 08:35:32 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 Aug 2020 08:35:32 GMT
Subject: [lworld] Integrated: 8244975: [lworld] Investigate if VM can
 implement Object::hashCode by calling ValueBootstrapMethods for inline types
In-Reply-To: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
References: <17mLe2PsOCmRLyKR56xC0PYzrCwcFRfgPI8243I9OxA=.94ff3e4b-57c3-4a00-b2dc-a3f6595b9fe4@github.com>
Message-ID: <rjACaTk3ADGR5VVUkEmeNhP74eFLEC5kbsWTuDmzxEQ=.cfa7f7b1-e624-4f72-bab5-84c176502cde@github.com>

On Wed, 5 Aug 2020 11:32:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use ValueBootstrapMethods for Object::hashCode()

This pull request has now been integrated.

Changeset: f891f433
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f891f433
Stats:     315 lines in 13 files changed: 134 ins; 126 del; 55 mod

8244975: [lworld] Investigate if VM can implement Object::hashCode by calling ValueBootstrapMethods for inline types

Reviewed-by: sadayapalam, mchung

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

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


From sadayapalam at openjdk.java.net  Tue Aug 11 10:52:31 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 11 Aug 2020 10:52:31 GMT
Subject: [lworld] Integrated: 8244233: [lworld] Nested types are not handled
 properly across projections
Message-ID: <TO0xy_kuCZWqRbD3GoB6LE9RjxP-hOtB7wLiDncY5gA=.78a8a6e2-1757-4db4-86d5-67fcfa0037e2@github.com>

Treatment for nested types.

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

Commit messages:
 - 8244233: Nested types are not handled properly across projections

Changes: https://git.openjdk.java.net/valhalla/pull/141/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/141/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244233
  Stats: 87 lines in 5 files changed: 85 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/141.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/141/head:pull/141

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


From sadayapalam at openjdk.java.net  Tue Aug 11 10:52:32 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 11 Aug 2020 10:52:32 GMT
Subject: [lworld] Integrated: 8244233: [lworld] Nested types are not handled
 properly across projections
In-Reply-To: <TO0xy_kuCZWqRbD3GoB6LE9RjxP-hOtB7wLiDncY5gA=.78a8a6e2-1757-4db4-86d5-67fcfa0037e2@github.com>
References: <TO0xy_kuCZWqRbD3GoB6LE9RjxP-hOtB7wLiDncY5gA=.78a8a6e2-1757-4db4-86d5-67fcfa0037e2@github.com>
Message-ID: <_zTiBgE1kUMz4Ac7LKpQj0fJ_W_pYh_MIpW6ngBzZfQ=.bad315ac-103a-4486-9874-eb4a651175ca@github.com>

On Tue, 11 Aug 2020 10:41:07 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Treatment for nested types.

This pull request has now been integrated.

Changeset: dda358bb
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/dda358bb
Stats:     87 lines in 5 files changed: 0 ins; 85 del; 2 mod

8244233: [lworld] Nested types are not handled properly across projections

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

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


From dsimms at openjdk.java.net  Tue Aug 11 12:42:32 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 Aug 2020 12:42:32 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <ESMuU75o4sQdv_Jl8016yaUywDwoA0BPjyxtW2LAxxw=.c3d830f8-936b-4fc5-b317-d1bdb5c39252@github.com>

Merge tag 'jdk-16+3', notes:

* Tooks "ours" only for: 8247697 Remove delayed_forbidden dead code in C2, needs reworking
* Trusted final, now includes inline type fields

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

Commit messages:
 - Trusted final, now includes inline type fields
 - Merge tag 'jdk-16+3' into lworld_merge_jdk_16_3
 - Merged ours for 8247697 Remove delayed_forbidden dead code in C2, needs reworking
 - Merge commit 'a16994ff7b321af20f49a56e11f458e052133568' into lworld_merge_jdk_16_3
 - 8239782: CC_INTERP is only used by Zero interpreter
 - 8248131: Simplify ServicesCatalog provider handling
 - 8247966: runtime/logging/loadLibraryTest/LoadLibraryTest.java failed "RuntimeException: 'Unloaded library with handle' missing from stdout/stderr"
 - 8225251: Minimise import statements in jpackage sources
 - 8247755: Leaner and more versatile GrowableArray classes
 - 8247820: ParallelGC: Process strong OopStorage entries in parallel
 - ... and 81 more: https://git.openjdk.java.net/valhalla/compare/f891f433...4b77c096

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/valhalla/142/webrev.00.0
 - jdk: https://webrevs.openjdk.java.net/valhalla/142/webrev.00.1

Changes: https://git.openjdk.java.net/valhalla/pull/142/files
  Stats: 20554 lines in 423 files changed: 11992 ins; 7511 del; 1051 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/142.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/142/head:pull/142

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


From dsimms at openjdk.java.net  Tue Aug 11 12:42:32 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 Aug 2020 12:42:32 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <ESMuU75o4sQdv_Jl8016yaUywDwoA0BPjyxtW2LAxxw=.c3d830f8-936b-4fc5-b317-d1bdb5c39252@github.com>
References: <ESMuU75o4sQdv_Jl8016yaUywDwoA0BPjyxtW2LAxxw=.c3d830f8-936b-4fc5-b317-d1bdb5c39252@github.com>
Message-ID: <OseiJo33k3DtFlCa1W6PcIK_6dl8sR9Gqm1Pta4i2CA=.efdaccf5-720f-4019-a5f1-3aef5378f979@github.com>

On Tue, 11 Aug 2020 12:24:16 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+3', notes:
> 
> * Tooks "ours" only for: 8247697 Remove delayed_forbidden dead code in C2, needs reworking
> * Trusted final, now includes inline type fields

/summary

Merge tag 'jdk-16+3', notes:

* Tooks "ours" only for: 8247697 Remove delayed_forbidden dead code in C2, needs reworking
* Trusted final, now includes inline type fields

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

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


From dsimms at openjdk.java.net  Tue Aug 11 12:42:34 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 Aug 2020 12:42:34 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <ESMuU75o4sQdv_Jl8016yaUywDwoA0BPjyxtW2LAxxw=.c3d830f8-936b-4fc5-b317-d1bdb5c39252@github.com>
References: <ESMuU75o4sQdv_Jl8016yaUywDwoA0BPjyxtW2LAxxw=.c3d830f8-936b-4fc5-b317-d1bdb5c39252@github.com>
Message-ID: <6jnUCAh40yQge6WJv833clqj6a0h4c66uguJAlO1y9A=.3fc4d6af-d491-4b40-84dc-e97c2ab9c7d6@github.com>

On Tue, 11 Aug 2020 12:24:16 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+3', notes:
> 
> * Tooks "ours" only for: 8247697 Remove delayed_forbidden dead code in C2, needs reworking
> * Trusted final, now includes inline type fields

This pull request has now been integrated.

Changeset: 93cde007
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/93cde007
Stats:     20560 lines in 423 files changed: 7517 ins; 11998 del; 1045 mod

Merge jdk

Merge tag 'jdk-16+3', notes:

* Tooks "ours" only for: 8247697 Remove delayed_forbidden dead code in C2, needs reworking
* Trusted final, now includes inline type fields

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

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


From thartmann at openjdk.java.net  Tue Aug 11 13:36:53 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 11 Aug 2020 13:36:53 GMT
Subject: [lworld] RFR: 8251398: [lworld] TestCallingConvention::test36
 spuriously fails due to incorrect field value
Message-ID: <FMVatC7-i5tJuCZZihK892fJd6he-HSGbdgE6rCG1n4=.2043356c-a304-42e1-84a0-a5d930645e25@github.com>

In addition to integer registers, we also need to save vector registers used for floating point arguments before
calling into the runtime in the GC barrier slowpaths.

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

Commit messages:
 - 8251398: [lworld] TestCallingConvention::test36 spuriously fails due to incorrect field value

Changes: https://git.openjdk.java.net/valhalla/pull/143/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/143/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251398
  Stats: 44 lines in 1 file changed: 40 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/143.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/143/head:pull/143

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


From dsimms at openjdk.java.net  Tue Aug 11 15:46:08 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 Aug 2020 15:46:08 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <M9NceQ90Vb3zNuSkUu-Q2Mlc4OJn6sa-J_6SihE9Rp8=.d2e48e6b-d6dc-4d24-85e3-1cec2cf98ec6@github.com>

Merge tag 'jdk-16+4' into lworld_merge_jdk_16_4
Added tag jdk-16+4 for changeset e2622818f0bd

# Conflicts:
#	make/test/BuildMicrobenchmark.gmk
#	src/hotspot/share/opto/memnode.cpp
#	src/hotspot/share/opto/type.cpp
#	src/hotspot/share/runtime/javaCalls.cpp

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

Commit messages:
 - Merge tag 'jdk-16+4' into lworld_merge_jdk_16_4
 - 8244724: CTW: C2 compilation fails with "Live Node limit exceeded limit"
 - 8248563: Gtest CFLAGS/warnings is not properly handled
 - 8248526: configure script failed on WSL in May 2020 update
 - Merge
 - 8246493: JDI stress/serial/mixed002 needs to use WhiteBox.deflateIdleMonitors support
 - 8248409: some jdk/javadoc/doclet tests fail (JDK 15)
 - Merge
 - 8246114: java/net/MulticastSocket/Promiscuous.java fails after 8241072 (multi-homed systems)
 - 8248048: ZGC: AArch64: SIGILL in load barrier register spilling
 - ... and 91 more: https://git.openjdk.java.net/valhalla/compare/93cde007...2cbcd88c

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/valhalla/144/webrev.00.0
 - jdk: https://webrevs.openjdk.java.net/valhalla/144/webrev.00.1

Changes: https://git.openjdk.java.net/valhalla/pull/144/files
  Stats: 9712 lines in 346 files changed: 4620 ins; 3764 del; 1328 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/144.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/144/head:pull/144

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


From dsimms at openjdk.java.net  Tue Aug 11 15:46:09 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 11 Aug 2020 15:46:09 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <M9NceQ90Vb3zNuSkUu-Q2Mlc4OJn6sa-J_6SihE9Rp8=.d2e48e6b-d6dc-4d24-85e3-1cec2cf98ec6@github.com>
References: <M9NceQ90Vb3zNuSkUu-Q2Mlc4OJn6sa-J_6SihE9Rp8=.d2e48e6b-d6dc-4d24-85e3-1cec2cf98ec6@github.com>
Message-ID: <qJ6pgMHVUuM-Zl8mwhI6ayukoxehq7cjSfvlHBnPKqE=.3f8ac0f5-522d-4fce-ab47-ece439209cb1@github.com>

On Tue, 11 Aug 2020 14:29:05 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+4' into lworld_merge_jdk_16_4
> Added tag jdk-16+4 for changeset e2622818f0bd
> 
> # Conflicts:
> #	make/test/BuildMicrobenchmark.gmk
> #	src/hotspot/share/opto/memnode.cpp
> #	src/hotspot/share/opto/type.cpp
> #	src/hotspot/share/runtime/javaCalls.cpp

This pull request has now been integrated.

Changeset: f0a8efc2
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f0a8efc2
Stats:     9717 lines in 346 files changed: 3769 ins; 4625 del; 1323 mod

Merge jdk

Merge tag 'jdk-16+4'

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

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


From thartmann at openjdk.java.net  Tue Aug 11 17:32:23 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 11 Aug 2020 17:32:23 GMT
Subject: [lworld] Integrated: 8251398: [lworld] TestCallingConvention::test36
 spuriously fails due to incorrect field value
In-Reply-To: <FMVatC7-i5tJuCZZihK892fJd6he-HSGbdgE6rCG1n4=.2043356c-a304-42e1-84a0-a5d930645e25@github.com>
References: <FMVatC7-i5tJuCZZihK892fJd6he-HSGbdgE6rCG1n4=.2043356c-a304-42e1-84a0-a5d930645e25@github.com>
Message-ID: <QcGpaN6p7hvwL4YmuIce1MLWwfRyMdVeAQQQn7QYRwY=.d022ae06-7232-4ef9-b0e7-ce51c54ab76c@github.com>

On Tue, 11 Aug 2020 13:29:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In addition to integer registers, we also need to save vector registers used for floating point arguments before
> calling into the runtime in the GC barrier slowpaths.

This pull request has now been integrated.

Changeset: 2455c8ed
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2455c8ed
Stats:     44 lines in 1 file changed: 2 ins; 40 del; 2 mod

8251398: [lworld] TestCallingConvention::test36 spuriously fails due to incorrect field value

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

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


From hseigel at openjdk.java.net  Fri Aug 14 17:31:08 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 14 Aug 2020 17:31:08 GMT
Subject: [lworld] RFR: 8251842: rename ACC_VALUE to ACC_INLINE
Message-ID: <OsC5Wf-4DOMC55f5J0hq89jHPuH2iVaRNFtRRNMNQBo=.4f95215b-d01e-4e15-8ca9-035a772eed81@github.com>

Change ACC_VALUE to ACC_INLINE and change JVM_ACC_VALUE to JVM_ACC_INLINE.  Tested with tiers 1-2 on Linux, MAC, and
Windows, and tiers 3-5 on Linux.

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

Commit messages:
 - 8251842: rename ACC_VALUE to ACC_INLINE

Changes: https://git.openjdk.java.net/valhalla/pull/145/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/145/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251842
  Stats: 53 lines in 20 files changed: 0 ins; 0 del; 53 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/145.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/145/head:pull/145

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


From fparain at openjdk.java.net  Fri Aug 14 18:02:42 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 14 Aug 2020 18:02:42 GMT
Subject: [lworld] RFR: 8251842: rename ACC_VALUE to ACC_INLINE
In-Reply-To: <OsC5Wf-4DOMC55f5J0hq89jHPuH2iVaRNFtRRNMNQBo=.4f95215b-d01e-4e15-8ca9-035a772eed81@github.com>
References: <OsC5Wf-4DOMC55f5J0hq89jHPuH2iVaRNFtRRNMNQBo=.4f95215b-d01e-4e15-8ca9-035a772eed81@github.com>
Message-ID: <aa2kJgxtvSQY0hnuZVJUx1OPvxdBEFY2YhjXMqU_JHQ=.7068af92-de20-4fe1-81b3-5fc9f7ee263c@github.com>

On Fri, 14 Aug 2020 17:23:00 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Change ACC_VALUE to ACC_INLINE and change JVM_ACC_VALUE to JVM_ACC_INLINE.  Tested with tiers 1-2 on Linux, MAC, and
> Windows, and tiers 3-5 on Linux.

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From hseigel at openjdk.java.net  Fri Aug 14 19:07:18 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 14 Aug 2020 19:07:18 GMT
Subject: [lworld] Integrated: 8251842: rename ACC_VALUE to ACC_INLINE
In-Reply-To: <OsC5Wf-4DOMC55f5J0hq89jHPuH2iVaRNFtRRNMNQBo=.4f95215b-d01e-4e15-8ca9-035a772eed81@github.com>
References: <OsC5Wf-4DOMC55f5J0hq89jHPuH2iVaRNFtRRNMNQBo=.4f95215b-d01e-4e15-8ca9-035a772eed81@github.com>
Message-ID: <BT-Kz3LQEtGZxzCC9jj5Tac67DH9t5aR4rsUkf4SOtM=.5dc84833-457a-45a2-9abe-b8e0f0268b7f@github.com>

On Fri, 14 Aug 2020 17:23:00 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Change ACC_VALUE to ACC_INLINE and change JVM_ACC_VALUE to JVM_ACC_INLINE.  Tested with tiers 1-2 on Linux, MAC, and
> Windows, and tiers 3-5 on Linux.

This pull request has now been integrated.

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

8251842: rename ACC_VALUE to ACC_INLINE

Reviewed-by: fparain

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

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


From hseigel at openjdk.java.net  Fri Aug 14 19:07:17 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 14 Aug 2020 19:07:17 GMT
Subject: [lworld] RFR: 8251842: rename ACC_VALUE to ACC_INLINE
In-Reply-To: <aa2kJgxtvSQY0hnuZVJUx1OPvxdBEFY2YhjXMqU_JHQ=.7068af92-de20-4fe1-81b3-5fc9f7ee263c@github.com>
References: <OsC5Wf-4DOMC55f5J0hq89jHPuH2iVaRNFtRRNMNQBo=.4f95215b-d01e-4e15-8ca9-035a772eed81@github.com>
 <aa2kJgxtvSQY0hnuZVJUx1OPvxdBEFY2YhjXMqU_JHQ=.7068af92-de20-4fe1-81b3-5fc9f7ee263c@github.com>
Message-ID: <GVX6_k0j_GKS5-1oa3gbB25bOC31k4_006ADqaO5_n8=.92268cd4-c47d-45de-ad87-18a57f76e1a4@github.com>

On Fri, 14 Aug 2020 18:00:24 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Change ACC_VALUE to ACC_INLINE and change JVM_ACC_VALUE to JVM_ACC_INLINE.  Tested with tiers 1-2 on Linux, MAC, and
>> Windows, and tiers 3-5 on Linux.
>
> Looks good to me.
> 
> Fred

Thanks Fred!

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

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


From sadayapalam at openjdk.java.net  Mon Aug 17 06:36:06 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Aug 2020 06:36:06 GMT
Subject: [lworld] Integrated: 8251504: [lworld] Support empty inline classes
 without -XDallowEmptyValues
In-Reply-To: <C00FCJKKW8jsjwS-66RFdkr_JiY8Mn8rZv_BpDc4h6k=.e0f09809-4cd5-4210-b889-c1287594907d@github.com>
References: <C00FCJKKW8jsjwS-66RFdkr_JiY8Mn8rZv_BpDc4h6k=.e0f09809-4cd5-4210-b889-c1287594907d@github.com>
Message-ID: <De1jaB1TZv2kXTGE9q55Jb2xckjtKrLPvhHJ3zG_T7M=.e7ee23d4-c05e-43e6-a4ab-41c25220e44f@github.com>

On Mon, 17 Aug 2020 06:27:23 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Support empty inline classes

This pull request has now been integrated.

Changeset: 77af8092
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/77af8092
Stats:     79 lines in 20 files changed: 32 ins; 28 del; 19 mod

8251504: [lworld] Support empty inline classes without -XDallowEmptyValues

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

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


From sadayapalam at openjdk.java.net  Mon Aug 17 06:36:04 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Aug 2020 06:36:04 GMT
Subject: [lworld] Integrated: 8251504: [lworld] Support empty inline classes
 without -XDallowEmptyValues
Message-ID: <C00FCJKKW8jsjwS-66RFdkr_JiY8Mn8rZv_BpDc4h6k=.e0f09809-4cd5-4210-b889-c1287594907d@github.com>

Support empty inline classes

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

Commit messages:
 - 8251504: [lworld] Support empty inline classes without -XDallowEmptyValues

Changes: https://git.openjdk.java.net/valhalla/pull/146/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/146/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251504
  Stats: 79 lines in 20 files changed: 28 ins; 32 del; 19 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/146.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/146/head:pull/146

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


From sadayapalam at openjdk.java.net  Mon Aug 17 11:42:37 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Aug 2020 11:42:37 GMT
Subject: [lworld] Integrated: 8244513: [lworld] Typing of conditional
 expressions involving values.
Message-ID: <ZvOH6zgQQlJPYfNWBbuPwbV_pWXRPaKiq9H_Bwy-um4=.b09b3139-f24d-48bb-b6fd-16eb46618f36@github.com>

For now, make typing of conditionals mimic the rules for primitives and boxing.

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

Commit messages:
 - 8244513: [lworld] Typing of conditional expressions involving values.
 - 8244513: [lworld] Typing of conditional expressions involving values.

Changes: https://git.openjdk.java.net/valhalla/pull/147/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/147/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244513
  Stats: 127 lines in 5 files changed: 106 ins; 17 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/147.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/147/head:pull/147

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


From sadayapalam at openjdk.java.net  Mon Aug 17 11:42:38 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Aug 2020 11:42:38 GMT
Subject: [lworld] Integrated: 8244513: [lworld] Typing of conditional
 expressions involving values.
In-Reply-To: <ZvOH6zgQQlJPYfNWBbuPwbV_pWXRPaKiq9H_Bwy-um4=.b09b3139-f24d-48bb-b6fd-16eb46618f36@github.com>
References: <ZvOH6zgQQlJPYfNWBbuPwbV_pWXRPaKiq9H_Bwy-um4=.b09b3139-f24d-48bb-b6fd-16eb46618f36@github.com>
Message-ID: <vXjIgv46Cy8gEhcamvcC-OMpDkpmkxlrpUG8DbTMw80=.555c8821-12e8-4c4d-9aae-76ff838224f8@github.com>

On Mon, 17 Aug 2020 11:32:38 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> For now, make typing of conditionals mimic the rules for primitives and boxing.

This pull request has now been integrated.

Changeset: f72ec3c3
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f72ec3c3
Stats:     127 lines in 5 files changed: 17 ins; 106 del; 4 mod

8244513: [lworld] Typing of conditional expressions involving values.

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

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


From sadayapalam at openjdk.java.net  Tue Aug 18 07:38:54 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Aug 2020 07:38:54 GMT
Subject: [lworld] Integrated: 8244232: [lworld] Improve javadoc comments for
 various methods dealing with projection types
Message-ID: <7c3rjEpSXTX5d1wNQe8z2wRbzW7OUrX33UK5-XIDF6I=.4a1d839f-d0ab-40ca-b8a1-c0d80fd1d5b7@github.com>

Update javadoc to reflect differences between referenceProjection APIs and the ref operator of the spec.

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

Commit messages:
 - 8244232: Improve javadoc comments for various methods dealing with projection types

Changes: https://git.openjdk.java.net/valhalla/pull/148/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/148/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244232
  Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/148.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/148/head:pull/148

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


From sadayapalam at openjdk.java.net  Tue Aug 18 07:38:54 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Aug 2020 07:38:54 GMT
Subject: [lworld] Integrated: 8244232: [lworld] Improve javadoc comments for
 various methods dealing with projection types
In-Reply-To: <7c3rjEpSXTX5d1wNQe8z2wRbzW7OUrX33UK5-XIDF6I=.4a1d839f-d0ab-40ca-b8a1-c0d80fd1d5b7@github.com>
References: <7c3rjEpSXTX5d1wNQe8z2wRbzW7OUrX33UK5-XIDF6I=.4a1d839f-d0ab-40ca-b8a1-c0d80fd1d5b7@github.com>
Message-ID: <3Vjk5XO1KFwi_DBevu0tsQcJJoxmMZdTYV8hHArNonw=.1fc6a23a-00f6-4dc0-84d8-dc69050db8a6@github.com>

On Tue, 18 Aug 2020 07:30:38 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Update javadoc to reflect differences between referenceProjection APIs and the ref operator of the spec.

This pull request has now been integrated.

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

8244232: [lworld] Improve javadoc comments for various methods dealing with projection types

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

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


From sadayapalam at openjdk.java.net  Tue Aug 18 12:48:12 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Aug 2020 12:48:12 GMT
Subject: [lworld] Integrated: 8251940: [lworld] Incorrect Signature attribute
 in class file.
Message-ID: <kqO-zpTb5f9lIU-fN2QDRX-pIeyxPrPwS-R_72Aj6uc=.dc738f4c-0515-4783-ac11-7856012b3a85@github.com>

Fix signature in inline class to reflect super type correctly.

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

Commit messages:
 - 8251940: [lworld] Incorrect Signature attribute in class file.

Changes: https://git.openjdk.java.net/valhalla/pull/150/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/150/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251940
  Stats: 55 lines in 2 files changed: 52 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/150.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/150/head:pull/150

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


From sadayapalam at openjdk.java.net  Tue Aug 18 12:48:13 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Aug 2020 12:48:13 GMT
Subject: [lworld] Integrated: 8251940: [lworld] Incorrect Signature attribute
 in class file.
In-Reply-To: <kqO-zpTb5f9lIU-fN2QDRX-pIeyxPrPwS-R_72Aj6uc=.dc738f4c-0515-4783-ac11-7856012b3a85@github.com>
References: <kqO-zpTb5f9lIU-fN2QDRX-pIeyxPrPwS-R_72Aj6uc=.dc738f4c-0515-4783-ac11-7856012b3a85@github.com>
Message-ID: <NKVMv_xHgP9JWIPBvsyoRuR2WPkwM1tCIHex68rLQEI=.d02a5e12-ebcf-44ee-ba8d-a1f37f8d912c@github.com>

On Tue, 18 Aug 2020 12:39:28 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Fix signature in inline class to reflect super type correctly.

This pull request has now been integrated.

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

8251940: [lworld] Incorrect Signature attribute in class file.

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

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


From thartmann at openjdk.java.net  Tue Aug 18 14:36:40 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 18 Aug 2020 14:36:40 GMT
Subject: [lworld] RFR: 8251442: [lworld] C2 compilation fails with
 assert(value->bottom_type()->higher_equal(_type))
Message-ID: <jDsawJeNPzHSuxqsHR9JV_jZ0mv4BGp8TyIlrQQe_8o=.e78ac1dc-796a-4190-a500-8cebe213dac8@github.com>

Similar to JDK-8242453 [1], the problem is that a load from a non-flat array can be pushed through an arraycopy from a
flat array (see LoadNode::can_see_arraycopy_value) and end up with an inconsistent memory input (oop load from a flat
array). The checks emitted by the arraycopy intrinsic will catch this and the load will be removed but other Ideal
transformations can still be executed before that happens and encounter this inconsistent state.

The fix is to add CheckCastPPNodes to the arraycopy intrinsic that propagate the information that the src/dst array is
not flat. This makes sure that the data path consistently dies if the input array is in fact a flat array. I've also
removed the workaround from the JDK-8242453 [1] fix.

When updating the type of CheckCastPPNodes, we need to make sure that the not_null_free and not_flat properties of
TypeAryPtr are propagated. This is done by TypeAryPtr::update_properties. A CheckCastPPNode that ends up with an
inconsistent input is then simply replaced by TOP.

This change also includes:
- Optimize subtype checks based on not_null_free/not_flat properties of array types
- New tests to verify that checkcasts are folded if one array type is known to be not null-free/flat and the other type
  is null-free/flat
- Test suite should detect compilation bailouts and fail (currently, only completely missing compilations were detected)
- Renamed "flat_array" to "flatten_array" (which means "flattened in arrays") for consistency with runtime code. We
  should think about a better name.
- Lots of refactoring, removal of default arguments in calls and dead code

[1] https://bugs.openjdk.java.net/browse/JDK-8242453

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

Commit messages:
 - 8251442: [lworld] C2 compilation fails with assert(value->bottom_type()->higher_equal(_type))

Changes: https://git.openjdk.java.net/valhalla/pull/151/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/151/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251442
  Stats: 450 lines in 17 files changed: 257 ins; 47 del; 146 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/151.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/151/head:pull/151

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


From thartmann at openjdk.java.net  Tue Aug 18 15:13:50 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 18 Aug 2020 15:13:50 GMT
Subject: [lworld] RFR: 8251442: [lworld] C2 compilation fails with
 assert(value->bottom_type()->higher_equal(_type)) [v2]
In-Reply-To: <jDsawJeNPzHSuxqsHR9JV_jZ0mv4BGp8TyIlrQQe_8o=.e78ac1dc-796a-4190-a500-8cebe213dac8@github.com>
References: <jDsawJeNPzHSuxqsHR9JV_jZ0mv4BGp8TyIlrQQe_8o=.e78ac1dc-796a-4190-a500-8cebe213dac8@github.com>
Message-ID: <61AFzLohDcSotbWqELW7cw4twtfZGS4pYi3A6dztekQ=.6ca9835c-8ea3-48a8-b0e4-78115d0c3440@github.com>

> Similar to JDK-8242453 [1], the problem is that a load from a non-flat array can be pushed through an arraycopy from a
> flat array (see LoadNode::can_see_arraycopy_value) and end up with an inconsistent memory input (oop load from a flat
> array). The checks emitted by the arraycopy intrinsic will catch this and the load will be removed but other Ideal
> transformations can still be executed before that happens and encounter this inconsistent state.  The fix is to add
> CheckCastPPNodes to the arraycopy intrinsic that propagate the information that the src/dst array is not flat. This
> makes sure that the data path consistently dies if the input array is in fact a flat array. I've also removed the
> workaround from the JDK-8242453 [1] fix.  When updating the type of CheckCastPPNodes, we need to make sure that the
> not_null_free and not_flat properties of TypeAryPtr are propagated. This is done by TypeAryPtr::update_properties. A
> CheckCastPPNode that ends up with an inconsistent input is then simply replaced by TOP.  This change also includes:
> - Optimize subtype checks based on not_null_free/not_flat properties of array types
> - New tests to verify that checkcasts are folded if one array type is known to be not null-free/flat and the other type
>   is null-free/flat
> - Test suite should detect compilation bailouts and fail (currently, only completely missing compilations were detected)
> - Renamed "flat_array" to "flatten_array" (which means "flattened in arrays") for consistency with runtime code. We
>   should think about a better name.
> - Lots of refactoring, removal of default arguments in calls and dead code
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8242453

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

  Removed too strong assert from InlineTypeBaseNode::merge_with

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/151/files
  - new: https://git.openjdk.java.net/valhalla/pull/151/files/2a54ae89..2699610d

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/151/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/151/webrev.00-01

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

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


From thartmann at openjdk.java.net  Tue Aug 18 15:58:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 18 Aug 2020 15:58:51 GMT
Subject: [lworld] Integrated: 8251442: [lworld] C2 compilation fails with
 assert(value->bottom_type()->higher_equal(_type))
In-Reply-To: <jDsawJeNPzHSuxqsHR9JV_jZ0mv4BGp8TyIlrQQe_8o=.e78ac1dc-796a-4190-a500-8cebe213dac8@github.com>
References: <jDsawJeNPzHSuxqsHR9JV_jZ0mv4BGp8TyIlrQQe_8o=.e78ac1dc-796a-4190-a500-8cebe213dac8@github.com>
Message-ID: <Uw6865kSsTOAniUe5Eg9xR2rbxGVSTX6yvyhiRBFsgg=.14ba051a-f3c6-4a61-b825-db90f762799e@github.com>

On Tue, 18 Aug 2020 14:29:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to JDK-8242453 [1], the problem is that a load from a non-flat array can be pushed through an arraycopy from a
> flat array (see LoadNode::can_see_arraycopy_value) and end up with an inconsistent memory input (oop load from a flat
> array). The checks emitted by the arraycopy intrinsic will catch this and the load will be removed but other Ideal
> transformations can still be executed before that happens and encounter this inconsistent state.  The fix is to add
> CheckCastPPNodes to the arraycopy intrinsic that propagate the information that the src/dst array is not flat. This
> makes sure that the data path consistently dies if the input array is in fact a flat array. I've also removed the
> workaround from the JDK-8242453 [1] fix.  When updating the type of CheckCastPPNodes, we need to make sure that the
> not_null_free and not_flat properties of TypeAryPtr are propagated. This is done by TypeAryPtr::update_properties. A
> CheckCastPPNode that ends up with an inconsistent input is then simply replaced by TOP.  This change also includes:
> - Optimize subtype checks based on not_null_free/not_flat properties of array types
> - New tests to verify that checkcasts are folded if one array type is known to be not null-free/flat and the other type
>   is null-free/flat
> - Test suite should detect compilation bailouts and fail (currently, only completely missing compilations were detected)
> - Renamed "flat_array" to "flatten_array" (which means "flattened in arrays") for consistency with runtime code. We
>   should think about a better name.
> - Lots of refactoring, removal of default arguments in calls and dead code
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8242453

This pull request has now been integrated.

Changeset: 5d1350ef
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/5d1350ef
Stats:     451 lines in 18 files changed: 48 ins; 257 del; 146 mod

8251442: [lworld] C2 compilation fails with assert(value->bottom_type()->higher_equal(_type))

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

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


From mchung at openjdk.java.net  Tue Aug 18 19:54:26 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 Aug 2020 19:54:26 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType and
 Class::referenceType in Java
Message-ID: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>

Now that javac generates the reference projection class as a sealed type, this patch reimplements
`Class::valueType` and `Class::referenceType` in Java.  VM no longer has any knowledge of
the value projection type and reference projection type.

This patch includes a temporary workaround to disable the preview feature check for sealed types
because inline types are not (yet) a preview feature in valhalla repo.  This workaround should be
removed when it's time to make inline class a preview feature.

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

Commit messages:
 - supports_sealed_types checks only the major version
 - remove unused import
 - disable preview feature check for sealed types
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lworld
 - implement Class::referenceType and Class::valueType in Java

Changes: https://git.openjdk.java.net/valhalla/pull/152/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/152/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251986
  Stats: 157 lines in 5 files changed: 83 ins; 54 del; 20 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/152/head:pull/152

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


From hseigel at openjdk.java.net  Tue Aug 18 20:53:46 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 18 Aug 2020 20:53:46 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <2QUT4CWtwLxuu1lhmNS4ObHrgna_DBj685jktl2YmfU=.dde7bba0-e980-4d08-96ae-4fa17c029126@github.com>

On Tue, 18 Aug 2020 19:47:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Now that javac generates the reference projection class as a sealed type, this patch reimplements
> `Class::valueType` and `Class::referenceType` in Java.  VM no longer has any knowledge of
> the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check for sealed types
> because inline types are not (yet) a preview feature in valhalla repo.  This workaround should be
> removed when it's time to make inline class a preview feature.

Hi Mandy,
The JVM changes look good.
Thanks, Harold

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

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


From roland at openjdk.java.net  Wed Aug 19 12:47:51 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 19 Aug 2020 12:47:51 GMT
Subject: [lworld] RFR: 8250764: [lworld] Merge JDK-8247697 in from mainline
Message-ID: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>

Brought the change for 8247697 in. Tweaked
LateInlineMHCallGenerator::do_late_inline_check() so behavior with
+AlwaysIncrementalInline is unchanged an our tests pass.

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

Commit messages:
 - 8250764: [lworld] Merge JDK-8247697 in from mainline

Changes: https://git.openjdk.java.net/valhalla/pull/153/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/153/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250764
  Stats: 28 lines in 4 files changed: 10 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/153.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/153/head:pull/153

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


From thartmann at openjdk.java.net  Wed Aug 19 13:31:16 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 Aug 2020 13:31:16 GMT
Subject: [lworld] RFR: 8250764: [lworld] Merge JDK-8247697 in from mainline
In-Reply-To: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
References: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
Message-ID: <kr3vunRUY04GFL-MnPvamxLi11zg3kMzoRFZgR9Vg_8=.dbb7f654-40b5-4ff2-965b-a6eb784a5140@github.com>

On Wed, 19 Aug 2020 12:36:57 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Brought the change for 8247697 in. Tweaked
> LateInlineMHCallGenerator::do_late_inline_check() so behavior with
> +AlwaysIncrementalInline is unchanged an our tests pass.

Looks good to me. Maybe add a comment to the changes in LateInlineMHCallGenerator::do_late_inline_check and remove the
extra brackets in doCall.cpp:188.

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

Marked as reviewed by thartmann (Committer).

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


From thartmann at openjdk.java.net  Wed Aug 19 15:00:47 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 Aug 2020 15:00:47 GMT
Subject: [lworld] RFR: 8252040: [lworld] Execute compiler unit tests in random
 order
Message-ID: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>

- Profiling of callee methods depends on execution order of unit tests. Execute tests in random order to increase
  coverage.
- At double field to test inline type
- Verify that expected NPEs are always thrown
- Fixed a test bug in TestLWorldProfiling.java (array element is not re-initialized and therefore NULL)
- Refactoring and removal of old, non-applicable TODOs

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

Commit messages:
 - 8252040: [lworld] Execute compiler unit tests in random order

Changes: https://git.openjdk.java.net/valhalla/pull/154/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/154/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252040
  Stats: 187 lines in 12 files changed: 14 ins; 8 del; 165 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/154.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/154/head:pull/154

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


From rriggs at openjdk.java.net  Wed Aug 19 19:31:20 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 19 Aug 2020 19:31:20 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <mmMHojha2Zao6J7UQ4m0U0QezfslInP_lgy7CEzMcYQ=.f20887b7-7015-4f2d-9be6-d74b88bb4a2a@github.com>

On Tue, 18 Aug 2020 19:47:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

src/java.base/share/classes/java/lang/Class.java line 631:

> 630:         } else if (isReferenceProjectionType()) {
> 631:             projectionTypes = new Class<?>[] { valueProjectionType(), this };
> 632:         } else {

It seems odd that isReferenceProjectType() uses projectionTypes before it is initialized (or is it re-initialized).
(Though there is a check for null).
The logic is not very straightforward; though I haven't looked at how to make it easier to follow.

src/java.base/share/classes/java/lang/Class.java line 666:

> 665:                 try {
> 666:                     Class<?> valType = Class.forName(cn, false, getClassLoader());
> 667:                     if (valType.isInlineClass()) {

The lookup by name implies that hidden classes can not be value classes (because they cannot be resolved by name).

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

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


From rriggs at openjdk.java.net  Wed Aug 19 19:53:09 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 19 Aug 2020 19:53:09 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <P5ywZX3484R0sGeROjX1FNbbYUOO-RQliDvipr-RRfI=.72de7367-8dd1-4ac0-bbe6-7c56065c138b@github.com>

On Tue, 18 Aug 2020 19:47:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

src/java.base/share/classes/java/lang/Class.java line 605:

> 604:         ensureProjectionTypesInited();
> 605:         System.out.println(getName() + " " + Arrays.toString(projectionTypes));
> 606:         return projectionTypes.length == 2 ? Optional.of(projectionTypes[1]) : Optional.empty();

Remove the println.

src/java.base/share/classes/java/lang/Class.java line 584:

> 583:         ensureProjectionTypesInited();
> 584:         System.out.println(getName() + " " + Arrays.toString(projectionTypes));
> 585:         return projectionTypes.length > 0 ? Optional.of(projectionTypes[0]) : Optional.empty();

println?

src/java.base/share/classes/java/lang/Class.java line 659:

> 658:         String[] subclassNames = getPermittedSubclasses0();
> 659:         System.out.println(getName() + " permits " + Arrays.toString(subclassNames));
> 660:         if (subclassNames.length == 1) {

Debug println().

src/java.base/share/classes/java/lang/Class.java line 661:

> 660:         if (subclassNames.length == 1) {
> 661:             String cn = subclassNames[0].replace('/', '.');
> 662:             int index = cn.lastIndexOf('.');

String.regionMatches() could be used to compare the substrings without making copies and it should be ok to compare the
package names without translating '/' to '.'.

src/java.base/share/classes/java/lang/Class.java line 650:

> 649:
> 650:         return valueProjectionType() != null;
> 651:     }

This path computed the valueProjecttionType and then discards it to be computed again on line 631.

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

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


From mchung at openjdk.java.net  Wed Aug 19 20:44:46 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 19 Aug 2020 20:44:46 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java
In-Reply-To: <mmMHojha2Zao6J7UQ4m0U0QezfslInP_lgy7CEzMcYQ=.f20887b7-7015-4f2d-9be6-d74b88bb4a2a@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
 <mmMHojha2Zao6J7UQ4m0U0QezfslInP_lgy7CEzMcYQ=.f20887b7-7015-4f2d-9be6-d74b88bb4a2a@github.com>
Message-ID: <SBveDCmoAPggAkDfugFdgdKHUfleVwFogbBwl7fE8UQ=.0187397b-1fb1-4aeb-9b74-b9a5a149780d@github.com>

On Wed, 19 Aug 2020 19:26:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now that javac generates the reference projection class as a sealed type,
>> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
>> VM no longer has any knowledge of the value projection type and reference projection type.
>> 
>> This patch includes a temporary workaround to disable the preview feature check
>> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
>> This workaround should be removed when it's time to make inline class a preview feature.
>
> src/java.base/share/classes/java/lang/Class.java line 666:
> 
>> 665:                 try {
>> 666:                     Class<?> valType = Class.forName(cn, false, getClassLoader());
>> 667:                     if (valType.isInlineClass()) {
> 
> The lookup by name implies that hidden classes can not be value classes (because they cannot be resolved by name).

An inline hidden class cannot be named and hence it can't be listed in `PermittedSubclasses`.  In other words, it can't
do like the language translation to translate an inline class `V` to have a pair `V$ref` and `V$val extends V$ref`.

A hidden class can be an inline class without the reference projection type.

> src/java.base/share/classes/java/lang/Class.java line 605:
> 
>> 604:         ensureProjectionTypesInited();
>> 605:         System.out.println(getName() + " " + Arrays.toString(projectionTypes));
>> 606:         return projectionTypes.length == 2 ? Optional.of(projectionTypes[1]) : Optional.empty();
> 
> Remove the println.

Thanks for catching that.

> src/java.base/share/classes/java/lang/Class.java line 584:
> 
>> 583:         ensureProjectionTypesInited();
>> 584:         System.out.println(getName() + " " + Arrays.toString(projectionTypes));
>> 585:         return projectionTypes.length > 0 ? Optional.of(projectionTypes[0]) : Optional.empty();
> 
> println?

Leftover debugging code.  Will remove

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

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


From mchung at openjdk.java.net  Wed Aug 19 21:03:32 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 19 Aug 2020 21:03:32 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v2]
In-Reply-To: <P5ywZX3484R0sGeROjX1FNbbYUOO-RQliDvipr-RRfI=.72de7367-8dd1-4ac0-bbe6-7c56065c138b@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
 <P5ywZX3484R0sGeROjX1FNbbYUOO-RQliDvipr-RRfI=.72de7367-8dd1-4ac0-bbe6-7c56065c138b@github.com>
Message-ID: <0MZnDaZO2cS_qL_HMI25xStwpGboQZlXITRiCzEjdAs=.b2b75179-0a64-4721-bbdd-cad423092be5@github.com>

On Wed, 19 Aug 2020 19:50:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since
>> the last revision:
>>  - remove debug println statement
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into projection-types
>>  - supports_sealed_types checks only the major version
>>  - remove unused import
>>  - disable preview feature check for sealed types
>>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lworld
>>  - implement Class::referenceType and Class::valueType in Java
>
> src/java.base/share/classes/java/lang/Class.java line 650:
> 
>> 649:
>> 650:         return valueProjectionType() != null;
>> 651:     }
> 
> This path computed the valueProjecttionType and then discards it to be computed again on line 631.

I don't think this path is performance critical.  We can look into this if performance turns out to be an issue.

> src/java.base/share/classes/java/lang/Class.java line 661:
> 
>> 660:         if (subclassNames.length == 1) {
>> 661:             String cn = subclassNames[0].replace('/', '.');
>> 662:             int index = cn.lastIndexOf('.');
> 
> String.regionMatches() could be used to compare the substrings without making copies and it should be ok to compare the
> package names without translating '/' to '.'.

getPackageName() returns a "."-separated package name (not the internal form). I will leave it as is.

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

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


From mchung at openjdk.java.net  Wed Aug 19 21:03:28 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 19 Aug 2020 21:03:28 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v2]
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <WBHoS0JJIKThHqvpgdgW8kbYyoJQ80ziqdMGcHlMvm4=.8f183f47-ad8d-4f51-a576-19101d223968@github.com>

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

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

 - remove debug println statement
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into projection-types
 - supports_sealed_types checks only the major version
 - remove unused import
 - disable preview feature check for sealed types
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lworld
 - implement Class::referenceType and Class::valueType in Java

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/152/files
  - new: https://git.openjdk.java.net/valhalla/pull/152/files/65d3cc87..36d4d860

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/152/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/152/webrev.00-01

  Stats: 528 lines in 23 files changed: 327 ins; 49 del; 152 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/152/head:pull/152

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


From mchung at openjdk.java.net  Thu Aug 20 01:47:31 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Aug 2020 01:47:31 GMT
Subject: [lworld] RFR: JDK-8252061 [lword] Support Object::toString for inline
 type
Message-ID: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>

This adds the `Object::toString` support for inline classes.  This will replace the need
for javac to generate the `toString` method to call the bootstrap method.

JDK-8206077 will revisit the overlap of `ValueBootstrapMethods` and `ObjectMethods`.

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

Commit messages:
 - update javadoc of Object::toString
 - fix ValueModifierTest for this change'
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into substitutability
 - [lworld] Object::toString support for inline type

Changes: https://git.openjdk.java.net/valhalla/pull/155/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/155/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252061
  Stats: 451 lines in 12 files changed: 150 ins; 264 del; 37 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/155.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/155/head:pull/155

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


From jrose at openjdk.java.net  Thu Aug 20 02:48:29 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Thu, 20 Aug 2020 02:48:29 GMT
Subject: [lworld] RFR: JDK-8252061 [lword] Support Object::toString for
 inline type
In-Reply-To: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
References: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
Message-ID: <Ajc5J7Mkwjov3BYEoDPan8YwQvE1LqghOMM3pw2R2iM=.dd5105d7-4342-4998-9559-7f32f8f455a0@github.com>

On Thu, 20 Aug 2020 01:40:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This adds the `Object::toString` support for inline classes.  This will replace the need
> for javac to generate the `toString` method to call the bootstrap method.
> 
> JDK-8206077 will revisit the overlap of `ValueBootstrapMethods` and `ObjectMethods`.
> 
> This patch also removes the private `isSubstituable0` method and makes sure
> that `isSubstitutable` does not have `acmp` instruction and can be invoked by VM.

A couple of comments:

1. In order for this to perform well, the code for each generated toString method needs to be JIT-ted, and to be
reached quickly (or even inlined) via ClassValue::get.  Optimization work (to be done later) should probably consider
[JDK-8238260](https://bugs.openjdk.java.net/browse/JDK-8238260).

2. We should try to handle Record subtypes the same way.  Putting funky bytecodes into classfiles, even using indy, is
worse than allowing Object::toString (and equals and hashCode) to vector through a specified, customized method, using
ClassValue::get.

3. I think it is reasonable to have special intrinsic logic in the JIT to hurry along the previous two steps, although
in the long run the JVM should have a good story (perhaps using ClassValue, perhaps not) for auto-expanded method
bodies.

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

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


From sadayapalam at openjdk.java.net  Thu Aug 20 05:00:39 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 20 Aug 2020 05:00:39 GMT
Subject: [lworld] RFR: JDK-8252061 [lword] Support Object::toString for
 inline type
In-Reply-To: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
References: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
Message-ID: <gdu_f_nAhgTjzo7UUlJkwWkcs_XRKyUS2AEkyTvWW7c=.f5ab61b0-8edd-4347-9d59-ce65c13dbc68@github.com>

On Thu, 20 Aug 2020 01:40:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This adds the `Object::toString` support for inline classes.  This will replace the need
> for javac to generate the `toString` method to call the bootstrap method.
> 
> JDK-8206077 will revisit the overlap of `ValueBootstrapMethods` and `ObjectMethods`.
> 
> This patch also removes the private `isSubstituable0` method and makes sure
> that `isSubstitutable` does not have `acmp` instruction and can be invoked by VM.

+1 for javac changes

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

Marked as reviewed by sadayapalam (Committer).

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


From thartmann at openjdk.java.net  Thu Aug 20 07:48:47 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 07:48:47 GMT
Subject: [lworld] RFR: 8252040: [lworld] Execute compiler unit tests in
 random order
In-Reply-To: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>
References: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>
Message-ID: <x0SWijM3U7ipGXcN6Esx6aZ3ehXEV9gqlBJOWmBU0NI=.e6d4b6c9-3869-4744-a8a7-c009e69e8fe4@github.com>

On Wed, 19 Aug 2020 14:53:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> - Profiling of callee methods depends on execution order of unit tests. Execute tests in random order to increase
>   coverage.
> - At double field to test inline type
> - Verify that expected NPEs are always thrown
> - Fixed a test bug in TestLWorldProfiling.java (array element is not re-initialized and therefore NULL)
> - Refactoring and removal of old, non-applicable TODOs

Executing tests in random order triggered at least 4 new bugs that I'll fix before pushing this change.

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

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


From rwestrel at redhat.com  Thu Aug 20 09:24:30 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 20 Aug 2020 11:24:30 +0200
Subject: [lworld] RFR: 8250764: [lworld] Merge JDK-8247697 in from mainline
In-Reply-To: <kr3vunRUY04GFL-MnPvamxLi11zg3kMzoRFZgR9Vg_8=.dbb7f654-40b5-4ff2-965b-a6eb784a5140@github.com>
References: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
 <kr3vunRUY04GFL-MnPvamxLi11zg3kMzoRFZgR9Vg_8=.dbb7f654-40b5-4ff2-965b-a6eb784a5140@github.com>
Message-ID: <874kox3c1d.fsf@redhat.com>


> Looks good to me. Maybe add a comment to the changes in LateInlineMHCallGenerator::do_late_inline_check and remove the
> extra brackets in doCall.cpp:188.

I'll do that. Thanks for the review.

Roland.



From roland at openjdk.java.net  Thu Aug 20 09:31:07 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 09:31:07 GMT
Subject: [lworld] RFR: 8251527: CTW: C2 (Shenandoah) compilation fails with
 SEGV due to unhandled catchproj == NULL
Message-ID: <73j-cF2UM9vHxveVq-EZ4e-6lciPy7YJLflNLsDSk9M=.2da74c34-803d-40b3-9761-444aa684834f@github.com>

In PhaseIdealLoop::flatten_array_element_type_check(), when pushing:

(LoadKlass (AddP (CastPP ...

through a Phi, the control of CastPP clone is set to region->in(i) but
the AddP clone control is set to get_ctrl(phi->in(i)) which can be
above region->in(i) while the AddP is below the CastPP. Fix is to use
region->in(i) for all clones.

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

Commit messages:
 - fix control used when pushing LoadKlass thru phi in PhaseIdealLoop::flatten_array_element_type_check()

Changes: https://git.openjdk.java.net/valhalla/pull/156/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/156/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251527
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/156.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/156/head:pull/156

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


From roland at openjdk.java.net  Thu Aug 20 09:41:11 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 09:41:11 GMT
Subject: [lworld] Withdrawn: 8251527: CTW: C2 (Shenandoah) compilation fails
 with SEGV due to unhandled catchproj == NULL
In-Reply-To: <73j-cF2UM9vHxveVq-EZ4e-6lciPy7YJLflNLsDSk9M=.2da74c34-803d-40b3-9761-444aa684834f@github.com>
References: <73j-cF2UM9vHxveVq-EZ4e-6lciPy7YJLflNLsDSk9M=.2da74c34-803d-40b3-9761-444aa684834f@github.com>
Message-ID: <bgH6jDm7cfv6ZufXSCS5sGR43qfLENV7ZMgEDyf2Oxo=.85b7b4be-b068-4120-a26f-3cac391f0509@github.com>

On Thu, 20 Aug 2020 09:23:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> In PhaseIdealLoop::flatten_array_element_type_check(), when pushing:
> 
> (LoadKlass (AddP (CastPP ...
> 
> through a Phi, the control of CastPP clone is set to region->in(i) but
> the AddP clone control is set to get_ctrl(phi->in(i)) which can be
> above region->in(i) while the AddP is below the CastPP. Fix is to use
> region->in(i) for all clones.

This pull request has been closed without being integrated.

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

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


From roland at openjdk.java.net  Thu Aug 20 09:41:09 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 09:41:09 GMT
Subject: [lworld] RFR: 8251527: CTW: C2 (Shenandoah) compilation fails
 with SEGV due to unhandled catchproj == NULL
In-Reply-To: <73j-cF2UM9vHxveVq-EZ4e-6lciPy7YJLflNLsDSk9M=.2da74c34-803d-40b3-9761-444aa684834f@github.com>
References: <73j-cF2UM9vHxveVq-EZ4e-6lciPy7YJLflNLsDSk9M=.2da74c34-803d-40b3-9761-444aa684834f@github.com>
Message-ID: <185Ce2MDV7mObcCnuVOzgXVCnnHNOp359ffHix2n7wk=.40444e0f-2379-4ea5-b1b7-f2de9625a1b3@github.com>

On Thu, 20 Aug 2020 09:23:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> In PhaseIdealLoop::flatten_array_element_type_check(), when pushing:
> 
> (LoadKlass (AddP (CastPP ...
> 
> through a Phi, the control of CastPP clone is set to region->in(i) but
> the AddP clone control is set to get_ctrl(phi->in(i)) which can be
> above region->in(i) while the AddP is below the CastPP. Fix is to use
> region->in(i) for all clones.

Used incorrect bug id. Closing it,

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

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


From roland at openjdk.java.net  Thu Aug 20 09:47:31 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 09:47:31 GMT
Subject: [lworld] RFR: 8250764: [lworld] Merge JDK-8247697 in from
 mainline [v2]
In-Reply-To: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
References: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
Message-ID: <SuM1dNvizHFrvoW85f9J0wb00ExyHtvlGN2oCOOev0U=.00d68296-37fa-421c-8bca-1ca334c7d6e8@github.com>

> Brought the change for 8247697 in. Tweaked
> LateInlineMHCallGenerator::do_late_inline_check() so behavior with
> +AlwaysIncrementalInline is unchanged an our tests pass.

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/153/files
  - new: https://git.openjdk.java.net/valhalla/pull/153/files/3599d1d2..d2e9d177

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/153/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/153/webrev.00-01

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

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


From roland at openjdk.java.net  Thu Aug 20 09:49:33 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 09:49:33 GMT
Subject: [lworld] RFR: 8250511: [lworld] C2 compilation crashes in
 PhaseIdealLoop::spinup
Message-ID: <OVq1dE_HeEMk-gJSLVusSCg-LXfS8Odzom2xRWU5gUs=.2a2e213d-143c-4903-86dc-963ece80d3f4@github.com>

In PhaseIdealLoop::flatten_array_element_type_check(), when pushing:

(LoadKlass (AddP (CastPP ...

through a Phi, the control of CastPP clone is set to region->in(i) but
the AddP clone control is set to get_ctrl(phi->in(i)) which can be
above region->in(i) while the AddP is below the CastPP. Fix is to use
region->in(i) for all clones.

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

Commit messages:
 - fix control used when pushing LoadKlass thru phi in PhaseIdealLoop::flatten_array_element_type_check()

Changes: https://git.openjdk.java.net/valhalla/pull/157/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/157/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250511
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/157.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/157/head:pull/157

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


From roland at openjdk.java.net  Thu Aug 20 09:57:28 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 09:57:28 GMT
Subject: [lworld] Integrated: 8250764: [lworld] Merge JDK-8247697 in from
 mainline
In-Reply-To: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
References: <KODeHs0Fzc6vvdqjgaA3V6LGGmZSdjuw8ZUDsuXhhfQ=.24376936-d57f-4e40-a1d3-865d038bbee9@github.com>
Message-ID: <0eXBrkpFFKD4cQQZEkJID0_EVeIizmWsojN-7Q7B2LA=.80b796e9-e9b5-4f0b-baae-28fdde375724@github.com>

On Wed, 19 Aug 2020 12:36:57 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Brought the change for 8247697 in. Tweaked
> LateInlineMHCallGenerator::do_late_inline_check() so behavior with
> +AlwaysIncrementalInline is unchanged an our tests pass.

This pull request has now been integrated.

Changeset: b697e163
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b697e163
Stats:     31 lines in 4 files changed: 5 ins; 13 del; 13 mod

8250764: [lworld] Merge JDK-8247697 in from mainline

Reviewed-by: thartmann

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

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


From thartmann at openjdk.java.net  Thu Aug 20 10:40:24 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 10:40:24 GMT
Subject: [lworld] RFR: 8250511: [lworld] C2 compilation crashes in
 PhaseIdealLoop::spinup
In-Reply-To: <OVq1dE_HeEMk-gJSLVusSCg-LXfS8Odzom2xRWU5gUs=.2a2e213d-143c-4903-86dc-963ece80d3f4@github.com>
References: <OVq1dE_HeEMk-gJSLVusSCg-LXfS8Odzom2xRWU5gUs=.2a2e213d-143c-4903-86dc-963ece80d3f4@github.com>
Message-ID: <PT1e5eM6Ip6-TUaC9Qbd7pmTMniTdfUNCu08HbFArBA=.181f4992-dcd8-4c8a-917e-96e4c2d0f1ad@github.com>

On Thu, 20 Aug 2020 09:42:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> In PhaseIdealLoop::flatten_array_element_type_check(), when pushing:
> 
> (LoadKlass (AddP (CastPP ...
> 
> through a Phi, the control of CastPP clone is set to region->in(i) but
> the AddP clone control is set to get_ctrl(phi->in(i)) which can be
> above region->in(i) while the AddP is below the CastPP. Fix is to use
> region->in(i) for all clones.

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

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


From roland at openjdk.java.net  Thu Aug 20 11:08:02 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 20 Aug 2020 11:08:02 GMT
Subject: [lworld] Integrated: 8250511: [lworld] C2 compilation crashes in
 PhaseIdealLoop::spinup
In-Reply-To: <OVq1dE_HeEMk-gJSLVusSCg-LXfS8Odzom2xRWU5gUs=.2a2e213d-143c-4903-86dc-963ece80d3f4@github.com>
References: <OVq1dE_HeEMk-gJSLVusSCg-LXfS8Odzom2xRWU5gUs=.2a2e213d-143c-4903-86dc-963ece80d3f4@github.com>
Message-ID: <xeJiz1P0opai7nY1PQ5zEyUoef4ULrKz6kF1rNZrSA0=.7309a729-31fa-484e-ad7d-6b0e7eee2e87@github.com>

On Thu, 20 Aug 2020 09:42:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> In PhaseIdealLoop::flatten_array_element_type_check(), when pushing:
> 
> (LoadKlass (AddP (CastPP ...
> 
> through a Phi, the control of CastPP clone is set to region->in(i) but
> the AddP clone control is set to get_ctrl(phi->in(i)) which can be
> above region->in(i) while the AddP is below the CastPP. Fix is to use
> region->in(i) for all clones.

This pull request has now been integrated.

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

8250511: [lworld] C2 compilation crashes in PhaseIdealLoop::spinup

Reviewed-by: thartmann

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

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


From rwestrel at redhat.com  Thu Aug 20 11:03:46 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 20 Aug 2020 13:03:46 +0200
Subject: [lworld] RFR: 8250511: [lworld] C2 compilation crashes in
 PhaseIdealLoop::spinup
In-Reply-To: <PT1e5eM6Ip6-TUaC9Qbd7pmTMniTdfUNCu08HbFArBA=.181f4992-dcd8-4c8a-917e-96e4c2d0f1ad@github.com>
References: <OVq1dE_HeEMk-gJSLVusSCg-LXfS8Odzom2xRWU5gUs=.2a2e213d-143c-4903-86dc-963ece80d3f4@github.com>
 <PT1e5eM6Ip6-TUaC9Qbd7pmTMniTdfUNCu08HbFArBA=.181f4992-dcd8-4c8a-917e-96e4c2d0f1ad@github.com>
Message-ID: <871rk137fx.fsf@redhat.com>


> Looks good to me.

Thanks for the review.

Roland.



From thartmann at openjdk.java.net  Thu Aug 20 14:33:34 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 14:33:34 GMT
Subject: [lworld] RFR: 8252110: [lworld] C2 compilation crashes with SIGSEGV
 in AddPNode::Value
Message-ID: <zzhT0z0wDJBZWQlyX1moY56vsZI306Y1eKJSXf1Df4c=.a67f8eeb-ea2b-4f6b-b687-11f080147e4c@github.com>

The receiver type check emitted by the PredictedCallGenerator needs to handle InlineTypeNodes.

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

Commit messages:
 - 8252110: [lworld] C2 compilation crashes with SIGSEGV in AddPNode::Value

Changes: https://git.openjdk.java.net/valhalla/pull/160/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/160/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252110
  Stats: 14 lines in 1 file changed: 11 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/160.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/160/head:pull/160

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


From thartmann at openjdk.java.net  Thu Aug 20 14:34:53 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 14:34:53 GMT
Subject: [lworld] RFR: 8252112: [lworld] Deoptimization fails when trying to
 re-assign empty inline type elements of a flattened array
Message-ID: <HyrRORs8Yd6TsgVYQG5JVX1pUQe4Vv0ZX3-ME8G68vU=.1aa1d3ca-6a04-4dbc-998d-4ccb4eadd747@github.com>

Deoptimization::reassign_flat_array_elements needs to handle flat arrays with empty inline type elements.

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

Commit messages:
 - 8252112: [lworld] Deoptimization fails when trying to re-assign empty inline type elements of a flattened array

Changes: https://git.openjdk.java.net/valhalla/pull/158/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/158/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252112
  Stats: 19 lines in 2 files changed: 19 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/158.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/158/head:pull/158

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


From thartmann at openjdk.java.net  Thu Aug 20 14:36:11 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 14:36:11 GMT
Subject: [lworld] RFR: 8252111: [lworld] C2 intrinsic needs to handle unsafe
 access to non-flattened field of constant inline type holder
Message-ID: <lp4p5GMSCaOXfJ-oG51vCr2YJpcnhiVwSCl_nfW04Wg=.89fae1eb-9bff-486f-b96e-e1e900a3ead9@github.com>

The C2 intrinsic for unsafe accesses fails to determine the field value when accessing a non-flattened field of a
constant inline type holder.

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

Commit messages:
 - 8252111: [lworld] C2 intrinsic needs to handle unsafe access to non-flattened field of constant inline type holder

Changes: https://git.openjdk.java.net/valhalla/pull/159/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/159/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252111
  Stats: 28 lines in 2 files changed: 17 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/159.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/159/head:pull/159

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


From thartmann at openjdk.java.net  Thu Aug 20 14:37:39 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 14:37:39 GMT
Subject: [lworld] RFR: 8252109: [lworld] C2 compilation fails with
 assert(\!has_phi_inputs(region)) failed: already cloned with phis
Message-ID: <Pl050f13J7754Y5W6XT7EnUFJgGVlna4589-qIHPdYk=.0a4aadbd-52f6-4565-8091-3847413aa11e@github.com>

Assert is too strong because during a PhiNode::Ideal transformation, some inputs of an InlineTypeNode might already be
PhiNodes  of the same region.

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

Commit messages:
 - 8252109: [lworld] C2 compilation fails with assert(\!has_phi_inputs(region)) failed: already cloned with phis

Changes: https://git.openjdk.java.net/valhalla/pull/161/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/161/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252109
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/161.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/161/head:pull/161

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


From thartmann at openjdk.java.net  Thu Aug 20 15:25:11 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Aug 2020 15:25:11 GMT
Subject: [lworld] RFR: 8252111: [lworld] C2 intrinsic needs to handle
 unsafe access to non-flattened field of constant inline type holder [v2]
In-Reply-To: <lp4p5GMSCaOXfJ-oG51vCr2YJpcnhiVwSCl_nfW04Wg=.89fae1eb-9bff-486f-b96e-e1e900a3ead9@github.com>
References: <lp4p5GMSCaOXfJ-oG51vCr2YJpcnhiVwSCl_nfW04Wg=.89fae1eb-9bff-486f-b96e-e1e900a3ead9@github.com>
Message-ID: <_NiZeXfwPDk1dEkS5nWXannnXBizOhbIrFolrSmsxYE=.9306fd54-7b3a-4cf7-8c14-758f6c50f791@github.com>

> The C2 intrinsic for unsafe accesses fails to determine the field value when accessing a non-flattened field of a
> constant inline type holder.

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

  Forgot to rename field

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/159/files
  - new: https://git.openjdk.java.net/valhalla/pull/159/files/d4d58592..2cf0c249

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/159/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/159/webrev.00-01

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

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


From mchung at openjdk.java.net  Thu Aug 20 19:02:20 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Aug 2020 19:02:20 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v3]
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <jPIQOyZKnGa9so_Dvnn_aq_2nPOYObzapndqCjLGue8=.6b40849c-2546-487d-be81-a65dc9e67396@github.com>

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

Mandy Chung 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' of https://github.com/openjdk/valhalla into projection-types
 - clean up the initialization of projectionTypes field
 - remove debug println statement
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into projection-types
 - supports_sealed_types checks only the major version
 - remove unused import
 - disable preview feature check for sealed types
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into lworld
 - implement Class::referenceType and Class::valueType in Java

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/152/files
  - new: https://git.openjdk.java.net/valhalla/pull/152/files/36d4d860..0e576ad3

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/152/webrev.02
 - incr: https://webrevs.openjdk.java.net/valhalla/152/webrev.01-02

  Stats: 123 lines in 6 files changed: 77 ins; 15 del; 31 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/152/head:pull/152

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


From mchung at openjdk.java.net  Thu Aug 20 19:11:50 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Aug 2020 19:11:50 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v4]
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <eyelaJM0A7RJxi25KAWT_O-ENSDHBM_qtu8A5HqsiMw=.a7a09ae6-31c5-4f4b-92b6-5acb80464b1c@github.com>

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  fix comment

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/152/files
  - new: https://git.openjdk.java.net/valhalla/pull/152/files/0e576ad3..1dcd5f3b

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/152/webrev.03
 - incr: https://webrevs.openjdk.java.net/valhalla/152/webrev.02-03

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

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


From mchung at openjdk.java.net  Thu Aug 20 19:44:59 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Aug 2020 19:44:59 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v5]
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <7tAdiHVWFo5uw9-5JcyLVr1J-K-gTrdH9xi52i_7NUk=.e324546f-42ec-4ec8-8d72-da43473dcd8d@github.com>

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  improve getProjectionTypes per Roger's suggestion

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/152/files
  - new: https://git.openjdk.java.net/valhalla/pull/152/files/1dcd5f3b..de9d8505

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/152/webrev.04
 - incr: https://webrevs.openjdk.java.net/valhalla/152/webrev.03-04

  Stats: 40 lines in 1 file changed: 18 ins; 21 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/152.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/152/head:pull/152

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


From mchung at openjdk.java.net  Thu Aug 20 19:45:26 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Aug 2020 19:45:26 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v5]
In-Reply-To: <mmMHojha2Zao6J7UQ4m0U0QezfslInP_lgy7CEzMcYQ=.f20887b7-7015-4f2d-9be6-d74b88bb4a2a@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
 <mmMHojha2Zao6J7UQ4m0U0QezfslInP_lgy7CEzMcYQ=.f20887b7-7015-4f2d-9be6-d74b88bb4a2a@github.com>
Message-ID: <nskLfT3nllT22qcPzhw5jwQsEqx0JFWslwKOTHaojxA=.79a5c9c0-e774-4706-bfa7-59fd5c47d6f5@github.com>

On Wed, 19 Aug 2020 19:25:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve getProjectionTypes per Roger's suggestion
>
> src/java.base/share/classes/java/lang/Class.java line 631:
> 
>> 630:         } else if (isReferenceProjectionType()) {
>> 631:             projectionTypes = new Class<?>[] { valueProjectionType(), this };
>> 632:         } else {
> 
> It seems odd that isReferenceProjectType() uses projectionTypes before it is initialized (or is it re-initialized).
> (Though there is a check for null).
> The logic is not very straightforward; though I haven't looked at how to make it easier to follow.

I have redone the logic and incorporated your suggestion in `getProjectionType` method.

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

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


From rriggs at openjdk.java.net  Thu Aug 20 20:21:41 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 20 Aug 2020 20:21:41 GMT
Subject: [lworld] RFR: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java [v5]
In-Reply-To: <7tAdiHVWFo5uw9-5JcyLVr1J-K-gTrdH9xi52i_7NUk=.e324546f-42ec-4ec8-8d72-da43473dcd8d@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
 <7tAdiHVWFo5uw9-5JcyLVr1J-K-gTrdH9xi52i_7NUk=.e324546f-42ec-4ec8-8d72-da43473dcd8d@github.com>
Message-ID: <E306SGDQ8VQ1qh7DigjKHL-RuOIFi4-8copPhVVQD9Q=.63235117-b859-41f6-8af1-9549acf897f2@github.com>

On Thu, 20 Aug 2020 19:44:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Now that javac generates the reference projection class as a sealed type,
>> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
>> VM no longer has any knowledge of the value projection type and reference projection type.
>> 
>> This patch includes a temporary workaround to disable the preview feature check
>> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
>> This workaround should be removed when it's time to make inline class a preview feature.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve getProjectionTypes per Roger's suggestion

Marked as reviewed by rriggs (Committer).

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

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


From mchung at openjdk.java.net  Thu Aug 20 20:24:48 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 20 Aug 2020 20:24:48 GMT
Subject: [lworld] Integrated: JDK-8251986: [lworld] implement Class::valueType
 and Class::referenceType in Java
In-Reply-To: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
References: <tbI9FPB-v28Oq2O1A4fETodTwQKy4GnZ3hjV4xlTiqI=.6ae44cbc-464e-43db-8bd9-6b81ff7806d1@github.com>
Message-ID: <8Jtu8lvty8cAZUzh39mFOhVi7UR1JiFQMW2NrqfyODA=.c04956ca-6b0d-4247-9364-df565231b32f@github.com>

On Tue, 18 Aug 2020 19:47:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Now that javac generates the reference projection class as a sealed type,
> this patch reimplements  `Class::valueType` and `Class::referenceType` in Java.
> VM no longer has any knowledge of the value projection type and reference projection type.
> 
> This patch includes a temporary workaround to disable the preview feature check
> for sealed types because inline types are not (yet) a preview feature in valhalla repo.
> This workaround should be removed when it's time to make inline class a preview feature.

This pull request has now been integrated.

Changeset: a5aa3a9d
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a5aa3a9d
Stats:     209 lines in 5 files changed: 54 ins; 135 del; 20 mod

8251986: [lworld] implement Class::valueType and Class::referenceType in Java

Reviewed-by: rriggs

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

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


From thartmann at openjdk.java.net  Fri Aug 21 07:58:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 Aug 2020 07:58:18 GMT
Subject: [lworld] Integrated: 8252110: [lworld] C2 compilation crashes with
 SIGSEGV in AddPNode::Value
In-Reply-To: <zzhT0z0wDJBZWQlyX1moY56vsZI306Y1eKJSXf1Df4c=.a67f8eeb-ea2b-4f6b-b687-11f080147e4c@github.com>
References: <zzhT0z0wDJBZWQlyX1moY56vsZI306Y1eKJSXf1Df4c=.a67f8eeb-ea2b-4f6b-b687-11f080147e4c@github.com>
Message-ID: <cp1HOq8pnWKxDauXW4dN9bREzl6SKG4FGo6BdRqUfSA=.a7339d0a-7fae-4197-a9b4-01c6775fc043@github.com>

On Thu, 20 Aug 2020 14:26:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The receiver type check emitted by the PredictedCallGenerator needs to handle InlineTypeNodes.

This pull request has now been integrated.

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

8252110: [lworld] C2 compilation crashes with SIGSEGV in AddPNode::Value

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

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


From thartmann at openjdk.java.net  Fri Aug 21 07:58:37 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 Aug 2020 07:58:37 GMT
Subject: [lworld] Integrated: 8252112: [lworld] Deoptimization fails when
 trying to re-assign empty inline type elements of a flattened array
In-Reply-To: <HyrRORs8Yd6TsgVYQG5JVX1pUQe4Vv0ZX3-ME8G68vU=.1aa1d3ca-6a04-4dbc-998d-4ccb4eadd747@github.com>
References: <HyrRORs8Yd6TsgVYQG5JVX1pUQe4Vv0ZX3-ME8G68vU=.1aa1d3ca-6a04-4dbc-998d-4ccb4eadd747@github.com>
Message-ID: <BsdRw7HiKaZoqp4_V9hxFSALOgI-LyPDjIURi2rwLQc=.d867ed8f-430a-4b71-9bf3-30f359695f98@github.com>

On Thu, 20 Aug 2020 14:26:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Deoptimization::reassign_flat_array_elements needs to handle flat arrays with empty inline type elements.

This pull request has now been integrated.

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

8252112: [lworld] Deoptimization fails when trying to re-assign empty inline type elements of a flattened array

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

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


From thartmann at openjdk.java.net  Fri Aug 21 07:58:03 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 Aug 2020 07:58:03 GMT
Subject: [lworld] Integrated: 8252109: [lworld] C2 compilation fails with
 assert(!has_phi_inputs(region)) failed: already cloned with phis
In-Reply-To: <Pl050f13J7754Y5W6XT7EnUFJgGVlna4589-qIHPdYk=.0a4aadbd-52f6-4565-8091-3847413aa11e@github.com>
References: <Pl050f13J7754Y5W6XT7EnUFJgGVlna4589-qIHPdYk=.0a4aadbd-52f6-4565-8091-3847413aa11e@github.com>
Message-ID: <b8yyW6L9w8joeXaehDgkjCIg8GWvi5vQU6-BlCCOvQ8=.304f0285-66a7-421a-b6b2-e4fb779f9d54@github.com>

On Thu, 20 Aug 2020 14:26:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Assert is too strong because during a PhiNode::Ideal transformation, some inputs of an InlineTypeNode might already be
> PhiNodes  of the same region.

This pull request has now been integrated.

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

8252109: [lworld] C2 compilation fails with assert(!has_phi_inputs(region)) failed: already cloned with phis

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

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


From thartmann at openjdk.java.net  Fri Aug 21 08:01:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 Aug 2020 08:01:18 GMT
Subject: [lworld] Integrated: 8252111: [lworld] C2 intrinsic needs to handle
 unsafe access to non-flattened field of constant inline type holder
In-Reply-To: <lp4p5GMSCaOXfJ-oG51vCr2YJpcnhiVwSCl_nfW04Wg=.89fae1eb-9bff-486f-b96e-e1e900a3ead9@github.com>
References: <lp4p5GMSCaOXfJ-oG51vCr2YJpcnhiVwSCl_nfW04Wg=.89fae1eb-9bff-486f-b96e-e1e900a3ead9@github.com>
Message-ID: <Iex5NAurY9K7gZxPyGgZSVlIamiQx6hVByeiAfWz9fQ=.1c3f9897-0b1d-40d0-96cf-fb9232a3b236@github.com>

On Thu, 20 Aug 2020 14:26:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The C2 intrinsic for unsafe accesses fails to determine the field value when accessing a non-flattened field of a
> constant inline type holder.

This pull request has now been integrated.

Changeset: c75f0f14
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c75f0f14
Stats:     28 lines in 2 files changed: 4 ins; 17 del; 7 mod

8252111: [lworld] C2 intrinsic needs to handle unsafe access to non-flattened field of constant inline type holder

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

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


From jc at sahnwaldt.de  Fri Aug 21 15:02:14 2020
From: jc at sahnwaldt.de (Jona Christopher Sahnwaldt)
Date: Fri, 21 Aug 2020 17:02:14 +0200
Subject: efficiency vs. immutability of inline classes
Message-ID: <CAEQewpqCJ56Ga6TaKseKYtz-q9hk8zfWrOYkayW9k+4+nPgH6w@mail.gmail.com>

Hi,

In C, it's common to have arrays of structs. Because structs are mutable, I
can iterate through an array and update a single field in each struct.

To do something similar with Java inline classes, since they are immutable,
I'd have to make a modified copy of each array item and copy the result
back into the array. This might be much less efficient than the C approach.

First a general question: This has probably been discussed before (but I
didn't find it in the list archive). What's the current thinking? Could
someone point me to any discussions or results? Thanks!

More specific questions: I recently read about "functional transformation
of immutable objects".
https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md
This feature may initially be intended for records, but let's apply it to
inline classes:

InlineType[] a = ...;  // InlineType has a field x
for (int i = 0; i < a.length; i++)
    a[i] = a[i] with { x = 3; };

Semantically, this makes two copies (from array to local variable and back).

Could the JIT be smart enough to transform this into an update of a single
field, without any copies of the whole object?

Or maybe we should give the JIT a hint and allow compound assignment
analogous to += et al.?

a[i] = with { x = 3; };

or

a[i] with= { x = 3; };

OK, the syntax isn't pretty, but maybe it helps improve performance... ;)

Regards,
Christopher


From brian.goetz at oracle.com  Fri Aug 21 15:33:24 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 21 Aug 2020 11:33:24 -0400
Subject: efficiency vs. immutability of inline classes
In-Reply-To: <CAEQewpqCJ56Ga6TaKseKYtz-q9hk8zfWrOYkayW9k+4+nPgH6w@mail.gmail.com>
References: <CAEQewpqCJ56Ga6TaKseKYtz-q9hk8zfWrOYkayW9k+4+nPgH6w@mail.gmail.com>
Message-ID: <d7a0715c-0c95-3bf9-115f-9e43450fa508@oracle.com>



> First a general question: This has probably been discussed before (but I
> didn't find it in the list archive). What's the current thinking? Could
> someone point me to any discussions or results? Thanks!
>
> More specific questions: I recently read about "functional transformation
> of immutable objects".
> https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md
> This feature may initially be intended for records, but let's apply it to
> inline classes:

Yes, that's the plan.? The document says that straight out; this is a 
feature about transformations on objects, which is not restricted to 
records, or inline classes, or even immutable classes.? Records just 
happen to come out of the box with all the moving parts needed to hook 
this up trivially, but other classes will join the fun soon, and inlines 
are likely to be among the best customers.

> InlineType[] a = ...;  // InlineType has a field x
> for (int i = 0; i < a.length; i++)
>      a[i] = a[i] with { x = 3; };
>
> Semantically, this makes two copies (from array to local variable and back).
>
> Could the JIT be smart enough to transform this into an update of a single
> field, without any copies of the whole object?

Absolutely.? That's an essential aspect of the inline class design; the 
restrictions on inline classes are designed, in part, to support these 
sorts of optimizations as a casual mid-day snack.

The `with` syntax is a distraction in this analysis; imagine the above 
were merely

 ??? a[i] = new InlineType(3, a.y())

The constructor is just a static factory method, which will routinely be 
inlined here because it's tiny.? Same for the y() accessor.? After 
inlining, SSA transformation, scalarization, value numbering, and 
register allocation, what will happen is that the x and y fields of your 
(hot) loop index will already be in registers, the store of a.y = a.y() 
will be trivially observed as dead, and what you'll get is "load #3 into 
register."

If the language automates this with `with`, same deal, because the 
language will generate ctor/dtor calls, which will get inlined, which 
are just scrutable data movement, which the JIT will similarly crush.

> Or maybe we should give the JIT a hint and allow compound assignment
> analogous to += et al.?
>
> a[i] = with { x = 3; };
>
> or
>
> a[i] with= { x = 3; };

A kind offer, but the JIT doesn't need this sort of help! Identifying 
these sorts of idioms is routine fare for compilers.

A better argument here would be that _humans_ would like this sort of 
help.? That's a valid discussion, but not needed at this point.

Cheers,
-Brian



From jc at sahnwaldt.de  Fri Aug 21 16:06:45 2020
From: jc at sahnwaldt.de (Jona Christopher Sahnwaldt)
Date: Fri, 21 Aug 2020 18:06:45 +0200
Subject: efficiency vs. immutability of inline classes
In-Reply-To: <d7a0715c-0c95-3bf9-115f-9e43450fa508@oracle.com>
References: <CAEQewpqCJ56Ga6TaKseKYtz-q9hk8zfWrOYkayW9k+4+nPgH6w@mail.gmail.com>
 <d7a0715c-0c95-3bf9-115f-9e43450fa508@oracle.com>
Message-ID: <CAEQewpr6F-AewsXOs+6Y5xCA3QkCDxaY2tguXY4110XZQoHYEg@mail.gmail.com>

On Fri, Aug 21, 2020, 17:33 Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> > First a general question: This has probably been discussed before (but I
> > didn't find it in the list archive). What's the current thinking? Could
> > someone point me to any discussions or results? Thanks!
> >
> > More specific questions: I recently read about "functional transformation
> > of immutable objects".
> >
> https://github.com/openjdk/amber-docs/blob/master/eg-drafts/reconstruction-records-and-classes.md
> > This feature may initially be intended for records, but let's apply it to
> > inline classes:
>
> Yes, that's the plan.  The document says that straight out; this is a
> feature about transformations on objects, which is not restricted to
> records, or inline classes, or even immutable classes.  Records just
> happen to come out of the box with all the moving parts needed to hook
> this up trivially, but other classes will join the fun soon, and inlines
> are likely to be among the best customers.
>
> > InlineType[] a = ...;  // InlineType has a field x
> > for (int i = 0; i < a.length; i++)
> >      a[i] = a[i] with { x = 3; };
> >
> > Semantically, this makes two copies (from array to local variable and
> back).
> >
> > Could the JIT be smart enough to transform this into an update of a
> single
> > field, without any copies of the whole object?
>
> Absolutely.  That's an essential aspect of the inline class design; the
> restrictions on inline classes are designed, in part, to support these
> sorts of optimizations as a casual mid-day snack.
>
> The `with` syntax is a distraction in this analysis; imagine the above
> were merely
>
>      a[i] = new InlineType(3, a.y())
>
> The constructor is just a static factory method, which will routinely be
> inlined here because it's tiny.  Same for the y() accessor.  After
> inlining, SSA transformation, scalarization, value numbering, and
> register allocation, what will happen is that the x and y fields of your
> (hot) loop index will already be in registers, the store of a.y = a.y()
> will be trivially observed as dead, and what you'll get is "load #3 into
> register."
>
> If the language automates this with `with`, same deal, because the
> language will generate ctor/dtor calls, which will get inlined, which
> are just scrutable data movement, which the JIT will similarly crush.
>

Thanks for the fast and thorough response! I totally underestimated how
much complexity the JIT is having for lunch every day. I'm beginning to
understand that efficiency and immutability aren't actually conflicting
goals in this case.

Quick follow-up question: If the InlineType ctor contains a check that y is
valid - will the JIT omit that check if it sees that y hasn't been
mentioned in the `with` block?


> > Or maybe we should give the JIT a hint and allow compound assignment
> > analogous to += et al.?
> >
> > a[i] = with { x = 3; };
> >
> > or
> >
> > a[i] with= { x = 3; };
>
> A kind offer, but the JIT doesn't need this sort of help! Identifying
> these sorts of idioms is routine fare for compilers.
>
> A better argument here would be that _humans_ would like this sort of
> help.  That's a valid discussion, but not needed at this point.


> Cheers,
> -Brian
>
>


From brian.goetz at oracle.com  Fri Aug 21 16:18:53 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 21 Aug 2020 12:18:53 -0400
Subject: efficiency vs. immutability of inline classes
In-Reply-To: <CAEQewpr6F-AewsXOs+6Y5xCA3QkCDxaY2tguXY4110XZQoHYEg@mail.gmail.com>
References: <CAEQewpqCJ56Ga6TaKseKYtz-q9hk8zfWrOYkayW9k+4+nPgH6w@mail.gmail.com>
 <d7a0715c-0c95-3bf9-115f-9e43450fa508@oracle.com>
 <CAEQewpr6F-AewsXOs+6Y5xCA3QkCDxaY2tguXY4110XZQoHYEg@mail.gmail.com>
Message-ID: <5780f34f-cb77-4b50-c125-abe6f9f9024b@oracle.com>


> Quick follow-up question: If the?InlineType ctor contains a check that 
> y is valid - will the JIT omit that check if it sees that y hasn't 
> been mentioned in the `with` block?

Yes, we've discussed this.? Currently that is not the case, but it is 
the sort of targeted optimization that could be considered if it becomes 
a problem.?? It requires putting together a number of things, none of 
which are impossible, but optimizations of this sort can be brittle in 
that they can exhibit "fall off the cliff" behaviors, where they work 
great for simple cases, but once you cross some threshold (such as 
inlining limits, or reordering the statements in the ctor), they start 
failing.

This is an example of work that the compiler has to "undo" because the 
code is working with over-large building blocks (like constructors) for 
reasons of human factors, not unlike previous generations of compilers 
had to struggle with identifying when loops could be vectorized.




From dsimms at openjdk.java.net  Mon Aug 24 10:03:57 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 24 Aug 2020 10:03:57 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <XS-Es8LvnixfqUAarpG4j3Z4TCtc4kqvJkpj0tRxAd0=.c2be66d5-b92d-4164-957d-2d8d0184ec5a@github.com>

Merge tag 'jdk-16+5'

# Conflicts:
#	src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
#	src/hotspot/share/memory/metaspaceShared.cpp
#	src/hotspot/share/opto/cfgnode.cpp
#	src/hotspot/share/opto/memnode.cpp
#	src/hotspot/share/opto/subnode.cpp
#	src/hotspot/share/opto/subnode.hpp

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

Commit messages:
 - More trailing whitespace
 - Merge tag 'jdk-16+5' into lworld_merge_jdk_16_5
 - 8248016: JFR: Remove Javadoc warnings
 - 8248701: On Windows generated modules-deps.gmk can contain backslash-r (CR) characters
 - 8248865: Document JNDI/LDAP timeout properties
 - 8248231: deserializeLambda created with wrong encoding if platform encoding not UTF-8
 - 8247762: [aarch64] Timeout in .../HeapDumpTestWithActiveProcess.java due to inf. loop in AARCH64CurrentFrameGuess.run()
 - 8244764: Improve assertion for CPP_VTABLE_PATCH_TYPES_DO
 - 8249002: New serviceability/sa/ClhsdbFindPC.java #id2 and #id3 tests are failing with ZGC
 - 8223955: Eliminate or reduce mixing of old File API and new Path/Files APIs
 - ... and 81 more: https://git.openjdk.java.net/valhalla/compare/c75f0f14...a380f3f1

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/valhalla/162/webrev.00.0
 - jdk: https://webrevs.openjdk.java.net/valhalla/162/webrev.00.1

Changes: https://git.openjdk.java.net/valhalla/pull/162/files
  Stats: 13592 lines in 438 files changed: 8858 ins; 2240 del; 2494 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/162.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/162/head:pull/162

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


From dsimms at openjdk.java.net  Mon Aug 24 10:03:59 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 24 Aug 2020 10:03:59 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <XS-Es8LvnixfqUAarpG4j3Z4TCtc4kqvJkpj0tRxAd0=.c2be66d5-b92d-4164-957d-2d8d0184ec5a@github.com>
References: <XS-Es8LvnixfqUAarpG4j3Z4TCtc4kqvJkpj0tRxAd0=.c2be66d5-b92d-4164-957d-2d8d0184ec5a@github.com>
Message-ID: <ZqRTj5F3BfqM3BwmP-asbiEiRPvkOzn8pcsWFnLiTaY=.ce263e5b-cb94-4622-aa78-19e6134b56a0@github.com>

On Mon, 24 Aug 2020 08:41:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+5'
> 
> # Conflicts:
> #	src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
> #	src/hotspot/share/memory/metaspaceShared.cpp
> #	src/hotspot/share/opto/cfgnode.cpp
> #	src/hotspot/share/opto/memnode.cpp
> #	src/hotspot/share/opto/subnode.cpp
> #	src/hotspot/share/opto/subnode.hpp

This pull request has now been integrated.

Changeset: cd5c75f8
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/cd5c75f8
Stats:     13582 lines in 438 files changed: 2230 ins; 8848 del; 2504 mod

Merge jdk

Merge tag 'jdk-16+5'

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

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


From thartmann at openjdk.java.net  Mon Aug 24 11:14:33 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 24 Aug 2020 11:14:33 GMT
Subject: [lworld] Integrated: 8252227: [lworld] Merge of jdk-16+5 broke
 compiler/arraycopy/TestEliminateArrayCopy.java
Message-ID: <zXhIetYLrMzqmNWgGeLZWZYVvldT6l3cwg0jwp9n6IU=.72a911c9-ee93-4b2d-9960-05f872f68f09@github.com>

Clone intrinsic should not emit flat array guard if src object can't be an array or flattening is completely disabled.

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

Commit messages:
 - 8252227: [lworld] Merge of jdk-16+5 broke compiler/arraycopy/TestEliminateArrayCopy.java

Changes: https://git.openjdk.java.net/valhalla/pull/163/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/163/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252227
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/163.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/163/head:pull/163

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


From thartmann at openjdk.java.net  Mon Aug 24 11:14:34 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 24 Aug 2020 11:14:34 GMT
Subject: [lworld] Integrated: 8252227: [lworld] Merge of jdk-16+5 broke
 compiler/arraycopy/TestEliminateArrayCopy.java
In-Reply-To: <zXhIetYLrMzqmNWgGeLZWZYVvldT6l3cwg0jwp9n6IU=.72a911c9-ee93-4b2d-9960-05f872f68f09@github.com>
References: <zXhIetYLrMzqmNWgGeLZWZYVvldT6l3cwg0jwp9n6IU=.72a911c9-ee93-4b2d-9960-05f872f68f09@github.com>
Message-ID: <MactHgYOXtbTEEcDJNnZVOoPB-upJu3Zm4iYBq_BlkE=.ec8eacd1-8a81-44f9-aae4-66081c53f600@github.com>

On Mon, 24 Aug 2020 10:41:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Clone intrinsic should not emit flat array guard if src object can't be an array or flattening is completely disabled.

This pull request has now been integrated.

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

8252227: [lworld] Merge of jdk-16+5 broke compiler/arraycopy/TestEliminateArrayCopy.java

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

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


From dsimms at openjdk.java.net  Mon Aug 24 12:44:00 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 24 Aug 2020 12:44:00 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <k3aC_lXa9c1As-tCHsDjTZfYyV0GQ_8Hx50NwixWS7E=.96f5a73c-2024-4bc7-8ed1-88af3a1c2336@github.com>

Merge tag 'jdk-16+6' into lworld_merge_jdk_16_6
Added tag jdk-16+6 for changeset 4a8fd81d64ba

# Conflicts:
#	src/hotspot/cpu/aarch64/aarch64.ad
#	src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
#	src/hotspot/share/classfile/classFileParser.cpp
#	src/hotspot/share/runtime/globals.hpp

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

Commit messages:
 - Merge tag 'jdk-16+6' into lworld_merge_jdk_16_6
 - 8247677: Incorrect class name displayed in DriverManager trace output
 - Merge
 - 8242891: vmTestbase/nsk/jvmti/ test should be fixed to fail early if JVMTI function return error
 - Merge
 - 8249036: clean up FileInstaller $test.src $cwd in vmTestbase_nsk_stress tests
 - 8249032: clean up FileInstaller $test.src $cwd in vmTestbase_nsk_sysdict tests
 - 8249035: clean up FileInstaller $test.src $cwd in vmTestbase_nsk_jdwp tests
 - 8249028: clean up FileInstaller $test.src $cwd in vmTestbase_nsk_monitoring tests
 - 8249033: clean up FileInstaller $test.src $cwd in vmTestbase_vm_metaspace tests
 - ... and 89 more: https://git.openjdk.java.net/valhalla/compare/cd5c75f8...f606d475

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/valhalla/164/webrev.00.0
 - jdk: https://webrevs.openjdk.java.net/valhalla/164/webrev.00.1

Changes: https://git.openjdk.java.net/valhalla/pull/164/files
  Stats: 10152 lines in 1959 files changed: 3509 ins; 4376 del; 2267 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/164.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/164/head:pull/164

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


From dsimms at openjdk.java.net  Mon Aug 24 12:44:02 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 24 Aug 2020 12:44:02 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <k3aC_lXa9c1As-tCHsDjTZfYyV0GQ_8Hx50NwixWS7E=.96f5a73c-2024-4bc7-8ed1-88af3a1c2336@github.com>
References: <k3aC_lXa9c1As-tCHsDjTZfYyV0GQ_8Hx50NwixWS7E=.96f5a73c-2024-4bc7-8ed1-88af3a1c2336@github.com>
Message-ID: <zQZROIaoatMkvddwWWr3Gf7lf1q7MY4s4gXHV8dMtPU=.05b73ec4-91b2-4cf7-9e8b-093c95544e18@github.com>

On Mon, 24 Aug 2020 11:30:38 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+6' into lworld_merge_jdk_16_6
> Added tag jdk-16+6 for changeset 4a8fd81d64ba
> 
> # Conflicts:
> #	src/hotspot/cpu/aarch64/aarch64.ad
> #	src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
> #	src/hotspot/share/classfile/classFileParser.cpp
> #	src/hotspot/share/runtime/globals.hpp

This pull request has now been integrated.

Changeset: a8215ec3
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a8215ec3
Stats:     10134 lines in 1959 files changed: 4358 ins; 3491 del; 2285 mod

Merge jdk

Merge 'jdk-16+6'

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

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


From sadayapalam at openjdk.java.net  Mon Aug 24 14:33:12 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Aug 2020 14:33:12 GMT
Subject: [lworld] Integrated: 8244713: [lworld] V.ref class should not
 inadvertently carry over attributes from V.class
Message-ID: <OEUro678lCyQljWE0iSJhbKC6ZlxciUC5m8SprgXpGk=.ec11669f-3679-492a-8595-371167ecf3ff@github.com>

Various tests to ensure that attributes are not simply carried over

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

Commit messages:
 - 8244713: V.ref class should not inadvertently carry over attributes from V.class

Changes: https://git.openjdk.java.net/valhalla/pull/165/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/165/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8244713
  Stats: 252 lines in 2 files changed: 252 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/165.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/165/head:pull/165

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


From sadayapalam at openjdk.java.net  Mon Aug 24 14:33:13 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Aug 2020 14:33:13 GMT
Subject: [lworld] Integrated: 8244713: [lworld] V.ref class should not
 inadvertently carry over attributes from V.class
In-Reply-To: <OEUro678lCyQljWE0iSJhbKC6ZlxciUC5m8SprgXpGk=.ec11669f-3679-492a-8595-371167ecf3ff@github.com>
References: <OEUro678lCyQljWE0iSJhbKC6ZlxciUC5m8SprgXpGk=.ec11669f-3679-492a-8595-371167ecf3ff@github.com>
Message-ID: <CoPTBCZR-Iel84-JlxtZ7gDw2rmmlDOHTU2qUHW6CpA=.0883b7cd-3aae-4104-94ac-363f78c3b858@github.com>

On Mon, 24 Aug 2020 14:15:47 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Various tests to ensure that attributes are not simply carried over

This pull request has now been integrated.

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

8244713: [lworld] V.ref class should not inadvertently carry over attributes from V.class

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

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


From thartmann at openjdk.java.net  Tue Aug 25 15:26:23 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 25 Aug 2020 15:26:23 GMT
Subject: [lworld] RFR: 8252299: [lworld] C2 compilation fails with
 assert(!use_ReduceInitialCardMarks()) failed: can only happen with card
 marking
Message-ID: <XFT7xPeQZqAL3kBvdpPaOajx-oiMh5E80WFtDptnpc4=.7de9c3bf-df8d-4333-bda0-133c29cec091@github.com>

When replacing an inline type buffer allocation by a dominating allocation, we are removing stores and re-link all
users of the dominated allocation to the dominating one (see InlineTypeNode::replace_allocation). Now we forgot to also
remove GC barriers for initializing stores to the dominated allocation, which causes several issues because these are
then re-linked to the dominated allocation as well while the corresponding stores were removed. The fix is to simply
remove these barriers as well via BarrierSet::eliminate_gc_barrier.

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

Commit messages:
 - 8252299: [lworld] C2 compilation fails with assert(\!use_ReduceInitialCardMarks()) failed: can only happen with card marking

Changes: https://git.openjdk.java.net/valhalla/pull/166/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/166/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252299
  Stats: 45 lines in 11 files changed: 15 ins; 0 del; 30 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/166.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/166/head:pull/166

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


From rriggs at openjdk.java.net  Tue Aug 25 17:32:34 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 25 Aug 2020 17:32:34 GMT
Subject: [lworld] RFR: JDK-8252061 [lword] Support Object::toString for
 inline type
In-Reply-To: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
References: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
Message-ID: <wqNZmLJnH8AXonESSpTN5uFqTNFjhiNiOFl_HBfrfHU=.5d002442-91ba-421a-8595-f2aa0f1fb0af@github.com>

On Thu, 20 Aug 2020 01:40:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This adds the `Object::toString` support for inline classes.  This will replace the need
> for javac to generate the `toString` method to call the bootstrap method.
> 
> JDK-8206077 will revisit the overlap of `ValueBootstrapMethods` and `ObjectMethods`.
> 
> This patch also removes the private `isSubstituable0` method and makes sure
> that `isSubstitutable` does not have `acmp` instruction and can be invoked by VM.

Marked as reviewed by rriggs (Committer).

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

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


From mchung at openjdk.java.net  Tue Aug 25 20:05:14 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 25 Aug 2020 20:05:14 GMT
Subject: [lworld] Integrated: JDK-8252061 [lword] Support Object::toString for
 inline type
In-Reply-To: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
References: <oVTszf1HMYH3xFW2uA9BAWsiVOY6k4HdYSLvBOlNk2k=.88d66db8-a81d-4f97-802d-6c5a7661b4a3@github.com>
Message-ID: <cETs7RNQyZ9d1M1iyGblwWyZVDSMSpAJsu9M8aqt3qE=.9dd60455-f5f0-424e-b0f2-92aec4054447@github.com>

On Thu, 20 Aug 2020 01:40:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This adds the `Object::toString` support for inline classes.  This will replace the need
> for javac to generate the `toString` method to call the bootstrap method.
> 
> JDK-8206077 will revisit the overlap of `ValueBootstrapMethods` and `ObjectMethods`.
> 
> This patch also removes the private `isSubstituable0` method and makes sure
> that `isSubstitutable` does not have `acmp` instruction and can be invoked by VM.

This pull request has now been integrated.

Changeset: acfed881
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/acfed881
Stats:     438 lines in 12 files changed: 251 ins; 137 del; 50 mod

8252061: [lword] Support Object::toString for inline type

Reviewed-by: sadayapalam, rriggs

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

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


From thartmann at openjdk.java.net  Wed Aug 26 11:58:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 26 Aug 2020 11:58:18 GMT
Subject: [lworld] Integrated: 8252299: [lworld] C2 compilation fails with
 assert(!use_ReduceInitialCardMarks()) failed: can only happen with card
 marking
In-Reply-To: <XFT7xPeQZqAL3kBvdpPaOajx-oiMh5E80WFtDptnpc4=.7de9c3bf-df8d-4333-bda0-133c29cec091@github.com>
References: <XFT7xPeQZqAL3kBvdpPaOajx-oiMh5E80WFtDptnpc4=.7de9c3bf-df8d-4333-bda0-133c29cec091@github.com>
Message-ID: <4hSx_dqlo9jShvapoYD3pECgiCx3fn5tALjBgeboCGc=.a2cbf660-b9ae-4451-8667-4a7a0c4614ff@github.com>

On Tue, 25 Aug 2020 15:20:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When replacing an inline type buffer allocation by a dominating allocation, we are removing stores and re-link all
> users of the dominated allocation to the dominating one (see InlineTypeNode::replace_allocation). Now we forgot to also
> remove GC barriers for initializing stores to the dominated allocation, which causes several issues because these are
> then re-linked to the dominated allocation as well while the corresponding stores were removed. The fix is to simply
> remove these barriers as well via BarrierSet::eliminate_gc_barrier.

This pull request has now been integrated.

Changeset: 54b54109
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/54b54109
Stats:     45 lines in 11 files changed: 0 ins; 15 del; 30 mod

8252299: [lworld] C2 compilation fails with assert(!use_ReduceInitialCardMarks()) failed: can only happen with card
marking

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

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


From fparain at openjdk.java.net  Wed Aug 26 20:16:40 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 26 Aug 2020 20:16:40 GMT
Subject: [lworld] RFR: 8229897: [lworld] C1 should avoid allocation when
 reading a field from a flattened field
Message-ID: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>

Please review this patch which removes temporary heap allocations when reading a field from a flattened field.

During the HIR graph construction, C1 detects sequences of consecutive getfield bytecodes involving flattened fields
and optimizes them with a single LoadField or NewInlineTypeInstance directly to the offset of the last nested field.

Performance improvement on a simple benchmark

    static inline class Point {
        int i = 0, j = 0;
    }
    static inline class Rectangle {
        Point p0 = new Point(), p1 = new Point();
    }
    static class NamedRectangle {
        Rectangle rect = new Rectangle();
        String name;
    }
    static NamedRectangle nr = new NamedRectangle();
    @Benchmark
    public void testGetfieldChain1(Blackhole blackhole) {
        int i = nr.rect.p0.j;                                                              // reads two flattened fields before
        reading an int blackhole.consume(i);
    }

    @Benchmark
    public void testGetfieldChain2(Blackhole blackhole) {
        Point p = nr.rect.p1;                                                          // reads a flattened field inside a
        flattened field blackhole.consume(p);
    }

Without the optimization:
Benchmark                             Mode  Samples  Score  Score error  Units
o.s.MyBenchmark.testGetfieldChain1    avgt      200  8.696        0.024  ns/op
o.s.MyBenchmark.testGetfieldChain2    avgt      200  8.969        0.027  ns/op

With the optimization:
Benchmark                             Mode  Samples  Score  Score error  Units
o.s.MyBenchmark.testGetfieldChain1    avgt      200  2.134        0.019  ns/op
o.s.MyBenchmark.testGetfieldChain2    avgt      200  5.150        0.017  ns/op


Tested with Mach5, tiers 1 to 3.

Thank you,

Fred

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

Commit messages:
 - Fix whitespaces
 - Fix whitespaces
 - Fix and upgrade tests
 - Adding back refactored unit test
 - Removing problematic unit test
 - Fix test configuration for C2
 - Add new test for NoSuchFieldError
 - Fixes, cleanup and unit test
 - Fix reading of flattened field, remove debug messages
 - Initial getfield optimization, no exception support

Changes: https://git.openjdk.java.net/valhalla/pull/167/files
 Webrev: https://webrevs.openjdk.java.net/valhalla/167/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8229897
  Stats: 1296 lines in 7 files changed: 1264 ins; 0 del; 32 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/167.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/167/head:pull/167

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


From john.r.rose at oracle.com  Wed Aug 26 23:14:11 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 26 Aug 2020 16:14:11 -0700
Subject: early steps on the road to customization
Message-ID: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>

To succeed with generics over inlines, we need to make
progress on (what I call) the Loop Customization Problem,
a grand challenge for our ecosystem.  In a nutshell, we
need to optimize hot code (pre-eminently loops or immediate
calls within loops) that is written generically for reuse, and
is in fact used in multiple specialized settings.

If we had macros or templates, we might ask our users
to code hot-but-reusable methods as macros of templates,
but that would fragment the language.

In the classical case of object-oriented reuse, we focus
on optimizing a super-class method in the setting of
a known receiver type (and perhaps other known types).
To do this, the user must first write at least a small method
in a subclass which calls the superclass method, and then
wait for the JIT to inline the latter method into the former.
The copy of superclass code that is inlined is then customized
at least for the receiver type.

(Sometimes the subclass method can be defined in an ad hoc
way by the Java compiler.  This is how equals, hashCode,
and toString are customized in the current preview of Records.
This doesn?t scale unless you have language rules to guide the
placement and contents of the injected methods.)

Requiring even a small subclass method is sometimes too much
manual ceremony.  An automatically spun lambda class has no
place in the code to write even the smallest subclass method.
And a generically-instantiated type like List<int> will not have
any place to define subclass methods, because? it?s not a class,
not even a hidden one.

(What goes for generically reusable code also goes for generically
reusable data, just as algorithms and data structures reinforce
each other and are incomplete in isolation.  For the JVM,
polymorphic layouts can defined using reflective techniques as
in Panama.  Any solution to the code customization problem
would provide a way to treat polymorphic container access
as a specializable algorithm.)

At the JVM level, what?s needed are mechanisms for organizing
specializations of generically reusable code (and data structures)
so that the JVM is guided to customize shared methods and
install the results of customization along hot paths where they
can be directly reached.  In HotSpot terms, we need the moral
equivalent of a subclass method which replicates (via inlining)
a superclass method in a customizable context.  Without the
actual subclass method, we need a way to identify hot access
points, such as v-table slots, which need the JIT to re-optimize
the inherited method.  This implies a method versioning system,
as well as something like an invocation counter on a v-table slot.

Of course customization has to be filtered according to opportunity:
There is no benefit to re-optimizing a method unless it makes use
of its customization context.  I think we can heuristically locate
opportunities for re-optimization, but I believe the user should
be in the loop as well, with the JVM taking hints from source
code structure:  Maybe annotations (though that?s a ?register
keyword? move), certainly hand-plumbed customization code
(using ClassValue, for example), and pre-eminently any new
language features associated with specialized generics.  If a
library author opts into specialized generics, that opt-in can
easily be parleyed into a clear signal to the JVM that code
which is parameterized appropriately is a strong candidate
for customized re-optimization.

Some of what I?m saying here is blue-sky future, and other
parts are in the sad bucket of ?hard problems we don?t try to
fix because they are too hard?.  But given the likely advent
of specialized generics, it is time to start building what we
can, and not waiting for language changes.  (Indeed, the
language changes are waiting for a clearer indication of
what the JVM can readily do!)

So I?d like to propose a medium-sized challenge problem,
a simple customizable list that works on both primitives
and references.  This can be worked on today, and doesn?t
require inline types or any other Valhalla mechanism.

In order to make the JVM-level problems really clear,
this example class uses ClassValue and MethodHandle APIs
to express the customization cut points.  Perhaps a future
language feature would compile specializable generic methods
to self-customize using this same infrastructure, or at least
something similar.

The superclass holding the generic algorithm defines a
ClassValue which spins up customized method handles
for each significant variation of the class.  There is just
one benchmark which runs repeatedly over the elements
of a long list, using List::get (not iterators).  The benchmark
wins if List::get is customized and loses (10x) if not.

Here?s the code, and a README with further thoughts.

http://cr.openjdk.java.net/~jrose/values/CustomizationExample/
http://cr.openjdk.java.net/~jrose/values/CustomizationExample/README.html

This is something we can work on today, in preparation
of support of inlines (and primitive) in specialized generics.

(IMO, this work also shows a way to properly factor the
implementation of Record::toString etc., without ad
hoc methods injected by javac.)

Please give it a look, if you are interested in these things.
N.B. I have not yet looked at the machine code of the benchmark,
so it?s possible that the 10x slowdown (on a trip through the
sharable method) has some low-hanging fruit.  But I?m
pretty sure there is solid new work needed here.

? John

P.S. For those not keeping close score, the answer is not
?just inline more deeply?, even if you can make my micro
go faster by inlining it until it bleeds.  For robust performance
of full applications, we something more, such as method
versioning.

From brian.goetz at oracle.com  Thu Aug 27 15:37:41 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 27 Aug 2020 11:37:41 -0400
Subject: early steps on the road to customization
In-Reply-To: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
Message-ID: <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>

Since several of these require trusting final fields, and there already 
is a TNSFF hook, does enabling that affect the macro-observed 
performance, or are these things hidden behind bigger roadblocks?

On 8/26/2020 7:14 PM, John Rose wrote:
> To succeed with generics over inlines, we need to make
> progress on (what I call) the Loop Customization Problem,
> a grand challenge for our ecosystem.  In a nutshell, we
> need to optimize hot code (pre-eminently loops or immediate
> calls within loops) that is written generically for reuse, and
> is in fact used in multiple specialized settings.
>
> If we had macros or templates, we might ask our users
> to code hot-but-reusable methods as macros of templates,
> but that would fragment the language.
>
> In the classical case of object-oriented reuse, we focus
> on optimizing a super-class method in the setting of
> a known receiver type (and perhaps other known types).
> To do this, the user must first write at least a small method
> in a subclass which calls the superclass method, and then
> wait for the JIT to inline the latter method into the former.
> The copy of superclass code that is inlined is then customized
> at least for the receiver type.
>
> (Sometimes the subclass method can be defined in an ad hoc
> way by the Java compiler.  This is how equals, hashCode,
> and toString are customized in the current preview of Records.
> This doesn?t scale unless you have language rules to guide the
> placement and contents of the injected methods.)
>
> Requiring even a small subclass method is sometimes too much
> manual ceremony.  An automatically spun lambda class has no
> place in the code to write even the smallest subclass method.
> And a generically-instantiated type like List<int> will not have
> any place to define subclass methods, because? it?s not a class,
> not even a hidden one.
>
> (What goes for generically reusable code also goes for generically
> reusable data, just as algorithms and data structures reinforce
> each other and are incomplete in isolation.  For the JVM,
> polymorphic layouts can defined using reflective techniques as
> in Panama.  Any solution to the code customization problem
> would provide a way to treat polymorphic container access
> as a specializable algorithm.)
>
> At the JVM level, what?s needed are mechanisms for organizing
> specializations of generically reusable code (and data structures)
> so that the JVM is guided to customize shared methods and
> install the results of customization along hot paths where they
> can be directly reached.  In HotSpot terms, we need the moral
> equivalent of a subclass method which replicates (via inlining)
> a superclass method in a customizable context.  Without the
> actual subclass method, we need a way to identify hot access
> points, such as v-table slots, which need the JIT to re-optimize
> the inherited method.  This implies a method versioning system,
> as well as something like an invocation counter on a v-table slot.
>
> Of course customization has to be filtered according to opportunity:
> There is no benefit to re-optimizing a method unless it makes use
> of its customization context.  I think we can heuristically locate
> opportunities for re-optimization, but I believe the user should
> be in the loop as well, with the JVM taking hints from source
> code structure:  Maybe annotations (though that?s a ?register
> keyword? move), certainly hand-plumbed customization code
> (using ClassValue, for example), and pre-eminently any new
> language features associated with specialized generics.  If a
> library author opts into specialized generics, that opt-in can
> easily be parleyed into a clear signal to the JVM that code
> which is parameterized appropriately is a strong candidate
> for customized re-optimization.
>
> Some of what I?m saying here is blue-sky future, and other
> parts are in the sad bucket of ?hard problems we don?t try to
> fix because they are too hard?.  But given the likely advent
> of specialized generics, it is time to start building what we
> can, and not waiting for language changes.  (Indeed, the
> language changes are waiting for a clearer indication of
> what the JVM can readily do!)
>
> So I?d like to propose a medium-sized challenge problem,
> a simple customizable list that works on both primitives
> and references.  This can be worked on today, and doesn?t
> require inline types or any other Valhalla mechanism.
>
> In order to make the JVM-level problems really clear,
> this example class uses ClassValue and MethodHandle APIs
> to express the customization cut points.  Perhaps a future
> language feature would compile specializable generic methods
> to self-customize using this same infrastructure, or at least
> something similar.
>
> The superclass holding the generic algorithm defines a
> ClassValue which spins up customized method handles
> for each significant variation of the class.  There is just
> one benchmark which runs repeatedly over the elements
> of a long list, using List::get (not iterators).  The benchmark
> wins if List::get is customized and loses (10x) if not.
>
> Here?s the code, and a README with further thoughts.
>
> http://cr.openjdk.java.net/~jrose/values/CustomizationExample/
> http://cr.openjdk.java.net/~jrose/values/CustomizationExample/README.html
>
> This is something we can work on today, in preparation
> of support of inlines (and primitive) in specialized generics.
>
> (IMO, this work also shows a way to properly factor the
> implementation of Record::toString etc., without ad
> hoc methods injected by javac.)
>
> Please give it a look, if you are interested in these things.
> N.B. I have not yet looked at the machine code of the benchmark,
> so it?s possible that the 10x slowdown (on a trip through the
> sharable method) has some low-hanging fruit.  But I?m
> pretty sure there is solid new work needed here.
>
> ? John
>
> P.S. For those not keeping close score, the answer is not
> ?just inline more deeply?, even if you can make my micro
> go faster by inlining it until it bleeds.  For robust performance
> of full applications, we something more, such as method
> versioning.



From john.r.rose at oracle.com  Thu Aug 27 21:52:41 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 27 Aug 2020 14:52:41 -0700
Subject: early steps on the road to customization
In-Reply-To: <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
 <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
Message-ID: <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>

On Aug 27, 2020, at 8:37 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Since several of these require trusting final fields, and there already is a TNSFF hook, does enabling that affect the macro-observed performance, or are these things hidden behind bigger roadblocks?

There are other roadblocks, certainly.  A ClassValue table is mutable,
like a MutableCallSite, so it requires some special logic.

Yesterday?s ?early step? was the proposal of a plausible benchmark.
Teasing apart the multiple components of the slowdown (relative to
hand customization) is going to be some further work.

Probably getting the performance up is some combination of:

- trusted finals
- constant-folding through ClassValue (like MCS)
- method versioning
- assigning correct cache points to versioned methods
- inlining tuning (there?s always that, but it?s not the major element here)

The effects of each factor can be estimated by appropriate experiments:

- force final trusting
- use a ClassValue approximator that the JIT can constant-fold
- force method versioning by hand-injection of bridges (?version bridges?) and @ForceInline
- manually set cache points by version bridge placement
- crank up the inlining tuning flags (not a final solution:  infinite inlining hurts real apps)

? John

From peter.levart at gmail.com  Fri Aug 28 12:53:22 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 28 Aug 2020 14:53:22 +0200
Subject: early steps on the road to customization
In-Reply-To: <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
 <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
 <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>
Message-ID: <1c86b856-1ccf-79ea-a438-0b66e332e12c@gmail.com>

Hi,

On 8/27/20 11:52 PM, John Rose wrote:
> The effects of each factor can be estimated by appropriate experiments:
>
> - use a ClassValue approximator that the JIT can constant-fold

...here's a quick hack that makes the 1st N (32) evaluated ClassValue 
instances constant-foldable:

https://github.com/plevart/valhalla/pull/1

I haven't checked the JIT-ed code, but JMH benchmark undoubtedly shows 
that it works:

https://gist.github.com/plevart/3ddada53824faede66e843acd0dfa92f

This patch does not support ClassValue.remove operation. Interesting 
question is whether it would be possible to support remove via some kind 
of MethodHandle/de-opt trickery (R?mi would know).

Regards, Peter



From thartmann at openjdk.java.net  Fri Aug 28 13:59:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 28 Aug 2020 13:59:18 GMT
Subject: [lworld] RFR: 8252040: [lworld] Execute compiler unit tests in
 random order [v2]
In-Reply-To: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>
References: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>
Message-ID: <Z9NSpyDpZ2n6EAmHBf87cWV75Iek8e5cX302oPwWrek=.11fcf5d8-3875-4993-8600-9652446ba943@github.com>

> - Profiling of callee methods depends on execution order of unit tests. Execute tests in random order to increase
>   coverage.
> - At double field to test inline type
> - Verify that expected NPEs are always thrown
> - Fixed a test bug in TestLWorldProfiling.java (array element is not re-initialized and therefore NULL)
> - Refactoring and removal of old, non-applicable TODOs

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

  Disable shuffling by default until all bugs are fixed

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/154/files
  - new: https://git.openjdk.java.net/valhalla/pull/154/files/a09cd5cd..02685bc8

Webrevs:
 - full: https://webrevs.openjdk.java.net/valhalla/154/webrev.01
 - incr: https://webrevs.openjdk.java.net/valhalla/154/webrev.00-01

  Stats: 18 lines in 2 files changed: 12 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/154.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/154/head:pull/154

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


From thartmann at openjdk.java.net  Fri Aug 28 14:14:37 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 28 Aug 2020 14:14:37 GMT
Subject: [lworld] RFR: 8229897: [lworld] C1 should avoid allocation when
 reading a field from a flattened field
In-Reply-To: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>
References: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>
Message-ID: <xKLlmjM11J8-1_15qniwuIDY0BpL3dwFR_tJWdRUkq8=.676727ad-4b61-4cd8-baf6-865a37fe03d2@github.com>

On Wed, 26 Aug 2020 19:56:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch which removes temporary heap allocations when reading a field from a flattened field.
> 
> During the HIR graph construction, C1 detects sequences of consecutive getfield bytecodes involving flattened fields
> and optimizes them with a single LoadField or NewInlineTypeInstance directly to the offset of the last nested field.
> Performance improvement on a simple benchmark
> 
>     static inline class Point {
>         int i = 0, j = 0;
>     }
>     static inline class Rectangle {
>         Point p0 = new Point(), p1 = new Point();
>     }
>     static class NamedRectangle {
>         Rectangle rect = new Rectangle();
>         String name;
>     }
>     static NamedRectangle nr = new NamedRectangle();
>     @Benchmark
>     public void testGetfieldChain1(Blackhole blackhole) {
>         int i = nr.rect.p0.j;                                                              // reads two flattened fields before
>         reading an int blackhole.consume(i);
>     }
> 
>     @Benchmark
>     public void testGetfieldChain2(Blackhole blackhole) {
>         Point p = nr.rect.p1;                                                          // reads a flattened field inside a
>         flattened field blackhole.consume(p);
>     }
> 
> Without the optimization:
> Benchmark                             Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testGetfieldChain1    avgt      200  8.696        0.024  ns/op
> o.s.MyBenchmark.testGetfieldChain2    avgt      200  8.969        0.027  ns/op
> 
> With the optimization:
> Benchmark                             Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testGetfieldChain1    avgt      200  2.134        0.019  ns/op
> o.s.MyBenchmark.testGetfieldChain2    avgt      200  5.150        0.017  ns/op
> 
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

Looks good to me!

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

Marked as reviewed by thartmann (Committer).

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


From fparain at openjdk.java.net  Fri Aug 28 14:34:39 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 28 Aug 2020 14:34:39 GMT
Subject: [lworld] RFR: 8229897: [lworld] C1 should avoid allocation when
 reading a field from a flattened field
In-Reply-To: <xKLlmjM11J8-1_15qniwuIDY0BpL3dwFR_tJWdRUkq8=.676727ad-4b61-4cd8-baf6-865a37fe03d2@github.com>
References: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>
 <xKLlmjM11J8-1_15qniwuIDY0BpL3dwFR_tJWdRUkq8=.676727ad-4b61-4cd8-baf6-865a37fe03d2@github.com>
Message-ID: <rZQb7UCO8QWgF0JDOAw1XATE8-1La7yq8PJcO0-pg0Y=.2f7d84f5-991c-4bf7-80c5-69cbdd5cb162@github.com>

On Fri, 28 Aug 2020 14:12:21 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Please review this patch which removes temporary heap allocations when reading a field from a flattened field.
>> 
>> During the HIR graph construction, C1 detects sequences of consecutive getfield bytecodes involving flattened fields
>> and optimizes them with a single LoadField or NewInlineTypeInstance directly to the offset of the last nested field.
>> Performance improvement on a simple benchmark
>> 
>>     static inline class Point {
>>         int i = 0, j = 0;
>>     }
>>     static inline class Rectangle {
>>         Point p0 = new Point(), p1 = new Point();
>>     }
>>     static class NamedRectangle {
>>         Rectangle rect = new Rectangle();
>>         String name;
>>     }
>>     static NamedRectangle nr = new NamedRectangle();
>>     @Benchmark
>>     public void testGetfieldChain1(Blackhole blackhole) {
>>         int i = nr.rect.p0.j;                                                              // reads two flattened fields before
>>         reading an int blackhole.consume(i);
>>     }
>> 
>>     @Benchmark
>>     public void testGetfieldChain2(Blackhole blackhole) {
>>         Point p = nr.rect.p1;                                                          // reads a flattened field inside a
>>         flattened field blackhole.consume(p);
>>     }
>> 
>> Without the optimization:
>> Benchmark                             Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testGetfieldChain1    avgt      200  8.696        0.024  ns/op
>> o.s.MyBenchmark.testGetfieldChain2    avgt      200  8.969        0.027  ns/op
>> 
>> With the optimization:
>> Benchmark                             Mode  Samples  Score  Score error  Units
>> o.s.MyBenchmark.testGetfieldChain1    avgt      200  2.134        0.019  ns/op
>> o.s.MyBenchmark.testGetfieldChain2    avgt      200  5.150        0.017  ns/op
>> 
>> 
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you,
>> 
>> Fred
>
> Looks good to me!

Thanks Tobias!

Fred

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

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


From fparain at openjdk.java.net  Fri Aug 28 14:34:41 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 28 Aug 2020 14:34:41 GMT
Subject: [lworld] Integrated: 8229897: [lworld] C1 should avoid allocation
 when reading a field from a flattened field
In-Reply-To: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>
References: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>
Message-ID: <VHBMdWsp-kHLpJNKRGdVzMfECqmrjG-iG6HhOKEoFZA=.3f091c28-35c3-481e-8660-ae5d6005a8b0@github.com>

On Wed, 26 Aug 2020 19:56:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch which removes temporary heap allocations when reading a field from a flattened field.
> 
> During the HIR graph construction, C1 detects sequences of consecutive getfield bytecodes involving flattened fields
> and optimizes them with a single LoadField or NewInlineTypeInstance directly to the offset of the last nested field.
> Performance improvement on a simple benchmark
> 
>     static inline class Point {
>         int i = 0, j = 0;
>     }
>     static inline class Rectangle {
>         Point p0 = new Point(), p1 = new Point();
>     }
>     static class NamedRectangle {
>         Rectangle rect = new Rectangle();
>         String name;
>     }
>     static NamedRectangle nr = new NamedRectangle();
>     @Benchmark
>     public void testGetfieldChain1(Blackhole blackhole) {
>         int i = nr.rect.p0.j;                                                              // reads two flattened fields before
>         reading an int blackhole.consume(i);
>     }
> 
>     @Benchmark
>     public void testGetfieldChain2(Blackhole blackhole) {
>         Point p = nr.rect.p1;                                                          // reads a flattened field inside a
>         flattened field blackhole.consume(p);
>     }
> 
> Without the optimization:
> Benchmark                             Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testGetfieldChain1    avgt      200  8.696        0.024  ns/op
> o.s.MyBenchmark.testGetfieldChain2    avgt      200  8.969        0.027  ns/op
> 
> With the optimization:
> Benchmark                             Mode  Samples  Score  Score error  Units
> o.s.MyBenchmark.testGetfieldChain1    avgt      200  2.134        0.019  ns/op
> o.s.MyBenchmark.testGetfieldChain2    avgt      200  5.150        0.017  ns/op
> 
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 3540dd4d
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3540dd4d
Stats:     1296 lines in 7 files changed: 0 ins; 1264 del; 32 mod

8229897: [lworld] C1 should avoid allocation when reading a field from a flattened field

Reviewed-by: thartmann

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

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


From fparain at openjdk.java.net  Fri Aug 28 14:34:40 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 28 Aug 2020 14:34:40 GMT
Subject: [lworld] RFR: 8229897: [lworld] C1 should avoid allocation when
 reading a field from a flattened field
In-Reply-To: <rZQb7UCO8QWgF0JDOAw1XATE8-1La7yq8PJcO0-pg0Y=.2f7d84f5-991c-4bf7-80c5-69cbdd5cb162@github.com>
References: <lOSL3njCcevdoY2SzH8Qah5VMmZY3FPGolMELjr5hpw=.c53dd4e7-3616-47fa-8eb3-16d100ec77e9@github.com>
 <xKLlmjM11J8-1_15qniwuIDY0BpL3dwFR_tJWdRUkq8=.676727ad-4b61-4cd8-baf6-865a37fe03d2@github.com>
 <rZQb7UCO8QWgF0JDOAw1XATE8-1La7yq8PJcO0-pg0Y=.2f7d84f5-991c-4bf7-80c5-69cbdd5cb162@github.com>
Message-ID: <VVZufcDGZLLvBwSNSqYrcYYcGddtbQZqD7GgLkHR778=.c698e44f-eefb-43f4-9b7e-02f75eeabcb2@github.com>

On Fri, 28 Aug 2020 14:30:41 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Looks good to me!
>
> Thanks Tobias!
> 
> Fred

/integrate

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

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


From john.r.rose at oracle.com  Fri Aug 28 22:12:54 2020
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 28 Aug 2020 15:12:54 -0700
Subject: early steps on the road to customization
In-Reply-To: <1c86b856-1ccf-79ea-a438-0b66e332e12c@gmail.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
 <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
 <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>
 <1c86b856-1ccf-79ea-a438-0b66e332e12c@gmail.com>
Message-ID: <E13BAA2E-3A44-4274-9E6D-B314B6C5479D@oracle.com>

Very tasty, thank you!

Here?s a discussion of the issue with CV::remove:

https://bugs.openjdk.java.net/browse/JDK-8238260

On Aug 28, 2020, at 5:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> On 8/27/20 11:52 PM, John Rose wrote:
>> The effects of each factor can be estimated by appropriate experiments:
>> 
>> - use a ClassValue approximator that the JIT can constant-fold
> 
> ...here's a quick hack that makes the 1st N (32) evaluated ClassValue instances constant-foldable:
> 
> https://github.com/plevart/valhalla/pull/1
> 
> I haven't checked the JIT-ed code, but JMH benchmark undoubtedly shows that it works:
> 
> https://gist.github.com/plevart/3ddada53824faede66e843acd0dfa92f
> 
> This patch does not support ClassValue.remove operation. Interesting question is whether it would be possible to support remove via some kind of MethodHandle/de-opt trickery (R?mi would know).
> 
> Regards, Peter
> 



From john.r.rose at oracle.com  Sat Aug 29 20:22:48 2020
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 29 Aug 2020 13:22:48 -0700
Subject: early steps on the road to customization
In-Reply-To: <E13BAA2E-3A44-4274-9E6D-B314B6C5479D@oracle.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
 <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
 <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>
 <1c86b856-1ccf-79ea-a438-0b66e332e12c@gmail.com>
 <E13BAA2E-3A44-4274-9E6D-B314B6C5479D@oracle.com>
Message-ID: <64FCD2F0-8DEE-4F4B-BA34-00CC5FE78BBD@oracle.com>

On Aug 28, 2020, at 3:12 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> Here?s a discussion of the issue with CV::remove:
> 
> https://bugs.openjdk.java.net/browse/JDK-8238260 <https://bugs.openjdk.java.net/browse/JDK-8238260>
I linked your contributions to that bug.  Thanks again.

We could generalize the MutableCallSite handshake to
cover both MCS and CV and whatever third and fourth
things we need in the future.  I think this is a worthy
and timely project.  Since Vladimir Ivanov is the author
of the existing handshakes, I?m CC-ing hom.  Here are
some further thoughts on this?

The pieces of the puzzle are, I think, as follows:

1. A compile-time constant folding protocol.  This should
accept, at JIT time (not in Java execution) one or more ?live?
values (obtained by the JIT using previous constant propagation)
and apply some compile-time function to those values to obtain
a new ?live? value, plus an indication of the status of that value.
The status is ?unknown? (no constant is available now), or ?certain?
(constant is locked in place and will never change), or ?speculative?
(constant is known but may change in the future).  The ?live?
values could be mere Java object references, for starters, but
I think the protocols can also support primitives and Valhalla
inline objects.  Arrays probably need some special processing too.

2. For speculative constants, there must be a way of baking a
record of the speculation into the n-method?s dependencies.
This record must include one (or maybe more) live values
which can assist a dependency checker in deciding when to
deoptimize the n-method.  (See code/dependencies.hpp
and MethodHandles::add_dependent_nmethod.)

3. There must be an algorithm for detecting revocation of
speculative constants and notifying dependent n-methods.
Such an algorithm probably has phases, an event-triggered
pass which locates a set of n-methods which are possibly
affected (worst case, *all* n-methods), and an analysis pass
which visits each n-method, scans its dependency list for
relevant dependencies,  and evaluates a function to detect
invalidated dependencies.  (See flush_dependent_nmethods.)

These protocols seem ambitious, but I think we can do things
which simplify them.

1. The JIT cannot execute Java code directly, but it certainly
models Java code completely.  Mutable heap variables are
modeled today using @Stable, and a similar annotation could
be created which produces the information needed in this
application.  The annotation would have to include an indication
of which events, if any, can invalidate the annotated variable.
(By contracts, with @Stable, invalidation is irrelevant.)
Note that reading heap variables does not require Java code
execution in JIT.

2. If the JIT decides (in step 1) to speculate on the value of a
mutable heap variable, it can easily create a ?witness object?
that encodes the observation.  The witness could contain a
base address and offset (unsafe Object/long pair) plus the
witnessed value.  To be type-polymorphic, the witnessed
value might be encoded as another Object/long pair (in private
storage never modified) plus a size in bytes.  To check the
validity of a witness, a bitwise comparison would be enough
in most cases, although maybe not all.  The witness would
also encode which events could potentially cause invalidation.
This witness would be stored (as a live reference) in the
n-method dependency list.

3. There must be a (trusted) JVM down-call which posts
invalidation events.  This would take one (or maybe more)
parameters which allow the JVM to concentrate only on
n-methods which contain witnesses that pertain to the
invalidation event.  This call must correctly sequence
with the update to a heap variable which causes the
invalidation, which probably means that the down-call
actually *performs* the update.

Today, there are two such down-calls in the JVM, named
setCallSiteTargetNormal and setCallSiteTargetVolatile.
They are customized to the two different types of mutable
call site.  But we don?t need one down-call for each kind of
invalidation, just one parameterized by a classification token
(and maybe a secondary token).  I suppose a Class object
would make a fine token for classifying invalidation events.

A Class could allow CHA-like considerations to play a role in
witness checking (using the built-in isAssignableFrom logic,
which the JVM can execute at any time).  Either a primary
or secondary down-call argument could be a Class object
which could be applied to either the base reference (of
the witnessed heap variable) or to the witnessed *value*
of that heap variable.  (I don?t have an application for this
at present

So this pencils out to:

1a. An annotation (trusted) like @Stable, say @Speculative.
Perhaps it doesn?t need any parameters (see below) which
would make it simpler to implement in the JVM.

1b. A SpeculativeBinding object (JVM internal) to serve as
a witness.  There?s a simple Java API for it, but it?s mostly just
a dumb record, consulted by the n-method dependency
logic.  The existing internal class CallSiteContext is a
first cut.  Java fields are variableType, variableBase,
variableOffset, valueBase, and valueOffset; others can be
injected by the JVM for handshakes, as currently with
CallSiteContext.  Re-validating a SpeculativeBinding requires
loading the two values at the two base/offset pairs (both of
the common type) and comparing them for something
like same-ness (acmp or even just pointer comparison).
It would be reasonable for a JIT-time query to return a
freshly-allocated SpeculativeBinding object as a possible
result to a query against a @Speculative-annotated variable.

2. A new dependency type Dependencies::speculative_value.
This would generalize and replace call_site_target_value.

3. A new JVM down-call SpeculativeBinding::update
which would take care of the necessary state changes.
It seems straightforward to design this as a virtual call,
which means the caller would need to come up with an
instance of a SB in order to tell it to invalidate.  That
turns out to be problematic, since when the original
Java library code needs to update a @Speculative heap
variable, it doesn?t really know whether the JIT has
created a witness for it.  Instead, the update call needs
to be told to update the heap variable, by whatever means
necessary, and the JVM needs full control over how to
find any relevant witnesses.  There are a number of ways
to get around this tricky bit; perhaps the simplest is to
make SpeculativeBinding be an abstract superclass
and fold it into the data structures that contain the
affected heap variables.  (Note that some of them are
arrays; the SB superclass would fold into the *holder*
of the array.)  This may be too intrusive, but if it works
maybe the annotation is superfluous, which would be
nice.  Another possibility is to create a fresh temporary
SpeculativeWitness object for every update, and allow
the JVM to somehow swap in a previously created one
(created by the JIT and stored in n-method dependency
lists) when that is relevant; the update operation would
be virtual on the witness; the JIT would replace the update
call with something suitable that handshakes with n-methods.
Another possibility (most straightforward) is to have the
update call be purely static, and take a bunch of parameters
about what?s getting updated where, plus which invalidation
events might be relevant.  The JVM runtime would nose around
for matching n-methods on that variable and DTRT.

? John

From thartmann at openjdk.java.net  Mon Aug 31 07:35:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 31 Aug 2020 07:35:51 GMT
Subject: [lworld] Integrated: 8252040: [lworld] Execute compiler unit tests in
 random order
In-Reply-To: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>
References: <4bHBZGeghyP4wsz5Pt5Sb4ikjo91RA1g-fYi8Fa6twI=.6dc98b9e-d989-4e3a-9f26-5b8c3fdb3aab@github.com>
Message-ID: <jx3B3Ly_Y3B3Zprhfl1O5hQ8kHRKKbGToJKM3Vi26Dw=.47d1a6e2-9a50-4886-a3c3-b9bf4c4ba442@github.com>

On Wed, 19 Aug 2020 14:53:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> - Profiling of callee methods depends on execution order of unit tests. Execute tests in random order to increase
>   coverage.
> - At double field to test inline type
> - Verify that expected NPEs are always thrown
> - Fixed a test bug in TestLWorldProfiling.java (array element is not re-initialized and therefore NULL)
> - Refactoring and removal of old, non-applicable TODOs

This pull request has now been integrated.

Changeset: 9bde3a44
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/9bde3a44
Stats:     202 lines in 12 files changed: 10 ins; 26 del; 166 mod

8252040: [lworld] Execute compiler unit tests in random order

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

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


From peter.levart at gmail.com  Mon Aug 31 11:19:23 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 31 Aug 2020 13:19:23 +0200
Subject: early steps on the road to customization
In-Reply-To: <E13BAA2E-3A44-4274-9E6D-B314B6C5479D@oracle.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
 <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
 <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>
 <1c86b856-1ccf-79ea-a438-0b66e332e12c@gmail.com>
 <E13BAA2E-3A44-4274-9E6D-B314B6C5479D@oracle.com>
Message-ID: <83b52115-9d07-8c35-a4e5-d44d612ad56c@gmail.com>

Hi,

I just wanted to see how far I could go with existing VM features, 
namely: @Stable annotation and MutableCallSite. Here's a variant of 
ClassValue that replaces entirely existing one and supports dynamic 
sizing of backing array, get(), remove() and put() operations and even 
re-use of table indexes used by GC-ed ClassValue instances. It passes 
the ClassValueTest:

https://github.com/plevart/valhalla/pull/3

It still manages to constant-fold the associated value when both 
ClassValue and Class are constants. Here's a benchmark that also 
includes variants where either or both of ClassValue and Class are 
constants or not to show how it compares with existing ClassValue. It is 
slower, but not by very much:

https://gist.github.com/plevart/edce6f150b881b542cc722ce11424ae3

I hope this can be used in performance experiments until JVM support for 
speculative values is created.

Regards, Peter

On 8/29/20 12:12 AM, John Rose wrote:
> Very tasty, thank you!
>
> Here?s a discussion of the issue with CV::remove:
>
> https://bugs.openjdk.java.net/browse/JDK-8238260
>
> On Aug 28, 2020, at 5:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi,
>>
>> On 8/27/20 11:52 PM, John Rose wrote:
>>> The effects of each factor can be estimated by appropriate experiments:
>>>
>>> - use a ClassValue approximator that the JIT can constant-fold
>> ...here's a quick hack that makes the 1st N (32) evaluated ClassValue instances constant-foldable:
>>
>> https://github.com/plevart/valhalla/pull/1
>>
>> I haven't checked the JIT-ed code, but JMH benchmark undoubtedly shows that it works:
>>
>> https://gist.github.com/plevart/3ddada53824faede66e843acd0dfa92f
>>
>> This patch does not support ClassValue.remove operation. Interesting question is whether it would be possible to support remove via some kind of MethodHandle/de-opt trickery (R?mi would know).
>>
>> Regards, Peter
>>



From peter.levart at gmail.com  Mon Aug 31 12:35:38 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 31 Aug 2020 14:35:38 +0200
Subject: early steps on the road to customization
In-Reply-To: <83b52115-9d07-8c35-a4e5-d44d612ad56c@gmail.com>
References: <B246D510-C711-4F65-BE2E-187000171C1C@oracle.com>
 <120aa39e-afe7-66a8-f82a-557bde44e66e@oracle.com>
 <D6585AAB-1178-454D-B7C0-4EEB920193E6@oracle.com>
 <1c86b856-1ccf-79ea-a438-0b66e332e12c@gmail.com>
 <E13BAA2E-3A44-4274-9E6D-B314B6C5479D@oracle.com>
 <83b52115-9d07-8c35-a4e5-d44d612ad56c@gmail.com>
Message-ID: <3ef0ceb5-3d6e-0c4c-2d0e-41551ca7c75a@gmail.com>



On 8/31/20 1:19 PM, Peter Levart wrote:
> Here's a variant of ClassValue that replaces entirely existing one and 
> supports dynamic sizing of backing array, get(), remove() and put() 
> operations and even re-use of table indexes used by GC-ed ClassValue 
> instances. It passes the ClassValueTest:
>
> https://github.com/plevart/valhalla/pull/3

Oops, I missed some races when resizing the backing array. They are 
fixed now. Benchmarks still hold:

https://github.com/plevart/valhalla/pull/4

Peter