From sadayapalam at openjdk.java.net  Mon Jan  3 11:03:38 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 Jan 2022 11:03:38 GMT
Subject: [lworld] Integrated: 8279377: [lworld] Javac Parser still has stale
 code supporting nullable projection types from a previous era
Message-ID: <YI5tHj123BJtHS8w6xu_18wNAV6KaWJIgA6tROFON7E=.d0336c74-6334-4c8d-8d81-368b9ded8bf9@github.com>

Garbage collect stale code handling nullable projection types using the ? syntax

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

Commit messages:
 - 8279377: [lworld] Javac Parser still has stale code supporting nullable projection types from a previous era

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

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

From sadayapalam at openjdk.java.net  Mon Jan  3 11:03:39 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 3 Jan 2022 11:03:39 GMT
Subject: [lworld] Integrated: 8279377: [lworld] Javac Parser still has stale
 code supporting nullable projection types from a previous era
In-Reply-To: <YI5tHj123BJtHS8w6xu_18wNAV6KaWJIgA6tROFON7E=.d0336c74-6334-4c8d-8d81-368b9ded8bf9@github.com>
References: <YI5tHj123BJtHS8w6xu_18wNAV6KaWJIgA6tROFON7E=.d0336c74-6334-4c8d-8d81-368b9ded8bf9@github.com>
Message-ID: <E5XOZkYd49hfA1WRXI73pWJ-InpxkeIemw0LSAR1eAw=.d26dfad4-2cd7-484d-9c4d-fc8e29780677@github.com>

On Mon, 3 Jan 2022 10:57:22 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Garbage collect stale code handling nullable projection types using the ? syntax

This pull request has now been integrated.

Changeset: 8692aefa
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8692aefa5ca3cb3dcd55dfa7f6d96c94f07ab813
Stats:     11 lines in 1 file changed: 0 ins; 9 del; 2 mod

8279377: [lworld] Javac Parser still has stale code supporting nullable projection types from a previous era

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

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

From andvasp at gmail.com  Tue Jan  4 12:31:57 2022
From: andvasp at gmail.com (Anderson Vasconcelos Pires)
Date: Tue, 4 Jan 2022 09:31:57 -0300
Subject: Using the variable instantiation to define if is primitive type
 (Bucket 3) or value type (Bucket 2)
Message-ID: <CACB8oqVLj_u6HMqFK=+u8EAFWKXaAFvRjc=+3MEaieF+LrwhyQ@mail.gmail.com>

Hi guys,

I am very excited about Valhalla and what it will do for Java. I was
wondering if the language proposals could be simplified a little bit
without affecting performance.

Please let me (maybe the community) know if the proposal below could be
applied or not.

>From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
equivalent, right?

If so, I was wondering if we could have just one class declaration and
distinguish the variable from how it is created.

The runtime variable would be a value object if we use the new keyword to
instantiate the variable, if not would be primitive value. I think it makes
a little bit of sense since the new is used to create an object today,
right?

See the example below:

[primitive or value] class Point {
    int x;
    int y;
}

Point p1 = Point(1, 1); // primitive value   - p1 is value of Point. Could
be defined at compile time as new Point() in the actual proposal;
Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
Could be defined at compile time as new Point.ref();

Assuming the Point.ref is a subtype of Point, I believe this could be
possible, right? If necessary, the right type could be defined at compile
time in some cases.

I do not know if it would have extra cost. I hope not.

private Point getPoint(boolean reference) {
     if (reference)
          return new Point(1, 1);
      else
          return Point(1, 1);
}

Point p1 = getPoint(true); // p1 runtime is a value object -> Point.ref

The array would be like below.

Point[] ps1 = Point[10];  // assert ps1[0].x == 0
Point[] ps2 = new Point[10]; // assert ps2[0] == null

In this way primitive variables could be null. I don't think this is a
problem since the wrapper class looks like it will continue to be nullable.
For another point of view, the builtin primitives cannot be null. An
Advantage is that it would not be necessary to include T.ref at the return
of Map.get.

One doubt is about another [primitive or value] class that has [primitive
or value] members like shown below.

[primitive or value] class Rectangle {
    Point low;
    Point high;
}

Maybe it would be a problem because the object size could not be defined
previously. But we may assume in this case the size of primitive value.
This way, Rectangle would be flat.

Thanks for your time and please let me know your thoughts about this
proposal.

Anderson.

From mariell.hoversholm at paf.com  Wed Jan  5 06:19:59 2022
From: mariell.hoversholm at paf.com (Mariell Hoversholm)
Date: Wed, 5 Jan 2022 07:19:59 +0100
Subject: Using the variable instantiation to define if is primitive type
 (Bucket 3) or value type (Bucket 2)
In-Reply-To: <CACB8oqVLj_u6HMqFK=+u8EAFWKXaAFvRjc=+3MEaieF+LrwhyQ@mail.gmail.com>
References: <CACB8oqVLj_u6HMqFK=+u8EAFWKXaAFvRjc=+3MEaieF+LrwhyQ@mail.gmail.com>
Message-ID: <CAKSb5uNnqV0C_OHJ6JzJqgnXdHY24BQEciOFCd_5G78y0H2Tqg@mail.gmail.com>

Hi Anderson,

I believe this could cause an issue for developers when it comes to reading
the
code: `new Point.ref(1, 1)` is clear in its intent that it wants to
instantiate
a _heap_ object as opposed to a 'primitive object'. It also makes it clear
that
they aren't necessarily the same type.

If Java were to 'flatten' (perhaps there is better terminology for this
case?)
the type into only `Point` (thereby allowing `new Point(1, 1)` to
instantiate
a new heap object), it could cause confusion. Furthermore, if we were to
require
a heap object (for nullability purposes?) in a method, this would be more
confusing:


    method(new Point(1, 1)); // Is this creating a `Point` or `Point.ref`?

    void method(@Nullable Point.ref point);


I am also somewhat unsure how the array behaviour would work in this case?
Arrays are themselves a 'new' type: beyond the primitives we have today
creating
e.g. `[I`, `[J`, etc., it would create either a `[QPrimitive;` (primitive
class)
or `[LPrimitive;` (heap class; `Point.ref[]`). Having the arrays 'hide' the
real
type with `new Point[10]` in fact being `new Point.ref[10]` while
`Point[10]` in
fact becomes `new Point[10]` is very confusing and may cause unwanted
problems.

The idea is interesting, I'm simply not sure from a consistency-to-the-user
standpoint: it would create differences I would not be welcoming of in a
language I use daily, nor do I believe others would either.

On Tue, 4 Jan 2022 at 13:33, Anderson Vasconcelos Pires <andvasp at gmail.com>
wrote:

> Hi guys,
>
> I am very excited about Valhalla and what it will do for Java. I was
> wondering if the language proposals could be simplified a little bit
> without affecting performance.
>
> Please let me (maybe the community) know if the proposal below could be
> applied or not.
>
> From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
> I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
> equivalent, right?
>
> If so, I was wondering if we could have just one class declaration and
> distinguish the variable from how it is created.
>
> The runtime variable would be a value object if we use the new keyword to
> instantiate the variable, if not would be primitive value. I think it makes
> a little bit of sense since the new is used to create an object today,
> right?
>
> See the example below:
>
> [primitive or value] class Point {
>     int x;
>     int y;
> }
>
> Point p1 = Point(1, 1); // primitive value   - p1 is value of Point. Could
> be defined at compile time as new Point() in the actual proposal;
> Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
> Could be defined at compile time as new Point.ref();
>
> Assuming the Point.ref is a subtype of Point, I believe this could be
> possible, right? If necessary, the right type could be defined at compile
> time in some cases.
>
> I do not know if it would have extra cost. I hope not.
>
> private Point getPoint(boolean reference) {
>      if (reference)
>           return new Point(1, 1);
>       else
>           return Point(1, 1);
> }
>
> Point p1 = getPoint(true); // p1 runtime is a value object -> Point.ref
>
> The array would be like below.
>
> Point[] ps1 = Point[10];  // assert ps1[0].x == 0
> Point[] ps2 = new Point[10]; // assert ps2[0] == null
>
> In this way primitive variables could be null. I don't think this is a
> problem since the wrapper class looks like it will continue to be nullable.
> For another point of view, the builtin primitives cannot be null. An
> Advantage is that it would not be necessary to include T.ref at the return
> of Map.get.
>
> One doubt is about another [primitive or value] class that has [primitive
> or value] members like shown below.
>
> [primitive or value] class Rectangle {
>     Point low;
>     Point high;
> }
>
> Maybe it would be a problem because the object size could not be defined
> previously. But we may assume in this case the size of primitive value.
> This way, Rectangle would be flat.
>
> Thanks for your time and please let me know your thoughts about this
> proposal.
>
> Anderson.
>


-- 

*Mariell Hoversholm *(she/her)

Software Developer @ <https://aboutpaf.com>

From sadayapalam at openjdk.java.net  Wed Jan  5 09:51:08 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 Jan 2022 09:51:08 GMT
Subject: [lworld] Integrated: 8279431: [lworld] Withdraw all support for
 ref-default classes
In-Reply-To: <Hn-IQoALWIjEfPtDY9iVeLp4vUGuir3efRAlquksBjA=.1cdd80e3-7e51-44f8-aab7-7e0aef954ad7@github.com>
References: <Hn-IQoALWIjEfPtDY9iVeLp4vUGuir3efRAlquksBjA=.1cdd80e3-7e51-44f8-aab7-7e0aef954ad7@github.com>
Message-ID: <sJ7rW6hpQpqrMb-NTJdV5Ki1ixuLbW1KoAyZm6R4YQ8=.576a1549-a75e-49be-96bd-85a35eb11281@github.com>

On Wed, 5 Jan 2022 09:38:42 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> This reverts commit a4066d7a21377c03c04565fe23981d650f777a7b and a few other 
> incremental additions on top of it. ref-default classes have lost their relevance
> in the new three bucket model subsumed by value classes.

This pull request has now been integrated.

Changeset: 021839b7
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/021839b798ccb65fca660fe86c2f6e6f07d94bb0
Stats:     4053 lines in 107 files changed: 12 ins; 3951 del; 90 mod

8279431: [lworld] Withdraw all support for ref-default classes

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

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

From sadayapalam at openjdk.java.net  Wed Jan  5 09:51:08 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 5 Jan 2022 09:51:08 GMT
Subject: [lworld] Integrated: 8279431: [lworld] Withdraw all support for
 ref-default classes
Message-ID: <Hn-IQoALWIjEfPtDY9iVeLp4vUGuir3efRAlquksBjA=.1cdd80e3-7e51-44f8-aab7-7e0aef954ad7@github.com>

This reverts commit a4066d7a21377c03c04565fe23981d650f777a7b and a few other 
incremental additions on top of it. ref-default classes have lost their relevance
in the new three bucket model subsumed by value classes.

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

Commit messages:
 - Fix white space issues
 - Revert "8244231: [lworld] Add support for ref-default and val-default inline classes."

Changes: https://git.openjdk.java.net/valhalla/pull/592/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=592&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279431
  Stats: 4053 lines in 107 files changed: 12 ins; 3951 del; 90 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/592.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/592/head:pull/592

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

From brian.goetz at oracle.com  Wed Jan  5 12:58:45 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 5 Jan 2022 07:58:45 -0500
Subject: Reader mail bag
Message-ID: <34afe0d9-c669-fdfd-5ecc-ad211cdf7ee8@oracle.com>


The below was received on the valhalla-spec-comments list; replying here 
as it would have been suitable for this list.

> I am very excited about Valhalla and what it will do for Java. I was
> wondering if the language proposals could be simplified a little bit
> without affecting performance.
>
> Please let me (maybe the community) know if the proposal below could be
> applied or not.
>
> From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
> I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
> equivalent, right?

Correct.? The reference companion P.ref of a primitive class P behaves 
like a value class.

> If so, I was wondering if we could have just one class declaration and
> distinguish the variable from how it is created.
>
> The runtime variable would be a value object if we use the new keyword to
> instantiate the variable, if not would be primitive value. I think it 
> makes
> a little bit of sense since the new is used to create an object today,
> right?

The distinction between a Point and a Point.ref is similar, 
semantically, to the difference between a long and a Long:

 ?- long is a direct value, Long is a reference to an object
 ?- because long is a large direct value, it can tear under race
 ?- because Long is a reference, it gets initialization safety guarantees
 ?- because Long is a reference, it can be null

What's different from today's long/Long story is that, by dropping 
identity, the VM is free to inline Point (and even Point.ref, to a 
lesser degree) in heap objects, and scalarize them in calling conventions.

But, the important distinction is not how the variable is _created_ -- a 
Point is just its (x, y) fields -- but how it is _stored_.? When you say 
`Point`, you are saying "I'm fine with direct (scalar) storage"; when 
you say `Point.ref`, you are saying "I require reference semantics."? 
But its the same Point either way.? When you convert from a Point to a 
Point.ref via widening, all that changes is the constraints on how the 
values are stored, but the result is still `==` to what you started with.

The temptation to try and merge buckets 2 and 3 is understandable, and 
we tried to do so several times.? But each time, something important was 
lost.

> See the example below:
>
> [primitive or value] class Point {
> ? ? int x;
> ? ? int y;
> }
>
> Point p1 = Point(1, 1); // primitive value? ?- p1 is value of Point. Could
> be defined at compile time as new Point() in the actual proposal;
> Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
> Could be defined at compile time as new Point.ref();

Ignoring the specific syntax proposal (presence or absence of `new`, 
which is pretty subtle), what you've just done is made `Point` 
polymorphic, which undermines many of the advantages that Valhalla would 
give.? We are able to optimize both Point and Point.ref in part because 
they are monomorphic.

> Assuming the Point.ref is a subtype of Point, I believe this could be
> possible, right? If necessary, the right type could be defined at compile
> time in some cases.
>
> I do not know if it would have extra cost. I hope not.

Yes, a lot :)

> private Point getPoint(boolean reference) {
> ? ? ?if (reference)
> ? ? ? ? ? return new Point(1, 1);
> ? ? ? else
> ? ? ? ? ? return Point(1, 1);
> }
>
> Point p1 = getPoint(true); // p1 runtime is a value object -> Point.ref
>
> The array would be like below.
>
> Point[] ps1 = Point[10];? // assert ps1[0].x == 0
> Point[] ps2 = new Point[10]; // assert ps2[0] == null
>
> In this way primitive variables could be null. I don't think this is a
> problem since the wrapper class looks like it will continue to be 
> nullable.
> For another point of view, the builtin primitives cannot be null. An
> Advantage is that it would not be necessary to include T.ref at the return
> of Map.get.
>
> One doubt is about another [primitive or value] class that has [primitive
> or value] members like shown below.
>
> [primitive or value] class Rectangle {
> ? ? Point low;
> ? ? Point high;
> }
>
> Maybe it would be a problem because the object size could not be defined
> previously. But we may assume in this case the size of primitive value.
> This way, Rectangle would be flat.
>
> Thanks for your time and please let me know your thoughts about this
> proposal.

From andvasp at gmail.com  Wed Jan  5 13:42:40 2022
From: andvasp at gmail.com (Anderson Vasconcelos Pires)
Date: Wed, 5 Jan 2022 10:42:40 -0300
Subject: Using the variable instantiation to define if is primitive type
 (Bucket 3) or value type (Bucket 2)
In-Reply-To: <CAKSb5uNnqV0C_OHJ6JzJqgnXdHY24BQEciOFCd_5G78y0H2Tqg@mail.gmail.com>
References: <CACB8oqVLj_u6HMqFK=+u8EAFWKXaAFvRjc=+3MEaieF+LrwhyQ@mail.gmail.com>
 <CAKSb5uNnqV0C_OHJ6JzJqgnXdHY24BQEciOFCd_5G78y0H2Tqg@mail.gmail.com>
Message-ID: <CACB8oqVUWHNjVejT=FKw5AKvP-TmRPkUsgEosOF1ZfsT58npEQ@mail.gmail.com>

Hi Mariell!

Thanks for your reply. Please check my answers in the email below.

The points that I would like to know if this proposal is possible to be
applied, if it has performance impact and another if people like it.

If it has performance impact, it is not a good idea and I think there is
but I have a hope.

My point to create this proposal is:

   - I prefer not to have .ref at language level.
   - I prefer not to have both value class and Primitive.ref, since they
   are equivalent.

In this proposal primitive can be null and I do not care but I care if it
has performance impact.

I understand that Primitive.ref is necessary for the JVM. Because of
development flexibility, maybe I will use more Primitive class than value
class and instantiate using .ref when I need nullability, atomicity even
though I don't like so much the .ref syntax;

But I see great progress in the Valhalla project and I am very excited and
anxious to be released. By the way I would like to congratulate the experts
for this excellent job!

On Wed, Jan 5, 2022 at 3:20 AM Mariell Hoversholm <
mariell.hoversholm at paf.com> wrote:

> Hi Anderson,
>
> I believe this could cause an issue for developers when it comes to
> reading the
> code: `new Point.ref(1, 1)` is clear in its intent that it wants to
> instantiate
> a _heap_ object as opposed to a 'primitive object'. It also makes it clear
> that
> they aren't necessarily the same type.
>

Yes. new Point.ref(1, 1) is more clear that is a reference type.


>
> If Java were to 'flatten' (perhaps there is better terminology for this
> case?)
> the type into only `Point` (thereby allowing `new Point(1, 1)` to
> instantiate
> a new heap object), it could cause confusion. Furthermore, if we were to
> require
> a heap object (for nullability purposes?) in a method, this would be more
> confusing:
>

In this proposal, primitive is nullable. Ok?
Point.ref is a sub type of Point. So creating new Point(1, 1) I am creating
Point.ref and using the Point interface that is the same. Like List list =
new ArrayList();


>     method(new Point(1, 1)); // Is this creating a `Point` or `Point.ref`?
>

Is creating a Point.ref if you want Point you would use Point(1, 1) without
new.


>
>     void method(@Nullable Point.ref point);
>

Point.ref would not be possible to use. You have to use it like below.

    void method(Point point);


>
>
> I am also somewhat unsure how the array behaviour would work in this case?
> Arrays are themselves a 'new' type: beyond the primitives we have today
> creating
> e.g. `[I`, `[J`, etc., it would create either a `[QPrimitive;` (primitive
> class)
> or `[LPrimitive;` (heap class; `Point.ref[]`). Having the arrays 'hide'
> the real
> type with `new Point[10]` in fact being `new Point.ref[10]` while
> `Point[10]` in
> fact becomes `new Point[10]` is very confusing and may cause unwanted
> problems.
>
> The idea is interesting, I'm simply not sure from a consistency-to-the-user
> standpoint: it would create differences I would not be welcoming of in a
> language I use daily, nor do I believe others would either.
>




>
> On Tue, 4 Jan 2022 at 13:33, Anderson Vasconcelos Pires <andvasp at gmail.com>
> wrote:
>
>> Hi guys,
>>
>> I am very excited about Valhalla and what it will do for Java. I was
>> wondering if the language proposals could be simplified a little bit
>> without affecting performance.
>>
>> Please let me (maybe the community) know if the proposal below could be
>> applied or not.
>>
>> From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
>> I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
>> equivalent, right?
>>
>> If so, I was wondering if we could have just one class declaration and
>> distinguish the variable from how it is created.
>>
>> The runtime variable would be a value object if we use the new keyword to
>> instantiate the variable, if not would be primitive value. I think it
>> makes
>> a little bit of sense since the new is used to create an object today,
>> right?
>>
>> See the example below:
>>
>> [primitive or value] class Point {
>>     int x;
>>     int y;
>> }
>>
>> Point p1 = Point(1, 1); // primitive value   - p1 is value of Point. Could
>> be defined at compile time as new Point() in the actual proposal;
>> Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
>> Could be defined at compile time as new Point.ref();
>>
>> Assuming the Point.ref is a subtype of Point, I believe this could be
>> possible, right? If necessary, the right type could be defined at compile
>> time in some cases.
>>
>> I do not know if it would have extra cost. I hope not.
>>
>> private Point getPoint(boolean reference) {
>>      if (reference)
>>           return new Point(1, 1);
>>       else
>>           return Point(1, 1);
>> }
>>
>> Point p1 = getPoint(true); // p1 runtime is a value object -> Point.ref
>>
>> The array would be like below.
>>
>> Point[] ps1 = Point[10];  // assert ps1[0].x == 0
>> Point[] ps2 = new Point[10]; // assert ps2[0] == null
>>
>> In this way primitive variables could be null. I don't think this is a
>> problem since the wrapper class looks like it will continue to be
>> nullable.
>> For another point of view, the builtin primitives cannot be null. An
>> Advantage is that it would not be necessary to include T.ref at the return
>> of Map.get.
>>
>> One doubt is about another [primitive or value] class that has [primitive
>> or value] members like shown below.
>>
>> [primitive or value] class Rectangle {
>>     Point low;
>>     Point high;
>> }
>>
>> Maybe it would be a problem because the object size could not be defined
>> previously. But we may assume in this case the size of primitive value.
>> This way, Rectangle would be flat.
>>
>> Thanks for your time and please let me know your thoughts about this
>> proposal.
>>
>> Anderson.
>>
>
>
> --
>
> *Mariell Hoversholm *(she/her)
>
> Software Developer @ <https://aboutpaf.com>
>

From forax at univ-mlv.fr  Wed Jan  5 13:56:04 2022
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 5 Jan 2022 14:56:04 +0100 (CET)
Subject: Using the variable instantiation to define if is primitive type
 (Bucket 3) or value type (Bucket 2)
In-Reply-To: <CACB8oqVLj_u6HMqFK=+u8EAFWKXaAFvRjc=+3MEaieF+LrwhyQ@mail.gmail.com>
References: <CACB8oqVLj_u6HMqFK=+u8EAFWKXaAFvRjc=+3MEaieF+LrwhyQ@mail.gmail.com>
Message-ID: <1144241056.5793867.1641390964781.JavaMail.zimbra@u-pem.fr>

----- Original Message -----
> From: "Anderson Vasconcelos Pires" <andvasp at gmail.com>
> To: valhalla-spec-comments at openjdk.java.net, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Sent: Tuesday, January 4, 2022 1:31:57 PM
> Subject: Using the variable instantiation to define if is primitive type (Bucket 3) or value type (Bucket 2)

> Hi guys,

Hi Anderson,

> 
> I am very excited about Valhalla and what it will do for Java. I was
> wondering if the language proposals could be simplified a little bit
> without affecting performance.
> 
> Please let me (maybe the community) know if the proposal below could be
> applied or not.
> 
> From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
> I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
> equivalent, right?

not exactly,
they both represent the same type a nullable object with a value semantics, but they are different beasts,
a Primitive.ref is an interface, a value class is a concrete class

> 
> If so, I was wondering if we could have just one class declaration and
> distinguish the variable from how it is created.
> 
> The runtime variable would be a value object if we use the new keyword to
> instantiate the variable, if not would be primitive value. I think it makes
> a little bit of sense since the new is used to create an object today,
> right?
> 
> See the example below:
> 
> [primitive or value] class Point {
>    int x;
>    int y;
> }
> 
> Point p1 = Point(1, 1); // primitive value   - p1 is value of Point. Could
> be defined at compile time as new Point() in the actual proposal;
> Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
> Could be defined at compile time as new Point.ref();
> 
> Assuming the Point.ref is a subtype of Point, I believe this could be
> possible, right? If necessary, the right type could be defined at compile
> time in some cases.

Point.ref is a NOT a subtype of Point, it works the other way, Point.ref a super type of Point (if Point is a primitive).

[...]

> 
> Anderson.


Let me try to explain how it works, at least this is how i explain it to myself.

Valhalla has more or less two related goals, we want to avoid to pay for abstraction (not allocate an Optional on stack) and we want to improve the information density (an arrays of objects should not be automatically an array of reference on heap).

For the first goal, we need to change the meaning of ==, hashCode, synchronize and weak reference because they all require either an address on heap or an object header.
We call these objects "value objects", == compare all fields, hashCode mix the values of some of the fields, synchronize throw an IllegalMonitorState and for weak refs we still not have figure how to deal with them. 

For the second goal, we need to introduce objects that are not represented by a reference but by the immediate values of their fields like with primitives.
We call these objects "primitive object", they are not nullable, tearable (are assigned in several CPU instructions which sucks for concurrent code), all zeroes must be a valid default value and have a box to interact with concurrent code and generic code.

We can remark that
- primitive objects are value objects because a primitive object has no address on heap.
- we can try to retrofit builtin primitive values (int, double, etc) to be primitive objects
- the box for a primitive object can be pushed to corner cases if we overhaul generics to work with primitive objects.
- the box for a primitive object can be an interface not a concrete class unlike Integer, Double, etc which is more efficient

But we can not have only one thingy that combines the property of a value object and a primitive object, because a primitive object breaks encapsulation, it is tearable and the default value bypass the constructor. The dichotomy between value object and primitive object represent that tradeoff.  


More on Point.ref, let say i declare a primitive Point
  primitive Point {
    private final int x;
    private final int y;
    
    Point(int x, int y) {
      this.x = x;
      this.y = y;
    }
   }

this is what the compiler generates
  sealed interface Point.ref permits Point {
  }
  primitive Point implements Point.ref {
    private final int x;
    private final int y;
    
    Point(int x, int y) {
      this.x = x;
      this.y = y;
    }
   }

Point.ref is an interface automatically generated by the compiler so the relation between a Point and a Point.ref are subtyping relation not boxing relation.

We may in the future revisit this because we currently have two ways to represent the same thing LPoint; and LPoint.ref;

regards,
R?mi

From sadayapalam at openjdk.java.net  Thu Jan  6 10:01:06 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 6 Jan 2022 10:01:06 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800 to
 align with draft JVMS
Message-ID: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>

Change ACC_PRIMITIVE to be 0x800 across components sources and tests

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

Commit messages:
 - 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800 to align with draft JVMS

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

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

From thartmann at openjdk.java.net  Thu Jan  6 13:19:43 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 6 Jan 2022 13:19:43 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
Message-ID: <DQRjgU4gCmXJkb062OFXsgL21VfbxhF7P6JSCDtnNro=.86c29ad4-dc17-4d9f-a132-8d2a64b788e7@github.com>

On Thu, 6 Jan 2022 09:54:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Change ACC_PRIMITIVE to be 0x800 across components sources and tests

Changes to the JIT test look good.

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

Marked as reviewed by thartmann (Committer).

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

From fparain at openjdk.java.net  Thu Jan  6 13:19:44 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 6 Jan 2022 13:19:44 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
Message-ID: <ZTEtBQZt1GtcSlc_aP4JJPpBEiAySny_j367aFK5Qi0=.da8c0417-f1b8-4b60-a4b7-4df9f961b748@github.com>

On Thu, 6 Jan 2022 09:54:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Change ACC_PRIMITIVE to be 0x800 across components sources and tests

HotSpot changes look good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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

From rriggs at openjdk.java.net  Thu Jan  6 15:13:39 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 6 Jan 2022 15:13:39 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
Message-ID: <OexdnLRtp3cu4Mc4RVosWWhZAf1XtRpNbbhgGjzd6Og=.f24d2f02-cc49-4c6a-91a7-8a9ddb926075@github.com>

On Thu, 6 Jan 2022 09:54:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Change ACC_PRIMITIVE to be 0x800 across components sources and tests

LGTM for libraries changes and jdeps

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

Marked as reviewed by rriggs (Committer).

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

From duke at openjdk.java.net  Thu Jan  6 15:33:45 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 6 Jan 2022 15:33:45 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
Message-ID: <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>

On Thu, 6 Jan 2022 09:54:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Change ACC_PRIMITIVE to be 0x800 across components sources and tests

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1551:

> 1549:             flags = adjustFlags(c.flags() & ~DEFAULT);
> 1550:             if ((flags & PROTECTED) != 0) flags |= PUBLIC;
> 1551:             flags = flags & (ClassFlags | ACC_PRIMITIVE) & ~STRICTFP;

As far as I can understand, `ACC_PRIMITIVE` was removed from here because it is driven by the relevant if-clause in relation to `PRIMITIVE_CLASS` in `adjustFlags` which makes the code clearer at this point. Is my assumption correct?

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

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

From sadayapalam at openjdk.java.net  Thu Jan  6 16:17:30 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 6 Jan 2022 16:17:30 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
 <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>
Message-ID: <R-KebVQ3omW6IhjacjujIfK6MuEkhwfHP1B8DrhY8Rs=.3530e797-0961-4c02-b0ad-d05441ebafc1@github.com>

On Thu, 6 Jan 2022 15:28:37 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Change ACC_PRIMITIVE to be 0x800 across components sources and tests
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1551:
> 
>> 1549:             flags = adjustFlags(c.flags() & ~DEFAULT);
>> 1550:             if ((flags & PROTECTED) != 0) flags |= PUBLIC;
>> 1551:             flags = flags & (ClassFlags | ACC_PRIMITIVE) & ~STRICTFP;
> 
> As far as I can understand, `ACC_PRIMITIVE` was removed from here because it is driven by the relevant if-clause in relation to `PRIMITIVE_CLASS` in `adjustFlags` which makes the code clearer at this point. Is my assumption correct?

Good question! Thanks for asking. 

Indeed there is a "problem" here - actually two problems, one old and one new. I put problem in quotes because, the bug is only latent at the moment and does not impact anything. but is nevertheless a bug and should be fixed.

Explanation. First the old bug:

In Flags.java we have the following:


LocalClassFlags                   = FINAL | ABSTRACT | STRICTFP | ENUM | SYNTHETIC  | PRIMITIVE_CLASS,
ClassFlags                        = LocalClassFlags | INTERFACE | PUBLIC | ANNOTATION,
``` 

This is problematic because PRIMITIVE_CLASS is defined to be 1 << 16 - while the class file representation of flags is only 16 bits. Which is why there is a mapping from PRIMITIVE_CLASS to ACC_PRIMITIVE in the first place.

So the definition of LocalClassFlags should have had the bit corresponding to 0x100 ie  (1 << 8) set by including a suitable symbolic constant in place of PRIMITIVE_CLASS.

The idea behind doing

flags = flags & ClassFlags


in the old (and new code) is ensure that no bit other than well defined class flags bits are set in the flags being written out to file. By not having 0x100 (old ACC_PRIMITIVE) set in ClassFlags we are inadvertently masking ACC_PRIMITIVE bit and to avoid running into problems there, we or back ACC_PRIMITIVE into the ClassFlags just being &ing.

New problem:

In the new code, again LocalClassFlags is missing ACC_PRIMITIVE, but things work just fine but by accident - only because ACC_PRIMITIVE shares the same value with ACC_STRICT !

I'll post a revision that will make this clear and address the latent bug (which may become real bug if ACC_PRIMITIVE changes value again to have a value that is not already a known bit pattern in LocalClassFlags) 

The right

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

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

From vromero at openjdk.java.net  Thu Jan  6 20:07:33 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 Jan 2022 20:07:33 GMT
Subject: RFR: Merge lworld
Message-ID: <tKsgtaFcH3kpD6cx-3733Btb4IStMtdBmk3cB9nVBYo=.80fdcddb-1d3a-4a38-8aef-acf347559a02@github.com>

# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java

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

Commit messages:
 - Merge branch 'lworld' into universal-tvars_merge_lworld
 - 8279431: [lworld] Withdraw all support for ref-default classes
 - 8279377: [lworld] Javac Parser still has stale code supporting nullable projection types from a previous era
 - 8274800: [lworld] Primitive classes can't be retransformed
 - 8278352: [lworld] nmethod assembly snippet in hs_err file misses method name and parameters
 - 8278350: [lworld] Compiler test failures after merge with mainline
 - Merge jdk
 - 8274685: Documentation suggests there are ArbitrarilyJumpableGenerator when none
 - 8273792: JumpableGenerator.rngs() documentation refers to wrong method
 - 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 - ... and 1123 more: https://git.openjdk.java.net/valhalla/compare/bc2580e1...443c8df8

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

Changes: https://git.openjdk.java.net/valhalla/pull/594/files
  Stats: 994625 lines in 4029 files changed: 527788 ins; 446352 del; 20485 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/594.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/594/head:pull/594

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

From vromero at openjdk.java.net  Thu Jan  6 20:22:26 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 Jan 2022 20:22:26 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <tKsgtaFcH3kpD6cx-3733Btb4IStMtdBmk3cB9nVBYo=.80fdcddb-1d3a-4a38-8aef-acf347559a02@github.com>
References: <tKsgtaFcH3kpD6cx-3733Btb4IStMtdBmk3cB9nVBYo=.80fdcddb-1d3a-4a38-8aef-acf347559a02@github.com>
Message-ID: <-NuE009NM9veZchy4wxGpthdtevUWh26FpSmOlZocJI=.0be6f448-84c7-417b-9ad6-ac6669c2c2a1@github.com>

> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'lworld' into universal-tvars_merge_lworld
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
 - Primitive value conversion
 - updating tests
 - Merge lworld
 - Merge lworld
 - universal type variables: initial prototype
   
   Reviewed-by: mcimadamore
 - Merge lworld
 - Merge lworld
 - Merge lworld

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

Changes: https://git.openjdk.java.net/valhalla/pull/594/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=594&range=01
  Stats: 796 lines in 22 files changed: 759 ins; 1 del; 36 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/594.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/594/head:pull/594

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

From vromero at openjdk.java.net  Thu Jan  6 20:22:30 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 6 Jan 2022 20:22:30 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <tKsgtaFcH3kpD6cx-3733Btb4IStMtdBmk3cB9nVBYo=.80fdcddb-1d3a-4a38-8aef-acf347559a02@github.com>
References: <tKsgtaFcH3kpD6cx-3733Btb4IStMtdBmk3cB9nVBYo=.80fdcddb-1d3a-4a38-8aef-acf347559a02@github.com>
Message-ID: <OddPaNuEtcae4YFST7FZDvIjJum7yXakdW05Z1tiSdQ=.aee914c2-6bf2-4abe-90b9-3d82d2d9f86a@github.com>

On Thu, 6 Jan 2022 19:45:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java

This pull request has now been integrated.

Changeset: b2983550
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b2983550085410c762306f6eaeb9e2f6aad5568b
Stats:     994625 lines in 4029 files changed: 527788 ins; 446352 del; 20485 mod

Merge lworld

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

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

From duke at openjdk.java.net  Thu Jan  6 22:18:44 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 6 Jan 2022 22:18:44 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <R-KebVQ3omW6IhjacjujIfK6MuEkhwfHP1B8DrhY8Rs=.3530e797-0961-4c02-b0ad-d05441ebafc1@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
 <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>
 <R-KebVQ3omW6IhjacjujIfK6MuEkhwfHP1B8DrhY8Rs=.3530e797-0961-4c02-b0ad-d05441ebafc1@github.com>
Message-ID: <f7QKmu6GioQUyJ3xNibIdBZiPcOrjddJjH3KBHmo8P8=.bc884e76-7cd2-4af9-afb3-6bf8b28ba541@github.com>

On Thu, 6 Jan 2022 16:14:15 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java line 1551:
>> 
>>> 1549:             flags = adjustFlags(c.flags() & ~DEFAULT);
>>> 1550:             if ((flags & PROTECTED) != 0) flags |= PUBLIC;
>>> 1551:             flags = flags & (ClassFlags | ACC_PRIMITIVE) & ~STRICTFP;
>> 
>> As far as I can understand, `ACC_PRIMITIVE` was removed from here because it is driven by the relevant if-clause in relation to `PRIMITIVE_CLASS` in `adjustFlags` which makes the code clearer at this point. Is my assumption correct?
>
> Good question! Thanks for asking. 
> 
> Indeed there is a "problem" here - actually two problems, one old and one new. I put problem in quotes because, the bug is only latent at the moment and does not impact anything. but is nevertheless a bug and should be fixed.
> 
> Explanation. First the old bug:
> 
> In Flags.java we have the following:
> 
> 
> LocalClassFlags                   = FINAL | ABSTRACT | STRICTFP | ENUM | SYNTHETIC  | PRIMITIVE_CLASS,
> ClassFlags                        = LocalClassFlags | INTERFACE | PUBLIC | ANNOTATION,
> ``` 
> 
> This is problematic because PRIMITIVE_CLASS is defined to be 1 << 16 - while the class file representation of flags is only 16 bits. Which is why there is a mapping from PRIMITIVE_CLASS to ACC_PRIMITIVE in the first place.
> 
> So the definition of LocalClassFlags should have had the bit corresponding to 0x100 ie  (1 << 8) set by including a suitable symbolic constant in place of PRIMITIVE_CLASS.
> 
> The idea behind doing
> 
> flags = flags & ClassFlags
> 
> 
> in the old (and new code) is ensure that no bit other than well defined class flags bits are set in the flags being written out to file. By not having 0x100 (old ACC_PRIMITIVE) set in ClassFlags we are inadvertently masking ACC_PRIMITIVE bit and to avoid running into problems there, we or back ACC_PRIMITIVE into the ClassFlags just being &ing.
> 
> New problem:
> 
> In the new code, again LocalClassFlags is missing ACC_PRIMITIVE, but things work just fine but by accident - only because ACC_PRIMITIVE shares the same value with ACC_STRICT !
> 
> I'll post a revision that will make this clear and address the latent bug (which may become real bug if ACC_PRIMITIVE changes value again to have a value that is not already a known bit pattern in LocalClassFlags) 
> 
> The right

Thank you for the detailed explanation.

> In the new code, again LocalClassFlags is missing ACC_PRIMITIVE, but things work just fine but by accident - only because ACC_PRIMITIVE shares the same value with ACC_STRICT !

I am still a bit confused because I don't see any uses of ACC_STRICT but only STRICT_FP at that level (which is indeed 1<<11, 0x0800). So in my mind it shares the same value with STRICT_FP not ACC_STRICT. I will fully get it with your upcoming revision ?? ?? 

Thanks again for the explanation!

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

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

From sadayapalam at openjdk.java.net  Fri Jan  7 05:51:30 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 7 Jan 2022 05:51:30 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <f7QKmu6GioQUyJ3xNibIdBZiPcOrjddJjH3KBHmo8P8=.bc884e76-7cd2-4af9-afb3-6bf8b28ba541@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
 <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>
 <R-KebVQ3omW6IhjacjujIfK6MuEkhwfHP1B8DrhY8Rs=.3530e797-0961-4c02-b0ad-d05441ebafc1@github.com>
 <f7QKmu6GioQUyJ3xNibIdBZiPcOrjddJjH3KBHmo8P8=.bc884e76-7cd2-4af9-afb3-6bf8b28ba541@github.com>
Message-ID: <jw_B5mj4zOvNEXLkZZktF05AkhO4EzquwM9zz5n0e6M=.657d4394-99a3-4bdf-a4c5-77064b9acc01@github.com>

On Thu, 6 Jan 2022 22:15:43 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Good question! Thanks for asking. 
>> 
>> Indeed there is a "problem" here - actually two problems, one old and one new. I put problem in quotes because, the bug is only latent at the moment and does not impact anything. but is nevertheless a bug and should be fixed.
>> 
>> Explanation. First the old bug:
>> 
>> In Flags.java we have the following:
>> 
>> 
>> LocalClassFlags                   = FINAL | ABSTRACT | STRICTFP | ENUM | SYNTHETIC  | PRIMITIVE_CLASS,
>> ClassFlags                        = LocalClassFlags | INTERFACE | PUBLIC | ANNOTATION,
>> ``` 
>> 
>> This is problematic because PRIMITIVE_CLASS is defined to be 1 << 16 - while the class file representation of flags is only 16 bits. Which is why there is a mapping from PRIMITIVE_CLASS to ACC_PRIMITIVE in the first place.
>> 
>> So the definition of LocalClassFlags should have had the bit corresponding to 0x100 ie  (1 << 8) set by including a suitable symbolic constant in place of PRIMITIVE_CLASS.
>> 
>> The idea behind doing
>> 
>> flags = flags & ClassFlags
>> 
>> 
>> in the old (and new code) is ensure that no bit other than well defined class flags bits are set in the flags being written out to file. By not having 0x100 (old ACC_PRIMITIVE) set in ClassFlags we are inadvertently masking ACC_PRIMITIVE bit and to avoid running into problems there, we or back ACC_PRIMITIVE into the ClassFlags just being &ing.
>> 
>> New problem:
>> 
>> In the new code, again LocalClassFlags is missing ACC_PRIMITIVE, but things work just fine but by accident - only because ACC_PRIMITIVE shares the same value with ACC_STRICT !
>> 
>> I'll post a revision that will make this clear and address the latent bug (which may become real bug if ACC_PRIMITIVE changes value again to have a value that is not already a known bit pattern in LocalClassFlags) 
>> 
>> The right
>
> Thank you for the detailed explanation.
> 
>> In the new code, again LocalClassFlags is missing ACC_PRIMITIVE, but things work just fine but by accident - only because ACC_PRIMITIVE shares the same value with ACC_STRICT !
> 
> I am still a bit confused because I don't see any uses of ACC_STRICT but only STRICT_FP at that level (which is indeed 1<<11, 0x0800). So in my mind it shares the same value with STRICT_FP not ACC_STRICT. I will fully get it with your upcoming revision ?? ?? 
> 
> Thanks again for the explanation!

But ACC_STRICT and STRICT_FP symbolize/represent the same and carry the same value. (The latter is javac's internal symbol.)

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

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

From duke at openjdk.java.net  Fri Jan  7 09:26:43 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 7 Jan 2022 09:26:43 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS
In-Reply-To: <jw_B5mj4zOvNEXLkZZktF05AkhO4EzquwM9zz5n0e6M=.657d4394-99a3-4bdf-a4c5-77064b9acc01@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
 <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>
 <R-KebVQ3omW6IhjacjujIfK6MuEkhwfHP1B8DrhY8Rs=.3530e797-0961-4c02-b0ad-d05441ebafc1@github.com>
 <f7QKmu6GioQUyJ3xNibIdBZiPcOrjddJjH3KBHmo8P8=.bc884e76-7cd2-4af9-afb3-6bf8b28ba541@github.com>
 <jw_B5mj4zOvNEXLkZZktF05AkhO4EzquwM9zz5n0e6M=.657d4394-99a3-4bdf-a4c5-77064b9acc01@github.com>
Message-ID: <ralPp8HhDWSaF3d7afj6EvbLoQuMbGBhKcLLfg5oBWY=.8b87338e-48e0-4f7a-8bca-1f776f44a2c3@github.com>

On Fri, 7 Jan 2022 05:48:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Thank you for the detailed explanation.
>> 
>>> In the new code, again LocalClassFlags is missing ACC_PRIMITIVE, but things work just fine but by accident - only because ACC_PRIMITIVE shares the same value with ACC_STRICT !
>> 
>> I am still a bit confused because I don't see any uses of ACC_STRICT but only STRICT_FP at that level (which is indeed 1<<11, 0x0800). So in my mind it shares the same value with STRICT_FP not ACC_STRICT. I will fully get it with your upcoming revision ?? ?? 
>> 
>> Thanks again for the explanation!
>
> But ACC_STRICT and STRICT_FP symbolize/represent the same and carry the same value. (The latter is javac's internal symbol.)

Got it, right!

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

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

From sadayapalam at openjdk.java.net  Fri Jan  7 11:11:36 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 7 Jan 2022 11:11:36 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS [v2]
In-Reply-To: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
Message-ID: <ywjuRoCG6RFeupLlL7g1xXbKym_-6QNim-WGbRfnhig=.661d208d-a574-4dc7-9eb3-23b9c36e4191@github.com>

> Change ACC_PRIMITIVE to be 0x800 across components sources and tests

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

  Post review, clarify code and eliminate latent bug that doesn't surface only
  because of the happy coincidence of values being equals between two class file
  constants.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/593/files
  - new: https://git.openjdk.java.net/valhalla/pull/593/files/accb6894..ac1817d0

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

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

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

From sadayapalam at openjdk.java.net  Fri Jan  7 11:25:43 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 7 Jan 2022 11:25:43 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS [v2]
In-Reply-To: <ralPp8HhDWSaF3d7afj6EvbLoQuMbGBhKcLLfg5oBWY=.8b87338e-48e0-4f7a-8bca-1f776f44a2c3@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
 <XsCFtq1R2N3UWcVLd-qidEztxklMjco0COimM0mh8L0=.2aa01c21-176e-43d9-a536-5eee27f15e33@github.com>
 <R-KebVQ3omW6IhjacjujIfK6MuEkhwfHP1B8DrhY8Rs=.3530e797-0961-4c02-b0ad-d05441ebafc1@github.com>
 <f7QKmu6GioQUyJ3xNibIdBZiPcOrjddJjH3KBHmo8P8=.bc884e76-7cd2-4af9-afb3-6bf8b28ba541@github.com>
 <jw_B5mj4zOvNEXLkZZktF05AkhO4EzquwM9zz5n0e6M=.657d4394-99a3-4bdf-a4c5-77064b9acc01@github.com>
 <ralPp8HhDWSaF3d7afj6EvbLoQuMbGBhKcLLfg5oBWY=.8b87338e-48e0-4f7a-8bca-1f776f44a2c3@github.com>
Message-ID: <BhnF3DqMe7w3K862okcv6_wdSJrtWttUbEStTcDj1VA=.c1b4c196-e3a9-4561-84b4-2a1028bf6b30@github.com>

On Fri, 7 Jan 2022 09:23:36 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> But ACC_STRICT and STRICT_FP symbolize/represent the same and carry the same value. (The latter is javac's internal symbol.)
>
> Got it, right!

OK, here is an incremental fix that addresses this concern. Some notes.

- First of all, we cant define PRIMITIVE_CLASS to be 0x800 because this bit pattern is already claimed by STRICT_FP (javac speak for ACC_STRICT which is class file speak)
- ACC_STRICT technically can never be applied to a class in the class file although in javac internal ASTs a class can be marked STRICT_FP to indicate that strictness in FP operations should be propagated to methods of the class. So there is a clash and we choose a different bit encoding.
- A note about naming. I chose PRIMITIVE_CLASS rather than PRIMITIVE to avoid confusion with basic/builtin primitives.
- Now PRIMITIVE_CLASS (javac internal symbol/encoding) needs to be mapped to ACC_PRIMITIVE (JVMS symbol/encoding) at the time of class file writing. This happens in com.sun.tools.javac.jvm.ClassWriter#adjustFlags
- According to JVMS Table 4.1-B. Class access and property modifiers and Table 4.7.6-A. Nested class access and property flags ACC_STRICT is not a valid flag on a class file and so ....
- JDK-7165659 (javac incorrectly sets strictfp access flag on inner-classes) should have arguably cleared STRICT_FP from LocalClassFlags in Flags.java but chose to clear it at the time of class file writing.
So the present update

- Removes STRICT_FP from LocalClassFlags
- Remove PRIMITIVE_CLASS from LocalClassFlags - Class flags are only 16 bits and PRIMITIVE_CLASS is 1 << 16 and so can't really fit in the class file flag and also needs mapping to ACC_PRIMITIVE. It was a bug to include it in the first place.
- Add ACC_PRIMITIVE to LocalClassFlags since that is valid with Valhalla
(Note LocalClassFlags is used as the base to subsequently define many other symbolic constants)

- Update the series of Extended*Flags constants to include PRIMITIVE_CLASS since the latter is really an extended flag (beyond 16 bits)
- Introduce two new Extended*Flags symbols for which no need existed till now.

The one still open minor oddity is why in com.sun.tools.javac.jvm.ClassWriter#writeClassFile we would choose to do

flags = flags & ClassFlags;

while not doing something similar in com.sun.tools.javac.jvm.ClassWriter#writeInnerClasses

but one can convince himself that this is harmless and really a nop. So I have chosen to leave this alone (needs much more ceremony to fix it - we need to define additional constants)

Please take a look and let me know of any more questions

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

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

From fparain at openjdk.java.net  Fri Jan  7 14:04:50 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 7 Jan 2022 14:04:50 GMT
Subject: [lworld] RFR: 8279624: [lworld] interpreter should avoid value copies
 in withfield when possible
Message-ID: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>

Please review this small change to reduce the number of copies the interpreter does when executing the withfield bytecode.
If the new value of the field to be updated is identical to the old value of the field, the interpreter simply returns the original value instance instead of creating a new copy.
This change remove more than 8K value copies when running the hotspot_valhalla test suite.

Tested with Mach5, tiers 1 to 3.

Thank you

Fred

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

Commit messages:
 - Avoid value copies in withfield when possible

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

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

From fparain at openjdk.java.net  Fri Jan  7 18:35:30 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 7 Jan 2022 18:35:30 GMT
Subject: [lworld] RFR: 8279624: [lworld] interpreter should avoid value
 copies in withfield when possible [v2]
In-Reply-To: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>
References: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>
Message-ID: <N8Jb0EBU9tTBafve5Z1muuU1P9DUY91JgTJC6jTfZWQ=.fea507e5-03b6-44b5-8cf8-5ebaea0fde99@github.com>

> Please review this small change to reduce the number of copies the interpreter does when executing the withfield bytecode.
> If the new value of the field to be updated is identical to the old value of the field, the interpreter simply returns the original value instance instead of creating a new copy.
> This change removes more than 8K value copies when running the hotspot_valhalla test suite.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you
> 
> Fred

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

  Add support for floating point fields

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/595/files
  - new: https://git.openjdk.java.net/valhalla/pull/595/files/e89b1cda..82e9d6f2

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

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

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

From duke at openjdk.java.net  Mon Jan 10 09:14:04 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Mon, 10 Jan 2022 09:14:04 GMT
Subject: [lworld] RFR: 8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800
 to align with draft JVMS [v2]
In-Reply-To: <ywjuRoCG6RFeupLlL7g1xXbKym_-6QNim-WGbRfnhig=.661d208d-a574-4dc7-9eb3-23b9c36e4191@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
 <ywjuRoCG6RFeupLlL7g1xXbKym_-6QNim-WGbRfnhig=.661d208d-a574-4dc7-9eb3-23b9c36e4191@github.com>
Message-ID: <OrxBdq7zE-PhTPXfruoAew6EbBvEaMCsfadqw5CzeD4=.6a098dab-6efe-464a-ad87-83c312802fd6@github.com>

On Fri, 7 Jan 2022 11:11:36 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Change ACC_PRIMITIVE to be 0x800 across components sources and tests
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Post review, clarify code and eliminate latent bug that doesn't surface only
>   because of the happy coincidence of values being equals between two class file
>   constants.

This looks good from my side too and all the fixes are clear.

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

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

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

From sadayapalam at openjdk.java.net  Mon Jan 10 09:22:53 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Jan 2022 09:22:53 GMT
Subject: [lworld] Integrated: 8279428: [lworld] Revalue ACC_PRIMITIVE to be
 0x800 to align with draft JVMS
In-Reply-To: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
References: <nx8FkbSp0wtijmYOi3SYROBQeY11aY4DJSdsxIBhYqQ=.011bd2b3-e9dc-4808-b34b-b2cdf675a31f@github.com>
Message-ID: <VAK-NPQMyUOGfTABCAU6MZgFxcLJhi96VI8jMlioNEM=.4d8ed8ae-4894-4b4d-8f2a-8fe07dc89267@github.com>

On Thu, 6 Jan 2022 09:54:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Change ACC_PRIMITIVE to be 0x800 across components sources and tests

This pull request has now been integrated.

Changeset: d555db6c
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d555db6ccd4d548380dcdde63db09460c157fe7a
Stats:     82 lines in 16 files changed: 8 ins; 4 del; 70 mod

8279428: [lworld] Revalue ACC_PRIMITIVE to be 0x800 to align with draft JVMS

Reviewed-by: thartmann, fparain, rriggs

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

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

From sadayapalam at openjdk.java.net  Mon Jan 10 12:36:12 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Jan 2022 12:36:12 GMT
Subject: [lworld] RFR: 8279368: [lworld] Add parser support for declaration of
 value classes
Message-ID: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>

Enhance the parser to accept value class declarations

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

Commit messages:
 - 8279368: Add parser support for declaration of value classes

Changes: https://git.openjdk.java.net/valhalla/pull/596/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=596&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279368
  Stats: 293 lines in 23 files changed: 239 ins; 9 del; 45 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/596.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/596/head:pull/596

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

From sadayapalam at openjdk.java.net  Mon Jan 10 12:39:46 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Jan 2022 12:39:46 GMT
Subject: [lworld] RFR: 8279368: [lworld] Add parser support for declaration
 of value classes
In-Reply-To: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
References: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
Message-ID: <x2kUN3vnQKNu37Arq8svO1sOKCiSdYOxFfIrtmWnBOI=.e603e094-ec5b-42d5-84b8-ea607760ed79@github.com>

On Mon, 10 Jan 2022 12:30:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Enhance the parser to accept value class declarations

Notes for reviewer:

    - This patch ddds support for value classes in the parser
      using the value modifier or the __value__ annotation 
      (latter is temporary untils IDEs support value modifier)

    - All that happens at the moment is, value class syntax is
      digested and a value classe is flagged as being one by 
      virtue of setting the Flags.VALUE_CLASS bit.

    - This bit itself is "dropped" (ignored) by subsequent stages
      of the pipeline as of now

    - Feature support base version level bumped up to 18

    - Introduce the class file symbolic constant ACC_VALUE (0x100)

    - Contains a bug fix - sometimes we were not emitting the best
      message for use of primitive/value classes with an inappropriate
      source level (instead of complaining "primitive/value classes are
      not supported in -source 17" we were instead complaining 
      "warning: 'primitive' may become a restricted type name in future"

    - Fixed a singular -> plural grammar issue in diagnostics.

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

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

From sadayapalam at openjdk.java.net  Mon Jan 10 14:35:51 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Jan 2022 14:35:51 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <5LWlaH7VmovBh6NbD6bj6xE6if6BTaiQb03MDh7Z7gA=.56bf2e4b-372b-4b37-a1da-327d8a318166@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

Jesper, I think this PR may be abandoned and the related JBS ticket closed as Not an Issue. 
Via https://bugs.openjdk.java.net/browse/JDK-8279431 all support for ref-default classes has
been ripped out - these are subsumed by value classes - the so called B2 classes - which are
'L' types (reference types) really. Value classes are reference types that are final, whose instances are
immutable after construction, lack identity and are marked as ACC_VALUE in class files.

The whole inlining/flattening thing is an "optimization" - so these classes are reference classes for
all practical purposes. Against that backdrop I think this PR has lost its relavance,

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

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

From duke at openjdk.java.net  Mon Jan 10 23:19:45 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Mon, 10 Jan 2022 23:19:45 GMT
Subject: [lworld] RFR: 8279368: [lworld] Add parser support for declaration
 of value classes
In-Reply-To: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
References: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
Message-ID: <9ok1E6KvAgQw_2s9nWdzfpStGIXO4-POj9K63GTql8A=.714a3abc-3514-440f-a52a-faa2e20731c8@github.com>

On Mon, 10 Jan 2022 12:30:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Enhance the parser to accept value class declarations

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

This looks good to me ??

I believe the following observations are not related to this PR so I am accepting it, but I would like to hear what you think:

1. `public native value class FooTest { }` passes but also `public native class FooTest { }`. `native` shouldn't be applicable here at all here I think.

2. An inconsistency in error reporting:


FooTest.java:2: error: repeated modifier
public native native class FooTest { }
              ^


but:

FooTest.java:2: error: class, interface, enum, or record expected
public value value class FooTest { }
       ^


What do you think?

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

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

From sadayapalam at openjdk.java.net  Mon Jan 10 23:40:57 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Jan 2022 23:40:57 GMT
Subject: [lworld] RFR: 8279368: [lworld] Add parser support for declaration
 of value classes
In-Reply-To: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
References: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
Message-ID: <_cl-7zgFHo5vxW2-LcEfCoAXeAhCqybjPRvx90nDELs=.f166d466-04a2-4163-a50a-b2da3362da2f@github.com>

On Mon, 10 Jan 2022 12:30:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Enhance the parser to accept value class declarations

Thanks Aggelos, both observations are valid and I will raise follow up tickets to tackle them.

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

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

From sadayapalam at openjdk.java.net  Mon Jan 10 23:40:59 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 10 Jan 2022 23:40:59 GMT
Subject: [lworld] Integrated: 8279368: [lworld] Add parser support for
 declaration of value classes
In-Reply-To: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
References: <ILbcrbbmhaoTdKDjQC5V6YzdJ0M5BKZBhYnhVW1R0DY=.3ecf993a-d8fb-45e8-8479-4a816d1ac045@github.com>
Message-ID: <sIr5SNCQkIQudzQkwmh59ZNhM6NeuTKjfPe8Xl4LvZU=.94f88ff8-c69c-4287-aab4-37172c7f4e13@github.com>

On Mon, 10 Jan 2022 12:30:11 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Enhance the parser to accept value class declarations

This pull request has now been integrated.

Changeset: 063c1c4d
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/063c1c4d2d3543b86ea21704436e9d43aecc73ea
Stats:     293 lines in 23 files changed: 239 ins; 9 del; 45 mod

8279368: [lworld] Add parser support for declaration of value classes

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

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

From sadayapalam at openjdk.java.net  Tue Jan 11 12:30:17 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 11 Jan 2022 12:30:17 GMT
Subject: [lworld] RFR: 8279672: [lworld] Implement semantic checks for
 value classes
In-Reply-To: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>
References: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>
Message-ID: <JEFkVIBUYUbbk_58McbGXW55vwPwlMBBR_jJ3HIFQEA=.aaa7e52a-aaad-4c2b-9604-23315f5209c1@github.com>

On Tue, 11 Jan 2022 12:20:38 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push down various sematic/behavioral restrictions/checks and the associated diagnostics from primitive to value classes.

Notes for reviewer:


This patch implements the semantic checks enumerated in JDK-8279672

    - These checks already exist the Valhalla code base, but were implemented
      at the level of B3 (primitive) classes. What this change set does therefore
      is to push these checks and diagnostics down to B2 (value) classes.

    - A primitive class automatically gets these checks by virtue of first of all
      being a value class.

    - For ease of review, I am pushing the changes in two sets, (a) the key changes and
      (b) incidental, routine, mostly boiler plate style changes to many tests

This patch also contains a cleanup:

    - We don't ANYMORE mark a value/primitive class as being final in the parser.
      This was not the best place for it and it actually requires some manueveres
      from us when we want to NOT expose (in diagnostics) those inserted implicit
      modifiers. Instead value classes are now marked final in the orthodox way in
      com.sun.tools.javac.comp.Check#checkFlags

Known issues deferred to later steps:

    - Some diagnostics/checks outside of the scope of JDK-8279672 that should 
      really operate at the level of value classes may be continuing to operate
      at the level of primitive classes. These will be fixed separately.

    - Javac incorrectly tolerates value records having synchronized methods.

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

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

From sadayapalam at openjdk.java.net  Tue Jan 11 12:30:16 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 11 Jan 2022 12:30:16 GMT
Subject: [lworld] RFR: 8279672: [lworld] Implement semantic checks for value
 classes
Message-ID: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>

Push down various sematic/behavioral restrictions/checks and the associated diagnostics from primitive to value classes.

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

Commit messages:
 - Test changes for JDK-8279672
 - 8279672:  Implement semantic checks for value classes

Changes: https://git.openjdk.java.net/valhalla/pull/597/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=597&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279672
  Stats: 205 lines in 26 files changed: 132 ins; 12 del; 61 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/597.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/597/head:pull/597

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

From feuerbach at spell.work  Tue Jan 11 13:24:59 2022
From: feuerbach at spell.work (Tim Feuerbach)
Date: Tue, 11 Jan 2022 14:24:59 +0100
Subject: JEP 401: Implications of migrating a class to a primitive one
Message-ID: <03dac90a-2c34-90a2-f1aa-da299c82ab2f@spell.work>

Hi,

after reading JEP 401, I have a couple of questions regarding the 
conversion of existing classes into primitive classes, specifically: is 
this change (bytecode) compatible or not?

Let's assume we have a Point class like in the JEP, but not yet declared 
as primitive. There's also another class, PointHolder:

class PointHolder {
 ??? Point point;
 ??? boolean isInitialized() {
 ??????? return Objects.nonNull(point);
 ??? }
}

(I used Objects.nonNull since I didn't know whether you want to make 
"non-ref'd primitive == null" a compile time error).

Before primitive class conversion, after compiling both Point and 
PointHolder, I run the following program:

PointHolder ph = new PointHolder();
System.out.println(ph.isInitialized()); // false

Now I add "primitive" to the Point class and recompile *only the Point 
class*.

 ??? 1. Does the program still run after that change?

 From my understanding, the "point" field in PointHolder was an L type 
and therefore the JVM will happily initialize the field to null. The 
output is still "false".

 ??? 2. Can I recompile PointHolder without errors?

I assume yes, and the Point field (which was implicitly Point.ref) will 
now refer to the primitive Q type. However, since this will result in 
the field being initizialized with Point.default, the semantics of the 
program will change (isInitialized() returns true). This seems like a 
source for potential errors and would mean once I published a type, I 
should never migrate it to a primitive (I can however choose to migrate 
to a value class, as is planned for LocalDate etc.). Also, it's counter 
intutitive that the program will break only once I recompile the 
consumer of a changed class, not the changed class itself.

JEP 402 gets away with making Integer etc. primitives and not breaking 
existing code by declaring Integer an alias of int.ref. Users will not 
have this ability (for now).

 ??? 3. Are there plans for the (distant) future to bring primitive 
aliasing capabilities to the user space as well?

For example, the following fictitious syntax would make the change above 
semantically compatible:

primitive class point ref-alias Point {...}


Tim


From duke at openjdk.java.net  Tue Jan 11 22:26:05 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Tue, 11 Jan 2022 22:26:05 GMT
Subject: [lworld] RFR: 8279672: [lworld] Implement semantic checks for
 value classes
In-Reply-To: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>
References: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>
Message-ID: <o9oGTJbFK2YcRbU184giVoSjWjrtIXNkUxsdcaoaICw=.3f0d2961-4a40-4f0b-8f42-47cc85e4e752@github.com>

On Tue, 11 Jan 2022 12:20:38 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push down various sematic/behavioral restrictions/checks and the associated diagnostics from primitive to value classes.

Looks good to me after checking many more combinations with generics, inner classes and more. 

??????

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

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

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

From sadayapalam at openjdk.java.net  Wed Jan 12 00:30:44 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 12 Jan 2022 00:30:44 GMT
Subject: [lworld] Integrated: 8279672: [lworld] Implement semantic checks for
 value classes
In-Reply-To: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>
References: <e2Tl4Alo7Y2uxL_7zTacFByvuOeGfWeT4nBgeqqqMHo=.52cc4842-aa37-4642-b921-23be36be3395@github.com>
Message-ID: <NIDUMUXQTzQR8-SUtYxdcyMR1d_rIGofoLQm685sV3s=.3d8ab41f-525a-4a06-a567-a57a6f1e4e2a@github.com>

On Tue, 11 Jan 2022 12:20:38 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push down various sematic/behavioral restrictions/checks and the associated diagnostics from primitive to value classes.

This pull request has now been integrated.

Changeset: bfa2f474
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bfa2f474ce2e936ca0d0eb9aadb242ab61a33ad2
Stats:     205 lines in 26 files changed: 132 ins; 12 del; 61 mod

8279672: [lworld] Implement semantic checks for value classes

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

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

From thartmann at openjdk.java.net  Wed Jan 12 07:26:21 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 12 Jan 2022 07:26:21 GMT
Subject: [lworld] RFR: 8279853: [lworld] Multiple issues with speculative type
 at checkcast
Message-ID: <ke-tEvI4IhlhLcVRVk6LGBanKMJfDXT3YBRdS9kJhrQ=.5064ee5c-90d1-4a8d-9c36-65ac57813a84@github.com>

At checkcast, C2 checks if speculative type information is narrower than the type we cast to and if so, uses the speculative type instead. Among other things, this enables scalarization based on profile information (see for example line 4234 in the test).

This change fixes several issues triggered by that optimization and also removes dead code that still assumed that inline types are null-free.

Thanks,
Tobias

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

Commit messages:
 - 8279853: [lworld] Multiple issues with speculative type at checkcast

Changes: https://git.openjdk.java.net/valhalla/pull/598/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=598&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279853
  Stats: 160 lines in 3 files changed: 140 ins; 11 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/598.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/598/head:pull/598

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

From thartmann at openjdk.java.net  Wed Jan 12 07:50:57 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 12 Jan 2022 07:50:57 GMT
Subject: [lworld] Integrated: 8279853: [lworld] Multiple issues with
 speculative type at checkcast
In-Reply-To: <ke-tEvI4IhlhLcVRVk6LGBanKMJfDXT3YBRdS9kJhrQ=.5064ee5c-90d1-4a8d-9c36-65ac57813a84@github.com>
References: <ke-tEvI4IhlhLcVRVk6LGBanKMJfDXT3YBRdS9kJhrQ=.5064ee5c-90d1-4a8d-9c36-65ac57813a84@github.com>
Message-ID: <3PJ3BXCP7KgSrlZeVzw7CqjswVFGoN1LswjW4hTvZ9I=.922e3b55-b931-4db1-af5e-2f583e3b19ad@github.com>

On Wed, 12 Jan 2022 07:19:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> At checkcast, C2 checks if speculative type information is narrower than the type we cast to and if so, uses the speculative type instead. Among other things, this enables scalarization based on profile information (see for example line 4234 in the test).
> 
> This change fixes several issues triggered by that optimization and also removes dead code that still assumed that inline types are null-free.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 677e325a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/677e325a8abf9af1e4095de0e2a3f12b097ceda3
Stats:     160 lines in 3 files changed: 140 ins; 11 del; 9 mod

8279853: [lworld] Multiple issues with speculative type at checkcast

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

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

From zjx001202 at gmail.com  Wed Jan 12 08:54:21 2022
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 12 Jan 2022 16:54:21 +0800
Subject: JEP 401: Implications of migrating a class to a primitive one
In-Reply-To: <03dac90a-2c34-90a2-f1aa-da299c82ab2f@spell.work>
References: <03dac90a-2c34-90a2-f1aa-da299c82ab2f@spell.work>
Message-ID: <CAJL5A3m+tsecBTmcAjK3Jcx3Ji-OJLxrV+qbOtGoCdq+OjOxfQ@mail.gmail.com>

Hey, you can see this JEP draft:

    https://openjdk.java.net/jeps/8277163

It allows you to declare identity free reference type classes.

Tim Feuerbach <feuerbach at spell.work> ?2022?1?11??? 23:49???

> Hi,
>
> after reading JEP 401, I have a couple of questions regarding the
> conversion of existing classes into primitive classes, specifically: is
> this change (bytecode) compatible or not?
>
> Let's assume we have a Point class like in the JEP, but not yet declared
> as primitive. There's also another class, PointHolder:
>
> class PointHolder {
>      Point point;
>      boolean isInitialized() {
>          return Objects.nonNull(point);
>      }
> }
>
> (I used Objects.nonNull since I didn't know whether you want to make
> "non-ref'd primitive == null" a compile time error).
>
> Before primitive class conversion, after compiling both Point and
> PointHolder, I run the following program:
>
> PointHolder ph = new PointHolder();
> System.out.println(ph.isInitialized()); // false
>
> Now I add "primitive" to the Point class and recompile *only the Point
> class*.
>
>      1. Does the program still run after that change?
>
>  From my understanding, the "point" field in PointHolder was an L type
> and therefore the JVM will happily initialize the field to null. The
> output is still "false".
>
>      2. Can I recompile PointHolder without errors?
>
> I assume yes, and the Point field (which was implicitly Point.ref) will
> now refer to the primitive Q type. However, since this will result in
> the field being initizialized with Point.default, the semantics of the
> program will change (isInitialized() returns true). This seems like a
> source for potential errors and would mean once I published a type, I
> should never migrate it to a primitive (I can however choose to migrate
> to a value class, as is planned for LocalDate etc.). Also, it's counter
> intutitive that the program will break only once I recompile the
> consumer of a changed class, not the changed class itself.
>
> JEP 402 gets away with making Integer etc. primitives and not breaking
> existing code by declaring Integer an alias of int.ref. Users will not
> have this ability (for now).
>
>      3. Are there plans for the (distant) future to bring primitive
> aliasing capabilities to the user space as well?
>
> For example, the following fictitious syntax would make the change above
> semantically compatible:
>
> primitive class point ref-alias Point {...}
>
>
> Tim
>
>

From sadayapalam at openjdk.java.net  Wed Jan 12 09:55:05 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 12 Jan 2022 09:55:05 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject
Message-ID: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>

Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject

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

Commit messages:
 - 8279838: PrimitiveObject is dead, long live ValueObject

Changes: https://git.openjdk.java.net/valhalla/pull/599/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=599&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279838
  Stats: 199 lines in 25 files changed: 68 ins; 66 del; 65 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/599.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/599/head:pull/599

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

From duke at openjdk.java.net  Wed Jan 12 12:00:52 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 12 Jan 2022 12:00:52 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject
In-Reply-To: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
Message-ID: <fIQxWV6idhFCFHUeS6k2uBCguOIjdmPvemqTOOhIRZE=.ca60b889-3771-497f-9003-b7130952ee6b@github.com>

On Wed, 12 Jan 2022 09:47:34 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject

Looks good! ??

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

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

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

From amenkov at openjdk.java.net  Wed Jan 12 14:16:12 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Wed, 12 Jan 2022 14:16:12 GMT
Subject: [lworld] RFR: 8279912: [lworld] The test
 jdk/java/lang/instrument/valhalla/RedefinePrimitive.java has started failing
Message-ID: <JCKu3Ma_KT5Vy8OAmjUsISOTDf38oC74Vu8QQhDwNN4=.677ab45e-4fb3-4811-a99e-e65d3fb5a0c3@github.com>

Updated class parser and class reconstituter to handle JVM_ACC_VALUE flag for primitive classes.

Filed JDK-8279922: [lworld] ClassParser should verify primitive class is value class
to add check for JVM_ACC_INLINE/JVM_ACC_VALUE consistency

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

Commit messages:
 - Added JVM_ACC_VALUE for primitive classes

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

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

From rriggs at openjdk.java.net  Wed Jan 12 15:04:54 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 12 Jan 2022 15:04:54 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject
In-Reply-To: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
Message-ID: <ukSIkpOQZAoZfQiFxnuNu0-RlbkvcL1TAVrotteVlJU=.f1226892-df24-4e0c-8ba9-c6f224b8c869@github.com>

On Wed, 12 Jan 2022 09:47:34 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject

Core-libs changes look fine.

The @since tags could be some value other than an actual release.
(1.18 is obsolete already).
Perhaps  "valhalla" or "jep-xxx".

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

Marked as reviewed by rriggs (Committer).

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

From sadayapalam at openjdk.java.net  Wed Jan 12 16:01:43 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 12 Jan 2022 16:01:43 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject [v2]
In-Reply-To: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
Message-ID: <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>

> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject

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

  Additional fixes for hotspot courtesy of Frederic Parain

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/599/files
  - new: https://git.openjdk.java.net/valhalla/pull/599/files/55b23355..489659ed

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

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

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

From forax at openjdk.java.net  Wed Jan 12 16:11:02 2022
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 12 Jan 2022 16:11:02 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject [v2]
In-Reply-To: <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
 <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>
Message-ID: <BMc4flZ2Ob7PFpB2Aov_-NGOnZYoKp9RlaccC5HvF4o=.7213e1e8-8000-4c90-b589-321c8ccff357@github.com>

On Wed, 12 Jan 2022 16:01:43 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional fixes for hotspot courtesy of Frederic Parain

I've seen 99 being used as transitional version number in several OpenJDK project.

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

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

From dsimms at openjdk.java.net  Wed Jan 12 17:14:00 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 12 Jan 2022 17:14:00 GMT
Subject: [lworld] RFR: 8279624: [lworld] interpreter should avoid value
 copies in withfield when possible [v2]
In-Reply-To: <N8Jb0EBU9tTBafve5Z1muuU1P9DUY91JgTJC6jTfZWQ=.fea507e5-03b6-44b5-8cf8-5ebaea0fde99@github.com>
References: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>
 <N8Jb0EBU9tTBafve5Z1muuU1P9DUY91JgTJC6jTfZWQ=.fea507e5-03b6-44b5-8cf8-5ebaea0fde99@github.com>
Message-ID: <nijFaPPSA9kBWizeECl1-HqSTiDE543h582TUIQ_TKc=.a1e9dd3e-d6cf-4562-8b1e-1d0b5f905c94@github.com>

On Fri, 7 Jan 2022 18:35:30 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this small change to reduce the number of copies the interpreter does when executing the withfield bytecode.
>> If the new value of the field to be updated is identical to the old value of the field, the interpreter simply returns the original value instance instead of creating a new copy.
>> This change removes more than 8K value copies when running the hotspot_valhalla test suite.
>> 
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for floating point fields

Looks good !

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

Marked as reviewed by dsimms (Committer).

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

From fparain at openjdk.java.net  Wed Jan 12 18:55:44 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 12 Jan 2022 18:55:44 GMT
Subject: [lworld] RFR: 8279624: [lworld] interpreter should avoid value
 copies in withfield when possible [v2]
In-Reply-To: <N8Jb0EBU9tTBafve5Z1muuU1P9DUY91JgTJC6jTfZWQ=.fea507e5-03b6-44b5-8cf8-5ebaea0fde99@github.com>
References: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>
 <N8Jb0EBU9tTBafve5Z1muuU1P9DUY91JgTJC6jTfZWQ=.fea507e5-03b6-44b5-8cf8-5ebaea0fde99@github.com>
Message-ID: <r95Od7q69eWf8IDNN_k7JYpY0Fk6DX5HuddafrfSQig=.626da928-2b2a-4fd4-a6db-934adce52c36@github.com>

On Fri, 7 Jan 2022 18:35:30 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Please review this small change to reduce the number of copies the interpreter does when executing the withfield bytecode.
>> If the new value of the field to be updated is identical to the old value of the field, the interpreter simply returns the original value instance instead of creating a new copy.
>> This change removes more than 8K value copies when running the hotspot_valhalla test suite.
>> 
>> Tested with Mach5, tiers 1 to 3.
>> 
>> Thank you
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for floating point fields

Thank you for the review.

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

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

From fparain at openjdk.java.net  Wed Jan 12 18:55:45 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 12 Jan 2022 18:55:45 GMT
Subject: [lworld] Integrated: 8279624: [lworld] interpreter should avoid value
 copies in withfield when possible
In-Reply-To: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>
References: <kzmF4XoJHbYm2gCjebDqQuvbtgAgW6Y--_g2V926Ono=.06d278f7-706b-4482-973b-092a8ed5ec78@github.com>
Message-ID: <vgvF-CltU_nT_Jj56RYcHkuvw7E4VpoxKXnue-HxHe8=.a6fc0799-3b71-4792-80c9-b7c6061f6688@github.com>

On Fri, 7 Jan 2022 13:57:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small change to reduce the number of copies the interpreter does when executing the withfield bytecode.
> If the new value of the field to be updated is identical to the old value of the field, the interpreter simply returns the original value instance instead of creating a new copy.
> This change removes more than 8K value copies when running the hotspot_valhalla test suite.
> 
> Tested with Mach5, tiers 1 to 3.
> 
> Thank you
> 
> Fred

This pull request has now been integrated.

Changeset: 3444c29d
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3444c29dbd7049c630ebd9f566737708550d3db3
Stats:     40 lines in 1 file changed: 39 ins; 1 del; 0 mod

8279624: [lworld] interpreter should avoid value copies in withfield when possible

Reviewed-by: dsimms

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

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

From fparain at openjdk.java.net  Wed Jan 12 18:56:54 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 12 Jan 2022 18:56:54 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject [v2]
In-Reply-To: <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
 <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>
Message-ID: <S6J2UNkwdj2_6DiU_qUM3B83_f173btwBcwfaJFK24s=.a22ffb34-5592-4376-828b-3b1dc6bac938@github.com>

On Wed, 12 Jan 2022 16:01:43 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional fixes for hotspot courtesy of Frederic Parain

Hotspot changes look good to me.
Thank you for including the Hotspot renaming patch.

Fred

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

Marked as reviewed by fparain (Committer).

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

From fparain at openjdk.java.net  Wed Jan 12 21:01:44 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 12 Jan 2022 21:01:44 GMT
Subject: [lworld] RFR: 8279912: [lworld] The test
 jdk/java/lang/instrument/valhalla/RedefinePrimitive.java has started failing
In-Reply-To: <JCKu3Ma_KT5Vy8OAmjUsISOTDf38oC74Vu8QQhDwNN4=.677ab45e-4fb3-4811-a99e-e65d3fb5a0c3@github.com>
References: <JCKu3Ma_KT5Vy8OAmjUsISOTDf38oC74Vu8QQhDwNN4=.677ab45e-4fb3-4811-a99e-e65d3fb5a0c3@github.com>
Message-ID: <o2HMqyyHTIhgUmjqOd1JVn9Ugvjjmv2soAfCn793LSA=.da419fbd-35ca-472d-8942-8622f4b438e8@github.com>

On Wed, 12 Jan 2022 14:10:07 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated class parser and class reconstituter to handle JVM_ACC_VALUE flag for primitive classes.
> 
> Filed JDK-8279922: [lworld] ClassParser should verify primitive class is value class
> to add check for JVM_ACC_INLINE/JVM_ACC_VALUE consistency

Looks good.

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

Marked as reviewed by fparain (Committer).

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

From sadayapalam at openjdk.java.net  Thu Jan 13 00:15:59 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 13 Jan 2022 00:15:59 GMT
Subject: [lworld] Integrated: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject
In-Reply-To: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
Message-ID: <p7xQ7NBQzRhgdI13xhAWrGDq8APQVPIJUL4H3fApeIk=.cec03a85-3bc0-4d61-8178-7116c481f915@github.com>

On Wed, 12 Jan 2022 09:47:34 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject

This pull request has now been integrated.

Changeset: d94e0371
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d94e0371546bb062f63ff69eea0a9d4fa89abe20
Stats:     232 lines in 29 files changed: 68 ins; 66 del; 98 mod

8279838: [lworld] PrimitiveObject is dead, long live ValueObject

Reviewed-by: rriggs, fparain

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

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

From sadayapalam at openjdk.java.net  Thu Jan 13 00:15:56 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 13 Jan 2022 00:15:56 GMT
Subject: [lworld] RFR: 8279838: [lworld] PrimitiveObject is dead,
 long live ValueObject [v2]
In-Reply-To: <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>
References: <iP7PjF7QiSskP97uDhQ7GmyY5Vyh3hmMtU-dg6MlocA=.180aaf4a-c335-4d84-acb5-a08e56dbca7d@github.com>
 <5OkEYu0xRyeRQXpz27TpnZwByWtOUluxVWSnmmCZWBw=.9cabff5c-df5a-4984-9e50-d641597e384e@github.com>
Message-ID: <pFD6mOTHk_eBF17joLoSyfD3CYV-Atc3_Jfwn48E7FY=.aa284e3a-e275-4766-a357-7ade04ebee05@github.com>

On Wed, 12 Jan 2022 16:01:43 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Javac, hotspot and jdk changes to cope with PrimitiveObject in its new avatar as ValueObject
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional fixes for hotspot courtesy of Frederic Parain

Thanks gentlemen, I have made a note of the observation ragarding @since for future use.

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

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

From sadayapalam at openjdk.java.net  Thu Jan 13 10:00:31 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 13 Jan 2022 10:00:31 GMT
Subject: [lworld] RFR: 8279901: [lworld] Javac should verify/ensure that a
 Functional interface implements neither IdentityObject nor ValueObject
Message-ID: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>

Disqualify interfaces that extend either of the top interface types from being lambda target types.

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

Commit messages:
 - 8279901:  Javac should verify/ensure that a Functional interface implements neither IdentityObject nor ValueObject

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

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

From duke at openjdk.java.net  Thu Jan 13 12:18:35 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 13 Jan 2022 12:18:35 GMT
Subject: [lworld] RFR: 8279901: [lworld] Javac should verify/ensure that a
 Functional interface implements neither IdentityObject nor ValueObject
In-Reply-To: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
References: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
Message-ID: <XP5eOP_PboBCnmD8QrrDPvo64faBKqdI-k9tTJhKH4E=.6c213c59-337d-444f-910a-de064217fb21@github.com>

On Thu, 13 Jan 2022 09:52:47 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Disqualify interfaces that extend either of the top interface types from being lambda target types.

LGTM ??

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

> 796:             }
> 797:             // Not functional if extending either of the top interface types.
> 798:             Type topInferface;

Small typo

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

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

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

From sadayapalam at openjdk.java.net  Thu Jan 13 12:35:27 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 13 Jan 2022 12:35:27 GMT
Subject: [lworld] RFR: 8279901: [lworld] Javac should verify/ensure that a
 Functional interface implements neither IdentityObject nor
 ValueObject [v2]
In-Reply-To: <XP5eOP_PboBCnmD8QrrDPvo64faBKqdI-k9tTJhKH4E=.6c213c59-337d-444f-910a-de064217fb21@github.com>
References: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
 <XP5eOP_PboBCnmD8QrrDPvo64faBKqdI-k9tTJhKH4E=.6c213c59-337d-444f-910a-de064217fb21@github.com>
Message-ID: <yTSqXDIovSvUOB2VX_dmJ8HOsk8bUJmxxgYC3Sg3tFU=.f31a941d-2cae-4068-a1ba-8ad04d66965b@github.com>

On Thu, 13 Jan 2022 12:15:35 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Small typo

Thanks Aggelos! Fixed.

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

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

From sadayapalam at openjdk.java.net  Thu Jan 13 12:35:26 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 13 Jan 2022 12:35:26 GMT
Subject: [lworld] RFR: 8279901: [lworld] Javac should verify/ensure that a
 Functional interface implements neither IdentityObject nor
 ValueObject [v2]
In-Reply-To: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
References: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
Message-ID: <-NBy8Ds_04SvrMhsz1EtOSO_l0GpW3styLXld5I1J4I=.722c685a-9f09-4aca-afd4-ddc0c1710523@github.com>

> Disqualify interfaces that extend either of the top interface types from being lambda target types.

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

  Fix typo spotted during code review (Thanks!)

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/601/files
  - new: https://git.openjdk.java.net/valhalla/pull/601/files/7ba6d9dd..42805bd0

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

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

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

From sadayapalam at openjdk.java.net  Thu Jan 13 12:35:28 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 13 Jan 2022 12:35:28 GMT
Subject: [lworld] Integrated: 8279901: [lworld] Javac should verify/ensure that
 a Functional interface implements neither IdentityObject nor ValueObject
In-Reply-To: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
References: <LY2yFdv2hoKFZRcHq6j2ob0Jp7IMwn2PSz_8Tb8OTiI=.6f253899-3432-4a66-af44-0d1e5fc6cf13@github.com>
Message-ID: <g9Iw8NwrPm5p0G7Z8QR6yzpmhBHjRHtT3OQ4o2KTNnc=.b5a284cd-fa2b-4679-90f6-223deb4af6a8@github.com>

On Thu, 13 Jan 2022 09:52:47 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Disqualify interfaces that extend either of the top interface types from being lambda target types.

This pull request has now been integrated.

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

8279901: [lworld] Javac should verify/ensure that a Functional interface implements neither IdentityObject nor ValueObject

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

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

From amenkov at openjdk.java.net  Thu Jan 13 15:49:58 2022
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Thu, 13 Jan 2022 15:49:58 GMT
Subject: [lworld] Integrated: 8279912: [lworld] The test
 jdk/java/lang/instrument/valhalla/RedefinePrimitive.java has started failing
In-Reply-To: <JCKu3Ma_KT5Vy8OAmjUsISOTDf38oC74Vu8QQhDwNN4=.677ab45e-4fb3-4811-a99e-e65d3fb5a0c3@github.com>
References: <JCKu3Ma_KT5Vy8OAmjUsISOTDf38oC74Vu8QQhDwNN4=.677ab45e-4fb3-4811-a99e-e65d3fb5a0c3@github.com>
Message-ID: <N5J7wTsO770aW5PmVdM7RA9Id0yVqGGDMYqkc742dxI=.9f42737b-de7e-4533-8b1d-7f1c10c1063a@github.com>

On Wed, 12 Jan 2022 14:10:07 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Updated class parser and class reconstituter to handle JVM_ACC_VALUE flag for primitive classes.
> 
> Filed JDK-8279922: [lworld] ClassParser should verify primitive class is value class
> to add check for JVM_ACC_INLINE/JVM_ACC_VALUE consistency

This pull request has now been integrated.

Changeset: 39c9e52c
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/39c9e52c33aee884a3b14b2e5a43f712df723a37
Stats:     7 lines in 3 files changed: 1 ins; 0 del; 6 mod

8279912: [lworld] The test jdk/java/lang/instrument/valhalla/RedefinePrimitive.java has started failing

Reviewed-by: fparain

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

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

From duke at openjdk.java.net  Fri Jan 14 02:44:58 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 14 Jan 2022 02:44:58 GMT
Subject: [valhalla-docs] RFR: Fix minor details
Message-ID: <MwC-U3FrCd5S5g0P7j7p4MD2o_i0NAtBcGBSpaBTM3I=.f6b00ff5-4bbf-42ac-b958-7f620a383040@github.com>

Minor details

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

Commit messages:
 - Fix minor details

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

PR: https://git.openjdk.java.net/valhalla-docs/pull/3

From duke at openjdk.java.net  Fri Jan 14 10:49:11 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 14 Jan 2022 10:49:11 GMT
Subject: [lworld] RFR: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
Message-ID: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>

Elides the restriction for `Cloneable`.

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

Commit messages:
 - JDK-8279656: Javac diagnostic compiler.err.primitive.class.must.not.implement.cloneable not valid anymore

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

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

From duke at openjdk.java.net  Fri Jan 14 16:56:36 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 14 Jan 2022 16:56:36 GMT
Subject: [valhalla-docs] RFR: Fix minor details
In-Reply-To: <MwC-U3FrCd5S5g0P7j7p4MD2o_i0NAtBcGBSpaBTM3I=.f6b00ff5-4bbf-42ac-b958-7f620a383040@github.com>
References: <MwC-U3FrCd5S5g0P7j7p4MD2o_i0NAtBcGBSpaBTM3I=.f6b00ff5-4bbf-42ac-b958-7f620a383040@github.com>
Message-ID: <3Y5inn9D9_Q4ycCspa8FijVoHS1jOHeJY6MZK_QNL2A=.93d0b206-c0c1-426a-bdae-e680e1e65c6d@github.com>

On Sat, 18 Dec 2021 00:54:50 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Minor details

Closing since the typos where fixed by another PR ??

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

PR: https://git.openjdk.java.net/valhalla-docs/pull/3

From duke at openjdk.java.net  Fri Jan 14 16:56:36 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 14 Jan 2022 16:56:36 GMT
Subject: [valhalla-docs] Withdrawn: Fix minor details
In-Reply-To: <MwC-U3FrCd5S5g0P7j7p4MD2o_i0NAtBcGBSpaBTM3I=.f6b00ff5-4bbf-42ac-b958-7f620a383040@github.com>
References: <MwC-U3FrCd5S5g0P7j7p4MD2o_i0NAtBcGBSpaBTM3I=.f6b00ff5-4bbf-42ac-b958-7f620a383040@github.com>
Message-ID: <qo2mv4rKb05RFKlzzP7pnc-x2WD3aNuvPGdbDb0M-Z0=.3c4e95d9-d02f-4a80-bd67-669010f80555@github.com>

On Sat, 18 Dec 2021 00:54:50 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Minor details

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/valhalla-docs/pull/3

From sadayapalam at openjdk.java.net  Mon Jan 17 09:44:01 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Jan 2022 09:44:01 GMT
Subject: [lworld] RFR: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
In-Reply-To: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
References: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
Message-ID: <xZiZ7Y10ZzsHOH62TmRQRh7sap2rAhFpUX051fYXZx0=.28a731e2-8ffc-4669-aca2-01cb63daad77@github.com>

On Fri, 14 Jan 2022 10:39:29 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Elides the restriction for `Cloneable`.

Changes requested by sadayapalam (Committer).

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

> 723:                 if (it.hasTag(CLASS)) {
> 724:                     if (isPrimitiveClass && it.tsym == syms.cloneableType.tsym) {
> 725:                         log.error(tree, Errors.PrimitiveClassMustNotImplementCloneable(ct));

I think this leaves the local variable isPrimitiveClass unused and in need of garbage collection. (There used to be multiple uses at some point past - that explains the local variable but these uses have fell away one by one)

test/langtools/tools/javac/valhalla/lworld-values/T8279656.java line 11:

> 9:     primitive class Primitive implements Cloneable {
> 10:     }
> 11: }

First I thought we may need a similar test in value-objects directory since value objects will get integrated ahead of and independently of primitive classes - but value objects are new and so were never restricted in the first place - so perhaps we don't need a test there after all.

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

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

From sadayapalam at openjdk.java.net  Mon Jan 17 09:44:02 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Jan 2022 09:44:02 GMT
Subject: [lworld] RFR: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
In-Reply-To: <xZiZ7Y10ZzsHOH62TmRQRh7sap2rAhFpUX051fYXZx0=.28a731e2-8ffc-4669-aca2-01cb63daad77@github.com>
References: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
 <xZiZ7Y10ZzsHOH62TmRQRh7sap2rAhFpUX051fYXZx0=.28a731e2-8ffc-4669-aca2-01cb63daad77@github.com>
Message-ID: <BU97cjzyerghZQ3xVB9lIwAuCLolGPIHI90yKqR5yzw=.4bcd936c-8255-43e4-8817-75a81153815f@github.com>

On Sat, 15 Jan 2022 09:26:08 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Elides the restriction for `Cloneable`.
>
> test/langtools/tools/javac/valhalla/lworld-values/T8279656.java line 11:
> 
>> 9:     primitive class Primitive implements Cloneable {
>> 10:     }
>> 11: }
> 
> First I thought we may need a similar test in value-objects directory since value objects will get integrated ahead of and independently of primitive classes - but value objects are new and so were never restricted in the first place - so perhaps we don't need a test there after all.

According to the javadoc on Cloneable: 

By convention, classes that implement this interface should override
 * {@code Object.clone} (which is protected) with a public method.
 * See {@link java.lang.Object#clone()} for details on overriding this
 * method.


But elsewhere we forbid clone from being overridden in a primitive/value class - that restriction should be co-lifted.
ATM if I compile

primitive class X implements Cloneable {
    public X clone() {
        throw new Error("Not implemented yet");
    }
}


it results in

X.java:2: error: value classes may not override the method clone from Object
    public X clone() {
             ^
1 error

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

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

From sadayapalam at openjdk.java.net  Mon Jan 17 10:44:14 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Jan 2022 10:44:14 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
Message-ID: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>

Push code code generation tactics and strategies from B3 to B2 classes.

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

Commit messages:
 - Implement code generation support for value classes

Changes: https://git.openjdk.java.net/valhalla/pull/604/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=604&range=00
  Stats: 177 lines in 14 files changed: 112 ins; 13 del; 52 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/604.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/604/head:pull/604

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

From sadayapalam at openjdk.java.net  Mon Jan 17 10:44:15 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 17 Jan 2022 10:44:15 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
Message-ID: <QX80gB8r7fcV6pWBciWrpCo4D4EV5Gv6mBFWojDjpk0=.5070c1b8-0d81-4e47-bdc8-be7882cf9419@github.com>

On Mon, 17 Jan 2022 10:37:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push code code generation tactics and strategies from B3 to B2 classes.

Notes for the reviewer:


This patch implements the code generation support for value classes.

    - Much of this functionality already exists in the Valhalla code base, but
      were implemented at the level of B3 (primitive) classes. What this change
      set does therefore is to push these code generation tactcs and strategies
      down to B2 (value) classes.

    - Rename defaultvalue opcode to aconst_init
    - Transate value class constructors to static factory methods of the name
      <init> with the return type of the class type.
    - Translate source level value instantiation attempts via new into calls to
      the static value factory method.
    - Translate assignments to fields with withfield rather than putfield.
    - In the class reader recognize value class factory methods and massage them
      and internalize them as normal constrctors - This is to minimize changes to
      the other phases of the compiler. A value class constrctor is treated as
      plain constrctor by javac but during class file emission, we do as mandated
      by JVMS.
      
Deferred

    - <init> to be renamed to <new>
    - Emission of Preload attribute
    - Marking stateless abstract classes as value supers.

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

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

From fparain at openjdk.java.net  Tue Jan 18 13:39:51 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 18 Jan 2022 13:39:51 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
Message-ID: <1jkd7LwEnyYDqjOcw3u8H9DrRkVEMztG5PrlTP2uA2s=.f363d980-9971-41ac-a626-0a2ffa0750c5@github.com>

On Mon, 17 Jan 2022 10:37:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push code code generation tactics and strategies from B3 to B2 classes.

Changes to the runtime test look good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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

From mcimadamore at openjdk.java.net  Tue Jan 18 14:12:02 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 Jan 2022 14:12:02 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
Message-ID: <jifHuRo4iZ_XhdV4o9_iFuJwypYZlDaIFcBf-_c_W-Y=.4790811e-2c26-4c90-9a6f-1736b86200fc@github.com>

On Mon, 17 Jan 2022 10:37:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push code code generation tactics and strategies from B3 to B2 classes.

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

> 1331:         @Override
> 1332:         public boolean isValueClass() {
> 1333:             return !isReferenceProjection() && tsym != null && tsym.isValueClass();

The new test for `isReferenceProjections` does not match my understanding of what a "value class" is. E.g. I believe a value class doesn't really have a reference projection (or, rather, doing vclass.ref is the same as doing String.ref - it's the identity). So it's not clear to me the rationale behind the new check.

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

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

From sadayapalam at openjdk.java.net  Tue Jan 18 15:07:02 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Jan 2022 15:07:02 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <jifHuRo4iZ_XhdV4o9_iFuJwypYZlDaIFcBf-_c_W-Y=.4790811e-2c26-4c90-9a6f-1736b86200fc@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
 <jifHuRo4iZ_XhdV4o9_iFuJwypYZlDaIFcBf-_c_W-Y=.4790811e-2c26-4c90-9a6f-1736b86200fc@github.com>
Message-ID: <oLH6EusVJzrC31T7eK5qosceEcQ5ujccTH-m6pnmzlk=.8528bb57-a891-4115-b2aa-bf8fd8f056e1@github.com>

On Tue, 18 Jan 2022 14:08:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Push code code generation tactics and strategies from B3 to B2 classes.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1333:
> 
>> 1331:         @Override
>> 1332:         public boolean isValueClass() {
>> 1333:             return !isReferenceProjection() && tsym != null && tsym.isValueClass();
> 
> The new test for `isReferenceProjections` does not match my understanding of what a "value class" is. E.g. I believe a value class doesn't really have a reference projection (or, rather, doing vclass.ref is the same as doing String.ref - it's the identity). So it's not clear to me the rationale behind the new check.

You are right, a B2 value class does not have a reference projection, in fact String.ref and ValueClass.ref will ATM result in a compile error. In the implementation .ref can be applied only to a primitive class (B3) - the spec may call for .ref to a total operation - but this is what we do at the moment awaiting spec clarification on the whole handling of .ref syntax. There is a ticket open for it - but at the moment I have trouble accessing JIRA)

Now a B3 class can and does have a reference projection and every B3 class is a B2 class. So
the receiver of the method isValueClass() could be a B3 class. This necessitates the new change
to the method.

Consider this methid from Gen:

public void visitDefaultValue(JCDefaultValue tree) {
        if (tree.type.isValueClass()) {
            code.emitop2(aconst_init, checkDimension(tree.pos(), tree.type), PoolWriter::putClass);
        } else if (tree.type.isReference()) {
            code.emitop0(aconst_null);
        } else {
            code.emitop0(zero(Code.typecode(tree.type)));
        }
        result = items.makeStackItem(tree.type);
        return;
    } 

Without the proposed change to isValueClass(), we would emit aconst_init instead of aconst_null for
PrimitiveClass.ref.default

On a related note, (again hampered by lack of access to JBS), we have a ticket open for rationalization/cleanup of various internal APIs - I had put in some work into it - but that had to be halted because of large scale changes to landscape - (ref default classes being gone for example). This work needs to be taken up in the context of the new
model to bring upto date the APIs. For example com.sun.tools.javac.code.Type.ClassType.Flavor is not current )

Let me know if this addresses this your question, Thanks for reviewing!

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

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

From duke at openjdk.java.net  Tue Jan 18 15:54:00 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Tue, 18 Jan 2022 15:54:00 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
Message-ID: <C0QCwl52XP25kPDpNvGYEp6k7lFusqprPRw67WE-xJU=.e3e2afee-ddf5-406f-a17c-bf55f21512a8@github.com>

On Mon, 17 Jan 2022 10:37:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push code code generation tactics and strategies from B3 to B2 classes.

Tested the current PR ??

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

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

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

From mcimadamore at openjdk.java.net  Tue Jan 18 16:05:59 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 Jan 2022 16:05:59 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <oLH6EusVJzrC31T7eK5qosceEcQ5ujccTH-m6pnmzlk=.8528bb57-a891-4115-b2aa-bf8fd8f056e1@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
 <jifHuRo4iZ_XhdV4o9_iFuJwypYZlDaIFcBf-_c_W-Y=.4790811e-2c26-4c90-9a6f-1736b86200fc@github.com>
 <oLH6EusVJzrC31T7eK5qosceEcQ5ujccTH-m6pnmzlk=.8528bb57-a891-4115-b2aa-bf8fd8f056e1@github.com>
Message-ID: <5V1jeSaETDMWSrfI44TfFlE5Ve1t8QRAnHBoxPjMWlY=.a59b614c-c170-4c5e-9b99-0e6fa0e0a054@github.com>

On Tue, 18 Jan 2022 15:03:47 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 1333:
>> 
>>> 1331:         @Override
>>> 1332:         public boolean isValueClass() {
>>> 1333:             return !isReferenceProjection() && tsym != null && tsym.isValueClass();
>> 
>> The new test for `isReferenceProjections` does not match my understanding of what a "value class" is. E.g. I believe a value class doesn't really have a reference projection (or, rather, doing vclass.ref is the same as doing String.ref - it's the identity). So it's not clear to me the rationale behind the new check.
>
> You are right, a B2 value class does not have a reference projection, in fact String.ref and ValueClass.ref will ATM result in a compile error. In the implementation .ref can be applied only to a primitive class (B3) - the spec may call for .ref to a total operation - but this is what we do at the moment awaiting spec clarification on the whole handling of .ref syntax. There is a ticket open for it - but at the moment I have trouble accessing JIRA
> 
> Now a B3 class can and does have a reference projection and every B3 class is a B2 class. So
> the receiver of the method isValueClass() could be a B3 class's primitive class type or its reference projection type . 
> This necessitates the new change to the method.
> 
> Consider this method from Gen:
> 
> public void visitDefaultValue(JCDefaultValue tree) {
>         if (tree.type.isValueClass()) {
>             code.emitop2(aconst_init, checkDimension(tree.pos(), tree.type), PoolWriter::putClass);
>         } else if (tree.type.isReference()) {
>             code.emitop0(aconst_null);
>         } else {
>             code.emitop0(zero(Code.typecode(tree.type)));
>         }
>         result = items.makeStackItem(tree.type);
>         return;
>     } 
> 
> Without the proposed change to isValueClass(), we would emit aconst_init instead of aconst_null for
> PrimitiveClass.ref.default
> 
> On a related note, (again hampered by lack of access to JBS), we have a ticket open for rationalization/cleanup of various internal APIs - I had put in some work into it - but that had to be halted because of large scale changes to landscape - (ref default classes being gone for example). This work needs to be taken up in the context of the new
> model to bring upto date the APIs. For example com.sun.tools.javac.code.Type.ClassType.Flavor is not current )
> 
> Let me know if this addresses this your question, Thanks for reviewing!

I'm still confused a bit. I get that this is all transitional, in a way - but I would expect javac to differentiate between B2 and B3 more. It is true, as you claim that `every B3 class is a B2 class`: some of the identity restrictions apply to both declarations. But in my opinion, the current javac support (as of before this PR) is much closer to B3 than it is to B2 declarations, at least from a type system perspective. That is, a `value class` should be, to javac, just a plain reference class, with no reference projection etc. So, if String.ref is an error, I'd expect vclass.ref to be an error in the same way (in this transitional world). 
>From a translation perspective I agree that B2 and B3 are not too different (no constructors, etc.) - but I'm a bit afraid that by blurring distinction between  B2 and B3 in the type system we might end up with problems further down the road.

That said, I understand that a lot of this is temporary, so if you think it would be more adequate I'm fine looking again at some point in the future.

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

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

From sadayapalam at openjdk.java.net  Tue Jan 18 16:30:52 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Jan 2022 16:30:52 GMT
Subject: [lworld] RFR: Implement code generation support for value classes
In-Reply-To: <5V1jeSaETDMWSrfI44TfFlE5Ve1t8QRAnHBoxPjMWlY=.a59b614c-c170-4c5e-9b99-0e6fa0e0a054@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
 <jifHuRo4iZ_XhdV4o9_iFuJwypYZlDaIFcBf-_c_W-Y=.4790811e-2c26-4c90-9a6f-1736b86200fc@github.com>
 <oLH6EusVJzrC31T7eK5qosceEcQ5ujccTH-m6pnmzlk=.8528bb57-a891-4115-b2aa-bf8fd8f056e1@github.com>
 <5V1jeSaETDMWSrfI44TfFlE5Ve1t8QRAnHBoxPjMWlY=.a59b614c-c170-4c5e-9b99-0e6fa0e0a054@github.com>
Message-ID: <XS9HJRB3zj8Wtwo0yd26Jwbt3kL7yti6Ke1oWJPa7nM=.f3b4a31d-e07c-4091-8697-074f051bc502@github.com>

On Tue, 18 Jan 2022 16:03:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> You are right, a B2 value class does not have a reference projection, in fact String.ref and ValueClass.ref will ATM result in a compile error. In the implementation .ref can be applied only to a primitive class (B3) - the spec may call for .ref to a total operation - but this is what we do at the moment awaiting spec clarification on the whole handling of .ref syntax. There is a ticket open for it - but at the moment I have trouble accessing JIRA
>> 
>> Now a B3 class can and does have a reference projection and every B3 class is a B2 class. So
>> the receiver of the method isValueClass() could be a B3 class's primitive class type or its reference projection type . 
>> This necessitates the new change to the method.
>> 
>> Consider this method from Gen:
>> 
>> public void visitDefaultValue(JCDefaultValue tree) {
>>         if (tree.type.isValueClass()) {
>>             code.emitop2(aconst_init, checkDimension(tree.pos(), tree.type), PoolWriter::putClass);
>>         } else if (tree.type.isReference()) {
>>             code.emitop0(aconst_null);
>>         } else {
>>             code.emitop0(zero(Code.typecode(tree.type)));
>>         }
>>         result = items.makeStackItem(tree.type);
>>         return;
>>     } 
>> 
>> Without the proposed change to isValueClass(), we would emit aconst_init instead of aconst_null for
>> PrimitiveClass.ref.default
>> 
>> On a related note, (again hampered by lack of access to JBS), we have a ticket open for rationalization/cleanup of various internal APIs - I had put in some work into it - but that had to be halted because of large scale changes to landscape - (ref default classes being gone for example). This work needs to be taken up in the context of the new
>> model to bring upto date the APIs. For example com.sun.tools.javac.code.Type.ClassType.Flavor is not current )
>> 
>> Let me know if this addresses this your question, Thanks for reviewing!
>
> I'm still confused a bit. I get that this is all transitional, in a way - but I would expect javac to differentiate between B2 and B3 more. It is true, as you claim that `every B3 class is a B2 class`: some of the identity restrictions apply to both declarations. But in my opinion, the current javac support (as of before this PR) is much closer to B3 than it is to B2 declarations, at least from a type system perspective. That is, a `value class` should be, to javac, just a plain reference class, with no reference projection etc. So, if String.ref is an error, I'd expect vclass.ref to be an error in the same way (in this transitional world). 
> From a translation perspective I agree that B2 and B3 are not too different (no constructors, etc.) - but I'm a bit afraid that by blurring distinction between  B2 and B3 in the type system we might end up with problems further down the road.
> 
> That said, I understand that a lot of this is temporary, so if you think it would be more adequate I'm fine looking again at some point in the future.

It is a fact that quite a bit of changes are in the pipeline, particularly with respect to internal API rationalization/cleanup, but lest I get too comfortable sweeping the present point of discussion under that carpet, here are some clarifications,

> I'm still confused a bit. I get that this is all transitional, in a way - but I would expect javac to differentiate between B2 >and B3 more. 

Yes, the API points isPrimitiveClass() will answer true only for B3 while isValueClass() will answer true for both B2 and B3. One of the next steps is to go through with a fine toothed comb every use of isPrimitiveClass in the code base
to make sure that it is guarding treatment specifc to B3 classes - everything else should have been pushed down to isValueClass() gate.

> It is true, as you claim that `every B3 class is a B2 class`: some of the identity restrictions apply to both declarations. >But in my opinion, the current javac support (as of before this PR) is much closer to B3 than it is to B2 declarations, at >least from a type system perspective. That is, a `value class` should be, to javac, just a plain reference class, with no >reference projection etc. So, if String.ref is an error, I'd expect vclass.ref to be an error in the same way (in this >transitional world).

Yes, String.ref is an error and given value class Point, Point.ref is an error today.

> From a translation perspective I agree that B2 and B3 are not too different (no constructors, etc.) - but I'm a bit afraid that by blurring distinction between B2 and B3 in the type system we might end up with problems further down the road.
> 
> That said, I understand that a lot of this is temporary, so if you think it would be more adequate I'm fine looking again at some point in the future.

I would say there is no blurring of distinction - the internal APIs that were evolving for a set of needs haven't fully been custom fit for the new world yet.

Yes, within the next couple of weeks, I expect to have futher changes that would have removed certain vestiges, retooled others to fit the current model and I will invite you to review that.

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

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

From sadayapalam at openjdk.java.net  Tue Jan 18 16:36:05 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Jan 2022 16:36:05 GMT
Subject: [lworld] Integrated: Implement code generation support for value
 classes
In-Reply-To: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
References: <CLUcjGC8Hs8p0Q-vwhO7zifhFAkGD_ZPfBpUu1qpICY=.1571170b-ba72-4e08-b21c-5a20c986c396@github.com>
Message-ID: <1mBjeI0qFhvBuEkhwjWr-g8wt3ugW3oqthrDWAjJDxE=.59cfbd03-9b0f-4cbf-8b2c-59c900912486@github.com>

On Mon, 17 Jan 2022 10:37:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Push code code generation tactics and strategies from B3 to B2 classes.

This pull request has now been integrated.

Changeset: e785b5ac
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e785b5ac19caf8f4d38147969955f7e9f6bbb24c
Stats:     177 lines in 14 files changed: 112 ins; 13 del; 52 mod

Implement code generation support for value classes

Reviewed-by: fparain

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

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

From sadayapalam at openjdk.java.net  Tue Jan 18 18:58:11 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 18 Jan 2022 18:58:11 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered
Message-ID: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>

Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut

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

Commit messages:
 - Fix trailing white space
 - 8280164: [lworld] Generate Preload attribute to enumerate value classes encountered

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

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

From duke at openjdk.java.net  Tue Jan 18 19:01:33 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Tue, 18 Jan 2022 19:01:33 GMT
Subject: [lworld] RFR: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
 [v2]
In-Reply-To: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
References: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
Message-ID: <bK3ckGCx-8Vr_-VwaWZ_tHHUNGW_axpnRZQYfSRCHUo=.0ba8dcf8-158f-4fbf-a012-5d67c48b09cb@github.com>

> Elides the restriction for `Cloneable`.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address reviews

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/603/files
  - new: https://git.openjdk.java.net/valhalla/pull/603/files/0b29cd23..5c432578

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

  Stats: 57 lines in 10 files changed: 1 ins; 47 del; 9 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/603.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/603/head:pull/603

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

From sadayapalam at openjdk.java.net  Wed Jan 19 04:32:58 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 04:32:58 GMT
Subject: [lworld] RFR: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
 [v2]
In-Reply-To: <bK3ckGCx-8Vr_-VwaWZ_tHHUNGW_axpnRZQYfSRCHUo=.0ba8dcf8-158f-4fbf-a012-5d67c48b09cb@github.com>
References: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
 <bK3ckGCx-8Vr_-VwaWZ_tHHUNGW_axpnRZQYfSRCHUo=.0ba8dcf8-158f-4fbf-a012-5d67c48b09cb@github.com>
Message-ID: <wRMeTu24y756824eqJZGquuPK-DmzzmzCqfMDfFpTfs=.8dd6c5b4-84d2-4bc9-8e03-f3559bbbc177@github.com>

On Tue, 18 Jan 2022 19:01:33 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Elides the restriction for `Cloneable`.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address reviews

Looks good to me, Congratulations and thanks on your first contribution to Valhalla!

IIRC, the process now for me to /sponsor and for you to /integrate

I am always confused if the order matters, we will know soon ;-)

test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java line 24:

> 22:             notifyAll();
> 23:             finalize();
> 24:         }

Rather than deleting this line, we could have simply commented saying clone is not an error anymore - that would have minimized the changes to the expected out file (we call them the golden files). No need to change now, but in future you can use such techniques to minimize diffs that are painful/tedious to verify.

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

Marked as reviewed by sadayapalam (Committer).

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

From thartmann at openjdk.java.net  Wed Jan 19 08:45:29 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 19 Jan 2022 08:45:29 GMT
Subject: [lworld] RFR: 8280006: [lworld] Compiler interface uses wrong class
 loader when looking up field type
Message-ID: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>

In the test, the primitive type `ValueOnBootclasspath` of flattened `Wrapper1.field` and the type `MyClass` of its flattened `field` are loaded by the boot classloader (`loader` is NULL):

<ciInlineKlass name=ValueOnBootclasspath loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,final,super super=java/lang/Object ident=1288 address=0x00007f5108540288>
<ciInstanceKlass name=MyClass loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,super ident=1292 address=0x00007f5108541160> 


During JIT compilation, when the type of `Wrapper1.field` is computed in `ciField::compute_type_impl()`, `Wrapper1` is used as the holder klass and therefore its class loader (`loader=0x000000062c754858`) is used as context for the lookup:


<ciField name=TestBootClassloader$Wrapper1.field signature=LMyClass; offset=12 type=(reference) flags=0010 is_constant=true is_flattened=false is_null_free=false>
<ciInlineKlass name=TestBootClassloader$Wrapper1 loader=0x000000062c754858 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,final,super super=java/lang/Object ident=1284 address=0x00007f510853f440>


But since `MyClass` was loaded by the boot classloader, the lookup via the application class loader fails and leads to an unloaded klass:

<ciInstanceKlass name=MyClass loader=0x000000062c754858 loaded=false ident=1289 address=0x00007f5108540708>


C2's type system then gets confused when mixing both `MyClass` types and bails out with `COMPILE SKIPPED: Can't determine return type. (retry at different tier)`.

The fix is to use the "original holder", i.e., the klass that defined the field in the source code and not the one that contains it at runtime due to flattening, for the lookup instead.

While debugging, I also noticed that loading of signature classes before JIT compilation does not apply to fields that came in through flattening. I filed [JDK-8280230](https://bugs.openjdk.java.net/browse/JDK-8280230) to investigate this separately.

Best regards,
Tobias

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

Commit messages:
 - 8280006: [lworld] Compiler interface uses wrong holder for flattened fields

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

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

From duke at openjdk.java.net  Wed Jan 19 10:40:54 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 19 Jan 2022 10:40:54 GMT
Subject: [lworld] RFR: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
 [v2]
In-Reply-To: <wRMeTu24y756824eqJZGquuPK-DmzzmzCqfMDfFpTfs=.8dd6c5b4-84d2-4bc9-8e03-f3559bbbc177@github.com>
References: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
 <bK3ckGCx-8Vr_-VwaWZ_tHHUNGW_axpnRZQYfSRCHUo=.0ba8dcf8-158f-4fbf-a012-5d67c48b09cb@github.com>
 <wRMeTu24y756824eqJZGquuPK-DmzzmzCqfMDfFpTfs=.8dd6c5b4-84d2-4bc9-8e03-f3559bbbc177@github.com>
Message-ID: <6faZYs5D6XQdqptKvCeIVgzkCWjGjvvVibVlBZpWfUE=.c2526bf9-4a68-4bdf-81e2-5bea3cd00452@github.com>

On Wed, 19 Jan 2022 04:28:02 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address reviews
>
> test/langtools/tools/javac/valhalla/lworld-values/CheckSync.java line 24:
> 
>> 22:             notifyAll();
>> 23:             finalize();
>> 24:         }
> 
> Rather than deleting this line, we could have simply commented saying clone is not an error anymore - that would have minimized the changes to the expected out file (we call them the golden files). No need to change now, but in future you can use such techniques to minimize diffs that are painful/tedious to verify.

Thank you for the recommendation!

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

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

From sadayapalam at openjdk.java.net  Wed Jan 19 11:58:46 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 11:58:46 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered
In-Reply-To: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
Message-ID: <3im8o037xdGi4J8KtJh0bBoWSTN7NR6zW847APBoKdA=.d5aeaac7-3b5a-4de6-b162-864e7d1c11b8@github.com>

On Tue, 18 Jan 2022 18:45:18 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut

test/langtools/tools/javac/valhalla/value-objects/PreloadAttributeTest.java line 54:

> 52:                V6 [] v61 = null;  // stack map table.
> 53:             } else {
> 54:                V5 [] v52 = null;

A note: V6 has no mention in the source file anywhere (local variable table, stack map table ...) and so doesn't feature in Preload either. The test should be updated to reflect that - it gives the impression that V6 is expected in the Preloads.

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

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

From sadayapalam at openjdk.java.net  Wed Jan 19 12:10:54 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 12:10:54 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered
In-Reply-To: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
Message-ID: <pksZB-ujbCh1e93eMSdB5o3dzaXYIgL3mqXzBW66MNc=.ac88b5ef-0e40-4514-9776-7e64901863e6@github.com>

On Tue, 18 Jan 2022 18:45:18 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java line 260:

> 258:         c.complete();
> 259:         if (c.isValueClass()) {
> 260:             valueClasses.add(c);

I suspect this should be if (c.isValueClass() && !c.isPrimitiveClass())

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

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

From duke at openjdk.java.net  Wed Jan 19 12:15:47 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 19 Jan 2022 12:15:47 GMT
Subject: [lworld] Integrated: 8279656: [lworld] Javac diagnostic
 compiler.err.primitive.class.must.not.implement.cloneable not valid anymore
In-Reply-To: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
References: <gFrkttoW4B9ugBetWXlfzbdcmindiC3MbkBvfcsC488=.99215769-9848-45f1-b146-55740a1f088d@github.com>
Message-ID: <Ua-aDM2npccXVwVlc5dE-gbxx-rPzuUOl52PhHur0-s=.09a75e7a-3345-4c5c-87f0-8bcc4a98d934@github.com>

On Fri, 14 Jan 2022 10:39:29 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Elides the restriction for `Cloneable`.

This pull request has now been integrated.

Changeset: 01bd664e
Author:    Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/01bd664ee6f20936d927fa57d4f1f812dc5441ad
Stats:     80 lines in 11 files changed: 1 ins; 70 del; 9 mod

8279656: [lworld] Javac diagnostic compiler.err.primitive.class.must.not.implement.cloneable not valid anymore

Reviewed-by: sadayapalam

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

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

From jespersm at openjdk.java.net  Wed Jan 19 12:19:06 2022
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 19 Jan 2022 12:19:06 GMT
Subject: [lworld] RFR: 8279906: [lworld] Javac tolerates synchronized methods
 in value/primitive records
Message-ID: <8tGSIs0NRexyTjJ-AyA0lF-6a9TSolAvpgCDEg2gCuE=.2542220c-7aff-4e0a-adc5-90c618169a06@github.com>

Fix JDK-8279906 by masking the record-specific flags.

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

Commit messages:
 - 8279906: [lworld] Javac tolerates synchronized methods in value/primitive records

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

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

From duke at openjdk.java.net  Wed Jan 19 13:45:53 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 19 Jan 2022 13:45:53 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered
In-Reply-To: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
Message-ID: <12gk3kp3Cikcb23bOxDvln-uJgPPwxo7g7qfulNkaSw=.4b7fe1fa-f5e8-409f-93a9-76b4a01e1c50@github.com>

On Tue, 18 Jan 2022 18:45:18 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut

I would expect all V* classes to be part of the `Preload`'s, `classes` field. Maybe my understanding is wrong. I checked with `javap` and it reports only one:


Classes to be preloaded:
  #14;                                    // value class PreloadAttributeTest$X


In any case, even if my understanding is wrong, can we use the same style as in `test/langtools/tools/javac/valhalla/value-objects/ValueCreationTest.java` to assert that the contents of the `Preload` attribute are the expected ones? (in this case 1).

What do you think? Otherwise it looks good.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java line 98:

> 96:     LinkedHashSet<ClassSymbol> innerClasses = new LinkedHashSet<>();
> 97: 
> 98:     HashSet<ClassSymbol> valueClasses = new HashSet<>();

nitpicking:`Set` instead of `HashSet` for the type definition? (hm, the interface is used below in line 101 but not in the line 96 above)

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

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

From sadayapalam at openjdk.java.net  Wed Jan 19 14:12:07 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 14:12:07 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered
In-Reply-To: <12gk3kp3Cikcb23bOxDvln-uJgPPwxo7g7qfulNkaSw=.4b7fe1fa-f5e8-409f-93a9-76b4a01e1c50@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
 <12gk3kp3Cikcb23bOxDvln-uJgPPwxo7g7qfulNkaSw=.4b7fe1fa-f5e8-409f-93a9-76b4a01e1c50@github.com>
Message-ID: <xr5OdBOzcYS911LPJnk_SX6tXPptGD3lUXla0mxAAo0=.c9c14b78-334f-494d-911c-24ff5c639f8e@github.com>

On Wed, 19 Jan 2022 13:24:31 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java line 98:
> 
>> 96:     LinkedHashSet<ClassSymbol> innerClasses = new LinkedHashSet<>();
>> 97: 
>> 98:     HashSet<ClassSymbol> valueClasses = new HashSet<>();
> 
> nitpicking:`Set` instead of `HashSet` for the type definition? (hm, the interface is used below in line 101 but not in the line 96 above)

Done. I started out that way and seeing the line above decided to align, but always do the right thing is a good motto :)

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

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

From sadayapalam at openjdk.java.net  Wed Jan 19 14:17:48 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 14:17:48 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered [v2]
In-Reply-To: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
Message-ID: <woLh1hysDqqSJH-byCV6YHU560gC-WZwXdbcEfXz6HM=.49457ae4-30a1-4ce7-af66-652350a9adbf@github.com>

> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut

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

  Address review comments ( Aggelos + self)

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/605/files
  - new: https://git.openjdk.java.net/valhalla/pull/605/files/1020359e..5dc24333

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

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

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

From sadayapalam at openjdk.java.net  Wed Jan 19 14:17:50 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 14:17:50 GMT
Subject: [lworld] Integrated: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered
In-Reply-To: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
Message-ID: <yGlUWa8WuLwrF5vMGb3iOcD3tMvavol8G0AiFP_2Y1Q=.ad7c9af8-dab0-4628-b0f4-d5e2f7977663@github.com>

On Tue, 18 Jan 2022 18:45:18 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut

This pull request has now been integrated.

Changeset: ab748ddc
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ab748ddcd4a30337db343f720ac379e00b265170
Stats:     267 lines in 11 files changed: 261 ins; 0 del; 6 mod

8280164: [lworld] Generate Preload attribute to enumerate value classes encountered

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

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

From jespersm at openjdk.java.net  Wed Jan 19 15:18:55 2022
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 19 Jan 2022 15:18:55 GMT
Subject: [lworld] Withdrawn: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <e9_TiqXuiBOQpkU1NvX6we-eeeTgDE-9R00PqKsrNkY=.c2d01437-535b-4626-8bd0-87637a170f9f@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

This pull request has been closed without being integrated.

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

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

From jespersm at openjdk.java.net  Wed Jan 19 15:18:54 2022
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Wed, 19 Jan 2022 15:18:54 GMT
Subject: [lworld] RFR: 8273301: [lworld] Bootstrap of instance-capturing
 lambda fails for reference favoring primitive types.
In-Reply-To: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
References: <8JysUurQzJI_DbT0D0lgZ-sv0PTRLiIuIBoJNiL-b8c=.a3b8a686-ca26-408c-8914-defb816591c3@github.com>
Message-ID: <pV-Qz39DGj0HnKwaLUNm6IghLTDnVA-PWycAPwL_pzc=.866af7fc-ff4b-444a-b760-bf8942a40ce5@github.com>

On Thu, 2 Sep 2021 20:10:36 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix the test by adjusting bootstrap parameters, like it was fixed in JDK-8271583.

Abandoning this, no longer relevant.

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

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

From sadayapalam at openjdk.java.net  Wed Jan 19 15:33:56 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 19 Jan 2022 15:33:56 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered [v2]
In-Reply-To: <12gk3kp3Cikcb23bOxDvln-uJgPPwxo7g7qfulNkaSw=.4b7fe1fa-f5e8-409f-93a9-76b4a01e1c50@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
 <12gk3kp3Cikcb23bOxDvln-uJgPPwxo7g7qfulNkaSw=.4b7fe1fa-f5e8-409f-93a9-76b4a01e1c50@github.com>
Message-ID: <aJnG4gaZievpy6e24gAuXYuC7pmNgZzyx6-75rKFNeQ=.701ee65c-f342-4aa4-a7a3-8508a22aeece@github.com>

On Wed, 19 Jan 2022 13:42:49 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> I would expect all V* classes to be part of the `Preload`'s, `classes` field. Maybe my understanding is wrong. I checked with `javap` and it reports only one:
> 
> ```
> Classes to be preloaded:
>   #14;                                    // value class PreloadAttributeTest$X
> ```

This is the javap output of PreloadAttributeTest.class - this class does not reference the V* classes at all.
If you look at the javap output of PreloadAttributeTest$X.class, you will see the V* classes

> 
> In any case, even if my understanding is wrong, can we use the same style as in `test/langtools/tools/javac/valhalla/value-objects/ValueCreationTest.java` to assert that the contents of the `Preload` attribute are the expected ones? (in this case 1).
> 

That test uses textual comparison which in general is turns out to be flaky - constant pool indices, byte code offsets can change when code generation changes in some minor unrelated way causing tests to "fail" needlessly.

The test you cite itself needs to move away to more robust form that avoid including immaterial things (such as indices/offsets etc) - this is a separate task that should be taken up. 
> What do you think? Otherwise it looks good.

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

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

From duke at openjdk.java.net  Wed Jan 19 15:38:52 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Wed, 19 Jan 2022 15:38:52 GMT
Subject: [lworld] RFR: 8280164: [lworld] Generate Preload attribute to
 enumerate value classes encountered [v2]
In-Reply-To: <woLh1hysDqqSJH-byCV6YHU560gC-WZwXdbcEfXz6HM=.49457ae4-30a1-4ce7-af66-652350a9adbf@github.com>
References: <q1SadnQi5jekK2WvbLQsL4lCg4-OFxYUSbtlK3Fa8dI=.83b6b4ed-6659-49ee-8637-fdcf735a8167@github.com>
 <woLh1hysDqqSJH-byCV6YHU560gC-WZwXdbcEfXz6HM=.49457ae4-30a1-4ce7-af66-652350a9adbf@github.com>
Message-ID: <OPdTFywANhhUamH1r2mO3Xic6AW_O8VRASZbJeqAb2Y=.31dc027c-0664-4a22-8d04-4aaea40ef947@github.com>

On Wed, 19 Jan 2022 14:17:48 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Modelled after InnerClasses attribute generation, we may be generating more information than necessary/useful but this is initial cut
>
> Srikanth Adayapalam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments ( Aggelos + self)

I was doing `javap -v valhalla/test/langtools/tools/javac/valhalla/value-objects/PreloadAttributeTest$X` without the `` so it was just `PreloadAttributeTest` effectively in the javap command ?? ?? 

All good then ??

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

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

From fparain at openjdk.java.net  Wed Jan 19 16:42:59 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 19 Jan 2022 16:42:59 GMT
Subject: [lworld] RFR: 8280006: [lworld] Compiler interface uses wrong
 class loader when looking up field type
In-Reply-To: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>
References: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>
Message-ID: <CRkcPRHlC2PVABJS2tGQIoZhjJg6jRbgPyXd73iIJl0=.0988845b-9ea1-4329-9fac-4e42061566f7@github.com>

On Wed, 19 Jan 2022 08:24:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In the test, the primitive type `ValueOnBootclasspath` of flattened `Wrapper1.field` and the type `MyClass` of its flattened `field` are loaded by the boot classloader (`loader` is NULL):
> 
> <ciInlineKlass name=ValueOnBootclasspath loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,final,super super=java/lang/Object ident=1288 address=0x00007f5108540288>
> <ciInstanceKlass name=MyClass loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,super ident=1292 address=0x00007f5108541160> 
> 
> 
> During JIT compilation, when the type of `Wrapper1.field` is computed in `ciField::compute_type_impl()`, `Wrapper1` is used as the holder klass and therefore its class loader (`loader=0x000000062c754858`) is used as context for the lookup:
> 
> 
> <ciField name=TestBootClassloader$Wrapper1.field signature=LMyClass; offset=12 type=(reference) flags=0010 is_constant=true is_flattened=false is_null_free=false>
> <ciInlineKlass name=TestBootClassloader$Wrapper1 loader=0x000000062c754858 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,final,super super=java/lang/Object ident=1284 address=0x00007f510853f440>
> 
> 
> But since `MyClass` was loaded by the boot classloader, the lookup via the application class loader fails and leads to an unloaded klass:
> 
> <ciInstanceKlass name=MyClass loader=0x000000062c754858 loaded=false ident=1289 address=0x00007f5108540708>
> 
> 
> C2's type system then gets confused when mixing both `MyClass` types and bails out with `COMPILE SKIPPED: Can't determine return type. (retry at different tier)`.
> 
> The fix is to use the "original holder", i.e., the klass that defined the field in the source code and not the one that contains it at runtime due to flattening, for the lookup instead.
> 
> While debugging, I also noticed that loading of signature classes before JIT compilation does not apply to fields that came in through flattening. I filed [JDK-8280230](https://bugs.openjdk.java.net/browse/JDK-8280230) to investigate this separately.
> 
> Best regards,
> Tobias

Looks good to me.
Nice job writing an unit test for this.

Fred

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

Marked as reviewed by fparain (Committer).

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

From sadayapalam at openjdk.java.net  Thu Jan 20 05:18:11 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 20 Jan 2022 05:18:11 GMT
Subject: [lworld] RFR: 8279906: [lworld] Javac tolerates synchronized
 methods in value/primitive records
In-Reply-To: <8tGSIs0NRexyTjJ-AyA0lF-6a9TSolAvpgCDEg2gCuE=.2542220c-7aff-4e0a-adc5-90c618169a06@github.com>
References: <8tGSIs0NRexyTjJ-AyA0lF-6a9TSolAvpgCDEg2gCuE=.2542220c-7aff-4e0a-adc5-90c618169a06@github.com>
Message-ID: <heYcQzTSqoP5GsarrKToREd7bHszEssExOc3Cq6KBts=.496e6cde-3c87-4203-8147-b08ab0f0c91d@github.com>

On Wed, 19 Jan 2022 10:34:05 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix JDK-8279906 by masking the record-specific flags.

Changes look good, Thanks Jesper! Please proceed to integrate.

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

Marked as reviewed by sadayapalam (Committer).

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

From thartmann at openjdk.java.net  Thu Jan 20 07:35:08 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Jan 2022 07:35:08 GMT
Subject: [lworld] RFR: 8280006: [lworld] Compiler interface uses wrong
 class loader when looking up field type
In-Reply-To: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>
References: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>
Message-ID: <PKLQ_PXnFU3zco1TLrWQ9pDpFaOlKTxf42ecGEuKYPk=.5f1c1bb4-cc96-41f4-bfbb-1ba2a0895a76@github.com>

On Wed, 19 Jan 2022 08:24:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In the test, the primitive type `ValueOnBootclasspath` of flattened `Wrapper1.field` and the type `MyClass` of its flattened `field` are loaded by the boot classloader (`loader` is NULL):
> 
> <ciInlineKlass name=ValueOnBootclasspath loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,final,super super=java/lang/Object ident=1288 address=0x00007f5108540288>
> <ciInstanceKlass name=MyClass loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,super ident=1292 address=0x00007f5108541160> 
> 
> 
> During JIT compilation, when the type of `Wrapper1.field` is computed in `ciField::compute_type_impl()`, `Wrapper1` is used as the holder klass and therefore its class loader (`loader=0x000000062c754858`) is used as context for the lookup:
> 
> 
> <ciField name=TestBootClassloader$Wrapper1.field signature=LMyClass; offset=12 type=(reference) flags=0010 is_constant=true is_flattened=false is_null_free=false>
> <ciInlineKlass name=TestBootClassloader$Wrapper1 loader=0x000000062c754858 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,final,super super=java/lang/Object ident=1284 address=0x00007f510853f440>
> 
> 
> But since `MyClass` was loaded by the boot classloader, the lookup via the application class loader fails and leads to an unloaded klass:
> 
> <ciInstanceKlass name=MyClass loader=0x000000062c754858 loaded=false ident=1289 address=0x00007f5108540708>
> 
> 
> C2's type system then gets confused when mixing both `MyClass` types and bails out with `COMPILE SKIPPED: Can't determine return type. (retry at different tier)`.
> 
> The fix is to use the "original holder", i.e., the klass that defined the field in the source code and not the one that contains it at runtime due to flattening, for the lookup instead.
> 
> While debugging, I also noticed that loading of signature classes before JIT compilation does not apply to fields that came in through flattening. I filed [JDK-8280230](https://bugs.openjdk.java.net/browse/JDK-8280230) to investigate this separately.
> 
> Best regards,
> Tobias

Thanks for the review, Fred! Yes, took me a while :)

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

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

From thartmann at openjdk.java.net  Thu Jan 20 07:35:10 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 20 Jan 2022 07:35:10 GMT
Subject: [lworld] Integrated: 8280006: [lworld] Compiler interface uses wrong
 class loader when looking up field type
In-Reply-To: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>
References: <VN2PDAOlDrCGYnw8gHi8AP0H_4q0d4qtbP54X32b2PE=.32a4de56-c593-4f17-bcb7-ddc3378a40f7@github.com>
Message-ID: <KRPFmY14oBR-pyr5DCIiDnFmFfut7klGCMuhPl0EVPM=.c0623acb-dd88-4870-8a96-03b4937d68dd@github.com>

On Wed, 19 Jan 2022 08:24:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In the test, the primitive type `ValueOnBootclasspath` of flattened `Wrapper1.field` and the type `MyClass` of its flattened `field` are loaded by the boot classloader (`loader` is NULL):
> 
> <ciInlineKlass name=ValueOnBootclasspath loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=public,final,super super=java/lang/Object ident=1288 address=0x00007f5108540288>
> <ciInstanceKlass name=MyClass loader=0x0000000000000000 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,super ident=1292 address=0x00007f5108541160> 
> 
> 
> During JIT compilation, when the type of `Wrapper1.field` is computed in `ciField::compute_type_impl()`, `Wrapper1` is used as the holder klass and therefore its class loader (`loader=0x000000062c754858`) is used as context for the lookup:
> 
> 
> <ciField name=TestBootClassloader$Wrapper1.field signature=LMyClass; offset=12 type=(reference) flags=0010 is_constant=true is_flattened=false is_null_free=false>
> <ciInlineKlass name=TestBootClassloader$Wrapper1 loader=0x000000062c754858 loaded=true initialized=true finalized=false subklass=false size=16 flags=DEFAULT_ACCESS,final,super super=java/lang/Object ident=1284 address=0x00007f510853f440>
> 
> 
> But since `MyClass` was loaded by the boot classloader, the lookup via the application class loader fails and leads to an unloaded klass:
> 
> <ciInstanceKlass name=MyClass loader=0x000000062c754858 loaded=false ident=1289 address=0x00007f5108540708>
> 
> 
> C2's type system then gets confused when mixing both `MyClass` types and bails out with `COMPILE SKIPPED: Can't determine return type. (retry at different tier)`.
> 
> The fix is to use the "original holder", i.e., the klass that defined the field in the source code and not the one that contains it at runtime due to flattening, for the lookup instead.
> 
> While debugging, I also noticed that loading of signature classes before JIT compilation does not apply to fields that came in through flattening. I filed [JDK-8280230](https://bugs.openjdk.java.net/browse/JDK-8280230) to investigate this separately.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: ab46c224
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ab46c224d70c4e605cdd648e5654ead28df33eed
Stats:     192 lines in 6 files changed: 185 ins; 0 del; 7 mod

8280006: [lworld] Compiler interface uses wrong class loader when looking up field type

Reviewed-by: fparain

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

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

From jespersm at openjdk.java.net  Thu Jan 20 08:43:18 2022
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 20 Jan 2022 08:43:18 GMT
Subject: [lworld] Integrated: 8279906: [lworld] Javac tolerates synchronized
 methods in value/primitive records
In-Reply-To: <8tGSIs0NRexyTjJ-AyA0lF-6a9TSolAvpgCDEg2gCuE=.2542220c-7aff-4e0a-adc5-90c618169a06@github.com>
References: <8tGSIs0NRexyTjJ-AyA0lF-6a9TSolAvpgCDEg2gCuE=.2542220c-7aff-4e0a-adc5-90c618169a06@github.com>
Message-ID: <0Saab3Ldn25NdbsqYIUaeC_u0tOiBlskOoJaMPzoC2E=.4769a573-72c1-467c-9072-0bd4f9a3d1a2@github.com>

On Wed, 19 Jan 2022 10:34:05 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> Fix JDK-8279906 by masking the record-specific flags.

This pull request has now been integrated.

Changeset: e82f5f10
Author:    Jesper Steen M?ller <jespersm at openjdk.org>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/e82f5f100824e325d7f58ea3d82bf47496671610
Stats:     18 lines in 5 files changed: 14 ins; 0 del; 4 mod

8279906: [lworld] Javac tolerates synchronized methods in value/primitive records

Reviewed-by: sadayapalam

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

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

From dsimms at openjdk.java.net  Thu Jan 20 11:53:33 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 20 Jan 2022 11:53:33 GMT
Subject: git: openjdk/valhalla: lworld: Trival: Header format error
Message-ID: <26e388f5-6fe8-453c-88cc-31c64370bd27@openjdk.org>

Changeset: bb4a4dfb
Author:    David Simms <dsimms at openjdk.org>
Date:      2022-01-20 11:53:12 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/bb4a4dfb5738a482d31837073e5006439185bcb4

Trival: Header format error

! src/java.base/share/classes/java/lang/__value__.java


From dsimms at openjdk.java.net  Thu Jan 20 11:57:32 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 20 Jan 2022 11:57:32 GMT
Subject: [lworld] Integrated: Trival: Header format error
Message-ID: <YhpfBfqJ5rzRQANnyPY8kZRW4B_bQkF4FzMo3oPECT0=.7e11ee83-46d9-46b7-bf37-07c87d9726c4@github.com>

Missing comma

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

Commit messages:
 - Copyright format

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

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

From dsimms at openjdk.java.net  Thu Jan 20 11:57:33 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 20 Jan 2022 11:57:33 GMT
Subject: [lworld] Integrated: Trival: Header format error
In-Reply-To: <YhpfBfqJ5rzRQANnyPY8kZRW4B_bQkF4FzMo3oPECT0=.7e11ee83-46d9-46b7-bf37-07c87d9726c4@github.com>
References: <YhpfBfqJ5rzRQANnyPY8kZRW4B_bQkF4FzMo3oPECT0=.7e11ee83-46d9-46b7-bf37-07c87d9726c4@github.com>
Message-ID: <gTtDSV38DsqV7bX9Rz5tV4bg0WTcIgDDmdtWfzekYY8=.0ff514cd-260b-4d50-8ebc-842203bfb2b3@github.com>

On Thu, 20 Jan 2022 11:50:55 GMT, David Simms <dsimms at openjdk.org> wrote:

> Missing comma

This pull request has now been integrated.

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

Trival: Header format error

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

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

From fparain at openjdk.java.net  Fri Jan 21 13:42:34 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 21 Jan 2022 13:42:34 GMT
Subject: [lworld] RFR: 8280381: [lworld] VM should accept static factory
 methods in value class files.
Message-ID: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>

Please review this patch that enables loading of value classes.
Support for value classes is minimal, but this is the first step to implement them.
The patch also includes some renaming to align Hotspot code with the JVMS draft.

Tested with Mach5, tiers 1-3 (so it builds on all platforms)

Thank you,

Fred

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

Commit messages:
 - Allow value classes to be loaded by the VM

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

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

From thartmann at openjdk.java.net  Fri Jan 21 14:01:43 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 Jan 2022 14:01:43 GMT
Subject: [lworld] RFR: 8280440: [lworld] Scalarization does not properly handle
 speculative types
Message-ID: <mpaAvnuG9q80Al23PehqCIojxfPPHlpGH1ixzQPHFr0=.6f2b5c58-836a-408e-8428-1d0f813ca733@github.com>

This patch fixes several issues with handling speculative types in combination with scalarization in C2 (wrong results and asserts). I added tests that cover all cases.

Thanks,
Tobias

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

Commit messages:
 - 8280440: [lworld] Scalarization does not properly handle speculative types

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

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

From thartmann at openjdk.java.net  Fri Jan 21 15:16:10 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 21 Jan 2022 15:16:10 GMT
Subject: [lworld] Integrated: 8280440: [lworld] Scalarization does not properly
 handle speculative types
In-Reply-To: <mpaAvnuG9q80Al23PehqCIojxfPPHlpGH1ixzQPHFr0=.6f2b5c58-836a-408e-8428-1d0f813ca733@github.com>
References: <mpaAvnuG9q80Al23PehqCIojxfPPHlpGH1ixzQPHFr0=.6f2b5c58-836a-408e-8428-1d0f813ca733@github.com>
Message-ID: <Qnv7JbvzqcLoskEM45Ldq-8KUpaQTLyjesqntZF0nAs=.ef42cb91-9fe4-48ff-a45c-89db9d9eb862@github.com>

On Fri, 21 Jan 2022 13:54:17 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch fixes several issues with handling speculative types in combination with scalarization in C2 (wrong results and asserts). I added tests that cover all cases.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 15f2c4ca
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/15f2c4ca178be2ad69715d19ad947d18e7fe06c1
Stats:     187 lines in 8 files changed: 160 ins; 12 del; 15 mod

8280440: [lworld] Scalarization does not properly handle speculative types

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

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

From duke at openjdk.java.net  Fri Jan 21 21:13:58 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 21 Jan 2022 21:13:58 GMT
Subject: [lworld] RFR: 8279655: [lworld] Bogus error: incompatible types:
 Object cannot be converted to Foo
Message-ID: <5x1FzcPNc3PIUpE5CJ41tiIMv0YyBDn-hmRvqZEIJxk=.ed75f240-3f84-493c-96d5-ed65c84c33ac@github.com>

Use of `referenceProjectionOrSelf` in the subtype check of the `areDisjoint` method.

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

Commit messages:
 - Use of reference projection in disjointness check

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

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

From vromero at openjdk.java.net  Sun Jan 23 23:46:52 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 23 Jan 2022 23:46:52 GMT
Subject: Integrated: some bug fixing, adding new regression tests
Message-ID: <YKc5D-BaLvN7jtcjF9RRxA3fVppYY-_Ll3DEzIJu05s=.e034051f-1c62-4487-9dad-fc2477977a56@github.com>

Bug fixing and more regression tests

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

Commit messages:
 - some regression tests are not passing

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

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

From vromero at openjdk.java.net  Sun Jan 23 23:46:53 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 23 Jan 2022 23:46:53 GMT
Subject: Integrated: some bug fixing, adding new regression tests
In-Reply-To: <YKc5D-BaLvN7jtcjF9RRxA3fVppYY-_Ll3DEzIJu05s=.e034051f-1c62-4487-9dad-fc2477977a56@github.com>
References: <YKc5D-BaLvN7jtcjF9RRxA3fVppYY-_Ll3DEzIJu05s=.e034051f-1c62-4487-9dad-fc2477977a56@github.com>
Message-ID: <oGwqcVVLnnkkChGKP3hgCTAQnQGd-KOU662CMciKuHI=.e188318e-f34f-479f-929a-f10cba01a809@github.com>

On Sun, 23 Jan 2022 19:22:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Bug fixing and more regression tests

This pull request has now been integrated.

Changeset: c1415c09
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c1415c09c9bcacb969f998345a18456ff598d31e
Stats:     93 lines in 2 files changed: 50 ins; 5 del; 38 mod

some bug fixing, adding new regression tests

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

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

From sadayapalam at openjdk.java.net  Mon Jan 24 05:40:22 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Jan 2022 05:40:22 GMT
Subject: [lworld] RFR: 8279655: [lworld] Bogus error: incompatible types:
 Object cannot be converted to Foo
In-Reply-To: <5x1FzcPNc3PIUpE5CJ41tiIMv0YyBDn-hmRvqZEIJxk=.ed75f240-3f84-493c-96d5-ed65c84c33ac@github.com>
References: <5x1FzcPNc3PIUpE5CJ41tiIMv0YyBDn-hmRvqZEIJxk=.ed75f240-3f84-493c-96d5-ed65c84c33ac@github.com>
Message-ID: <S4MaaoIW9JFTSpY-GPMStEgL3sL-k2dPJSB4mvnIZP8=.51da3b85-f936-482e-abb0-441939ff80a7@github.com>

On Fri, 21 Jan 2022 21:03:41 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Use of `referenceProjectionOrSelf` in the subtype check of the `areDisjoint` method.

Changes look good. Please proceed to integrate, Thanks!

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

Marked as reviewed by sadayapalam (Committer).

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

From sadayapalam at openjdk.java.net  Mon Jan 24 08:02:53 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Jan 2022 08:02:53 GMT
Subject: [lworld] Integrated: 8280514: [API-cleanup] Merge the internal API
 points Types.is{Primitive/Value}Class with Type.is{Primitive/Value}Class
Message-ID: <FmpOd8fS0Mhq5gP-7u50iaShgVbLP9quOmb0wTgenxE=.62b1dc86-9613-4067-9f62-8076d6e513ff@github.com>

Eliminate redundant internal APIs by merging uses

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

Commit messages:
 - 8280514: [API-cleanup] Merge the internal API points Types.is{Primitive/Value}Class with Type.is{Primitive/Value}Class

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

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

From sadayapalam at openjdk.java.net  Mon Jan 24 08:02:53 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Jan 2022 08:02:53 GMT
Subject: [lworld] Integrated: 8280514: [API-cleanup] Merge the internal API
 points Types.is{Primitive/Value}Class with Type.is{Primitive/Value}Class
In-Reply-To: <FmpOd8fS0Mhq5gP-7u50iaShgVbLP9quOmb0wTgenxE=.62b1dc86-9613-4067-9f62-8076d6e513ff@github.com>
References: <FmpOd8fS0Mhq5gP-7u50iaShgVbLP9quOmb0wTgenxE=.62b1dc86-9613-4067-9f62-8076d6e513ff@github.com>
Message-ID: <zjBE-gSmWzSxfSzBY8h0t4iGVSGjCUuJfHso9l1It80=.7713f0d6-27b7-4e29-8f9e-e3fac9fa7759@github.com>

On Mon, 24 Jan 2022 07:53:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Eliminate redundant internal APIs by merging uses

This pull request has now been integrated.

Changeset: a9a8c83a
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a9a8c83a4b2411149bb88b053827778d0e934c76
Stats:     36 lines in 8 files changed: 0 ins; 8 del; 28 mod

8280514: [API-cleanup] Merge the internal API points Types.is{Primitive/Value}Class with Type.is{Primitive/Value}Class

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

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

From sadayapalam at openjdk.java.net  Mon Jan 24 08:59:51 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Jan 2022 08:59:51 GMT
Subject: [lworld] Integrated: 8280519: Revert fix for JDK-8212175 as it is not
 relevant anymore
In-Reply-To: <4RUqVPbGoXWPOVCm_mJe-ggWPnBJJ94WpyZfe5uoLpU=.4a4ec61a-cd45-4615-93f3-5e4c8f4f1b5e@github.com>
References: <4RUqVPbGoXWPOVCm_mJe-ggWPnBJJ94WpyZfe5uoLpU=.4a4ec61a-cd45-4615-93f3-5e4c8f4f1b5e@github.com>
Message-ID: <Z00a2zM9VwvgWYLNHJtD0xyIXFYPz0rKxiqOfLQX738=.24670d26-0a98-430c-8309-d5329ab49119@github.com>

On Mon, 24 Jan 2022 08:52:48 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Revert fix for JDK-8212175 as it is not relevant anymore

This pull request has now been integrated.

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

8280519: Revert fix for JDK-8212175 as it is not relevant anymore

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

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

From sadayapalam at openjdk.java.net  Mon Jan 24 08:59:50 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 24 Jan 2022 08:59:50 GMT
Subject: [lworld] Integrated: 8280519: Revert fix for JDK-8212175 as it is not
 relevant anymore
Message-ID: <4RUqVPbGoXWPOVCm_mJe-ggWPnBJJ94WpyZfe5uoLpU=.4a4ec61a-cd45-4615-93f3-5e4c8f4f1b5e@github.com>

Revert fix for JDK-8212175 as it is not relevant anymore

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

Commit messages:
 - 8280519: Revert fix for JDK-8212175 as it is not relevant anymore

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

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

From duke at openjdk.java.net  Mon Jan 24 10:32:25 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Mon, 24 Jan 2022 10:32:25 GMT
Subject: [lworld] Integrated: 8279655: [lworld] Bogus error: incompatible
 types: Object cannot be converted to Foo
In-Reply-To: <5x1FzcPNc3PIUpE5CJ41tiIMv0YyBDn-hmRvqZEIJxk=.ed75f240-3f84-493c-96d5-ed65c84c33ac@github.com>
References: <5x1FzcPNc3PIUpE5CJ41tiIMv0YyBDn-hmRvqZEIJxk=.ed75f240-3f84-493c-96d5-ed65c84c33ac@github.com>
Message-ID: <kCpgQ_C4lL1Ijvc8HGNUD_ij34O3ZENlTILjamAvnFg=.42f26874-59bd-4781-8bf0-2ea0c3e0d1e0@github.com>

On Fri, 21 Jan 2022 21:03:41 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> Use of `referenceProjectionOrSelf` in the subtype check of the `areDisjoint` method.

This pull request has now been integrated.

Changeset: 0c0b8872
Author:    Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0c0b8872921cd442f662a9db8d5df0876667220b
Stats:     19 lines in 2 files changed: 18 ins; 0 del; 1 mod

8279655: [lworld] Bogus error: incompatible types: Object cannot be converted to Foo

Reviewed-by: sadayapalam

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

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

From thartmann at openjdk.java.net  Mon Jan 24 10:38:44 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 24 Jan 2022 10:38:44 GMT
Subject: [lworld] RFR: 8280270: [lworld] JITs miss some klass initialization
 checks for defaultvalue
Message-ID: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>

C1 and C2 miss some klass initialization checks for defaultvalue.

Long term, we should add support for patching defaultvalue in C1 (tracked by [JDK-8265067](https://bugs.openjdk.java.net/browse/JDK-8265067)).

Thanks,
Tobias

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

Commit messages:
 - More fixes
 - Merge branch 'lworld' into JDK-8280270
 - More checks
 - 8280270: [lworld] C2 misses some klass initialization checks

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

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

From fparain at openjdk.java.net  Mon Jan 24 10:38:45 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 24 Jan 2022 10:38:45 GMT
Subject: [lworld] RFR: 8280270: [lworld] JITs miss some klass
 initialization checks for defaultvalue
In-Reply-To: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>
References: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>
Message-ID: <ELRAgWt17p2nknWykXoCYERlEg9CkAKFuXEsPUudP64=.7d1dc43f-02f4-41db-819f-b626fef32692@github.com>

On Fri, 21 Jan 2022 15:36:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1 and C2 miss some klass initialization checks for defaultvalue.
> 
> Long term, we should add support for patching defaultvalue in C1 (tracked by [JDK-8265067](https://bugs.openjdk.java.net/browse/JDK-8265067)).
> 
> Thanks,
> Tobias

C1 changes look good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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

From thartmann at openjdk.java.net  Mon Jan 24 10:38:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 24 Jan 2022 10:38:45 GMT
Subject: [lworld] RFR: 8280270: [lworld] JITs miss some klass
 initialization checks for defaultvalue
In-Reply-To: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>
References: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>
Message-ID: <-Wm6lCQ4EamgrRmojrqfaadKarn0tNwSg-M65kbSHOI=.51117c3c-1c0f-41e9-8f8d-f5ef6cff2d72@github.com>

On Fri, 21 Jan 2022 15:36:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1 and C2 miss some klass initialization checks for defaultvalue.
> 
> Long term, we should add support for patching defaultvalue in C1 (tracked by [JDK-8265067](https://bugs.openjdk.java.net/browse/JDK-8265067)).
> 
> Thanks,
> Tobias

Thanks for the review, Fred!

This patch also contains some fixes for unrelated issues that I found during stress testing.

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

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

From thartmann at openjdk.java.net  Mon Jan 24 12:25:36 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 24 Jan 2022 12:25:36 GMT
Subject: [lworld] Integrated: 8280270: [lworld] JITs miss some klass
 initialization checks for defaultvalue
In-Reply-To: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>
References: <5EQPnisbGiIq1_ojXxVctQ325t7XzCnLtUtouq8RIpA=.3ca3e34c-c8a4-435d-941a-0413df05405c@github.com>
Message-ID: <2JCdN8npHHvtVnV9KrVv2AppT5MOebHs9or1dpLbRaY=.08443167-eb30-4eac-a32a-5635ca815122@github.com>

On Fri, 21 Jan 2022 15:36:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C1 and C2 miss some klass initialization checks for defaultvalue.
> 
> Long term, we should add support for patching defaultvalue in C1 (tracked by [JDK-8265067](https://bugs.openjdk.java.net/browse/JDK-8265067)).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 6610bca7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/6610bca71691a3f2665ef77e0cf7ab4b846d8d94
Stats:     46 lines in 6 files changed: 19 ins; 6 del; 21 mod

8280270: [lworld] JITs miss some klass initialization checks for defaultvalue

Reviewed-by: fparain

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

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

From dsimms at openjdk.java.net  Mon Jan 24 14:12:32 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 24 Jan 2022 14:12:32 GMT
Subject: [lworld] RFR: 8280381: [lworld] VM should accept static factory
 methods in value class files.
In-Reply-To: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>
References: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>
Message-ID: <Cmh-x3SiQtaaehZBtPfm-aIkcL3cGsRCyH8NoWXRWvU=.e8a7a7fa-3396-4419-80d8-e74f705a4125@github.com>

On Fri, 21 Jan 2022 13:36:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch that enables loading of value classes.
> Support for value classes is minimal, but this is the first step to implement them.
> The patch also includes some renaming to align Hotspot code with the JVMS draft.
> 
> Tested with Mach5, tiers 1-3 (so it builds on all platforms)
> 
> Thank you,
> 
> Fred

Looks good

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

Marked as reviewed by dsimms (Committer).

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

From fparain at openjdk.java.net  Mon Jan 24 17:19:23 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 24 Jan 2022 17:19:23 GMT
Subject: [lworld] RFR: 8280381: [lworld] VM should accept static factory
 methods in value class files.
In-Reply-To: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>
References: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>
Message-ID: <ixShztvLvfjYyuLX1WNd-0k4GTQHo8uK6xqcSXSdSaU=.3e953515-29d5-4b25-aa3e-a51ceb4a4110@github.com>

On Fri, 21 Jan 2022 13:36:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch that enables loading of value classes.
> Support for value classes is minimal, but this is the first step to implement them.
> The patch also includes some renaming to align Hotspot code with the JVMS draft.
> 
> Tested with Mach5, tiers 1-3 (so it builds on all platforms)
> 
> Thank you,
> 
> Fred

Thank your for the review.

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

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

From fparain at openjdk.java.net  Mon Jan 24 17:19:23 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 24 Jan 2022 17:19:23 GMT
Subject: [lworld] Integrated: 8280381: [lworld] VM should accept static factory
 methods in value class files.
In-Reply-To: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>
References: <unY_T9B4XicuCtLzFBilG-vhdSWvZgm9-GGR7EHGyYU=.a06ff83a-d2dc-4501-a72a-e382eac77848@github.com>
Message-ID: <j8WN5yN9TVDZK-r1NMZodMYNSsnyNfev_4aPfYPgz-Q=.03eac00f-92ef-4081-aee0-c772dc84c9a3@github.com>

On Fri, 21 Jan 2022 13:36:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this patch that enables loading of value classes.
> Support for value classes is minimal, but this is the first step to implement them.
> The patch also includes some renaming to align Hotspot code with the JVMS draft.
> 
> Tested with Mach5, tiers 1-3 (so it builds on all platforms)
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: ba87b167
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ba87b167f2fe2327508a06ec8652c6ddaa9402c1
Stats:     110 lines in 42 files changed: 9 ins; 0 del; 101 mod

8280381: [lworld] VM should accept static factory methods in value class files.

Reviewed-by: dsimms

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

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

From andvasp at gmail.com  Mon Jan 24 18:26:02 2022
From: andvasp at gmail.com (Anderson Vasconcelos Pires)
Date: Mon, 24 Jan 2022 15:26:02 -0300
Subject: Value class with fields mutable as non default
Message-ID: <CACB8oqURkAWKcaHrMdm4o6QDeFmoMXa-XxPY55MNiYGCs6TP-Q@mail.gmail.com>

Hi guys,

I have in mind that identity is a heavy thing in Java. So I would avoid
identity classes as much as possible. The object model [1] instructs us to
use identity classes for the following cases:

*Use identity classes when we need mutability, layout extension, or
locking;*

My naive understanding tells me that fields of a value class could be
mutable keeping the standard as immutable. I know that value classes being
immutable is beneficial to the JVM but I am wondering if it would have some
advantage in having this possibility too.

Considering the user case below where I have such a business logic like a
cache data update. My doubt is if the situation below would be good to use
identity class, value class or value class with mutable fields?

value class ManyFields {
    public String field1, field2, field3, field4, field5;
}

var manyFieldsById = new HashMap<String, ManyFields>();

Using value class:

var manyFields  = manyFieldsById.get("xxx")
manyFields = manyFields.createAnotherInstanceSettingField1("anotherValue");
manyFieldsById.put("xxx", manyFields)

Using identity class or value class with mutable fields:
[value] class ManyFields {
    public *non-final* String field1, field2, field3, field4, field5;
}

var manyFields  = manyFieldsById.get("xxx")
manyFields.field1 = "anotherValue"; // do not create another instance and
do not put it in the Map.

In this scenario would it be better to use value class, identity class or
value class with mutability if mutability would be possible?

[1] -
https://openjdk.java.net/projects/valhalla/design-notes/state-of-valhalla/02-object-model

Thanks for your time and please let me know your thoughts about this.

Anderson.

From heidinga at openjdk.java.net  Mon Jan 24 19:45:34 2022
From: heidinga at openjdk.java.net (Dan Heidinga)
Date: Mon, 24 Jan 2022 19:45:34 GMT
Subject: [valhalla-docs] RFR: Minor grammatical fixes
Message-ID: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>

Some minor grammatical changes and a adjusted wording to reflect that Q may be flattened but flatness isn't guaranteed.

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

Commit messages:
 - Minor grammatical fixes

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

PR: https://git.openjdk.java.net/valhalla-docs/pull/8

From john.r.rose at oracle.com  Tue Jan 25 03:24:58 2022
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 24 Jan 2022 19:24:58 -0800
Subject: [valhalla-docs] RFR: Minor grammatical fixes
In-Reply-To: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>
References: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>
Message-ID: <18332809-8211-47B0-9698-839444D785C7@oracle.com>

Thanks, Dan.

On 24 Jan 2022, at 11:45, Dan Heidinga wrote:

> Some minor grammatical changes and a adjusted wording to reflect that Q may be flattened but flatness isn't guaranteed.
>
> -------------
>
> Commit messages:
>  - Minor grammatical fixes
>
> Changes: https://git.openjdk.java.net/valhalla-docs/pull/8/files
>  Webrev: https://webrevs.openjdk.java.net/?repo=valhalla-docs&pr=8&range=00
>   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>   Patch: https://git.openjdk.java.net/valhalla-docs/pull/8.diff
>   Fetch: git fetch https://git.openjdk.java.net/valhalla-docs pull/8/head:pull/8
>
> PR: https://git.openjdk.java.net/valhalla-docs/pull/8

From sadayapalam at openjdk.java.net  Tue Jan 25 10:20:37 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 25 Jan 2022 10:20:37 GMT
Subject: [lworld] RFR: 8280456: [lworld] javac should allow compilation with
 abstract java.lang.Object class
Message-ID: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>

- Warn on attempt to instantiate Object
    - If j.l.O is seen as abstract, don't complain about abstract class instantiation
    - Reroute instantiation to calls of java.util.Objects.newIdentity
    - Extend treatment to both constructor invocations and constructor references.

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

Commit messages:
 - 8280456: javac should allow compilation with abstract java.lang.Object class

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

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

From sadayapalam at openjdk.java.net  Tue Jan 25 10:20:37 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 25 Jan 2022 10:20:37 GMT
Subject: [lworld] RFR: 8280456: [lworld] javac should allow compilation
 with abstract java.lang.Object class
In-Reply-To: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>
References: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>
Message-ID: <_0jHk5Auu_UylAHb_iqX9KwL5uR8SmMqqh1sFNJxZS8=.a7f04f40-cc40-4680-8330-97436971b6ba@github.com>

On Tue, 25 Jan 2022 10:11:09 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> - Warn on attempt to instantiate Object
>     - If j.l.O is seen as abstract, don't complain about abstract class instantiation
>     - Reroute instantiation to calls of java.util.Objects.newIdentity
>     - Extend treatment to both constructor invocations and constructor references.

Notes for reviewer:

This is a follow up to JDK-8237073 - that fix by oversight did not include treatment of constructor references of the form (Object::new) - these need to be warned about and these also need to rerouted to java.util.Objects.newIdentity(). The present
fix does that.

The present fix in addition ensures that javac does not emit an error of the form:


ObjectTest.java:5: error: Object is abstract; cannot be instantiated
    Object o = new Object();


when the JDK changes to make Object abstract. 

Javac should not choke on existing code attempting instantiate object.

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

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

From thartmann at openjdk.java.net  Tue Jan 25 11:03:32 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 25 Jan 2022 11:03:32 GMT
Subject: [lworld] RFR: 8280524: [lworld] Interpreter incorrectly handles
 uninitialized static inline type field
Message-ID: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>

Code in the interpreter that's supposed to check if the type of a static, null-free inline type field is initialized assumes that `rcx` contains the `InlineKlass*`. However, `rcx` is only initialized for non-static fields:
https://github.com/openjdk/valhalla/blob/ba87b167f2fe2327508a06ec8652c6ddaa9402c1/src/hotspot/cpu/x86/templateTable_x86.cpp#L2939-L2943

As a result, the check spuriously fails, leading to an "impossible" NPE because the null value is not replaced by the default value. This patch also fixes an unrelated issue where an `instanceHandle` should be used instead of an `instanceOop`.

I found this with compiler stress testing and initially assumed that it is a compiler bug. The patch was contributed by @fparain.

Thanks,
Tobias

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

Commit messages:
 - 8280524: [lworld] Interpreter incorrectly handles uninitialized static inline type field

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

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

From thartmann at openjdk.java.net  Tue Jan 25 12:24:36 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 25 Jan 2022 12:24:36 GMT
Subject: git: openjdk/valhalla: lworld: 8280524: [lworld] Interpreter
 incorrectly handles uninitialized static inline type field
Message-ID: <8f9c07e0-02d4-4311-b24e-5b97903a4dfd@openjdk.org>

Changeset: 41147748
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2022-01-25 12:24:09 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/41147748dfb9f7c3db52b7798d92f2c90e1573b0

8280524: [lworld] Interpreter incorrectly handles uninitialized static inline type field

Co-authored-by: Frederic Parain <fparain at openjdk.org>
Reviewed-by: fparain

! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp


From fparain at openjdk.java.net  Tue Jan 25 12:24:46 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 25 Jan 2022 12:24:46 GMT
Subject: [lworld] RFR: 8280524: [lworld] Interpreter incorrectly handles
 uninitialized static inline type field
In-Reply-To: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>
References: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>
Message-ID: <QpRqPO_qkxRfTmpRmGGDD4g076p06P9nibUVfmZ4mF4=.85c0a8a3-f52b-4c8c-b56c-034aec0fc4bb@github.com>

On Tue, 25 Jan 2022 10:57:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Code in the interpreter that's supposed to check if the type of a static, null-free inline type field is initialized assumes that `rcx` contains the `InlineKlass*`. However, `rcx` is only initialized for non-static fields:
> https://github.com/openjdk/valhalla/blob/ba87b167f2fe2327508a06ec8652c6ddaa9402c1/src/hotspot/cpu/x86/templateTable_x86.cpp#L2939-L2943
> 
> As a result, the check spuriously fails, leading to an "impossible" NPE because the null value is not replaced by the default value. This patch also fixes an unrelated issue where an `instanceHandle` should be used instead of an `instanceOop`.
> 
> I found this with compiler stress testing and initially assumed that it is a compiler bug. The patch was contributed by @fparain.
> 
> Thanks,
> Tobias

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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

From thartmann at openjdk.java.net  Tue Jan 25 12:24:46 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 25 Jan 2022 12:24:46 GMT
Subject: [lworld] RFR: 8280524: [lworld] Interpreter incorrectly handles
 uninitialized static inline type field
In-Reply-To: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>
References: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>
Message-ID: <ZiYYR_VHdKKCgGRg3FNyWfXobBlO2J7tiYkrXW53aUw=.af1f7116-3281-4749-8f6d-6605262f3f5e@github.com>

On Tue, 25 Jan 2022 10:57:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Code in the interpreter that's supposed to check if the type of a static, null-free inline type field is initialized assumes that `rcx` contains the `InlineKlass*`. However, `rcx` is only initialized for non-static fields:
> https://github.com/openjdk/valhalla/blob/ba87b167f2fe2327508a06ec8652c6ddaa9402c1/src/hotspot/cpu/x86/templateTable_x86.cpp#L2939-L2943
> 
> As a result, the check spuriously fails, leading to an "impossible" NPE because the null value is not replaced by the default value. This patch also fixes an unrelated issue where an `instanceHandle` should be used instead of an `instanceOop`.
> 
> I found this with compiler stress testing and initially assumed that it is a compiler bug. The patch was contributed by @fparain.
> 
> Thanks,
> Tobias

Thanks, Fred!

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

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

From thartmann at openjdk.java.net  Tue Jan 25 12:27:50 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 25 Jan 2022 12:27:50 GMT
Subject: [lworld] Integrated: 8280524: [lworld] Interpreter incorrectly handles
 uninitialized static inline type field
In-Reply-To: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>
References: <_P2qNrEv-_r7Hz2GzNQaKIc25tfSL6mdS3Xv9n8cd-o=.8f516790-a007-435b-9fca-e156480c22de@github.com>
Message-ID: <QUzwRGs-twGYRm8Fct6TZ9vQa9IeCo-hqlkx4gNrbR0=.dda54f9b-88ef-4e6c-a984-b83de7751c5f@github.com>

On Tue, 25 Jan 2022 10:57:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Code in the interpreter that's supposed to check if the type of a static, null-free inline type field is initialized assumes that `rcx` contains the `InlineKlass*`. However, `rcx` is only initialized for non-static fields:
> https://github.com/openjdk/valhalla/blob/ba87b167f2fe2327508a06ec8652c6ddaa9402c1/src/hotspot/cpu/x86/templateTable_x86.cpp#L2939-L2943
> 
> As a result, the check spuriously fails, leading to an "impossible" NPE because the null value is not replaced by the default value. This patch also fixes an unrelated issue where an `instanceHandle` should be used instead of an `instanceOop`.
> 
> I found this with compiler stress testing and initially assumed that it is a compiler bug. The patch was contributed by @fparain.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8280524: [lworld] Interpreter incorrectly handles uninitialized static inline type field

Co-authored-by: Frederic Parain <fparain at openjdk.org>
Reviewed-by: fparain

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

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

From duke at openjdk.java.net  Tue Jan 25 15:21:50 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Tue, 25 Jan 2022 15:21:50 GMT
Subject: [lworld] RFR: 8280456: [lworld] javac should allow compilation
 with abstract java.lang.Object class
In-Reply-To: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>
References: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>
Message-ID: <RQKTrI4NnMVbVFBgw6-BGwCrEr3EtIbHZgOJnTyhX3s=.1490ce92-1f70-4ed6-afcc-fd270f4677b1@github.com>

On Tue, 25 Jan 2022 10:11:09 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> - Warn on attempt to instantiate Object
>     - If j.l.O is seen as abstract, don't complain about abstract class instantiation
>     - Reroute instantiation to calls of java.util.Objects.newIdentity
>     - Extend treatment to both constructor invocations and constructor references.

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

LGTM ??

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

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

From heidinga at openjdk.java.net  Tue Jan 25 21:11:19 2022
From: heidinga at openjdk.java.net (Dan Heidinga)
Date: Tue, 25 Jan 2022 21:11:19 GMT
Subject: [valhalla-docs] RFR: Minor grammatical fixes [v2]
In-Reply-To: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>
References: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>
Message-ID: <ttv6784TDdrddpSnw8gUOjv7GO5cO-vKZKjloTI5iRM=.72d7c21e-674e-43ad-a871-e0926a12fc71@github.com>

> Some minor grammatical changes and a adjusted wording to reflect that Q may be flattened but flatness isn't guaranteed.

Dan Heidinga has updated the pull request incrementally with one additional commit since the last revision:

  Add missing array '[' to descriptor

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

Changes:
  - all: https://git.openjdk.java.net/valhalla-docs/pull/8/files
  - new: https://git.openjdk.java.net/valhalla-docs/pull/8/files/2df9b8b1..f880d6b0

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

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

PR: https://git.openjdk.java.net/valhalla-docs/pull/8

From briangoetz at openjdk.java.net  Tue Jan 25 21:15:45 2022
From: briangoetz at openjdk.java.net (Brian Goetz)
Date: Tue, 25 Jan 2022 21:15:45 GMT
Subject: [valhalla-docs] Withdrawn: Minor grammatical fixes
In-Reply-To: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>
References: <GGt-VDcDszTau_99LBQxHcwO41SNC-VM-fgT46XRUHY=.baef069f-dcd5-4639-84b1-94b7d7a15bb8@github.com>
Message-ID: <NDkQOh5NK8B_mBMSWkm9ESaiNaYOYaweynl9FOkO-yM=.d221efbe-590b-4bb8-8270-e75f248b8992@github.com>

On Mon, 24 Jan 2022 19:39:58 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> Some minor grammatical changes and a adjusted wording to reflect that Q may be flattened but flatness isn't guaranteed.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/valhalla-docs/pull/8

From sadayapalam at openjdk.java.net  Wed Jan 26 00:35:03 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 26 Jan 2022 00:35:03 GMT
Subject: [lworld] Integrated: 8280456: [lworld] javac should allow compilation
 with abstract java.lang.Object class
In-Reply-To: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>
References: <nMWKWIR0rl6JXgVZeqH_qs4soVfphz5bULcRjc3mRcg=.12438183-fd59-44bb-b684-ddd5b78152a5@github.com>
Message-ID: <k1eTkLX7urzP_hqAcNOZJTbFsmEh_v12cnCm1aI67-4=.9c29ab14-75da-4b1b-9933-9a80650602ab@github.com>

On Tue, 25 Jan 2022 10:11:09 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> - Warn on attempt to instantiate Object
>     - If j.l.O is seen as abstract, don't complain about abstract class instantiation
>     - Reroute instantiation to calls of java.util.Objects.newIdentity
>     - Extend treatment to both constructor invocations and constructor references.

This pull request has now been integrated.

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

8280456: [lworld] javac should allow compilation with abstract java.lang.Object class

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

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

From dsimms at openjdk.java.net  Wed Jan 26 10:05:18 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 26 Jan 2022 10:05:18 GMT
Subject: [lworld] RFR: 8280704: [lworld] Rename defaultvalue to aconst_init in
 tests
Message-ID: <cqGuGoTeqYqUQGyauLwLCUkOUTdDGCfUOTV5lTmFEjk=.f783b5e6-fe71-4916-b4c9-56af1d6bb351@github.com>

Renamed defaultvalue to aconst_init

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

Commit messages:
 - Renamed defaultvalue to aconst_init

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

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

From fparain at openjdk.java.net  Wed Jan 26 14:01:08 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 26 Jan 2022 14:01:08 GMT
Subject: [lworld] RFR: 8280704: [lworld] Rename defaultvalue to aconst_init
 in tests
In-Reply-To: <cqGuGoTeqYqUQGyauLwLCUkOUTdDGCfUOTV5lTmFEjk=.f783b5e6-fe71-4916-b4c9-56af1d6bb351@github.com>
References: <cqGuGoTeqYqUQGyauLwLCUkOUTdDGCfUOTV5lTmFEjk=.f783b5e6-fe71-4916-b4c9-56af1d6bb351@github.com>
Message-ID: <UfGkUcLQ5iPxKqdkIgZNUEUsrsK8kppESDZKPMhCETo=.326da2bf-d81b-4a6c-90e9-47dd70fdabfd@github.com>

On Wed, 26 Jan 2022 10:00:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Renamed defaultvalue to aconst_init

LGTM

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

Marked as reviewed by fparain (Committer).

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

From dsimms at openjdk.java.net  Wed Jan 26 14:11:02 2022
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 26 Jan 2022 14:11:02 GMT
Subject: [lworld] Integrated: 8280704: [lworld] Rename defaultvalue to
 aconst_init in tests
In-Reply-To: <cqGuGoTeqYqUQGyauLwLCUkOUTdDGCfUOTV5lTmFEjk=.f783b5e6-fe71-4916-b4c9-56af1d6bb351@github.com>
References: <cqGuGoTeqYqUQGyauLwLCUkOUTdDGCfUOTV5lTmFEjk=.f783b5e6-fe71-4916-b4c9-56af1d6bb351@github.com>
Message-ID: <UsvPLdCTq1f3yV2YeAA7nmQ8lbB07x_mf3U7OosqPb0=.6307e3dc-1fd8-43b9-84c4-850a453c7fe6@github.com>

On Wed, 26 Jan 2022 10:00:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Renamed defaultvalue to aconst_init

This pull request has now been integrated.

Changeset: 0c1345f8
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0c1345f88372fbf64a76b86c50ea5bd52556d1e6
Stats:     31 lines in 12 files changed: 0 ins; 0 del; 31 mod

8280704: [lworld] Rename defaultvalue to aconst_init in tests

Reviewed-by: fparain

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

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

From mchung at openjdk.java.net  Wed Jan 26 21:15:13 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 26 Jan 2022 21:15:13 GMT
Subject: [lworld] RFR: 8280746: [lworld] Initial core libraries support for
 value classes
Message-ID: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>

This is an initial core libraries patch to support value classes; in particular it will get the bootstrap methods for the substitutability test and the default implementation of hashCode to work so that it enables further testing and development to continue.   Only small number of new tests are added in this patch.  More update and new tests will continue via JDK-8280603.

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

Commit messages:
 - 8280746: [lworld] Initial core libraries update for value classes

Changes: https://git.openjdk.java.net/valhalla/pull/619/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=619&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280746
  Stats: 177 lines in 30 files changed: 88 ins; 3 del; 86 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/619.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/619/head:pull/619

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

From mchung at openjdk.java.net  Wed Jan 26 21:26:36 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 26 Jan 2022 21:26:36 GMT
Subject: [lworld] RFR: 8280746: [lworld] Initial core libraries support for
 value classes [v2]
In-Reply-To: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
References: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
Message-ID: <R_B7xvc8cua1Lz46vwKLIt65nvYnzseh6jeU_FKX4s0=.60574def-7b6e-42a8-a0ff-e13dcf14a25b@github.com>

> This is an initial core libraries patch to support value classes; in particular it will get the bootstrap methods for the substitutability test and the default implementation of hashCode to work so that it enables further testing and development to continue.   Only small number of new tests are added in this patch.  More update and new tests will continue via JDK-8280603.

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

  Rename the value class test method to Class::isValue

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/619/files
  - new: https://git.openjdk.java.net/valhalla/pull/619/files/fe66a30a..b4d953d8

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

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

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

From mchung at openjdk.java.net  Thu Jan 27 00:06:46 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 27 Jan 2022 00:06:46 GMT
Subject: [lworld] RFR: 8280746: [lworld] Initial core libraries support for
 value classes [v3]
In-Reply-To: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
References: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
Message-ID: <_r7hal7qYxtCmnR8WGlWxNUD4IQvW_BKFURq5sdLm_E=.6271e6a1-49cd-4b21-9e51-a04ff718ea0b@github.com>

> This is an initial core libraries patch to support value classes; in particular it will get the bootstrap methods for the substitutability test and the default implementation of hashCode to work so that it enables further testing and development to continue.   Only small number of new tests are added in this patch.  More update and new tests will continue via JDK-8280603.

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

  Fix test

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/619/files
  - new: https://git.openjdk.java.net/valhalla/pull/619/files/b4d953d8..b553a9b8

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

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

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

From thartmann at openjdk.java.net  Thu Jan 27 15:21:35 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 27 Jan 2022 15:21:35 GMT
Subject: [lworld] RFR: 8280707: [lworld] More issues with C2's arraycopy
 intrinsic
Message-ID: <NHTt8REqoJNMR7qPGiFDJirXH_9itVYXEl6oU11p5_w=.23321a82-1377-42a2-9809-f512c0df5aec@github.com>

The memory output of the `MemBarCPUOrder` node added to prevent writes into the source from floating below the arraycopy is not correctly wired. As a result, we hit an "dependence cycle found" assert in GCM. I also removed a comment in that code that was already removed from mainline.

In `TypeAryPtr::add_field_offset_and_offset` we set the wrong offset if the field is not found in a flat array (for example, because the inline type has no fields). This leads to an assert in the matcher due to an unexpected address type change.

Thanks,
Tobias

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

Commit messages:
 - 8280707: [lworld] More issues with C2's arraycopy intrinsic

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

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

From rriggs at openjdk.java.net  Thu Jan 27 16:44:08 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 27 Jan 2022 16:44:08 GMT
Subject: [lworld] RFR: 8280746: [lworld] Initial core libraries support for
 value classes [v3]
In-Reply-To: <_r7hal7qYxtCmnR8WGlWxNUD4IQvW_BKFURq5sdLm_E=.6271e6a1-49cd-4b21-9e51-a04ff718ea0b@github.com>
References: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
 <_r7hal7qYxtCmnR8WGlWxNUD4IQvW_BKFURq5sdLm_E=.6271e6a1-49cd-4b21-9e51-a04ff718ea0b@github.com>
Message-ID: <Eo5LJJgl2IvRmr9E8yq3xJo-XqS4dbDxh2iJSmtIeg0=.6dd47d20-615d-4553-869d-1c308e477934@github.com>

On Thu, 27 Jan 2022 00:06:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This is an initial core libraries patch to support value classes; in particular it will get the bootstrap methods for the substitutability test and the default implementation of hashCode to work so that it enables further testing and development to continue.   Only small number of new tests are added in this patch.  More update and new tests will continue via JDK-8280603.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

LGTM

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

Marked as reviewed by rriggs (Committer).

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

From mchung at openjdk.java.net  Thu Jan 27 16:46:18 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 27 Jan 2022 16:46:18 GMT
Subject: git: openjdk/valhalla: lworld: 8280746: [lworld] Initial core
 libraries support for value classes
Message-ID: <6fe47980-bc8a-4ff2-a8ae-b7cc3ef6fbb9@openjdk.org>

Changeset: 32e6ec4e
Author:    Mandy Chung <mchung at openjdk.org>
Date:      2022-01-27 16:45:44 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/32e6ec4e73b56d982819cc4e10218701cc11fb82

8280746: [lworld] Initial core libraries support for value classes

Reviewed-by: rriggs

! src/java.base/share/classes/java/io/ObjectOutputStream.java
! src/java.base/share/classes/java/io/ObjectStreamClass.java
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/IdentityObject.java
! src/java.base/share/classes/java/lang/ValueObject.java
! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java
! src/java.base/share/classes/java/lang/invoke/MemberName.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/VarHandles.java
! src/java.base/share/classes/java/lang/invoke/X-VarHandle.java.template
! src/java.base/share/classes/java/lang/ref/PhantomReference.java
! src/java.base/share/classes/java/lang/ref/Reference.java
! src/java.base/share/classes/java/lang/ref/SoftReference.java
! src/java.base/share/classes/java/lang/ref/WeakReference.java
! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
! src/java.base/share/classes/java/lang/runtime/PrimitiveObjectMethods.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java
! test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypeArray.java
! test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java
! test/jdk/valhalla/valuetypes/BasicTest.java
! test/jdk/valhalla/valuetypes/MethodHandleTest.java
! test/jdk/valhalla/valuetypes/SubstitutabilityTest.java
! test/jdk/valhalla/valuetypes/ValueArray.java
! test/jdk/valhalla/valuetypes/ValueConstantDesc.java
+ test/jdk/valhalla/valuetypes/ValueOptional.java


From mchung at openjdk.java.net  Thu Jan 27 16:50:03 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 27 Jan 2022 16:50:03 GMT
Subject: [lworld] Integrated: 8280746: [lworld] Initial core libraries support
 for value classes
In-Reply-To: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
References: <Pja83h7i8OO2IrPCgJISpszzveEmeROnl2UejCPKcPc=.e521628b-42f2-4028-b95d-21a492525c88@github.com>
Message-ID: <DtYqIGFYo6Pd6lXKV-GBMT5EHtB1RlUpSxwpiRqK7Tw=.181eb3ae-20c4-44ce-b21d-a4ec529e455c@github.com>

On Wed, 26 Jan 2022 21:07:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This is an initial core libraries patch to support value classes; in particular it will get the bootstrap methods for the substitutability test and the default implementation of hashCode to work so that it enables further testing and development to continue.   Only small number of new tests are added in this patch.  More update and new tests will continue via JDK-8280603.

This pull request has now been integrated.

Changeset: 32e6ec4e
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/32e6ec4e73b56d982819cc4e10218701cc11fb82
Stats:     177 lines in 30 files changed: 88 ins; 3 del; 86 mod

8280746: [lworld] Initial core libraries support for value classes

Reviewed-by: rriggs

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

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

From duke at openjdk.java.net  Thu Jan 27 19:30:56 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Thu, 27 Jan 2022 19:30:56 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support should
 evolve to work with value classes
Message-ID: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>

This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.

Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

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

Commit messages:
 - 8280382: [lworld] JCWithField AST node support should evolve to work with value classes

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 05:02:32 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 05:02:32 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <9YhZVxo8fNXJGIqfsIDGf-vs9kMySPcl18IUgwLt2eY=.cd4941cd-b137-42ac-95c7-214cc7fe4deb@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 3942:

> 3940: compiler.err.primitive.or.value.class.instance.field.expected.here=\
> 3941:     withfield operator requires an instance field of a primitive or a value class here
> 3942: 

This message is not in alignment with rest of diagnostics that ony speak of value classes. I suggest we amend this to 
compiler.err.value.class.instance.field.expected.here. I think it is very visible and open that every primitive class is a value class so it is not necessary to call out primitive or value class

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 05:06:40 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 05:06:40 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <BzJ3hRYfvlkUQjGkeNKn9JFGyvHq58g7vn96rFqWNcI=.b2a7bfd3-41dd-41e8-a7c3-256eb0c164e9@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

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

> 331:                 */
> 332:                 if (env.info.inWithField && v.getKind() == ElementKind.FIELD && (v.flags() & STATIC) == 0 && (v.owner.type.isPrimitiveClass() || v.owner.type.isValueClass())) {
> 333:                     if (env.enclClass.sym.outermostClass() == v.owner.outermostClass())

I suggest we fix all places where a check is being made for isPrimitiveClass() || isValueClass() to just check for isValueClass(). Every primitive class is also a value class so this check is redundant and also is not in alignment with other places where only isValueClass() check is being made. Thirdly and most importantly, we want to reach a state in the codebase where every check of isPrimitiveClass() is essential to triggering behavior that is unique to B3 classes. Any code controlled by isPrimitiveClass() must be specific for B3 classes. This will significantly improve code readability.

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 05:24:24 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 05:24:24 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

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

> 613:                     !t.hasTag(BOT) && isSubtype(t, s.referenceProjectionOrSelf());
> 614:         }
> 615: 

These changes are not necessary and in fact are incorrect. See that with this change, the following code does not compile anymore which it should.


public value class X {
    public static void main(String[] args) {
        X x = null;
    }
}


This triggers an error: 
X.java:3: error: incompatible types: <null> cannot be converted to X
        X x = null;
              ^

X being a B2 value class its instances are very much nullable.

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 05:29:35 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 05:29:35 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <1IX5crz4moJ5p7F5nlk-Wo3ZAjIqnuKYFRleQfVeBgE=.01fb9120-a6fc-483e-ae53-3a47bb68825f@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

test/langtools/tools/javac/valhalla/value-objects/WithFieldOperatorTest.java line 33:

> 31:             x = __WithField(x.x, 12.0); // float cannot be assigned to int
> 32:             x = __WithField(x.v, null); // null cannot be assigned to value
> 33:             return x;

Null can be assigned to value, so this line should not trigger an error

test/langtools/tools/javac/valhalla/value-objects/WithFieldOperatorTest.out line 9:

> 7: WithFieldOperatorTest.java:31:34: compiler.err.prob.found.req: (compiler.misc.possible.loss.of.precision: double, int)
> 8: WithFieldOperatorTest.java:32:34: compiler.err.prob.found.req: (compiler.misc.inconvertible.types: compiler.misc.type.null, WithFieldOperatorTest.V)
> 9: WithFieldOperatorTest.java:40:26: compiler.err.cant.assign.val.to.final.var: x

Error 8 should not be emitted

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 05:41:40 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 05:41:40 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <n7VNWFNRzPWJYcctILoZuo3iePE6JNwID-XeG604mUc=.24ff60c3-8ad7-4e8b-8b5f-bc1c50500168@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

I have indicated problem spots. Please incorporate the changes and update, Thanks!

test/langtools/tools/javac/valhalla/value-objects/FlattenableNegativeTest.java line 38:

> 36:         }
> 37:     }
> 38: }

For value classes, this is not a negative test. The test should compile fine.

test/langtools/tools/javac/valhalla/value-objects/FlattenableNegativeTest.out line 10:

> 8: FlattenableNegativeTest.java:33:25: compiler.err.prob.found.req: (compiler.misc.inconvertible.types: compiler.misc.type.null, FlattenableNegativeTest.V)
> 9: FlattenableNegativeTest.java:34:32: compiler.err.prob.found.req: (compiler.misc.inconvertible.types: compiler.misc.type.null, FlattenableNegativeTest.V)
> 10: 9 errors

None of these errors should be emitted, null is assignable to B2 instances.

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

Changes requested by sadayapalam (Committer).

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

From thartmann at openjdk.java.net  Fri Jan 28 07:01:40 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 28 Jan 2022 07:01:40 GMT
Subject: [lworld] Integrated: 8280707: [lworld] More issues with C2's arraycopy
 intrinsic
In-Reply-To: <NHTt8REqoJNMR7qPGiFDJirXH_9itVYXEl6oU11p5_w=.23321a82-1377-42a2-9809-f512c0df5aec@github.com>
References: <NHTt8REqoJNMR7qPGiFDJirXH_9itVYXEl6oU11p5_w=.23321a82-1377-42a2-9809-f512c0df5aec@github.com>
Message-ID: <R1RlNr9AjvT1ynaGIVLdKsin-qym2iMYfPh_c-jWcTg=.00518f9a-6f39-4535-89e2-618be89b9995@github.com>

On Thu, 27 Jan 2022 15:15:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The memory output of the `MemBarCPUOrder` node added to prevent writes into the source from floating below the arraycopy is not correctly wired. As a result, we hit an "dependence cycle found" assert in GCM. I also removed a comment in that code that was already removed from mainline.
> 
> In `TypeAryPtr::add_field_offset_and_offset` we set the wrong offset if the field is not found in a flat array (for example, because the inline type has no fields). This leads to an assert in the matcher due to an unexpected address type change.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 22b271d0
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/22b271d0b3db95f914b9f8abb9eeb04169c1e05a
Stats:     93 lines in 3 files changed: 75 ins; 14 del; 4 mod

8280707: [lworld] More issues with C2's arraycopy intrinsic

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 07:10:25 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 07:10:25 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <RzncxEM8jUOK6HFix-ED_ThU7gpMzoQ69dBuOpY44iw=.51b7b181-4cbf-4f35-94b2-352b871e9c28@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

Change value to primitive class instance in one test in lworld-values directory

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

Changes requested by sadayapalam (Committer).

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

From sadayapalam at openjdk.java.net  Fri Jan 28 07:10:26 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 07:10:26 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <1IX5crz4moJ5p7F5nlk-Wo3ZAjIqnuKYFRleQfVeBgE=.01fb9120-a6fc-483e-ae53-3a47bb68825f@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <1IX5crz4moJ5p7F5nlk-Wo3ZAjIqnuKYFRleQfVeBgE=.01fb9120-a6fc-483e-ae53-3a47bb68825f@github.com>
Message-ID: <RyFD2JxTGy4G7sMUzxjzwYdbUCFReKQfDNG0h7RiWSY=.acd68218-2838-42fb-ad8b-46f55987dba8@github.com>

On Fri, 28 Jan 2022 05:26:07 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
>> 
>> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?
>
> test/langtools/tools/javac/valhalla/value-objects/WithFieldOperatorTest.java line 33:
> 
>> 31:             x = __WithField(x.x, 12.0); // float cannot be assigned to int
>> 32:             x = __WithField(x.v, null); // null cannot be assigned to value
>> 33:             return x;
> 
> Null can be assigned to value, so this line should not trigger an error

Also this test in lworld-values directory should be amended to say "null cannot be assigned to primitive class instance" - it should not say value. Confusingly, at a distant past point, B3 classes used to be called value classes and hence this test refers to stale terminology

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

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

From duke at openjdk.java.net  Fri Jan 28 09:31:41 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 09:31:41 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>
Message-ID: <kdKVPlEgD8fFVX1-qpleTERAC43mX5ZAp7wJFrpZt68=.cd234d37-b3fa-4389-90b4-5a55a1b283ad@github.com>

On Fri, 28 Jan 2022 05:21:20 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
>> 
>> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 615:
> 
>> 613:                     !t.hasTag(BOT) && isSubtype(t, s.referenceProjectionOrSelf());
>> 614:         }
>> 615: 
> 
> These changes are not necessary and in fact are incorrect. See that with this change, the following code does not compile anymore which it should.
> 
> 
> public value class X {
>     public static void main(String[] args) {
>         X x = null;
>     }
> }
> 
> 
> This triggers an error: 
> X.java:3: error: incompatible types: <null> cannot be converted to X
>         X x = null;
>               ^
> 
> X being a B2 value class its instances are very much nullable.

You are right. The idea behind it was that I was getting a null reference exception on the subtype check. `t.referenceProjection()` was returning `null`  and it was blowing up on the `t.equalsIgnoreMetadata(s)`. The triggering code was something like the following (so the reference projection of `o`  was `null`).


value static final class V {}

Object o = V.default;


What do you think?

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 09:45:45 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 09:45:45 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <kdKVPlEgD8fFVX1-qpleTERAC43mX5ZAp7wJFrpZt68=.cd234d37-b3fa-4389-90b4-5a55a1b283ad@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>
 <kdKVPlEgD8fFVX1-qpleTERAC43mX5ZAp7wJFrpZt68=.cd234d37-b3fa-4389-90b4-5a55a1b283ad@github.com>
Message-ID: <AF8v3EYDvjrI2VhQY7Rex7PozmcgwjqZyiRTGmtayIQ=.57ad11ba-5708-4b84-9302-136145d550e9@github.com>

On Fri, 28 Jan 2022 09:28:29 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> You are right. The idea behind it was that I was getting a null reference exception on the subtype check. `t.referenceProjection()` was returning `null` and it was blowing up on the `t.equalsIgnoreMetadata(s)`. The triggering code was something like the following (so the reference projection of `o` was `null`).
> 
> ```
> value static final class V {}
> 
> Object o = V.default;
> ```
> 
> What do you think?

If this probem is still persisting, I suggest we raise a separate ticket for it. I don't know what is going on there, but can take a look and share observations on a separate task basis.

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

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

From duke at openjdk.java.net  Fri Jan 28 10:25:33 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 10:25:33 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <AF8v3EYDvjrI2VhQY7Rex7PozmcgwjqZyiRTGmtayIQ=.57ad11ba-5708-4b84-9302-136145d550e9@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>
 <kdKVPlEgD8fFVX1-qpleTERAC43mX5ZAp7wJFrpZt68=.cd234d37-b3fa-4389-90b4-5a55a1b283ad@github.com>
 <AF8v3EYDvjrI2VhQY7Rex7PozmcgwjqZyiRTGmtayIQ=.57ad11ba-5708-4b84-9302-136145d550e9@github.com>
Message-ID: <Ge_lEmPolQQyUsRbamrUBJYkU_igQ1zENHSsfA6UfWc=.b2b465b1-595b-438c-9463-849f729d6192@github.com>

On Fri, 28 Jan 2022 09:41:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> You are right. The idea behind it was that I was getting a null reference exception on the subtype check. `t.referenceProjection()` was returning `null`  and it was blowing up on the `t.equalsIgnoreMetadata(s)`. The triggering code was something like the following (so the reference projection of `o`  was `null`).
>> 
>> 
>> value static final class V {}
>> 
>> Object o = V.default;
>> 
>> 
>> What do you think?
>
>> You are right. The idea behind it was that I was getting a null reference exception on the subtype check. `t.referenceProjection()` was returning `null` and it was blowing up on the `t.equalsIgnoreMetadata(s)`. The triggering code was something like the following (so the reference projection of `o` was `null`).
>> 
>> ```
>> value static final class V {}
>> 
>> Object o = V.default;
>> ```
>> 
>> What do you think?
> 
> If this probem is still persisting, I suggest we raise a separate ticket for it. I don't know what is going on there, but can take a look and share observations on a separate task basis.

It was only introduced only after changing the lines 608 and 609 above, so it feels related to this change:

> https://github.com/openjdk/valhalla/pull/621/files/e0f302f20eacdbb796d03240b5b727ce053ed451#diff-244efd7111106b403c989b25a6d0c719dcb15d44892320cfdc6056a418defb21L608-L609

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

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

From duke at openjdk.java.net  Fri Jan 28 10:39:35 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 10:39:35 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <RzncxEM8jUOK6HFix-ED_ThU7gpMzoQ69dBuOpY44iw=.51b7b181-4cbf-4f35-94b2-352b871e9c28@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <RzncxEM8jUOK6HFix-ED_ThU7gpMzoQ69dBuOpY44iw=.51b7b181-4cbf-4f35-94b2-352b871e9c28@github.com>
Message-ID: <mnQbgei_TcybA8Qey_SbdoCVCoNKG2yTcSnUTiaSPdU=.33a33957-598e-43d9-ac30-27d421985761@github.com>

On Fri, 28 Jan 2022 07:06:51 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
>> 
>> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?
>
> Change value to primitive class instance in one test in lworld-values directory

Thanks for the review @sadayapalam! ??  will address the comments

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 11:54:26 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 11:54:26 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <Ge_lEmPolQQyUsRbamrUBJYkU_igQ1zENHSsfA6UfWc=.b2b465b1-595b-438c-9463-849f729d6192@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>
 <kdKVPlEgD8fFVX1-qpleTERAC43mX5ZAp7wJFrpZt68=.cd234d37-b3fa-4389-90b4-5a55a1b283ad@github.com>
 <AF8v3EYDvjrI2VhQY7Rex7PozmcgwjqZyiRTGmtayIQ=.57ad11ba-5708-4b84-9302-136145d550e9@github.com>
 <Ge_lEmPolQQyUsRbamrUBJYkU_igQ1zENHSsfA6UfWc=.b2b465b1-595b-438c-9463-849f729d6192@github.com>
Message-ID: <cfG38BLPNaPW5ORSL3lWm_qWM287SogbQMiF0LI18a4=.01f4ba7e-7e69-43a3-bed2-baee65a93cbd@github.com>

On Fri, 28 Jan 2022 10:19:52 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>>> You are right. The idea behind it was that I was getting a null reference exception on the subtype check. `t.referenceProjection()` was returning `null` and it was blowing up on the `t.equalsIgnoreMetadata(s)`. The triggering code was something like the following (so the reference projection of `o` was `null`).
>>> 
>>> ```
>>> value static final class V {}
>>> 
>>> Object o = V.default;
>>> ```
>>> 
>>> What do you think?
>> 
>> If this probem is still persisting, I suggest we raise a separate ticket for it. I don't know what is going on there, but can take a look and share observations on a separate task basis.
>
> It was only introduced only after changing the lines 608 and 609 above, so it feels related to this change:
> 
>> https://github.com/openjdk/valhalla/pull/621/files/e0f302f20eacdbb796d03240b5b727ce053ed451#diff-244efd7111106b403c989b25a6d0c719dcb15d44892320cfdc6056a418defb21L608-L609

But those lines need not change at all. The original code in com.sun.tools.javac.code.Types#isConvertible(com.sun.tools.javac.code.Type, com.sun.tools.javac.code.Type, com.sun.tools.javac.util.Warner) viz:

boolean tValue = t.isPrimitiveClass();
        boolean sValue = s.isPrimitiveClass();
        if (tValue != sValue) {
            return tValue ?
                    isSubtype(t.referenceProjection(), s) :
                    !t.hasTag(BOT) && isSubtype(t, s.referenceProjection());
        }

is necessitated by the fact that in the language model a primitive class is an island. Even though Point may be declared to be:

primitive class Point extends Object {}

asSuper(Point, Object) would return null meaning Point is not a subclass of Object. We bend over backwards maintaining this isolated world view of primitive classes to make it analogous to how int is not a subtype of Object, but is convertible to Integer which is a subtype of Object. Likewise Point is not a subtype of Object, but is convertible to Point.ref and Point.ref is a subtype of Object.

So is Point convertible to Object ? Yes, not because it is a subtype of Object, but because it can be converted to Point.ref and Point.ref is a subtype of Object.

This is the dance that is being done in the code above. This code should not and need not change at all for the present topic at hand.

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

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

From duke at openjdk.java.net  Fri Jan 28 12:49:40 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 12:49:40 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <BzJ3hRYfvlkUQjGkeNKn9JFGyvHq58g7vn96rFqWNcI=.b2a7bfd3-41dd-41e8-a7c3-256eb0c164e9@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <BzJ3hRYfvlkUQjGkeNKn9JFGyvHq58g7vn96rFqWNcI=.b2a7bfd3-41dd-41e8-a7c3-256eb0c164e9@github.com>
Message-ID: <fBk0tQVHQ6yQQBdOfLvEr6qj9YHljQy8kTiGgXQnr5I=.c8dba7ed-8773-4123-9a41-93ecb508eb59@github.com>

On Fri, 28 Jan 2022 05:02:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
>> 
>> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 333:
> 
>> 331:                 */
>> 332:                 if (env.info.inWithField && v.getKind() == ElementKind.FIELD && (v.flags() & STATIC) == 0 && (v.owner.type.isPrimitiveClass() || v.owner.type.isValueClass())) {
>> 333:                     if (env.enclClass.sym.outermostClass() == v.owner.outermostClass())
> 
> I suggest we fix all places where a check is being made for isPrimitiveClass() || isValueClass() to just check for isValueClass(). Every primitive class is also a value class so this check is redundant and also is not in alignment with other places where only isValueClass() check is being made. Thirdly and most importantly, we want to reach a state in the codebase where every check of isPrimitiveClass() is essential to triggering behavior that is unique to B3 classes. Any code controlled by isPrimitiveClass() must be specific for B3 classes. This will significantly improve code readability.

good remark, thx!

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

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

From duke at openjdk.java.net  Fri Jan 28 13:16:42 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 13:16:42 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes [v2]
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <bJbbfbk-5dtnnxYSznhXZ16brwlkbN3_74jkiBJIQMg=.71c20cca-af10-4c27-892f-128345334fcb@github.com>

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/621/files
  - new: https://git.openjdk.java.net/valhalla/pull/621/files/e0f302f2..5aa7e600

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

  Stats: 107 lines in 12 files changed: 38 ins; 49 del; 20 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/621.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/621/head:pull/621

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

From duke at openjdk.java.net  Fri Jan 28 13:16:44 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 13:16:44 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes [v2]
In-Reply-To: <cfG38BLPNaPW5ORSL3lWm_qWM287SogbQMiF0LI18a4=.01f4ba7e-7e69-43a3-bed2-baee65a93cbd@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <jLzU3UI-wBd5plnqOKpldK2Nald41ui0-mUiq7VfkJs=.a98c53e3-b84f-45e2-9b0c-bbb8f2d5d41f@github.com>
 <kdKVPlEgD8fFVX1-qpleTERAC43mX5ZAp7wJFrpZt68=.cd234d37-b3fa-4389-90b4-5a55a1b283ad@github.com>
 <AF8v3EYDvjrI2VhQY7Rex7PozmcgwjqZyiRTGmtayIQ=.57ad11ba-5708-4b84-9302-136145d550e9@github.com>
 <Ge_lEmPolQQyUsRbamrUBJYkU_igQ1zENHSsfA6UfWc=.b2b465b1-595b-438c-9463-849f729d6192@github.com>
 <cfG38BLPNaPW5ORSL3lWm_qWM287SogbQMiF0LI18a4=.01f4ba7e-7e69-43a3-bed2-baee65a93cbd@github.com>
Message-ID: <_FQeuUIqxtW9m7zLMxMWlukxW2vFpXvv-TXVNX4xSPw=.c925c83b-7a1d-4b33-9179-ad255891ff57@github.com>

On Fri, 28 Jan 2022 11:51:16 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> It was only introduced only after changing the lines 608 and 609 above, so it feels related to this change:
>> 
>>> https://github.com/openjdk/valhalla/pull/621/files/e0f302f20eacdbb796d03240b5b727ce053ed451#diff-244efd7111106b403c989b25a6d0c719dcb15d44892320cfdc6056a418defb21L608-L609
>
> But those lines need not change at all. The original code in com.sun.tools.javac.code.Types#isConvertible(com.sun.tools.javac.code.Type, com.sun.tools.javac.code.Type, com.sun.tools.javac.util.Warner) viz:
> 
> boolean tValue = t.isPrimitiveClass();
>         boolean sValue = s.isPrimitiveClass();
>         if (tValue != sValue) {
>             return tValue ?
>                     isSubtype(t.referenceProjection(), s) :
>                     !t.hasTag(BOT) && isSubtype(t, s.referenceProjection());
>         }
> 
> is necessitated by the fact that in the language model a primitive class is an island. Even though Point may be declared to be:
> 
> primitive class Point extends Object {}
> 
> asSuper(Point, Object) would return null meaning Point is not a subclass of Object. We bend over backwards maintaining this isolated world view of primitive classes to make it analogous to how int is not a subtype of Object, but is convertible to Integer which is a subtype of Object. Likewise Point is not a subtype of Object, but is convertible to Point.ref and Point.ref is a subtype of Object.
> 
> So is Point convertible to Object ? Yes, not because it is a subtype of Object, but because it can be converted to Point.ref and Point.ref is a subtype of Object.
> 
> This is the dance that is being done in the code above. This code should not and need not change at all for the present topic at hand.

You are right. I made it it work by rebuilding and reverting this change! Thanks for the detailed explanation as always ????????????

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

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

From sadayapalam at openjdk.java.net  Fri Jan 28 13:51:39 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 28 Jan 2022 13:51:39 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes [v2]
In-Reply-To: <bJbbfbk-5dtnnxYSznhXZ16brwlkbN3_74jkiBJIQMg=.71c20cca-af10-4c27-892f-128345334fcb@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <bJbbfbk-5dtnnxYSznhXZ16brwlkbN3_74jkiBJIQMg=.71c20cca-af10-4c27-892f-128345334fcb@github.com>
Message-ID: <7kI4SH2RcXz1XcRyWgDHiv15qgUdEyKhN4EDq7k88Ng=.5d056ca2-7004-40dd-8142-0f0840726724@github.com>

On Fri, 28 Jan 2022 13:16:42 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

>> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
>> 
>> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review

One change is requested, otherwise looks good. Please make this change and once the tests are known to be green, proceed to integrate, Thanks!

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

> 1333:             if (tree.init != null) {
> 1334:                 if ((v.flags_field & FINAL) == 0 || ((v.flags_field & STATIC) == 0 && (v.owner.isPrimitiveClass() || v.owner.isValueClass())) ||
> 1335:                     !memberEnter.needsLazyConstValue(tree.init)) {

There is still one instanceof isPrimitiveClass() || isValueClass() left in

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

Marked as reviewed by sadayapalam (Committer).

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

From duke at openjdk.java.net  Fri Jan 28 15:27:47 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 15:27:47 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes [v3]
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <20KRnqzz9kyTrI6QjHjFNzTFxy8DhMtTLT3MlES9lLQ=.21728f65-7a86-4a0e-ad78-6f66a515928c@github.com>

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

Aggelos Biboudis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Address review

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/621/files
  - new: https://git.openjdk.java.net/valhalla/pull/621/files/5aa7e600..30b9b62d

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

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

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

From duke at openjdk.java.net  Fri Jan 28 15:27:51 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 15:27:51 GMT
Subject: [lworld] RFR: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes [v2]
In-Reply-To: <7kI4SH2RcXz1XcRyWgDHiv15qgUdEyKhN4EDq7k88Ng=.5d056ca2-7004-40dd-8142-0f0840726724@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
 <bJbbfbk-5dtnnxYSznhXZ16brwlkbN3_74jkiBJIQMg=.71c20cca-af10-4c27-892f-128345334fcb@github.com>
 <7kI4SH2RcXz1XcRyWgDHiv15qgUdEyKhN4EDq7k88Ng=.5d056ca2-7004-40dd-8142-0f0840726724@github.com>
Message-ID: <Vrchd4qaws7xn0zASPWsgnzlS3ymifizIiekNAczNw0=.1b2d55d0-094e-4ba1-aa1e-e627b57a8977@github.com>

On Fri, 28 Jan 2022 13:47:08 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1335:
> 
>> 1333:             if (tree.init != null) {
>> 1334:                 if ((v.flags_field & FINAL) == 0 || ((v.flags_field & STATIC) == 0 && (v.owner.isPrimitiveClass() || v.owner.isValueClass())) ||
>> 1335:                     !memberEnter.needsLazyConstValue(tree.init)) {
> 
> There is still one instanceof isPrimitiveClass() || isValueClass() left in

Oups. Good catch.

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

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

From duke at openjdk.java.net  Fri Jan 28 15:46:37 2022
From: duke at openjdk.java.net (Aggelos Biboudis)
Date: Fri, 28 Jan 2022 15:46:37 GMT
Subject: [lworld] Integrated: 8280382: [lworld] JCWithField AST node support
 should evolve to work with value classes
In-Reply-To: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
References: <F5BbktX3HVMCdQ4Yl7jcoxoZFbh_CQxNZngyphpXUKU=.e1ef1153-526c-4745-baef-91c368675180@github.com>
Message-ID: <oL6-VDXz4Wf3B6QiVQK6RoZtIfpwTc2qflI1pTc83UM=.49d5bb21-fe1e-45d8-b18f-20d91b498628@github.com>

On Thu, 27 Jan 2022 19:24:47 GMT, Aggelos Biboudis <duke at openjdk.java.net> wrote:

> This PR ports basic `withField` tests from lworld-values to value-objects and extending some areas of code to support `withField` within value classes.
> 
> Nitpicking and a note: one of the error messages is now `compiler.err.primitive.or.value.class.instance.field.expected.here`. Would you propose to disambiguate further depending whether we are inside a `primitive` or a `value` class?

This pull request has now been integrated.

Changeset: d41022dc
Author:    Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Committer: Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d41022dc679bc275dd57ef8f2a1c9bf817d559d8
Stats:     597 lines in 18 files changed: 585 ins; 0 del; 12 mod

8280382: [lworld] JCWithField AST node support should evolve to work with value classes

Reviewed-by: sadayapalam

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

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

From sadayapalam at openjdk.java.net  Mon Jan 31 14:18:15 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 Jan 2022 14:18:15 GMT
Subject: [lworld] RFR: 8280194: Abstract classes that allow value
 subclasses should be marked ACC_PERMITS_VALUE (0x0040)
In-Reply-To: <6R7uyjsabNXiT2YljFGI3ohOzBDtOTIYMF-MdK6tncI=.4ff4eb00-4cdc-4123-887c-a827cc4dc35b@github.com>
References: <6R7uyjsabNXiT2YljFGI3ohOzBDtOTIYMF-MdK6tncI=.4ff4eb00-4cdc-4123-887c-a827cc4dc35b@github.com>
Message-ID: <sxbvEDn5_VkzM_gPwjfJhEk285Saty-AAcnl1KJzqjg=.dbb8f56f-bc8c-4f15-9f05-acf9ea757c42@github.com>

On Mon, 31 Jan 2022 14:08:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Mark abstract classes that qualify with ACC_PERMITS_VALUE flag.

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

> 2379:                             if ((s.flags() & (SYNCHRONIZED | STATIC)) == SYNCHRONIZED) {
> 2380:                                 return true;
> 2381:                             } else if (s.isConstructor()) {

This is a bug fix - static methods may be synchronized or not - immaterial.

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

> 1253:                     }
> 1254:                 }
> 1255: 

This is too late here. Now this is moved up to MemberEnter

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

> 1450:                 env.dup(tree, env.info.dup(env.info.scope.dupUnshared(fakeOwner)));
> 1451: 
> 1452:             if ((tree.flags & STATIC) != 0) localEnv.info.staticLevel++;

This is too late in Attr. This is now moved up.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 239:

> 237:             }
> 238:         }
> 239:     }

This used to happen in Attr, but that is too late. Pulled up to here now

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 265:

> 263:     }
> 264: 
> 265:     public void visitVarDef(JCVariableDecl tree) {

This used to happen in Attr, but that is too late. Pulled up to here now

test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerClassesInAnonymousClassTest.java line 63:

> 61:         setPrefix("class Anonymous { int f; } {new Anonymous() {");
> 62:         List<TestCase> sources = super.generateTestCases();
> 63: 

Hack to suppress ACC_PERMITS_VALUE bit from being set thereby causing the test to "fail"

test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerClassesInLocalClassTest.java line 56:

> 54:             sb.append(outerModifier.getString()).append(' ');
> 55:             sb.append("class Local { int f; ");
> 56:             Map<String, Set<String>> class2Flags = new HashMap<>();

Hack to suppress ACC_PERMITS_VALUE bit from being set thereby causing the test to "fail"

test/langtools/tools/javac/classfiles/attributes/innerclasses/InnerClassesTestBase.java line 300:

> 298:                 sb.append(String.format("%s A%d { %s %s}\n", innerClassType, count, instField, privateConstructor));
> 299:                 Set<String> flags = getFlags(innerClassType, innerMod);
> 300:                 class2Flags.put("A" + count, flags);

Hacks to suppress ACC_PERMITS_VALUE bit from being set thereby causing the test to "fail"

test/langtools/tools/javac/processing/rounds/OverwriteBetweenCompilations.java line 26:

> 24: /*
> 25:  * @ignore
> 26:  * @test

This test fails and will be followed up via a separate ticket.

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

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

From sadayapalam at openjdk.java.net  Mon Jan 31 14:18:12 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 Jan 2022 14:18:12 GMT
Subject: [lworld] RFR: 8280194: Abstract classes that allow value subclasses
 should be marked ACC_PERMITS_VALUE (0x0040)
Message-ID: <6R7uyjsabNXiT2YljFGI3ohOzBDtOTIYMF-MdK6tncI=.4ff4eb00-4cdc-4123-887c-a827cc4dc35b@github.com>

Mark abstract classes that qualify with ACC_PERMITS_VALUE flag.

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

Commit messages:
 - 8280194: Abstract classes that allow value subclasses should be marked ACC_PERMITS_VALUE (0x0040)

Changes: https://git.openjdk.java.net/valhalla/pull/622/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=622&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280194
  Stats: 273 lines in 16 files changed: 228 ins; 10 del; 35 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/622.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/622/head:pull/622

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

From sadayapalam at openjdk.java.net  Mon Jan 31 15:11:39 2022
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 31 Jan 2022 15:11:39 GMT
Subject: [lworld] RFR: 8280194: Abstract classes that allow value
 subclasses should be marked ACC_PERMITS_VALUE (0x0040)
In-Reply-To: <6R7uyjsabNXiT2YljFGI3ohOzBDtOTIYMF-MdK6tncI=.4ff4eb00-4cdc-4123-887c-a827cc4dc35b@github.com>
References: <6R7uyjsabNXiT2YljFGI3ohOzBDtOTIYMF-MdK6tncI=.4ff4eb00-4cdc-4123-887c-a827cc4dc35b@github.com>
Message-ID: <6nxO8hYKOD6p3nqb9L6im57IyNfXG-PJdFm5S8KveuM=.55c0d31e-6a8e-4b51-b800-651466bb2725@github.com>

On Mon, 31 Jan 2022 14:08:59 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Mark abstract classes that qualify with ACC_PERMITS_VALUE flag.

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

> 1102:                 }
> 1103:             }
> 1104:         }

This is the most essential change - it piggy backs on existing code in Types.asSuper

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

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