From sadayapalam at openjdk.java.net  Tue Jun  1 08:10:54 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 1 Jun 2021 08:10:54 GMT
Subject: [lworld] Integrated: 8267910: [lworld] Javac fails to implicitly type
 abstract classes as implementing IdentityObject
Message-ID: <fLAv_kwv2XhWft9wLC_AKWdz_WIpQHVRoQEy5crsCZc=.48d63862-ce85-4c8a-b21b-a87917631e3a@github.com>

Align with deraft spec on implicit typing of abstract classes

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

Commit messages:
 - 8267910: Javac fails to implicitly type abstract classes as implementing IdentityObject

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

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


From sadayapalam at openjdk.java.net  Tue Jun  1 08:10:57 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 1 Jun 2021 08:10:57 GMT
Subject: [lworld] Integrated: 8267910: [lworld] Javac fails to implicitly type
 abstract classes as implementing IdentityObject
In-Reply-To: <fLAv_kwv2XhWft9wLC_AKWdz_WIpQHVRoQEy5crsCZc=.48d63862-ce85-4c8a-b21b-a87917631e3a@github.com>
References: <fLAv_kwv2XhWft9wLC_AKWdz_WIpQHVRoQEy5crsCZc=.48d63862-ce85-4c8a-b21b-a87917631e3a@github.com>
Message-ID: <vzNemO-EsmXKkxjSb9xa5GLqGZCE8F5a-uQ_RLPxYjI=.bfcba5b1-e8a0-4c5b-a918-d6fc3bece429@github.com>

On Tue, 1 Jun 2021 08:05:06 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Align with deraft spec on implicit typing of abstract classes

This pull request has now been integrated.

Changeset: b3b74d9d
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b3b74d9db732a6dd7bf28bc8492e5fb9d7b2c32a
Stats:     141 lines in 11 files changed: 119 ins; 7 del; 15 mod

8267910: [lworld] Javac fails to implicitly type abstract classes as implementing IdentityObject

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

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


From david.simms at oracle.com  Tue Jun  1 12:43:42 2021
From: david.simms at oracle.com (David Simms)
Date: Tue, 1 Jun 2021 14:43:42 +0200
Subject: Pull current jdk/jdk to lworld?
In-Reply-To: <b773cfea-7c09-7cae-fbee-b54fc229b803@redhat.com>
References: <b773cfea-7c09-7cae-fbee-b54fc229b803@redhat.com>
Message-ID: <99e98da4-4b06-3c1b-c58a-72774275b1b6@oracle.com>

On 2021-05-31 11:07, Aleksey Shipilev wrote:
> Hi,
>
> Could anyone pull current jdk/jdk to lworld? There are plenty of build 
> failures in current lworld that are fixed in mainline.
>
Out sick just now, probably after tagging on Thursday...



From shade at redhat.com  Tue Jun  1 14:41:15 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 1 Jun 2021 16:41:15 +0200
Subject: Pull current jdk/jdk to lworld?
In-Reply-To: <99e98da4-4b06-3c1b-c58a-72774275b1b6@oracle.com>
References: <b773cfea-7c09-7cae-fbee-b54fc229b803@redhat.com>
 <99e98da4-4b06-3c1b-c58a-72774275b1b6@oracle.com>
Message-ID: <f9c2e9f0-d7cb-c51e-1373-7886cb13dee8@redhat.com>

On 6/1/21 2:43 PM, David Simms wrote:
> On 2021-05-31 11:07, Aleksey Shipilev wrote:
>> Hi,
>>
>> Could anyone pull current jdk/jdk to lworld? There are plenty of build
>> failures in current lworld that are fixed in mainline.
>>
> Out sick just now, probably after tagging on Thursday...

Yeah, no problem.

-- 
Thanks,
-Aleksey



From mchung at openjdk.java.net  Thu Jun  3 04:06:17 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 3 Jun 2021 04:06:17 GMT
Subject: RFR: 8267948: [lword] Core reflection and method handles support for
 L/Q model
Message-ID: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>

This PR implements the primary (`ref`) mirror and secondary (`val`) mirror for primitive classes [1].   The following APIs returning `Class` return the primary mirror: 

`Object::getClass`
`Class::getClass`
`Class::forName`
`java.lang.reflect.Member::getDeclaringClass` (i.e. `Field`, `Method` and `Constructor`)

`Class::getName` and `Class::getSimpleName` return the same name for the `ref` and `val` mirror of a primitive class.  Therefore, Class.forName(type.getName()) will work if the type is either `ref` or `val` mirror.

`Class::getTypeName` returns `Foo.ref` if this `Class` is a primitive reference type.  (we will revisit this for reference-favoring primitive class.)

New proposed APIs: 
`Class::isPrimitiveClass` returns true for the `ref` and `val` mirror of a primitive class. 

`Class::isPrimaryType` returns true if this `Class` object represents the primary mirror
`Class::asPrimaryType` returns the primary type of this class or interface.
- An alternative I considered is `Class::isReferenceType` and `Class::asReferenceType` but they will have to specify the special case for primitive types which are not (yet) primitive classes.   I want to go with this initial patch to make progress for the prototype.  We will follow up the API discussion next.

`Class::isValueType` returns true if this `Class` object represents the primary mirror
`Class::asValueType` returns the primary type of this class or interface.

Several tests fail when running with -Xcomp which may depend on the second phase JIT support work (JDK-8267932) which depends on this work to make progress.

[1] https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md

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

Commit messages:
 - 8267948: [lword] Core reflection and method handles support for L/Q model

Changes: https://git.openjdk.java.net/valhalla/pull/436/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=436&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267948
  Stats: 768 lines in 47 files changed: 431 ins; 137 del; 200 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/436.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/436/head:pull/436

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


From fparain at openjdk.java.net  Fri Jun  4 12:16:16 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 4 Jun 2021 12:16:16 GMT
Subject: RFR: 8267948: [lword] Core reflection and method handles support
 for L/Q model
In-Reply-To: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
References: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
Message-ID: <5mOdIwbs95EEuuraavrsWEpq9nANPaHj-a6VJaK6Yes=.d68a0d8f-8c85-4fcb-8dda-978ccb3a9541@github.com>

On Thu, 3 Jun 2021 03:45:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR implements the primary (`ref`) mirror and secondary (`val`) mirror for primitive classes [1].   The following APIs returning `Class` return the primary mirror: 
> 
> `Object::getClass`
> `Class::getClass`
> `Class::forName`
> `java.lang.reflect.Member::getDeclaringClass` (i.e. `Field`, `Method` and `Constructor`)
> 
> `Class::getName` and `Class::getSimpleName` return the same name for the `ref` and `val` mirror of a primitive class.  Therefore, Class.forName(type.getName()) will work if the type is either `ref` or `val` mirror.
> 
> `Class::getTypeName` returns `Foo.ref` if this `Class` is a primitive reference type.  (we will revisit this for reference-favoring primitive class.)
> 
> New proposed APIs: 
> `Class::isPrimitiveClass` returns true for the `ref` and `val` mirror of a primitive class. 
> 
> `Class::isPrimaryType` returns true if this `Class` object represents the primary mirror
> `Class::asPrimaryType` returns the primary type of this class or interface.
> - An alternative I considered is `Class::isReferenceType` and `Class::asReferenceType` but they will have to specify the special case for primitive types which are not (yet) primitive classes.   I want to go with this initial patch to make progress for the prototype.  We will follow up the API discussion next.
> 
> `Class::isValueType` returns true if this `Class` object represents the primary mirror
> `Class::asValueType` returns the primary type of this class or interface.
> 
> Several tests fail when running with -Xcomp which may depend on the second phase JIT support work (JDK-8267932) which depends on this work to make progress.
> 
> [1] https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md

The runtime part looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From rriggs at openjdk.java.net  Sat Jun  5 18:43:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sat, 5 Jun 2021 18:43:18 GMT
Subject: RFR: 8267948: [lword] Core reflection and method handles support
 for L/Q model
In-Reply-To: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
References: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
Message-ID: <i2QH3S7i-r8UH7jUVjCGD4zqoUb97o8QK1fHCEvB4Ug=.cb884d22-bae4-4663-95e1-ad73b713891d@github.com>

On Thu, 3 Jun 2021 03:45:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR implements the primary (`ref`) mirror and secondary (`val`) mirror for primitive classes [1].   The following APIs returning `Class` return the primary mirror: 
> 
> `Object::getClass`
> `Class::getClass`
> `Class::forName`
> `java.lang.reflect.Member::getDeclaringClass` (i.e. `Field`, `Method` and `Constructor`)
> 
> `Class::getName` and `Class::getSimpleName` return the same name for the `ref` and `val` mirror of a primitive class.  Therefore, Class.forName(type.getName()) will work if the type is either `ref` or `val` mirror.
> 
> `Class::getTypeName` returns `Foo.ref` if this `Class` is a primitive reference type.  (we will revisit this for reference-favoring primitive class.)
> 
> New proposed APIs: 
> `Class::isPrimitiveClass` returns true for the `ref` and `val` mirror of a primitive class. 
> 
> `Class::isPrimaryType` returns true if this `Class` object represents the primary mirror
> `Class::asPrimaryType` returns the primary type of this class or interface.
> - An alternative I considered is `Class::isReferenceType` and `Class::asReferenceType` but they will have to specify the special case for primitive types which are not (yet) primitive classes.   I want to go with this initial patch to make progress for the prototype.  We will follow up the API discussion next.
> 
> `Class::isValueType` returns true if this `Class` object represents the primary mirror
> `Class::asValueType` returns the primary type of this class or interface.
> 
> Several tests fail when running with -Xcomp which may depend on the second phase JIT support work (JDK-8267932) which depends on this work to make progress.
> 
> [1] https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md

Generally looks ok.
I think there will be confusion between Class.isPrimitive() and Class.isPrimitiveClass()
but that's the way it is.

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

Marked as reviewed by rriggs (Committer).

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


From mchung at openjdk.java.net  Mon Jun  7 16:20:40 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 7 Jun 2021 16:20:40 GMT
Subject: Integrated: 8267948: [lword] Core reflection and method handles
 support for L/Q model
In-Reply-To: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
References: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
Message-ID: <VrrsuQ1PUtKZnj_i4HMHdLuKmJwj_H3N0_gUMvwjl-E=.02da5c3d-235e-4a27-a191-e31ed32b5f67@github.com>

On Thu, 3 Jun 2021 03:45:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR implements the primary (`ref`) mirror and secondary (`val`) mirror for primitive classes [1].   The following APIs returning `Class` return the primary mirror: 
> 
> `Object::getClass`
> `Class::getClass`
> `Class::forName`
> `java.lang.reflect.Member::getDeclaringClass` (i.e. `Field`, `Method` and `Constructor`)
> 
> `Class::getName` and `Class::getSimpleName` return the same name for the `ref` and `val` mirror of a primitive class.  Therefore, Class.forName(type.getName()) will work if the type is either `ref` or `val` mirror.
> 
> `Class::getTypeName` returns `Foo.ref` if this `Class` is a primitive reference type.  (we will revisit this for reference-favoring primitive class.)
> 
> New proposed APIs: 
> `Class::isPrimitiveClass` returns true for the `ref` and `val` mirror of a primitive class. 
> 
> `Class::isPrimaryType` returns true if this `Class` object represents the primary mirror
> `Class::asPrimaryType` returns the primary type of this class or interface.
> - An alternative I considered is `Class::isReferenceType` and `Class::asReferenceType` but they will have to specify the special case for primitive types which are not (yet) primitive classes.   I want to go with this initial patch to make progress for the prototype.  We will follow up the API discussion next.
> 
> `Class::isValueType` returns true if this `Class` object represents the primary mirror
> `Class::asValueType` returns the primary type of this class or interface.
> 
> Several tests fail when running with -Xcomp which may depend on the second phase JIT support work (JDK-8267932) which depends on this work to make progress.
> 
> [1] https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md

This pull request has now been integrated.

Changeset: d9d96e8c
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d9d96e8c8df1546a9930fba89a081c10b1a52349
Stats:     768 lines in 47 files changed: 431 ins; 137 del; 200 mod

8267948: [lword] Core reflection and method handles support for L/Q model

Reviewed-by: fparain, rriggs

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

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


From mchung at openjdk.java.net  Mon Jun  7 16:53:34 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 7 Jun 2021 16:53:34 GMT
Subject: RFR: 8267948: [lword] Core reflection and method handles support
 for L/Q model
In-Reply-To: <i2QH3S7i-r8UH7jUVjCGD4zqoUb97o8QK1fHCEvB4Ug=.cb884d22-bae4-4663-95e1-ad73b713891d@github.com>
References: <UxNGDlSJqWlGGQxVmwjOY_FQwIhgsCEkOxhbftBx6Rg=.e630ac00-969d-4051-86ce-a1e422983769@github.com>
 <i2QH3S7i-r8UH7jUVjCGD4zqoUb97o8QK1fHCEvB4Ug=.cb884d22-bae4-4663-95e1-ad73b713891d@github.com>
Message-ID: <-mh6Q_rF7dZlSgbJxMiw4LaFxJap6j5Y8RK9pa1Hs58=.0bb6de9d-aa98-46ac-9838-aa55c1a62aad@github.com>

On Sat, 5 Jun 2021 18:40:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Generally looks ok.

Thanks Roger.

> I think there will be confusion between Class.isPrimitive() and Class.isPrimitiveClass()
> but that's the way it is.

It probably becomes not so much of an issue when JEP 402 is in.

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

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


From fparain at openjdk.java.net  Tue Jun  8 13:24:49 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 8 Jun 2021 13:24:49 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model
Message-ID: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>

Fix all but one test to pass with the new L/Q model and the new core reflection.
The failing test, TestIntrinsics.java might be a real VM bug and not a test bug, but it is C2 related.

Fred

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

Commit messages:
 - Fix tests to use new L/Q model and new core reflection

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

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


From hseigel at openjdk.java.net  Tue Jun  8 13:48:31 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Jun 2021 13:48:31 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model
In-Reply-To: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
Message-ID: <SNI_K56cVP863i6rhl6d3QvHfK3kUgpZed10Cb2RBKw=.ba208e5a-01dd-4433-bf5d-b0b7be5bb63d@github.com>

On Tue, 8 Jun 2021 13:17:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix all but one test to pass with the new L/Q model and the new core reflection.
> The failing test, TestIntrinsics.java might be a real VM bug and not a test bug, but it is C2 related.
> 
> Fred

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

> 73:         Asserts.assertTrue(test1(MyValue1.class, MyValue1.class), "test1_2 failed");
> 74:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_3 failed");
> 75:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_4 failed");

should the first MyValue1.class.asValueType() in line 75 be MyValue1.class (to match MyValue1.ref.class) ?

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

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


From fparain at openjdk.java.net  Tue Jun  8 14:36:37 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 8 Jun 2021 14:36:37 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model
In-Reply-To: <SNI_K56cVP863i6rhl6d3QvHfK3kUgpZed10Cb2RBKw=.ba208e5a-01dd-4433-bf5d-b0b7be5bb63d@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
 <SNI_K56cVP863i6rhl6d3QvHfK3kUgpZed10Cb2RBKw=.ba208e5a-01dd-4433-bf5d-b0b7be5bb63d@github.com>
Message-ID: <B5ppvWlG7XjORIC3GEAJAYZCOhctzofBCNo5NyXlaHg=.bd04ec8b-1976-4c42-a450-aa2f77e3e07a@github.com>

On Tue, 8 Jun 2021 13:45:52 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Fix all but one test to pass with the new L/Q model and the new core reflection.
>> The failing test, TestIntrinsics.java might be a real VM bug and not a test bug, but it is C2 related.
>> 
>> Fred
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 75:
> 
>> 73:         Asserts.assertTrue(test1(MyValue1.class, MyValue1.class), "test1_2 failed");
>> 74:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_3 failed");
>> 75:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_4 failed");
> 
> should the first MyValue1.class.asValueType() in line 75 be MyValue1.class (to match MyValue1.ref.class) ?

MyValue1.class.asValueType() and MyValue1.class are different (secondary mirror vs primary mirror), so changing from MyValue1.class.asValueType() to MyValue1.class would make this line to fail.
However, this line has not been fixed properly (it accidentally duplicates line 74).
Now, I think the right way to fix it is:

Asserts.assertFalse(test1(MyValue1.class, MyValue.class.asValueType()), "test1_4 failed");

The test has to be inverted from assertTrue to assertFalse to verify that the two mirrors are distinct.

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

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


From fparain at openjdk.java.net  Tue Jun  8 15:09:58 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 8 Jun 2021 15:09:58 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model [v2]
In-Reply-To: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
Message-ID: <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>

> Fix all but one test to pass with the new L/Q model and the new core reflection.
> The failing test, TestIntrinsics.java might be a real VM bug and not a test bug, but it is C2 related.
> 
> Fred

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

  Fix TestIntrinsics.java line 75

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/437/files
  - new: https://git.openjdk.java.net/valhalla/pull/437/files/88153ead..a5abb91b

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

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

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


From hseigel at openjdk.java.net  Tue Jun  8 15:30:29 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Jun 2021 15:30:29 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model [v2]
In-Reply-To: <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
 <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>
Message-ID: <SIsqjp9vhWaMhefgO2PpSCgkN5a5pbVqaHH2Ttr4EXY=.06b59b62-d662-44d9-a094-453dd3ee8f89@github.com>

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

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

The changes look good!
Thanks, Harold

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

Marked as reviewed by hseigel (Committer).

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


From fparain at openjdk.java.net  Tue Jun  8 15:30:30 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 8 Jun 2021 15:30:30 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model [v2]
In-Reply-To: <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
 <E5QvPzUSIDr_AvDNbT3uEqZzmRL5Iu-_rgC4RvQqYmM=.b2983a59-6802-4de5-aaa9-2e9cdcb8970a@github.com>
Message-ID: <3c51syIJVdNwSIHXkXP4TgH1R5TJb6vqaMdIBuNwg2Q=.fbecc737-13b2-422a-82fe-224dc844f9a0@github.com>

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

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

Harold,

Thank you for the review and for spotting the bad fix.

Fred

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

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


From fparain at openjdk.java.net  Tue Jun  8 15:30:30 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 8 Jun 2021 15:30:30 GMT
Subject: Integrated: 8268389: [lworld] Tests must be update after core
 reflection changes for the L/Q model
In-Reply-To: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
Message-ID: <jiOxtKs71drFWufEd6BZIic3jRhX33n5-YvBGLARNUQ=.18e131fa-c436-4d98-bc6c-97425fbb13f9@github.com>

On Tue, 8 Jun 2021 13:17:20 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix all but one test to pass with the new L/Q model and the new core reflection.
> The failing test, TestIntrinsics.java might be a real VM bug and not a test bug, but it is C2 related.
> 
> Fred

This pull request has now been integrated.

Changeset: 8807adf6
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8807adf609ebf2a35c2b334ef2574354b10d4090
Stats:     78 lines in 5 files changed: 0 ins; 0 del; 78 mod

8268389: [lworld] Tests must be update after core reflection changes for the L/Q model

Reviewed-by: hseigel

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

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


From mchung at openjdk.java.net  Tue Jun  8 17:15:26 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Jun 2021 17:15:26 GMT
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model [v2]
In-Reply-To: <B5ppvWlG7XjORIC3GEAJAYZCOhctzofBCNo5NyXlaHg=.bd04ec8b-1976-4c42-a450-aa2f77e3e07a@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
 <SNI_K56cVP863i6rhl6d3QvHfK3kUgpZed10Cb2RBKw=.ba208e5a-01dd-4433-bf5d-b0b7be5bb63d@github.com>
 <B5ppvWlG7XjORIC3GEAJAYZCOhctzofBCNo5NyXlaHg=.bd04ec8b-1976-4c42-a450-aa2f77e3e07a@github.com>
Message-ID: <OuRdQGLC3sTMsQZK2jofdB1F2Fp8XxkvBfmm6C1nkc4=.4474a75d-89e3-48b8-97c8-68e309901d0c@github.com>

On Tue, 8 Jun 2021 14:33:51 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 75:
>> 
>>> 73:         Asserts.assertTrue(test1(MyValue1.class, MyValue1.class), "test1_2 failed");
>>> 74:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_3 failed");
>>> 75:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_4 failed");
>> 
>> should the first MyValue1.class.asValueType() in line 75 be MyValue1.class (to match MyValue1.ref.class) ?
>
> MyValue1.class.asValueType() and MyValue1.class are different (secondary mirror vs primary mirror), so changing from MyValue1.class.asValueType() to MyValue1.class would make this line to fail.
> However, this line has not been fixed properly (it accidentally duplicates line 74).
> Now, I think the right way to fix it is:
> 
> Asserts.assertFalse(test1(MyValue1.class, MyValue.class.asValueType()), "test1_4 failed");
> 
> The test has to be inverted from assertTrue to assertFalse to verify that the two mirrors are distinct.

In fact `MyValue1.class` == `ldc QMyValue1;` and `MyValue1.class` and `MyValue1.class.asValueType()` are the secondary mirror.  `MyValue1.ref.class` is the primary mirror.

AFAIU, these tests fail in -Xcomp mode (pass in -Xint mode) as it's awaiting for the JIT phase 2 support (JDK-8267932) which is blocked by the core reflection support.

Would disabling -Xcomp run from these tests be a better temporay fix until JDK-8267932?

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

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


From frederic.parain at oracle.com  Tue Jun  8 18:04:57 2021
From: frederic.parain at oracle.com (Frederic Parain)
Date: Tue, 8 Jun 2021 18:04:57 +0000
Subject: RFR: 8268389: [lworld] Tests must be update after core reflection
 changes for the L/Q model [v2]
In-Reply-To: <OuRdQGLC3sTMsQZK2jofdB1F2Fp8XxkvBfmm6C1nkc4=.4474a75d-89e3-48b8-97c8-68e309901d0c@github.com>
References: <kANd7O6qTdb4AjL4mMBvj5zLIv8bur8bAyaX4JjzlW8=.d6c711d9-bcb8-4555-ac9e-65bf710331fb@github.com>
 <SNI_K56cVP863i6rhl6d3QvHfK3kUgpZed10Cb2RBKw=.ba208e5a-01dd-4433-bf5d-b0b7be5bb63d@github.com>
 <B5ppvWlG7XjORIC3GEAJAYZCOhctzofBCNo5NyXlaHg=.bd04ec8b-1976-4c42-a450-aa2f77e3e07a@github.com>
 <OuRdQGLC3sTMsQZK2jofdB1F2Fp8XxkvBfmm6C1nkc4=.4474a75d-89e3-48b8-97c8-68e309901d0c@github.com>
Message-ID: <D0D145E2-FF50-4699-BB40-16C98BF0F76B@oracle.com>



> On Jun 8, 2021, at 1:15 PM, Mandy Chung <mchung at openjdk.java.net> wrote:
> 
> On Tue, 8 Jun 2021 14:33:51 GMT, Frederic Parain <fparain at openjdk.org> wrote:
> 
>>> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java line 75:
>>> 
>>>> 73:         Asserts.assertTrue(test1(MyValue1.class, MyValue1.class), "test1_2 failed");
>>>> 74:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_3 failed");
>>>> 75:         Asserts.assertTrue(test1(MyValue1.class.asValueType(), MyValue1.class.asValueType()), "test1_4 failed");
>>> 
>>> should the first MyValue1.class.asValueType() in line 75 be MyValue1.class (to match MyValue1.ref.class) ?
>> 
>> MyValue1.class.asValueType() and MyValue1.class are different (secondary mirror vs primary mirror), so changing from MyValue1.class.asValueType() to MyValue1.class would make this line to fail.
>> However, this line has not been fixed properly (it accidentally duplicates line 74).
>> Now, I think the right way to fix it is:
>> 
>> Asserts.assertFalse(test1(MyValue1.class, MyValue.class.asValueType()), "test1_4 failed");
>> 
>> The test has to be inverted from assertTrue to assertFalse to verify that the two mirrors are distinct.
> 
> In fact `MyValue1.class` == `ldc QMyValue1;` and `MyValue1.class` and `MyValue1.class.asValueType()` are the secondary mirror. `MyValue1.ref.class` is the primary mirror.


Mandy,

Thank you for the clarification. Many of the changes are in fact incorrect(invalid changes from x.ref.class to x.class).
I was confused because getClass() always returns the primary mirror and .class returns either the primary or the secondary (I should have known that because I reviewed your code implementing this).
I?ll back out this changeset and re-do it correctly.

Fred


> 
> AFAIU, these tests fail in -Xcomp mode (pass in -Xint mode) as it's awaiting for the JIT phase 2 support (JDK-8267932) which is blocked by the core reflection support.
> 
> Would disabling -Xcomp run from these tests be a better temporay fix until JDK-8267932?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/valhalla/pull/437


From mchung at openjdk.java.net  Tue Jun  8 20:06:44 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Jun 2021 20:06:44 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash`
Message-ID: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>

`Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

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

Commit messages:
 - 8268358: [lworld] toString for primitive class should return `ClassName at hash`

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

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


From rriggs at openjdk.java.net  Tue Jun  8 20:37:29 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 8 Jun 2021 20:37:29 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash`
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <M69xDflYtoWHKe1G7eXo24ohjGoDRaGpc6RCVoSbByU=.969b0978-23b1-441c-a06a-0e8b4c08df4f@github.com>

On Tue, 8 Jun 2021 19:55:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

If the hashcode of a primitive class uses the normal multiply and add technique,
values may still be leaked because the algorithm is predictable and can be replicated.
Perhaps with a secure hash...

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

Marked as reviewed by rriggs (Committer).

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


From mchung at openjdk.java.net  Tue Jun  8 21:13:29 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Jun 2021 21:13:29 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash`
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <91I1rTkYgkd2TzupufQgGa2BfaNvP2_DAoamM1Qj-ek=.d16926d3-3f73-48ab-b2fe-52439d12390e@github.com>

On Tue, 8 Jun 2021 19:55:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

This is the default implementation of `Object::toString`.   If one wants a class to use secure hash, they can override the `hashCode` method.

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

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


From fparain at openjdk.java.net  Wed Jun  9 12:18:49 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 9 Jun 2021 12:18:49 GMT
Subject: Integrated: 8268399: [BACKOUT] [lworld] Tests must be update after
 core reflection changes for the L/Q model
Message-ID: <2Lv8tO7UeMSS0qvQq2t6IQbNTTBnoeyt8wfY2ZxxkPo=.a63170d6-c82f-49db-a43d-7de0225c0016@github.com>

This reverts commit 8807adf609ebf2a35c2b334ef2574354b10d4090.

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

Commit messages:
 - [backout] 8268389: [lworld] Tests must be update after core reflection changes for the L/Q model

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

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


From fparain at openjdk.java.net  Wed Jun  9 12:18:49 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 9 Jun 2021 12:18:49 GMT
Subject: Integrated: 8268399: [BACKOUT] [lworld] Tests must be update after
 core reflection changes for the L/Q model
In-Reply-To: <2Lv8tO7UeMSS0qvQq2t6IQbNTTBnoeyt8wfY2ZxxkPo=.a63170d6-c82f-49db-a43d-7de0225c0016@github.com>
References: <2Lv8tO7UeMSS0qvQq2t6IQbNTTBnoeyt8wfY2ZxxkPo=.a63170d6-c82f-49db-a43d-7de0225c0016@github.com>
Message-ID: <DvxnO-uQ1dNoAFRRwq4gkRqe8FQPULucJuxNWiI-6Vw=.902c7270-aa40-41c0-8035-833754ebf9d6@github.com>

On Wed, 9 Jun 2021 12:10:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This reverts commit 8807adf609ebf2a35c2b334ef2574354b10d4090.

This pull request has now been integrated.

Changeset: 35520745
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/35520745eb62d7349569ab187137fd03307ff92c
Stats:     78 lines in 5 files changed: 0 ins; 0 del; 78 mod

8268399: [BACKOUT] [lworld] Tests must be update after core reflection changes for the L/Q model

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

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


From jrose at openjdk.java.net  Wed Jun  9 16:27:36 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 9 Jun 2021 16:27:36 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash`
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <BTFmR801j2CFo5LKbg5RmoJ7eqeptrloB4klq0LkR90=.b57b0394-2511-4c36-a62a-2cc5179f5747@github.com>

On Tue, 8 Jun 2021 19:55:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

I agree strongly with this change.  The correct
generalization to primitives of System.identityHashCode and
the hex number mentioned by Object.toString is not something
that looks like java.lang.Record field reports, but rather a
VM-chosen number, suitable for hash codes, and hard to
predict.

But, using the algorithm of Objects.hashCode should not be
the final word in producing the VM-chosen number.

(This is not the PR to change that, but this is a very good
moment to make the point.)

We should use a variable (salted) hash code, so that people
will not rely on the presence of the `31*x+` hashcode.  It
would be an own-goal if we locked ourselves forever into a
new use of that weak and leaky algorithm.

(The `31*x+` hash code computes a weighted checksum of
`Sum[i] x[L-i]*(31**i)`, truncated to 32 bits.  It is very
prone to collisions, especially when neighboring x?s are
linearly related.  A better hash code would (a) be more
resistant to simple collisions and (b) would tend to have
all bits of output depend on all bits of input.)

At a bare minimum, the JVM should configure a constant
random 32-bit ?salt? at startup time, and xor that number
into the computation of the primitive hash code in such a
way that the output (for one object) is unguessable.

That is not secure (nor am I expecting this) since after you
hash a few thousand test objects you can reverse-engineer
the constants.  But adding the randomness _now_ would give
us the ability to tune the algorithm _going forward_.

Note that the JVM?s identity hash code is configurable and
relatively unpredictable [1].

[1]:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/synchronizer.cpp#L828

We could make the same true of the built-in primitive hash
code.  The key step would be replacing the `31*x+` step with
a step that uses a larger state (at least 64 bits) and
better mixing (at least another shift and xor).

The cost of such upgrades is negligible.  The Marsaglia
register used for identity hash code is 128 bits (a good
size) and each hash step uses four xor operations to produce
one 32-bit value.

A different use of a similar register could consume about 64
bits of primitive field material for each step.  More steps
for smaller chunks of field material would improve mixing at
a growing CPU cost.  A little parametric salt could be added
either at the beginning or during hash steps.  All such
options could be configured at VM startup time, as with
object identity hash codes.

(I think, in the future, using a couple iterations of the
hardware AES instruction, or a 64-bit multiply, might be
slightly more performant with better mixing, but that's a
reseach project for later, and in any case produces more
bits than would be useful to a 32-bit result.)

Again: None of the above suggestions are cryptographic; they
can all be reversed straightforwardly.  But they are all
superior to the legacy `31*x+` hash code, and (crucially) if
we adopt a variable (salted) scheme, we can evolve the
algorithm.  If we use a fixed algorithm, we are stuck with
it forever.

And `31*x+`, as a fixed algorithm, is about the worst
choice.  We are stuck with it for java.lang.String.  We
don?t need _new_ uses of it.

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

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


From mchung at openjdk.java.net  Wed Jun  9 17:08:40 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 9 Jun 2021 17:08:40 GMT
Subject: RFR: 8268418: [lworld] VM assert illegal mirror klass when calling
 Class::getInterfaces on a flat array
Message-ID: <4lVkbwRKevXaxL8oKAJUybXImab0veQd-NQjBtbEF3M=.17c79f1e-7bf2-4614-9e60-6b5d5ddcdd3f@github.com>

Fix the assert in `JVM_GetClassInterfaces` to check for flat array.

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

Commit messages:
 - 8268418: [lworld] VM assert illegal mirror klass when calling Class::getInterfaces on a flat array

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

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


From fparain at openjdk.java.net  Wed Jun  9 17:32:32 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 9 Jun 2021 17:32:32 GMT
Subject: RFR: 8268418: [lworld] VM assert illegal mirror klass when
 calling Class::getInterfaces on a flat array
In-Reply-To: <4lVkbwRKevXaxL8oKAJUybXImab0veQd-NQjBtbEF3M=.17c79f1e-7bf2-4614-9e60-6b5d5ddcdd3f@github.com>
References: <4lVkbwRKevXaxL8oKAJUybXImab0veQd-NQjBtbEF3M=.17c79f1e-7bf2-4614-9e60-6b5d5ddcdd3f@github.com>
Message-ID: <o0jpvsbxtddcaMMZ4Z-eGoK4lUZqJpjns3_SPsQNhtU=.146f121f-5d0f-4231-b23e-076b1f64dc51@github.com>

On Wed, 9 Jun 2021 17:03:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Fix the assert in `JVM_GetClassInterfaces` to check for flat array.

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From mchung at openjdk.java.net  Wed Jun  9 17:43:24 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 9 Jun 2021 17:43:24 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash`
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <zMANNNvEcIamRdbO5EhBLfY_e7SHq38YBonZ47mOMxw=.2d868c4e-874d-4cbd-b231-9b0342e94e8b@github.com>

On Tue, 8 Jun 2021 19:55:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

This reminds me [JDK-8201462](https://bugs.openjdk.java.net/browse/JDK-8201462).

FWIW the current implementation already adds the randomness to
the hash code computation with a constant random 32-bit ?salt? 
configured at startup but it still carries the `31*x+` pattern which 
should be cleaned up.

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

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


From mchung at openjdk.java.net  Wed Jun  9 17:45:33 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 9 Jun 2021 17:45:33 GMT
Subject: Integrated: 8268418: [lworld] VM assert illegal mirror klass when
 calling Class::getInterfaces on a flat array
In-Reply-To: <4lVkbwRKevXaxL8oKAJUybXImab0veQd-NQjBtbEF3M=.17c79f1e-7bf2-4614-9e60-6b5d5ddcdd3f@github.com>
References: <4lVkbwRKevXaxL8oKAJUybXImab0veQd-NQjBtbEF3M=.17c79f1e-7bf2-4614-9e60-6b5d5ddcdd3f@github.com>
Message-ID: <vTgDh-rcI3CZpX93p24ZeDpLymLl6I6EF6n2HU0zikw=.e94699e9-07c4-4d8a-9661-78dd710d26ea@github.com>

On Wed, 9 Jun 2021 17:03:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Fix the assert in `JVM_GetClassInterfaces` to check for flat array.

This pull request has now been integrated.

Changeset: 31e99673
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/31e99673a1fcb6c6a60205db4cc2366efb49f217
Stats:     33 lines in 2 files changed: 32 ins; 0 del; 1 mod

8268418: [lworld] VM assert illegal mirror klass when calling Class::getInterfaces on a flat array

Reviewed-by: fparain

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

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


From john.r.rose at oracle.com  Wed Jun  9 18:40:02 2021
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 9 Jun 2021 18:40:02 +0000
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash`
In-Reply-To: <zMANNNvEcIamRdbO5EhBLfY_e7SHq38YBonZ47mOMxw=.2d868c4e-874d-4cbd-b231-9b0342e94e8b@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
 <zMANNNvEcIamRdbO5EhBLfY_e7SHq38YBonZ47mOMxw=.2d868c4e-874d-4cbd-b231-9b0342e94e8b@github.com>
Message-ID: <FFB52F6E-EC84-4F2E-885E-27543C7730DB@oracle.com>

On Jun 9, 2021, at 10:43 AM, Mandy Chung <mchung at openjdk.java.net<mailto:mchung at openjdk.java.net>> wrote:

On Tue, 8 Jun 2021 19:55:46 GMT, Mandy Chung <mchung at openjdk.org<mailto:mchung at openjdk.org>> wrote:

`Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

This reminds me [JDK-8201462](https://bugs.openjdk.java.net/browse/JDK-8201462).

Yes.  That is a larger brain dump.  My comments
on this thread are hopefully narrower and more
actionable.

FWIW the current implementation already adds the randomness to
the hash code computation with a constant random 32-bit ?salt?
configured at startup but it still carries the `31*x+` pattern which
should be cleaned up.

I didn?t know that; good!  Flexibility for the
future my main concern right now.


From sadayapalam at openjdk.java.net  Thu Jun 10 12:05:51 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 10 Jun 2021 12:05:51 GMT
Subject: Integrated: 8267597: [lworld] Withdraw all support for bifurcated
 class generation for primitive classes
In-Reply-To: <CoQn06X2UmJI_KtmPGCOMdBc8YzSxhqAQZdZNXAZkT4=.e0cd2de6-c15f-4c5e-8185-2f5235aae45d@github.com>
References: <CoQn06X2UmJI_KtmPGCOMdBc8YzSxhqAQZdZNXAZkT4=.e0cd2de6-c15f-4c5e-8185-2f5235aae45d@github.com>
Message-ID: <4o40k8zfZk1XnwWNrl0kLAzoc208UkJErAY0equajA0=.0a502f2a-41d4-4046-9453-2e98226b043c@github.com>

On Thu, 10 Jun 2021 11:57:32 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Adjust code generation and tests to the new unified world view

This pull request has now been integrated.

Changeset: d23562e4
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/d23562e422f2660c80b8a225d3d31aa1effb64de
Stats:     805 lines in 27 files changed: 3 ins; 738 del; 64 mod

8267597: [lworld] Withdraw all support for bifurcated class generation for primitive classes
8268527: [lqagain] langtool tests need tweaks to run properly in an universe where -XDunifiedValRefClass is the default

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

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


From sadayapalam at openjdk.java.net  Thu Jun 10 12:05:50 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 10 Jun 2021 12:05:50 GMT
Subject: Integrated: 8267597: [lworld] Withdraw all support for bifurcated
 class generation for primitive classes
Message-ID: <CoQn06X2UmJI_KtmPGCOMdBc8YzSxhqAQZdZNXAZkT4=.e0cd2de6-c15f-4c5e-8185-2f5235aae45d@github.com>

Adjust code generation and tests to the new unified world view

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

Commit messages:
 - 8267597: Withdraw all support for bifurcated class generation for primitive classes

Changes: https://git.openjdk.java.net/valhalla/pull/441/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=441&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267597
  Stats: 805 lines in 27 files changed: 3 ins; 738 del; 64 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/441.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/441/head:pull/441

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


From fparain at openjdk.java.net  Thu Jun 10 13:07:42 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 10 Jun 2021 13:07:42 GMT
Subject: RFR: 8268553: [lworld] CI must return secondary mirror when accessing
 CONSTANT_Class with Q-signature
Message-ID: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>

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

Thank you,

Fred

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

Commit messages:
 - Add secondary mirror support to CI

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

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


From mchung at openjdk.java.net  Thu Jun 10 22:37:19 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 10 Jun 2021 22:37:19 GMT
Subject: RFR: 8268553: [lworld] CI must return secondary mirror when
 accessing CONSTANT_Class with Q-signature
In-Reply-To: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
References: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
Message-ID: <Kbv_3Ez5u3SKsY1_26SpBrv5I9kns9Z_4uqCvcwTpts=.23a40657-6b7a-40a3-a143-3c05a5057e0b@github.com>

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

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

It looks right to me.

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

Marked as reviewed by mchung (Committer).

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


From mchung at openjdk.java.net  Fri Jun 11 01:03:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 11 Jun 2021 01:03:27 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash` [v2]
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <sM8fTPQdIu2jt7Sp0hqDXrLQYzk5iuKoy1wmvYQGr9o=.0c5a76c0-a8e8-4428-8865-641d62c743ff@github.com>

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

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

 - Merge branch 'lqagain' of https://github.com/openjdk/valhalla into substitutable
 - 8268358: [lworld] toString for primitive class should return `ClassName at hash`

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

Changes: https://git.openjdk.java.net/valhalla/pull/438/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=438&range=01
  Stats: 191 lines in 22 files changed: 13 ins; 143 del; 35 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/438.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/438/head:pull/438

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


From sadayapalam at openjdk.java.net  Fri Jun 11 07:07:27 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 11 Jun 2021 07:07:27 GMT
Subject: Integrated: 8268584: [lqagain] Javac tests should not needlessly
 hardcode toString() output
In-Reply-To: <8tu6TfuDhom8z7St9vsIMBF6ieYVmx8tiYUEEY_nXA8=.ed8ac042-239b-4361-b378-ffdb0e9bd73e@github.com>
References: <8tu6TfuDhom8z7St9vsIMBF6ieYVmx8tiYUEEY_nXA8=.ed8ac042-239b-4361-b378-ffdb0e9bd73e@github.com>
Message-ID: <K4kZLRbsbDeXe2TJ9MXGHh-7wHsJLl0PI7-In-Ylj70=.98080254-605f-4392-84ad-15e187a49e3f@github.com>

On Fri, 11 Jun 2021 06:52:05 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Modify javac tests to not use textual comparisons of primitive object state as a means of verifying behavior

This pull request has now been integrated.

Changeset: 64ec4ecf
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/64ec4ecfd42c5e005d44948efbd119081b44896b
Stats:     24 lines in 11 files changed: 0 ins; 1 del; 23 mod

8268584: [lqagain] Javac tests should not needlessly hardcode toString() output

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

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


From sadayapalam at openjdk.java.net  Fri Jun 11 07:07:26 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Fri, 11 Jun 2021 07:07:26 GMT
Subject: Integrated: 8268584: [lqagain] Javac tests should not needlessly
 hardcode toString() output
Message-ID: <8tu6TfuDhom8z7St9vsIMBF6ieYVmx8tiYUEEY_nXA8=.ed8ac042-239b-4361-b378-ffdb0e9bd73e@github.com>

Modify javac tests to not use textual comparisons of primitive object state as a means of verifying behavior

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

Commit messages:
 - Fix white space problem
 - 8268584: Javac tests should not needlessly hardcode toString() output

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

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


From mchung at openjdk.java.net  Fri Jun 11 21:39:26 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 11 Jun 2021 21:39:26 GMT
Subject: RFR: 8268358: [lworld] toString for primitive class should return
 `ClassName@hash` [v3]
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <hdzECMILc-66omVBvDSBgoNcM0JoXAp59SD_iu3uP2k=.4973ac34-7e8d-4968-82d6-9bf5192477b1@github.com>

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'lqagain' of https://github.com/openjdk/valhalla into substitutable
 - Merge branch 'lqagain' of https://github.com/openjdk/valhalla into substitutable
 - 8268358: [lworld] toString for primitive class should return `ClassName at hash`

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

Changes: https://git.openjdk.java.net/valhalla/pull/438/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=438&range=02
  Stats: 170 lines in 12 files changed: 7 ins; 143 del; 20 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/438.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/438/head:pull/438

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


From mchung at openjdk.java.net  Fri Jun 11 22:45:14 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 11 Jun 2021 22:45:14 GMT
Subject: Integrated: 8268358: [lworld] toString for primitive class should
 return `ClassName@hash`
In-Reply-To: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
References: <kGfWsFnb8E_hBcWLpPEwltHsE_5dwOLSXL6V6NxIMzc=.1a561288-1401-49d1-937a-ef4bb0cca651@github.com>
Message-ID: <fI3unhQB4sEE6nRkhHzv5gWEeOzEbmFqAXsjZGxEh1I=.714705e6-71dd-4124-9cb8-e41f62bfc5b0@github.com>

On Tue, 8 Jun 2021 19:55:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `Object::toString` implementation of a primitive class should return the traditional `ClassName at hash` (rather than listing the field values) not to leak any private and security-sensitive information.   A primitive class can override `toString` implementation for their custom string representation.

This pull request has now been integrated.

Changeset: 569dd54b
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/569dd54b777029d8e4b4687d2db6d57f111111a6
Stats:     170 lines in 12 files changed: 7 ins; 143 del; 20 mod

8268358: [lworld] toString for primitive class should return `ClassName at hash`

Reviewed-by: rriggs

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

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


From shade at redhat.com  Mon Jun 14 08:12:18 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 14 Jun 2021 10:12:18 +0200
Subject: Pull current jdk/jdk to lworld?
In-Reply-To: <f9c2e9f0-d7cb-c51e-1373-7886cb13dee8@redhat.com>
References: <b773cfea-7c09-7cae-fbee-b54fc229b803@redhat.com>
 <99e98da4-4b06-3c1b-c58a-72774275b1b6@oracle.com>
 <f9c2e9f0-d7cb-c51e-1373-7886cb13dee8@redhat.com>
Message-ID: <a3849c64-7ae3-d53a-c4b5-4e0fab2c95d3@redhat.com>

On 6/1/21 4:41 PM, Aleksey Shipilev wrote:
> On 6/1/21 2:43 PM, David Simms wrote:
>> On 2021-05-31 11:07, Aleksey Shipilev wrote:
>>> Hi,
>>>
>>> Could anyone pull current jdk/jdk to lworld? There are plenty of build
>>> failures in current lworld that are fixed in mainline.
>>>
>> Out sick just now, probably after tagging on Thursday...
> 
> Yeah, no problem.

This still did not happen, right?

-- 
Thanks,
-Aleksey



From sadayapalam at openjdk.java.net  Mon Jun 14 08:16:37 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 14 Jun 2021 08:16:37 GMT
Subject: Integrated: 8268656: [lqagain] A few code chunks dealing with dual
 class scheme still left in
In-Reply-To: <GGV9peu1b5Yo_s_-i9MHaUK1DdxD8wMD8iRtCkv3-Ec=.0396b930-8bdf-4a53-8771-af55bd8a46db@github.com>
References: <GGV9peu1b5Yo_s_-i9MHaUK1DdxD8wMD8iRtCkv3-Ec=.0396b930-8bdf-4a53-8771-af55bd8a46db@github.com>
Message-ID: <inLfg0u0aiJHW7sNuU_43ZyY45357sNZrmdlir-X32M=.7519fc2b-4f5d-47a5-9d63-09a43e4e96de@github.com>

On Mon, 14 Jun 2021 08:08:19 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Remove lingering dead code.

This pull request has now been integrated.

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

8268656: [lqagain] A few code chunks dealing with dual class scheme still left in

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

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


From sadayapalam at openjdk.java.net  Mon Jun 14 08:16:35 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 14 Jun 2021 08:16:35 GMT
Subject: Integrated: 8268656: [lqagain] A few code chunks dealing with dual
 class scheme still left in
Message-ID: <GGV9peu1b5Yo_s_-i9MHaUK1DdxD8wMD8iRtCkv3-Ec=.0396b930-8bdf-4a53-8771-af55bd8a46db@github.com>

Remove lingering dead code.

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

Commit messages:
 - 8268656: [lqagain] A few code chunks dealing with dual class scheme still left in

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

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


From sadayapalam at openjdk.java.net  Mon Jun 14 11:45:44 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 14 Jun 2021 11:45:44 GMT
Subject: [lworld] RFR: 8268671: [lworld] Wrong code generated for
 PrimitiveClass.ref.default
Message-ID: <mXhgyKFqyCRKdP5jYWkq_mXmSbBdlYrli5F5dwuFoYg=.460e86c7-5382-42c9-9a10-9dcd62847623@github.com>

Lower X.ref.default using aconst_null

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

Commit messages:
 - Add test for JDK-8268671
 - 8268671: Wrong code generated for PrimitiveClass.ref.default

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

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


From jrose at openjdk.java.net  Mon Jun 14 20:59:52 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 14 Jun 2021 20:59:52 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
Message-ID: <AQ9AnVkQrAfS1ow_rGRPfusjJ8Bqge-6tE8eu9PTUUQ=.2e586554-8327-4e21-a541-8b90d90697cd@github.com>

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

Thank you for explaining to all of us about word-tearing, but that seems to be moot in the context of this PR.  This feature (`NonTearable`) is about *structure tearing*, which is a distinct concept.  Hence the different name, as you might have noticed.

There is also a reason for not using the term "atomic".  Indeed it was my preference, but Brian (as he can explain himself as well) has at least two good reasons for avoiding that term, and going with the new term `NonTearable` (as well as the underlying exposition about the *new* phenomenon of structure tearing).

(The term non-tearable is in fact closely synonymous with the term atomic, which literally means non-cuttable.)

A couple of reasons *not* to use "atomic" here:  First, the term is already taken, in the package `java.util.concurrent.atomic`, with classes like `AtomicInteger`.  Users would be faced with different `AtomicFoo` types, leading to needless pedagogical burden.  (It doesn't matter that a dozen JMM experts would be made happier by using a common term for a common underlying notion.)  Second, although you nicely propose `AtomicAccess` as a good and correct term, the basic meaning of Atomic, at the user level, is already *stronger* than atomic access:  It implies not only that structures won't tear, as longs and doubles can tear in Old Java, but also the word "atomic" implies some kind of state-to-state consistency, such as is provided by CAS or atomic add.  Yes, I see that "access" in "atomic access" is a clever way of backing away from state-to-state consistency claims, but it's too subtle.  A new term is needed for the weaker concept.

In other words, for API design, let's keep using the term Atomic for the stronger (more useful term) and NonTearable for the weaker idea of a atomic-for-single-acceses-only.  That's what you are seeing with the term "non-tearable", and what I hope you can also see with the development of the not-really-so-weird discussion of "structure tearing".

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

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


From jrose at openjdk.java.net  Mon Jun 14 21:39:19 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 14 Jun 2021 21:39:19 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
Message-ID: <KIEtQ8SB0uk-RNkm5rswZ5jiRNdP3gGTm1_k9wx6OBU=.8ab4df9d-0d6b-4793-a857-9da09c49a867@github.com>

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

src/java.base/share/classes/java/lang/AtomicAccess.java line 64:

> 62:  * If data integrity or security depends on proper construction,
> 63:  * the class should be declared as implementing {@code AtomicAccess}.
> 64:  *

This comment is useful, because it distinguishes non-tearable from the
de-facto standard notion (in the JDK) of "atomic", which pertains to
"compound operations".  Atomic compound operations relate multiple
states of a variable in a consistent sequence sequence.  This is a
strictly stronger notion than access atomicity or non-tearability.

I support adding such a comment here, but also note that its
presence in the PR is evidence that the type name should
*not* be changed to `AtomicAccess`, precisely because
users are likely to confuse *this new* use of atomic with
*existing old* uses, all of which imply the stronger concept.

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

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


From forax at univ-mlv.fr  Mon Jun 14 21:42:49 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 14 Jun 2021 23:42:49 +0200 (CEST)
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <AQ9AnVkQrAfS1ow_rGRPfusjJ8Bqge-6tE8eu9PTUUQ=.2e586554-8327-4e21-a541-8b90d90697cd@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
 <AQ9AnVkQrAfS1ow_rGRPfusjJ8Bqge-6tE8eu9PTUUQ=.2e586554-8327-4e21-a541-8b90d90697cd@github.com>
Message-ID: <988406655.746463.1623706969137.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "John R Rose" <jrose at openjdk.java.net>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Lundi 14 Juin 2021 22:59:52
> Objet: Re: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable" nomenclature to "access atomic" [v2]

> On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 
>>> Current Valhalla code has the experimental marker interface
>>> `java.lang.NonTearable`, which is actually about access atomicity. It makes
>>> weird claims about word tearing and out-of-thin air values.
>>> 
>>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This
>>> problem is sometimes known as word tearing, and on processors that cannot
>>> easily update a single byte in isolation some other approach will be
>>> required"._ That is, word tearing is when we cannot update the _narrow_ member
>>> without doing a _wider_ access, thus necessarily affecting the adjacent
>>> members. In Valhalla case, what we are dealing with is access atomicity: we
>>> sometimes cannot access the _wide_ member without doing a set of _narrower_
>>> accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs",
>>> not "word-tearing of double and longs".
>>> 
>>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values,
>>> which are not related here at all. OOTA are the beasts from the causality
>>> loops: those are values that were never written by normal execution of the
>>> program (i.e. speculative values). In Valhalla case, the writes that produce
>>> the broken hybrid are known and expected writes from the conflicting writers.
>>> 
>>> This nomenclature percolates to Valhalla VM code, so some change is needed there
>>> as well.
>>> 
>>> Additional testing:
>>>  - [x] `runtime/valhalla` tests
>>
>> Aleksey Shipilev has updated the pull request incrementally with one additional
>> commit since the last revision:
>> 
>>   Rename a few other tests
> 
> Thank you for explaining to all of us about word-tearing, but that seems to be
> moot in the context of this PR.  This feature (`NonTearable`) is about
> *structure tearing*, which is a distinct concept.  Hence the different name, as
> you might have noticed.
> 
> There is also a reason for not using the term "atomic".  Indeed it was my
> preference, but Brian (as he can explain himself as well) has at least two good
> reasons for avoiding that term, and going with the new term `NonTearable` (as
> well as the underlying exposition about the *new* phenomenon of structure
> tearing).
> 
> (The term non-tearable is in fact closely synonymous with the term atomic, which
> literally means non-cuttable.)

Another possible term is Indivisible.

R?mi


From jrose at openjdk.java.net  Mon Jun 14 21:42:52 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 14 Jun 2021 21:42:52 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
Message-ID: <2YwqywvJY-fAhXLYnT_c0RksKZ4rH9DG5kIks0a8Xg0=.8da5b065-707f-4fbe-a9c7-30cf1de19a20@github.com>

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

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

> 2082:           "(whitespace and commas separate names, "                         \
> 2083:           "and leading and trailing stars '*' are wildcards)")              \
> 2084:                                                                             \

Internally to the JVM, the term "atomic" is acceptable, as long as
in context it is correctly understood as *single-access* atomicity.
(Which it is.)  The product flag here is at the boundary between
the JVM internals and the end-user (who sets the JVM flag on
the command line).  At that point, it is better to use the external
term `NonTearable`, which (for pedagogical reasons, as explained
elsewhere) does not use the word "atomic" but rather a synonym.

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

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


From jrose at openjdk.java.net  Mon Jun 14 21:57:03 2021
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 14 Jun 2021 21:57:03 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
Message-ID: <SsVEfH8XjuxF7v4OwjZMazfgvfCMN3EWmIfIBmCyHBA=.db8cb711-2214-48ad-9777-55f6261cdf73@github.com>

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

Some of this PR is based on wrong-headed misunderstanding
of the term "structure tearing", and some is based on a difference
of opinion about what's best for the end-user.  The part I would
prefer to keep makes more clear the connections between
the existing "compound-atomic" APIs, all of which have `Atomic`
in their names, and the necessary new feature for multi-component
access atomicity, which should *not* have `Atomic` in its name.

Please reformulate to be less disruptive of existing decisions,
or change the decisions by persuasion.

It looks to me like the only useful change proposed here
is a reformulation of the trailing comment in NonTearable.java,
relating it more usefully to the Atomic ?  APIs.

A better exposition of "structure tearing" would be welcome too.
The discussion of transient vs. permanent failure is illuminating.

I think "out of thin air" is a useful description of what a programmer
sees on such a failure, since the structure as a whole was never
constructed by any thread.  I realize that it might distract someone
familiar with the JMM literature.  Perhaps a less confusing term
would be "a composite value never created by any thread", but
"out of thin air" (in scare quotes) seems descriptive to me at least.

The material point for the end user is that structure tearing can
lead to the appearance (temporary or permanent) of primitive
values which were never created by any thread.  Giving a way
to control that phenomenon ("out of thin air" structures, created
by races if not speculation) is the motivation for this feature.

Notice that this problem is new to primitive classes.  There is
no corresponding notion for identity classes which are
configured like primitives, and therefore have all final fields.
The JMM guarantees safe publication for those, which means
no rogue states are ever visible in *those* multi-component
structures.  But when multi-component primitives are inlined,
the JMM needs a *new* guarantee in the place of safe publication.
Non-tearability is the term we have chosen for this.

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

Changes requested by jrose (Committer).

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


From briangoetz at openjdk.java.net  Mon Jun 14 22:27:03 2021
From: briangoetz at openjdk.java.net (Brian Goetz)
Date: Mon, 14 Jun 2021 22:27:03 GMT
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
Message-ID: <flM_uRuQtgDmrDv0Wx13sSSSJFVXa_lic7z4PKzykQo=.d003c781-2a21-47b0-99b8-8c5f06e3d35a@github.com>

On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>> 
>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>> 
>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>> 
>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>> 
>> Additional testing:
>>  - [x] `runtime/valhalla` tests
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename a few other tests

I am not married to the term `non-tearable`, and happy to consider alternatives, but `atomic` is definitely a move in the wrong direction.  John outlined most of the arguments, but basically: atomicity, in the context of user-visible Java APIs, is generally reserved for describing atomicity of user-level mutative operations, including read-modify-write operations (e.g., CAS, incrementAndGet, etc.)  This is the A from "ACID".  (Our friends in the database community might call these operations _serialized_, but as that also means something else in Java, we won't call it that either.)   

So, happy to consider alternatives to non-tearable (it was just the best we came up with at the time), but I think `Atomic*` will definitely send the wrong message about what operations are atomic relative to each other.

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

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


From kirk.pepperdine at gmail.com  Mon Jun 14 23:28:47 2021
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Mon, 14 Jun 2021 16:28:47 -0700
Subject: [lworld] RFR: 8267763: [lworld][lw3] Change "non-tearable"
 nomenclature to "access atomic" [v2]
In-Reply-To: <flM_uRuQtgDmrDv0Wx13sSSSJFVXa_lic7z4PKzykQo=.d003c781-2a21-47b0-99b8-8c5f06e3d35a@github.com>
References: <FTa2gTZ2gr5toJJ5ZfCTFElcgd7fpYqZjb2-e_i0uyY=.3030e7a6-09d8-49c8-a56c-4019a9cd72c9@github.com>
 <44RHAIv5ngOMhc4fV4Icw9c0H3v_e1e6KuKFRh_-5tk=.73092596-aac3-4ba3-8baa-eb2e2f50f50f@github.com>
 <flM_uRuQtgDmrDv0Wx13sSSSJFVXa_lic7z4PKzykQo=.d003c781-2a21-47b0-99b8-8c5f06e3d35a@github.com>
Message-ID: <59A82E51-22D6-4774-9269-BE47D802390C@gmail.com>

Not that my vote counts but I didn?t find NonTearable to be all that terrible (pun intended). At first I was thinking primitive tearing but a wee bit of reading cleared that up. I did a little splunking about in the OED and nothing really stood out as being more appropriate or offered any where near the level of clarity that this name does.

Kind regards,
Kirk


> On Jun 14, 2021, at 3:27 PM, Brian Goetz <briangoetz at openjdk.java.net> wrote:
> 
> On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 
>>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>>> 
>>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>>> 
>>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>>> 
>>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>>> 
>>> Additional testing:
>>> - [x] `runtime/valhalla` tests
>> 
>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>  Rename a few other tests
> 
> I am not married to the term `non-tearable`, and happy to consider alternatives, but `atomic` is definitely a move in the wrong direction.  John outlined most of the arguments, but basically: atomicity, in the context of user-visible Java APIs, is generally reserved for describing atomicity of user-level mutative operations, including read-modify-write operations (e.g., CAS, incrementAndGet, etc.)  This is the A from "ACID".  (Our friends in the database community might call these operations _serialized_, but as that also means something else in Java, we won't call it that either.)   
> 
> So, happy to consider alternatives to non-tearable (it was just the best we came up with at the time), but I think `Atomic*` will definitely send the wrong message about what operations are atomic relative to each other.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/valhalla/pull/428



From kirk at kodewerk.com  Mon Jun 14 23:52:04 2021
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Mon, 14 Jun 2021 16:52:04 -0700
Subject: Change non-tearable nomenclature to access atomic
References: <202106142328.15ENSxkn173653@aserp3020.oracle.com>
Message-ID: <80924A5E-B91F-4C45-A8BA-87FF17294732@kodewerk.com>


> 
> 
> Not that my vote counts but I didn?t find NonTearable to be all that terrible (pun intended). At first I was thinking primitive tearing but a wee bit of reading cleared that up. I did a little splunking about in the OED and nothing really stood out as being more appropriate or offered any where near the level of clarity that this name does.
> 
> Kind regards,
> Kirk
> 
> 
>> On Jun 14, 2021, at 3:27 PM, Brian Goetz <briangoetz at openjdk.java.net> wrote:
>> 
>> On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> 
>>>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>>>> 
>>>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>>>> 
>>>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>>>> 
>>>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>>>> 
>>>> Additional testing:
>>>> - [x] `runtime/valhalla` tests
>>> 
>>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>>> 
>>> Rename a few other tests
>> 
>> I am not married to the term `non-tearable`, and happy to consider alternatives, but `atomic` is definitely a move in the wrong direction.  John outlined most of the arguments, but basically: atomicity, in the context of user-visible Java APIs, is generally reserved for describing atomicity of user-level mutative operations, including read-modify-write operations (e.g., CAS, incrementAndGet, etc.)  This is the A from "ACID".  (Our friends in the database community might call these operations _serialized_, but as that also means something else in Java, we won't call it that either.)   
>> 
>> So, happy to consider alternatives to non-tearable (it was just the best we came up with at the time), but I think `Atomic*` will definitely send the wrong message about what operations are atomic relative to each other.
>> 
>> -------------
>> 
>> PR: https://git.openjdk.java.net/valhalla/pull/428
> 
> 
> 



From jespersm at openjdk.java.net  Tue Jun 15 07:41:01 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 15 Jun 2021 07:41:01 GMT
Subject: [lworld] RFR: 8268671: [lworld] Wrong code generated for
 PrimitiveClass.ref.default
In-Reply-To: <mXhgyKFqyCRKdP5jYWkq_mXmSbBdlYrli5F5dwuFoYg=.460e86c7-5382-42c9-9a10-9dcd62847623@github.com>
References: <mXhgyKFqyCRKdP5jYWkq_mXmSbBdlYrli5F5dwuFoYg=.460e86c7-5382-42c9-9a10-9dcd62847623@github.com>
Message-ID: <jIa46O6im54qyebEsFug0GHUNViID0NId8Klnkwyp2E=.04307b59-3150-4b3b-bdb5-f134c15862d2@github.com>

On Mon, 14 Jun 2021 11:38:56 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Lower X.ref.default using aconst_null

Looks good to me!

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

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


From sadayapalam at openjdk.java.net  Tue Jun 15 07:47:09 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 15 Jun 2021 07:47:09 GMT
Subject: [lworld] Integrated: 8268671: [lworld] Wrong code generated for
 PrimitiveClass.ref.default
In-Reply-To: <mXhgyKFqyCRKdP5jYWkq_mXmSbBdlYrli5F5dwuFoYg=.460e86c7-5382-42c9-9a10-9dcd62847623@github.com>
References: <mXhgyKFqyCRKdP5jYWkq_mXmSbBdlYrli5F5dwuFoYg=.460e86c7-5382-42c9-9a10-9dcd62847623@github.com>
Message-ID: <K5dO5suEJ0PpzLPdork1Mze9Zb4Wp4JKlPbLjkmdHHg=.30fac12a-d710-4ee9-8038-5106db986ed2@github.com>

On Mon, 14 Jun 2021 11:38:56 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Lower X.ref.default using aconst_null

This pull request has now been integrated.

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

8268671: [lworld] Wrong code generated for PrimitiveClass.ref.default

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

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


From dl at cs.oswego.edu  Tue Jun 15 11:58:39 2021
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 15 Jun 2021 07:58:39 -0400
Subject: Change non-tearable nomenclature to access atomic
In-Reply-To: <80924A5E-B91F-4C45-A8BA-87FF17294732@kodewerk.com>
References: <202106142328.15ENSxkn173653@aserp3020.oracle.com>
 <80924A5E-B91F-4C45-A8BA-87FF17294732@kodewerk.com>
Message-ID: <9b107680-d84c-ee8a-2891-a81673851f96@cs.oswego.edu>

I have seen the term "Unitary" used in this context. Basically a synonym 
for atomic, but doesn't carry the conventional interpretation of 
necessarily supporting RMWs.

On 6/14/21 7:52 PM, Kirk Pepperdine wrote:
>>
>> Not that my vote counts but I didn?t find NonTearable to be all that terrible (pun intended). At first I was thinking primitive tearing but a wee bit of reading cleared that up. I did a little splunking about in the OED and nothing really stood out as being more appropriate or offered any where near the level of clarity that this name does.
>>
>> Kind regards,
>> Kirk
>>
>>
>>> On Jun 14, 2021, at 3:27 PM, Brian Goetz <briangoetz at openjdk.java.net> wrote:
>>>
>>> On Mon, 31 May 2021 09:36:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>>>
>>>>> Current Valhalla code has the experimental marker interface `java.lang.NonTearable`, which is actually about access atomicity. It makes weird claims about word tearing and out-of-thin air values.
>>>>>
>>>>> First, this is not word tearing. Word tearing, as defined by JLS 17.6 is: _"This problem is sometimes known as word tearing, and on processors that cannot easily update a single byte in isolation some other approach will be required"._ That is, word tearing is when we cannot update the _narrow_ member without doing a _wider_ access, thus necessarily affecting the adjacent members. In Valhalla case, what we are dealing with is access atomicity: we sometimes cannot access the _wide_ member without doing a set of _narrower_ accesses. This is why JLS 17.7 says "non-atomic treatment of double and longs", not "word-tearing of double and longs".
>>>>>
>>>>> Second, the docs for `j.l.NonTearable` mention "out-of-thin-air" (OOTA) values, which are not related here at all. OOTA are the beasts from the causality loops: those are values that were never written by normal execution of the program (i.e. speculative values). In Valhalla case, the writes that produce the broken hybrid are known and expected writes from the conflicting writers.
>>>>>
>>>>> This nomenclature percolates to Valhalla VM code, so some change is needed there as well.
>>>>>
>>>>> Additional testing:
>>>>> - [x] `runtime/valhalla` tests
>>>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>>>>
>>>> Rename a few other tests
>>> I am not married to the term `non-tearable`, and happy to consider alternatives, but `atomic` is definitely a move in the wrong direction.  John outlined most of the arguments, but basically: atomicity, in the context of user-visible Java APIs, is generally reserved for describing atomicity of user-level mutative operations, including read-modify-write operations (e.g., CAS, incrementAndGet, etc.)  This is the A from "ACID".  (Our friends in the database community might call these operations _serialized_, but as that also means something else in Java, we won't call it that either.)
>>>
>>> So, happy to consider alternatives to non-tearable (it was just the best we came up with at the time), but I think `Atomic*` will definitely send the wrong message about what operations are atomic relative to each other.
>>>
>>> -------------
>>>
>>> PR: https://git.openjdk.java.net/valhalla/pull/428
>>
>>


From dsimms at openjdk.java.net  Wed Jun 16 14:00:49 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 16 Jun 2021 14:00:49 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>

Includes
* Version flip fixes
* Dropped JDK-8267151, needs reimplementation bug
* Dropped 8266015, needs reimplementation bug

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

Commit messages:
 - Version flip fixes
 - Logical merge fixes for compilation
 - Merge tag 'jdk-18+1' into lworld_merge_jdk_18_1
 - 8267930: Refine code for loading hsdis library
 - 8268574: ProblemList tests failing due to UseBiasedLocking going away
 - 8267556: Enhance class paths check during runtime
 - 8267893: Improve jtreg test failure handler do get native/mixed stack traces for cores and live processes
 - 8268223: Problemlist vmTestbase/nsk/jdi/HiddenClass/events/events001.java
 - 8268539: several serviceability/sa tests should be run in driver mode
 - 8268361: Fix the infinite loop in next_line
 - ... and 560 more: https://git.openjdk.java.net/valhalla/compare/b3b74d9d...66799c4b

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

Changes: https://git.openjdk.java.net/valhalla/pull/446/files
  Stats: 619935 lines in 5433 files changed: 520658 ins; 77528 del; 21749 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/446.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/446/head:pull/446

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


From dsimms at openjdk.java.net  Wed Jun 16 14:18:41 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 16 Jun 2021 14:18:41 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>
References: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>
Message-ID: <g3kvaDhDT2xOJZHLOKU5aXXFX71rsH5KazjZ7rFsgSs=.fc2b2ad0-a0d8-4ca3-8d9c-14f1b3337223@github.com>

> Includes
> * Version flip fixes
> * Dropped JDK-8267151, needs reimplementation bug
> * Dropped 8266015, needs reimplementation bug

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

  Over-zealous with JavaThread for current thread

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/446/files
  - new: https://git.openjdk.java.net/valhalla/pull/446/files/66799c4b..cdbb5019

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

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

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


From dsimms at openjdk.java.net  Wed Jun 16 15:19:17 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 16 Jun 2021 15:19:17 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>
References: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>
Message-ID: <zD5wYvDG7YA_c8fgtBtVOBS7UouV7ReYGIC-GDZW5PU=.4542e851-da16-47cc-8642-22d1a522f099@github.com>

> Includes
> * Version flip fixes
> * Dropped JDK-8267151, needs reimplementation bug
> * Dropped JDK-8266015, needs reimplementation bug

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

  TestNG update breaks a few things

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/446/files
  - new: https://git.openjdk.java.net/valhalla/pull/446/files/cdbb5019..b19a3f5f

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

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

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


From mchung at openjdk.java.net  Wed Jun 16 19:10:40 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 16 Jun 2021 19:10:40 GMT
Subject: Integrated: JDK-8268908: Update test/jdk/valhalla/valuetypes tests to
 prepare for jtreg 6 and other clean up
In-Reply-To: <fzDi6gE9wJxgGXhS40C8i5b9293xMH3mqG9cECkHcts=.bb31a805-e259-4ca6-9a08-c1031c8f5672@github.com>
References: <fzDi6gE9wJxgGXhS40C8i5b9293xMH3mqG9cECkHcts=.bb31a805-e259-4ca6-9a08-c1031c8f5672@github.com>
Message-ID: <5D_N1i1CAoztzBomt0_FQKgcj1xD4uO1RnrVXVg9MyY=.07e9a320-226c-4516-8580-e8c1951a186b@github.com>

On Wed, 16 Jun 2021 19:03:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6. Also rename references to the term "inline" to "primitive". some test case reorganization.

This pull request has now been integrated.

Changeset: 52ee195b
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/52ee195b05474ba561c0e0886fcb2cc58fd93edb
Stats:     1857 lines in 22 files changed: 746 ins; 841 del; 270 mod

8268908: Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6 and other clean up

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

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


From mchung at openjdk.java.net  Wed Jun 16 19:10:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 16 Jun 2021 19:10:39 GMT
Subject: Integrated: JDK-8268908: Update test/jdk/valhalla/valuetypes tests to
 prepare for jtreg 6 and other clean up
Message-ID: <fzDi6gE9wJxgGXhS40C8i5b9293xMH3mqG9cECkHcts=.bb31a805-e259-4ca6-9a08-c1031c8f5672@github.com>

Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6. Also rename references to the term "inline" to "primitive". some test case reorganization.

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

Commit messages:
 - JDK-8268908: Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6 and other clean up

Changes: https://git.openjdk.java.net/valhalla/pull/447/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=447&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8268908
  Stats: 1857 lines in 22 files changed: 746 ins; 841 del; 270 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/447.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/447/head:pull/447

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


From dsimms at openjdk.java.net  Thu Jun 17 07:49:40 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Jun 2021 07:49:40 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>
References: <ckl5Ob_bE5cPM8ZXVOfNjoTskqkA_P_pXU4xg_c0WDU=.eedbd463-c2d3-423f-b981-8216a3f1e75d@github.com>
Message-ID: <wE0hDULpuVkpOJ50aSq_JM7aNn9MLa4KH2P6kcFRDjE=.93f169f7-d7f9-49ea-beaf-4f0e2c4de68b@github.com>

On Wed, 16 Jun 2021 13:50:25 GMT, David Simms <dsimms at openjdk.org> wrote:

> Includes
> * Version flip fixes
> * Dropped JDK-8267151, reimplementation bug: JDK-8268945
> * Dropped JDK-8266015, reimplementation bug: JDK-8268946

This pull request has now been integrated.

Changeset: 00034f17
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/00034f17830f05ed04c92b3857971c74e06cf26b
Stats:     619955 lines in 5437 files changed: 520677 ins; 77528 del; 21750 mod

Merge jdk

Merge tag 'jdk-18+1'

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

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


From dsimms at openjdk.java.net  Thu Jun 17 11:58:17 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Jun 2021 11:58:17 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <V8551Q4yfDq6xE9YWwv6pOe3DtW0R9883gWpwEVlOSo=.e05825f6-593b-44b2-847e-f48050416673@github.com>

Merge tag 'jdk-18+2'
# Conflicts:
#	src/hotspot/share/opto/compile.cpp
#	src/hotspot/share/opto/compile.hpp
#	src/hotspot/share/opto/macroArrayCopy.cpp

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

Commit messages:
 - Merge tag 'jdk-18+2' into lworld_merge_jdk_18_2
 - 8267752: KVHashtable doesn't deallocate entries
 - 8267870: Remove unnecessary char_converter during class loading
 - 8268078: ClassListParser::_interfaces should be freed
 - 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated <owner is scalar replaced>'
 - Merge
 - 8268768: idea.sh has been updated in surprising and incompatible ways
 - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64
 - 8268723: Problem list SA core file tests on OSX when using ZGC
 - 8268736: Use apiNote in AutoCloseable.close javadoc
 - ... and 42 more: https://git.openjdk.java.net/valhalla/compare/00034f17...35dae09e

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

Changes: https://git.openjdk.java.net/valhalla/pull/448/files
  Stats: 3948 lines in 145 files changed: 2999 ins; 548 del; 401 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/448.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/448/head:pull/448

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


From sadayapalam at openjdk.java.net  Thu Jun 17 12:02:09 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 17 Jun 2021 12:02:09 GMT
Subject: [lworld] Integrated: 8267821: [lworld] Javac's handling of
 `primitive' modifier is unlike the handling of other restricted identifiers
Message-ID: <GtcH3piyIpeRdPgKKNtcqjNixrgOkWjuu7vsQEdRYWQ=.09ccd878-57d8-4a55-b795-2b93f54705bf@github.com>

Harmonize handling of `primitive' modifier along the lines of other reserved type identifiers.

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

Commit messages:
 - 8267821: Javac's handling of `primitive' modifier is unlike the handling of other restricted identifiers

Changes: https://git.openjdk.java.net/valhalla/pull/449/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=449&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267821
  Stats: 134 lines in 8 files changed: 60 ins; 73 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/449.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/449/head:pull/449

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


From sadayapalam at openjdk.java.net  Thu Jun 17 12:02:10 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Thu, 17 Jun 2021 12:02:10 GMT
Subject: [lworld] Integrated: 8267821: [lworld] Javac's handling of
 `primitive' modifier is unlike the handling of other restricted identifiers
In-Reply-To: <GtcH3piyIpeRdPgKKNtcqjNixrgOkWjuu7vsQEdRYWQ=.09ccd878-57d8-4a55-b795-2b93f54705bf@github.com>
References: <GtcH3piyIpeRdPgKKNtcqjNixrgOkWjuu7vsQEdRYWQ=.09ccd878-57d8-4a55-b795-2b93f54705bf@github.com>
Message-ID: <-syoPPRh695MGFWw5YllnQGQyl1yXJVz1HAaqowNAz0=.2ee564f2-beaf-4389-9121-271233262d2e@github.com>

On Thu, 17 Jun 2021 11:54:35 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Harmonize handling of `primitive' modifier along the lines of other reserved type identifiers.

This pull request has now been integrated.

Changeset: 0a854314
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0a85431493a483c4596e4d578be494724daa1382
Stats:     134 lines in 8 files changed: 60 ins; 73 del; 1 mod

8267821: [lworld] Javac's handling of `primitive' modifier is unlike the handling of other restricted identifiers

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

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


From dsimms at openjdk.java.net  Thu Jun 17 12:46:52 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Jun 2021 12:46:52 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <V8551Q4yfDq6xE9YWwv6pOe3DtW0R9883gWpwEVlOSo=.e05825f6-593b-44b2-847e-f48050416673@github.com>
References: <V8551Q4yfDq6xE9YWwv6pOe3DtW0R9883gWpwEVlOSo=.e05825f6-593b-44b2-847e-f48050416673@github.com>
Message-ID: <BnYHou51WtMnYdoSco2jF9DTcKLWID0cIBM_x4aUT7I=.20bbcdb0-c23c-4d20-8098-c06a28d54809@github.com>

On Thu, 17 Jun 2021 11:49:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-18+2'
> # Conflicts:
> #	src/hotspot/share/opto/compile.cpp
> #	src/hotspot/share/opto/compile.hpp
> #	src/hotspot/share/opto/macroArrayCopy.cpp

This pull request has now been integrated.

Changeset: 85af6b56
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/85af6b560efc65b40fd0ec43e16ae7e27a563518
Stats:     3948 lines in 145 files changed: 2999 ins; 548 del; 401 mod

Merge jdk

Merge tag 'jdk-18+2'

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

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


From dsimms at openjdk.java.net  Thu Jun 17 15:25:58 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Jun 2021 15:25:58 GMT
Subject: RFR: Merge lworld
Message-ID: <yFzSxFuBeL9jtcRRiKFrnO4r0jLNFdjkaDK-1fAHM6w=.7e826d68-1f37-457b-8ad9-91c60e6a5510@github.com>

Merge lworld @jdk-18+2

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

Commit messages:
 - Merge branch 'lworld' into lqagain_merge_lworld_18_2
 - Merge jdk
 - 8267752: KVHashtable doesn't deallocate entries
 - 8267870: Remove unnecessary char_converter during class loading
 - 8268078: ClassListParser::_interfaces should be freed
 - 8268780: Use 'print_cr' instead of 'print' for the message 'eliminated <owner is scalar replaced>'
 - Merge
 - 8268768: idea.sh has been updated in surprising and incompatible ways
 - 8268828: ProblemList compiler/intrinsics/VectorizedMismatchTest.java on win-x64
 - 8268723: Problem list SA core file tests on OSX when using ZGC
 - ... and 623 more: https://git.openjdk.java.net/valhalla/compare/52ee195b...f1fabd8b

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

Changes: https://git.openjdk.java.net/valhalla/pull/450/files
  Stats: 623518 lines in 5525 files changed: 523879 ins; 77624 del; 22015 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/450.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/450/head:pull/450

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


From dsimms at openjdk.java.net  Thu Jun 17 15:30:49 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Jun 2021 15:30:49 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <yFzSxFuBeL9jtcRRiKFrnO4r0jLNFdjkaDK-1fAHM6w=.7e826d68-1f37-457b-8ad9-91c60e6a5510@github.com>
References: <yFzSxFuBeL9jtcRRiKFrnO4r0jLNFdjkaDK-1fAHM6w=.7e826d68-1f37-457b-8ad9-91c60e6a5510@github.com>
Message-ID: <z-STNQ0RfgI-4BXHUf9-ibExCAl-hDLdoKzdHp8cS58=.971f5bea-2049-480b-9c17-40b10b3f7c4b@github.com>

> Merge lworld @jdk-18+2

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'lworld' into lqagain_merge_lworld_18_2
   
   Merge lworld @jdk-18+2
 - 8268908: Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6 and other clean up
 - 8268656: [lqagain] A few code chunks dealing with dual class scheme still left in
 - 8268358: [lworld] toString for primitive class should return `ClassName at hash`
   
   Reviewed-by: rriggs
 - 8268584: [lqagain] Javac tests should not needlessly hardcode toString() output
 - 8267597: [lworld] Withdraw all support for bifurcated class generation for primitive classes
   8268527: [lqagain] langtool tests need tweaks to run properly in an universe where -XDunifiedValRefClass is the default
 - 8268418: [lworld] VM assert illegal mirror klass when calling Class::getInterfaces on a flat array
   
   Reviewed-by: fparain
 - 8268399: [BACKOUT] [lworld] Tests must be update after core reflection changes for the L/Q model
 - 8268389: [lworld] Tests must be update after core reflection changes for the L/Q model
   
   Reviewed-by: hseigel
 - 8267948: [lword] Core reflection and method handles support for L/Q model
   
   Reviewed-by: fparain, rriggs
 - ... and 10 more: https://git.openjdk.java.net/valhalla/compare/85af6b56...f1fabd8b

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

Changes: https://git.openjdk.java.net/valhalla/pull/450/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=450&range=01
  Stats: 4434 lines in 187 files changed: 1581 ins; 2015 del; 838 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/450.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/450/head:pull/450

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


From dsimms at openjdk.java.net  Thu Jun 17 15:30:55 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 17 Jun 2021 15:30:55 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <yFzSxFuBeL9jtcRRiKFrnO4r0jLNFdjkaDK-1fAHM6w=.7e826d68-1f37-457b-8ad9-91c60e6a5510@github.com>
References: <yFzSxFuBeL9jtcRRiKFrnO4r0jLNFdjkaDK-1fAHM6w=.7e826d68-1f37-457b-8ad9-91c60e6a5510@github.com>
Message-ID: <1NUj9XpINWMTg3x_hEpQ123POHVKpx5n_TFbradU110=.a1c0ff8d-3899-46f3-a30a-a6aa0b4d49d5@github.com>

On Thu, 17 Jun 2021 15:19:13 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge lworld @jdk-18+2

This pull request has now been integrated.

Changeset: 70a24057
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/70a2405721f6b9fcb26dd3f4b8d412bee671ad1b
Stats:     623518 lines in 5525 files changed: 523879 ins; 77624 del; 22015 mod

Merge lworld

Merge lworld @jdk-18+2

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

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


From mchung at openjdk.java.net  Thu Jun 17 22:24:13 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 17 Jun 2021 22:24:13 GMT
Subject: Integrated: JDK-8268980: [lword] Fix Class::descriptorString to
 return L-descriptor for primitive ref type
Message-ID: <gx4zOyT3Thk8ua8mxKP7WnQTuyHgeB8dJHPo8XP997E=.2be816db-9c71-4011-a22d-518ecdabbe9b@github.com>

JDK-8268980: [lword] Fix Class::descriptorString to return L-descriptor for primitive ref type

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

Commit messages:
 - remove tab and trailing whitespaces
 - add a new test with primitive reference type as parameter type
 - JDK-8268980: [lword] Fix Class::descriptorString to return L-descriptor for primitive ref type
 - Merge branch 'lqagain' of https://github.com/openjdk/valhalla into test-cleanup
 - JDK-8268908: Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6 and other clean up

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

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


From mchung at openjdk.java.net  Thu Jun 17 22:24:16 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 17 Jun 2021 22:24:16 GMT
Subject: Integrated: JDK-8268980: [lword] Fix Class::descriptorString to
 return L-descriptor for primitive ref type
In-Reply-To: <gx4zOyT3Thk8ua8mxKP7WnQTuyHgeB8dJHPo8XP997E=.2be816db-9c71-4011-a22d-518ecdabbe9b@github.com>
References: <gx4zOyT3Thk8ua8mxKP7WnQTuyHgeB8dJHPo8XP997E=.2be816db-9c71-4011-a22d-518ecdabbe9b@github.com>
Message-ID: <9sxZWG1S7c_wxI45emYI_Fz3RqUbjRGnIuzNrtzRs04=.80495702-be39-44da-81a0-7ebabbd7a61b@github.com>

On Thu, 17 Jun 2021 22:12:14 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> JDK-8268980: [lword] Fix Class::descriptorString to return L-descriptor for primitive ref type

This pull request has now been integrated.

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

8268980: [lword] Fix Class::descriptorString to return L-descriptor for primitive ref type

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

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


From mchung at openjdk.java.net  Thu Jun 17 22:51:00 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 17 Jun 2021 22:51:00 GMT
Subject: Integrated: JDK-8268981: [lworld]
 UnifiedPrimitiveClassNestHostTest.java should test with the primary mirror
Message-ID: <Aw_3mNbtRusGwjXhOZvFgprt0luBWO_oIZ4o7iEULV4=.e563d079-5498-4c50-85d9-813c95154f03@github.com>

Fix the bug in test/langtools/tools/javac/valhalla/lworld-values/UnifiedPrimitiveClassNestHostTest.java test that verifies the nest host with a secondary mirror but the core reflection API returns the primary mirror.

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

Commit messages:
 - JDK-8268981:  [lworld] UnifiedPrimitiveClassNestHostTest.java should test with the primary mirror

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

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


From mchung at openjdk.java.net  Thu Jun 17 22:51:02 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 17 Jun 2021 22:51:02 GMT
Subject: Integrated: JDK-8268981: [lworld]
 UnifiedPrimitiveClassNestHostTest.java should test with the primary mirror
In-Reply-To: <Aw_3mNbtRusGwjXhOZvFgprt0luBWO_oIZ4o7iEULV4=.e563d079-5498-4c50-85d9-813c95154f03@github.com>
References: <Aw_3mNbtRusGwjXhOZvFgprt0luBWO_oIZ4o7iEULV4=.e563d079-5498-4c50-85d9-813c95154f03@github.com>
Message-ID: <TO8LjscjnlEQ6MoiB-Sp_Mv-ipafb4nDwFQP3jeCeyU=.19ea5cff-ea33-4ac8-bfde-f811d61e8d43@github.com>

On Thu, 17 Jun 2021 22:42:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Fix the bug in test/langtools/tools/javac/valhalla/lworld-values/UnifiedPrimitiveClassNestHostTest.java test that verifies the nest host with a secondary mirror but the core reflection API returns the primary mirror.

This pull request has now been integrated.

Changeset: 521bed27
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/521bed276efe4cc2bf09daa7dc3206b9a981fc69
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8268981: [lworld] UnifiedPrimitiveClassNestHostTest.java should test with the primary mirror

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

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


From dsimms at openjdk.java.net  Fri Jun 18 10:16:26 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 18 Jun 2021 10:16:26 GMT
Subject: [lworld] RFR: JDK-8269023 [lworld] L/Q<type> support
Message-ID: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>

Merge work from lqagain branch

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

Commit messages:
 - 8268981: [lworld] UnifiedPrimitiveClassNestHostTest.java should test with the primary mirror
 - 8268980: [lword] Fix Class::descriptorString to return L-descriptor for primitive ref type
 - Merge lworld
 - 8268908: Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6 and other clean up
 - 8268656: [lqagain] A few code chunks dealing with dual class scheme still left in
 - 8268358: [lworld] toString for primitive class should return `ClassName at hash`
 - 8268584: [lqagain] Javac tests should not needlessly hardcode toString() output
 - 8267597: [lworld] Withdraw all support for bifurcated class generation for primitive classes
 - 8268418: [lworld] VM assert illegal mirror klass when calling Class::getInterfaces on a flat array
 - 8268399: [BACKOUT] [lworld] Tests must be update after core reflection changes for the L/Q model
 - ... and 12 more: https://git.openjdk.java.net/valhalla/compare/85af6b56...521bed27

Changes: https://git.openjdk.java.net/valhalla/pull/453/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=453&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269023
  Stats: 4484 lines in 188 files changed: 1629 ins; 2014 del; 841 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/453.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/453/head:pull/453

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


From mchung at openjdk.java.net  Fri Jun 18 21:26:28 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 18 Jun 2021 21:26:28 GMT
Subject: RFR: JDK-8218159: ValueBootstrapMethods.isSubstitutable should not
 filter synthetic fields
Message-ID: <GzKmaCdEtltjtxBFUtBbVhfz-R-2Q2IDNunSQtU70kY=.84c00b6c-83c0-4a54-942c-03e28b544c36@github.com>

`acmp` on two primitive objects of the same type are considered equals if all of their fields are "equivalent" including synthetic fields, for example, which can be an enclosing instance and captured outer locals.

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

Commit messages:
 - JDK-8218159: ValueBootstrapMethods.isSubstitutable should not filter synthetic fields

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

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


From mchung at openjdk.java.net  Fri Jun 18 22:18:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 18 Jun 2021 22:18:39 GMT
Subject: Integrated: JDK-8218159: ValueBootstrapMethods.isSubstitutable should
 not filter synthetic fields
In-Reply-To: <GzKmaCdEtltjtxBFUtBbVhfz-R-2Q2IDNunSQtU70kY=.84c00b6c-83c0-4a54-942c-03e28b544c36@github.com>
References: <GzKmaCdEtltjtxBFUtBbVhfz-R-2Q2IDNunSQtU70kY=.84c00b6c-83c0-4a54-942c-03e28b544c36@github.com>
Message-ID: <4OtL2vs9vctTX3BUDqHyzgVyuyFlMF4ZEuqlTpPThZY=.12da45be-03d9-4698-87b6-3d0593dd011b@github.com>

On Fri, 18 Jun 2021 21:04:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `acmp` on two primitive objects of the same type are considered equals if all of their fields are "equivalent" including synthetic fields, for example, which can be an enclosing instance and captured outer locals.

This pull request has now been integrated.

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

8218159: ValueBootstrapMethods.isSubstitutable should not filter synthetic fields

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

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


From sadayapalam at openjdk.java.net  Mon Jun 21 09:26:41 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 21 Jun 2021 09:26:41 GMT
Subject: [lworld] Integrated: 8267824: [lworld] Lots of lingering references
 to inline/value types in Javac code base
Message-ID: <gHpV4Z98TS7g9yc26ALFouP90jzUbbcYpVAzUp0PoXI=.b8b365b3-09c0-4cb2-afa9-cf2e47e9e7b4@github.com>

Purge stale terminilogy references in identifiers, comments, files ...

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

Commit messages:
 - 8267824: [lworld] Lots of lingering references to inline/value types in Javac code base

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

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


From sadayapalam at openjdk.java.net  Mon Jun 21 09:26:44 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 21 Jun 2021 09:26:44 GMT
Subject: [lworld] Integrated: 8267824: [lworld] Lots of lingering references
 to inline/value types in Javac code base
In-Reply-To: <gHpV4Z98TS7g9yc26ALFouP90jzUbbcYpVAzUp0PoXI=.b8b365b3-09c0-4cb2-afa9-cf2e47e9e7b4@github.com>
References: <gHpV4Z98TS7g9yc26ALFouP90jzUbbcYpVAzUp0PoXI=.b8b365b3-09c0-4cb2-afa9-cf2e47e9e7b4@github.com>
Message-ID: <IAR35NLTUmcQaeVTG-xUVLusocBJp4FGzcOwK_KrwFQ=.452411b7-ee33-4ddf-bc14-9ce80d1c1ac3@github.com>

On Mon, 21 Jun 2021 09:17:57 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Purge stale terminilogy references in identifiers, comments, files ...

This pull request has now been integrated.

Changeset: fab7d7a1
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/fab7d7a13a257b386372b19de3aceb67542b30ba
Stats:     89 lines in 21 files changed: 3 ins; 5 del; 81 mod

8267824: [lworld] Lots of lingering references to inline/value types in Javac code base

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

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


From dsimms at openjdk.java.net  Mon Jun 21 09:31:53 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 21 Jun 2021 09:31:53 GMT
Subject: [lworld] RFR: JDK-8269023 [lworld] L/Q<type> support [v2]
In-Reply-To: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>
References: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>
Message-ID: <cfhF9asBdwJ5qhC__7yOVTZC9iyPJbQEKmAyokfVqXU=.080c5d41-4b2c-47f5-bc71-02c92acd1dc5@github.com>

> Merge work from lqagain branch

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

  8218159: ValueBootstrapMethods.isSubstitutable should not filter synthetic fields

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/453/files
  - new: https://git.openjdk.java.net/valhalla/pull/453/files/521bed27..2a7e977a

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

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

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


From dsimms at openjdk.java.net  Mon Jun 21 09:37:56 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 21 Jun 2021 09:37:56 GMT
Subject: [lworld] RFR: JDK-8269023 [lworld] L/Q<type> support [v3]
In-Reply-To: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>
References: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>
Message-ID: <rABE_u2LUVgILOmn3UmafDJudlKiLIAMRnqRxRSOTdk=.20b45d19-4241-47e8-bffe-d7b44cbebcc6@github.com>

> Merge work from lqagain branch

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'lworld' of https://git.openjdk.java.net/valhalla into close_lqagain
 - 8218159: ValueBootstrapMethods.isSubstitutable should not filter synthetic fields
 - 8268981: [lworld] UnifiedPrimitiveClassNestHostTest.java should test with the primary mirror
 - 8268980: [lword] Fix Class::descriptorString to return L-descriptor for primitive ref type
 - Merge lworld
   
   Merge lworld @jdk-18+2
 - 8268908: Update test/jdk/valhalla/valuetypes tests to prepare for jtreg 6 and other clean up
 - 8268656: [lqagain] A few code chunks dealing with dual class scheme still left in
 - 8268358: [lworld] toString for primitive class should return `ClassName at hash`
   
   Reviewed-by: rriggs
 - 8268584: [lqagain] Javac tests should not needlessly hardcode toString() output
 - 8267597: [lworld] Withdraw all support for bifurcated class generation for primitive classes
   8268527: [lqagain] langtool tests need tweaks to run properly in an universe where -XDunifiedValRefClass is the default
 - ... and 14 more: https://git.openjdk.java.net/valhalla/compare/fab7d7a1...9579e93b

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

Changes: https://git.openjdk.java.net/valhalla/pull/453/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=453&range=02
  Stats: 4537 lines in 188 files changed: 1709 ins; 1987 del; 841 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/453.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/453/head:pull/453

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


From dsimms at openjdk.java.net  Mon Jun 21 09:57:05 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 21 Jun 2021 09:57:05 GMT
Subject: [lworld] Integrated: JDK-8269023 [lworld] L/Q<type> support
In-Reply-To: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>
References: <0uhVogGBOhFf-vPOAf4-MFab5HB33iSCWBjbQrRoU1U=.239f1c67-f4d5-40ca-b731-f87431499fdf@github.com>
Message-ID: <A85bDDqgqT8GvLeiILolbSwTEhLlIWigBVqwgvf6dc8=.e1f1688d-23d5-42ee-ad9c-3984168e3083@github.com>

On Fri, 18 Jun 2021 10:07:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge work from lqagain branch

This pull request has now been integrated.

Changeset: 3c399d9f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/3c399d9f7f36903e4c2583c16b0080e01181114a
Stats:     4537 lines in 188 files changed: 1709 ins; 1987 del; 841 mod

8269023: [lworld] L/Q<type> support

Co-authored-by: Frederic Parain <fparain at openjdk.org>
Co-authored-by: Tobias Hartmann <thartmann at openjdk.org>
Co-authored-by: Mandy Chung <mchung at openjdk.org>
Co-authored-by: Srikanth Adayapalam <sadayapalam at openjdk.org>

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

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


From sadayapalam at openjdk.java.net  Mon Jun 21 14:14:47 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 21 Jun 2021 14:14:47 GMT
Subject: [lworld] Integrated: 8269084: [lworld] runtime/cds tests need to be
 migrated to the unified class file scheme
In-Reply-To: <y92CNqkOPJTBOJ0yXHSNO3DK_cG0xDfmt3LN1acCdkg=.81b683a1-3ac9-4970-a38d-6ed80fb5721e@github.com>
References: <y92CNqkOPJTBOJ0yXHSNO3DK_cG0xDfmt3LN1acCdkg=.81b683a1-3ac9-4970-a38d-6ed80fb5721e@github.com>
Message-ID: <VmyKL0j7q6a5QvVLHIfN_BnSPhJcvnLOLjLjCYvebog=.9e9ea599-a6f9-4edc-aeb6-df09f44854c3@github.com>

On Mon, 21 Jun 2021 14:05:48 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Tests should not attempt to bundle the non-existent .ref.class files

This pull request has now been integrated.

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

8269084: [lworld] runtime/cds tests need to be migrated to the unified class file scheme

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

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


From sadayapalam at openjdk.java.net  Mon Jun 21 14:14:45 2021
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 21 Jun 2021 14:14:45 GMT
Subject: [lworld] Integrated: 8269084: [lworld] runtime/cds tests need to be
 migrated to the unified class file scheme
Message-ID: <y92CNqkOPJTBOJ0yXHSNO3DK_cG0xDfmt3LN1acCdkg=.81b683a1-3ac9-4970-a38d-6ed80fb5721e@github.com>

Tests should not attempt to bundle the non-existent .ref.class files

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

Commit messages:
 - 8269084: [lworld] runtime/cds tests need to be migrated to the unified class file scheme

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

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


From epavlova at openjdk.java.net  Mon Jun 21 22:43:20 2021
From: epavlova at openjdk.java.net (Ekaterina Pavlova)
Date: Mon, 21 Jun 2021 22:43:20 GMT
Subject: [lworld] RFR: Convert valhalla/inlinetypes tests to new IR framework
Message-ID: <JbwdgnRIVwvN-9P98EyD7dHRRanNK4dllRS-to8Dcnc=.2e088aab-a834-4c45-98fc-a03b620b123e@github.com>

This PR converts compiler/valhalla/inlinetypes tests based on old Valhalla/IR test framework to new one 
which was recently integrated by Christian as part of JDK-8254129.
The tests which were we decided to convert are basically the ones which extends InlineTypeTest class.
The rest of compiler/valhalla/inlinetypes tests were agreed (with Christian and Tobias) to keep untouched 
as they are in most cases regression tests.

The conversion rules/approach is pretty well described in the bug's description section (see JDK-8263024).
A detailed description of new IR test framework could found in test/hotspot/jtreg/compiler/lib/ir_framework/README.md.

Testing:
 Ran compiler/valhalla/inlinetypes in all the configurations used in hs-tier1-9.
 There 2 failed converted tests:
  compiler/valhalla/inlinetypes//TestNullableArrays.java - new bug JDK-8269070 filed
  compiler/valhalla/inlinetypes/TestIntrinsics.java - know issue tracked by JDK-8239003


Big thanks to Christian and Tobias for advice and help during this tests conversion.

Please review the changes.

Thanks,
Katya

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

Commit messages:
 - Converted to new IR framework

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

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


From shade at openjdk.java.net  Tue Jun 22 08:59:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 22 Jun 2021 08:59:54 GMT
Subject: [lworld] RFR: 8269095: Fix Valhalla Zero build failures
Message-ID: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>

This should make Zero buildable again in Valhalla workspace. Zero would not work with primitive classes just yet, failing with "unimplemented bytecode" when reaching the Valhalla code, but at least it would not fail the builds.

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

Commit messages:
 - 8269095: Fix Valhalla Zero build failures

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

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


From rriggs at openjdk.java.net  Tue Jun 22 20:20:10 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 20:20:10 GMT
Subject: [lworld] RFR: JDK-8269172: Add java.util.Objects.newIdentity method
Message-ID: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>

Replaces the existing Objects.newIdentity() method with the matching method in JDK17.

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

Commit messages:
 - JDK-8269172: Add java.util.Objects.newIdentity method

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

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


From mchung at openjdk.java.net  Tue Jun 22 20:28:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 22 Jun 2021 20:28:49 GMT
Subject: [lworld] RFR: JDK-8269172: Add java.util.Objects.newIdentity
 method
In-Reply-To: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>
References: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>
Message-ID: <BXsORDBJ9Ncgw8LNVyV4e8Na8URYyjb-WwDgIEZG3FE=.7261ce14-103c-4481-9337-49bd3fa7f157@github.com>

On Tue, 22 Jun 2021 20:14:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Replaces the existing Objects.newIdentity() method with the matching method in JDK17.

It's fine to bring this in early.  Or it could simply wait until lworld is sync'ed with jdk after JDK-8269096 is integrated and pulled down to the master.

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

Marked as reviewed by mchung (Committer).

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


From rriggs at openjdk.java.net  Tue Jun 22 20:32:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 22 Jun 2021 20:32:51 GMT
Subject: [lworld] RFR: JDK-8269172: Add java.util.Objects.newIdentity
 method
In-Reply-To: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>
References: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>
Message-ID: <aWipDZgBSZy4Z9rqT5lbEEvbn7NUwHBF_MCavwIrZ3Y=.b89e5560-e9d7-468c-83d4-885d0fd34a35@github.com>

On Tue, 22 Jun 2021 20:14:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Replaces the existing Objects.newIdentity() method with the matching method in JDK17.

Yep, I figured to preempt a question about how to resolve the conflict between the old impl and new one and save some head-scratching.

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

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


From dsimms at openjdk.java.net  Wed Jun 23 07:47:36 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 23 Jun 2021 07:47:36 GMT
Subject: [lworld] RFR: 8269095: Fix Valhalla Zero build failures
In-Reply-To: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>
References: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>
Message-ID: <wBKMcCS2isNj1tFJhhFsx-rrSihEcVhLPa_LS3vKXAk=.6a2e1acf-6c4e-442e-a9b3-b6408b038062@github.com>

On Tue, 22 Jun 2021 08:54:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should make Zero buildable again in Valhalla workspace. Zero would not work with primitive classes just yet, failing with "unimplemented bytecode" when reaching the Valhalla code, but at least it would not fail the builds.

This looks fine

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

Marked as reviewed by dsimms (Committer).

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


From shade at openjdk.java.net  Wed Jun 23 07:51:47 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 07:51:47 GMT
Subject: [lworld] RFR: 8269095: Fix Valhalla Zero build failures
In-Reply-To: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>
References: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>
Message-ID: <Iw4ofyW-QovEkyW_9jVb2fkCsiTfznz0obWO_4wWuUE=.54d323ad-10ed-478c-ac71-99c57a1c37d5@github.com>

On Tue, 22 Jun 2021 08:54:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should make Zero buildable again in Valhalla workspace. Zero would not work with primitive classes just yet, failing with "unimplemented bytecode" when reaching the Valhalla code, but at least it would not fail the builds.

Thanks!

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

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


From shade at openjdk.java.net  Wed Jun 23 07:56:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 07:56:39 GMT
Subject: [lworld] Integrated: 8269095: Fix Valhalla Zero build failures
In-Reply-To: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>
References: <NmcocNYFXM5hJAjTARqwLa2QLYCJXMxxj9M6sxXoswY=.56c58ec5-c46e-46c3-847b-1f78cbf4d1b6@github.com>
Message-ID: <U9YjKMrq95hLLFUT1I0ES7IwSAS3HNhOuwt0cOutgHE=.325d55c0-020b-4903-92a9-e364868b550f@github.com>

On Tue, 22 Jun 2021 08:54:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should make Zero buildable again in Valhalla workspace. Zero would not work with primitive classes just yet, failing with "unimplemented bytecode" when reaching the Valhalla code, but at least it would not fail the builds.

This pull request has now been integrated.

Changeset: 936d430d
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/936d430d38c8e5f596a8b00ecfc648ee7199fe04
Stats:     30 lines in 3 files changed: 20 ins; 0 del; 10 mod

8269095: Fix Valhalla Zero build failures

Reviewed-by: dsimms

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

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


From shade at openjdk.java.net  Wed Jun 23 13:04:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 13:04:53 GMT
Subject: [lworld] RFR: 8269231: Fix 32-bit Valhalla (Zero) builds
Message-ID: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>

Building linux-x86-zero-fastdebug builds shows a few 32-bit cleanliness problems.

The first failure is:

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

Commit messages:
 - 8269231: Fix 32-bit Valhalla (Zero) builds

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

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


From rriggs at openjdk.java.net  Wed Jun 23 13:08:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 23 Jun 2021 13:08:51 GMT
Subject: [lworld] Integrated: JDK-8269172: Add java.util.Objects.newIdentity
 method
In-Reply-To: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>
References: <dIz2cPPC2sbAHvfo8mdGSTT3x9jNRO8kTy7qV50lwn8=.2199fa31-81f3-4756-a2fe-b9f3ee5767b4@github.com>
Message-ID: <totSXbon7705JHCNPZt3LgnKp__Rh2VGGrfj8CaLIpo=.e1015fae-c49f-495c-b0b2-95ed5fa20546@github.com>

On Tue, 22 Jun 2021 20:14:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Replaces the existing Objects.newIdentity() method with the matching method in JDK17.

This pull request has now been integrated.

Changeset: bb107118
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bb1071183ffdce1c8ed4ca09790437d8543df831
Stats:     42 lines in 2 files changed: 27 ins; 14 del; 1 mod

8269172: Add java.util.Objects.newIdentity method

Reviewed-by: mchung

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

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


From dsimms at openjdk.java.net  Wed Jun 23 14:42:49 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 23 Jun 2021 14:42:49 GMT
Subject: [lworld] RFR: 8269231: Fix 32-bit Valhalla (Zero) builds
In-Reply-To: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>
References: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>
Message-ID: <zhhi01yddA6JB0t0bsOHCiJk7NNuAp24Jc44MafyjJ8=.34a2e2ed-d711-4f0a-af04-416a7166795d@github.com>

On Wed, 23 Jun 2021 12:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Building linux-x86-zero-fastdebug builds shows a few 32-bit cleanliness problems.
> 
> The first failure is:

Thanks for cleaning the 32-bit zero builds too

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

Marked as reviewed by dsimms (Committer).

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


From shade at openjdk.java.net  Wed Jun 23 14:56:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 14:56:41 GMT
Subject: [lworld] RFR: 8269231: Fix 32-bit Valhalla (Zero) builds
In-Reply-To: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>
References: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>
Message-ID: <NcAVPIiusihTP2OMcA_NaUSlsPCUfmxzevIVwVrlV-Y=.9611fe75-d091-49c8-8615-5c6434e76c31@github.com>

On Wed, 23 Jun 2021 12:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Building linux-x86-zero-fastdebug builds shows a few 32-bit cleanliness problems.
> 
> The first failure is:

Yup. I think the vast majority of these issues would break x86_32-server too, but that would also need some macroAssembler fixes to work. I have a few prototype fixes there. Meanwhile, it would be nice to unbreak 32-bit Zero builds.

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

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


From dsimms at openjdk.java.net  Wed Jun 23 15:07:15 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 23 Jun 2021 15:07:15 GMT
Subject: git: openjdk/valhalla: lworld: 8269231: Fix 32-bit Valhalla (Zero)
 builds
Message-ID: <c63757b9-22db-41c1-b456-38cabd9736fa@openjdk.org>

Changeset: f2538f48
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
Date:      2021-06-23 15:06:51 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/f2538f48e64fe6f7870e237fd529000d0ececf9b

8269231: Fix 32-bit Valhalla (Zero) builds

Reviewed-by: dsimms

! src/hotspot/share/oops/flatArrayKlass.cpp
! src/hotspot/share/oops/markWord.hpp
! src/hotspot/share/oops/markWord.inline.hpp
! src/hotspot/share/oops/objArrayKlass.cpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp



From shade at openjdk.java.net  Wed Jun 23 15:09:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Jun 2021 15:09:51 GMT
Subject: [lworld] Integrated: 8269231: Fix 32-bit Valhalla (Zero) builds
In-Reply-To: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>
References: <qHFKEjIY13_vbNUPcVstT_6SK-zVQXr1BfLeGfiTngE=.144a58b5-283a-4223-9980-62ca146cd4ae@github.com>
Message-ID: <gStw0ifvmz5lfpmJbn6GBmyIMGoKp_VD7zIJjasv_Ns=.47352e5c-3f94-435d-ac2b-f71150c85d9b@github.com>

On Wed, 23 Jun 2021 12:58:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Building linux-x86-zero-fastdebug builds shows a few 32-bit cleanliness problems.
> 
> The first failure is:

This pull request has now been integrated.

Changeset: f2538f48
Author:    Aleksey Shipilev <shade at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/f2538f48e64fe6f7870e237fd529000d0ececf9b
Stats:     34 lines in 8 files changed: 26 ins; 0 del; 8 mod

8269231: Fix 32-bit Valhalla (Zero) builds

Reviewed-by: dsimms

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

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


From roland at openjdk.java.net  Wed Jun 23 15:44:38 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Jun 2021 15:44:38 GMT
Subject: RFR: 8268553: [lworld] CI must return secondary mirror when
 accessing CONSTANT_Class with Q-signature
In-Reply-To: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
References: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
Message-ID: <_JsLuZXQwJnDpEHQrmakGPJULfFTzAy2_Yt6_UvnMNg=.e691d86e-441b-4e4f-bb01-416882815f3d@github.com>

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

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

Looks good to me.

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

Marked as reviewed by roland (Committer).

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


From fparain at openjdk.java.net  Wed Jun 23 17:33:54 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 23 Jun 2021 17:33:54 GMT
Subject: RFR: 8268553: [lworld] CI must return secondary mirror when
 accessing CONSTANT_Class with Q-signature
In-Reply-To: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
References: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
Message-ID: <Paa7pDqNuIw_08XJbR4iLq0mcMKqaNWJc-WmcZU5OI0=.fa7d13eb-5fa4-49b2-9f9d-4f07b0a0ec20@github.com>

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

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

Mandy, Roland,

Thank you for your reviews,

Fred

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

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


From fparain at openjdk.java.net  Wed Jun 23 17:34:05 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 23 Jun 2021 17:34:05 GMT
Subject: Integrated: 8268553: [lworld] CI must return secondary mirror when
 accessing CONSTANT_Class with Q-signature
In-Reply-To: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
References: <dFnA-iENn1l44_ZmRoyMHsjlwhVmdO6QWNA5EvtgGm4=.f24aae40-8480-44b5-8554-98a84cbc997e@github.com>
Message-ID: <-McYYstK-nofZ0F6yD3bw8jjHOcnSAlvjhFhjQ_S8R0=.8ce6790a-e841-4510-b25f-798867838f7c@github.com>

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

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

This pull request has now been integrated.

Changeset: 4d064baa
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4d064baaecd2986b22cdba9cba1e649f8b934d87
Stats:     14 lines in 3 files changed: 13 ins; 0 del; 1 mod

8268553: [lworld] CI must return secondary mirror when accessing CONSTANT_Class with Q-signature

Reviewed-by: mchung, roland

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

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


From ngasson at openjdk.java.net  Thu Jun 24 05:59:00 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Thu, 24 Jun 2021 05:59:00 GMT
Subject: [lworld] RFR: 8268021: [lworld] [AArch64] fix support for
 InlineTypeReturnedAsFields
Message-ID: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>

The code to support this on AArch64 was already mostly written but
untested or bit-rotted. This patch also contains the allocation
optimisation to MacroAssembler::store_inline_type_fields_to_buf() from
JDK-8263067.

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

Commit messages:
 - 8268021: [lworld] [AArch64] fix support for InlineTypeReturnedAsFields

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

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


From dsimms at openjdk.java.net  Thu Jun 24 08:07:10 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Jun 2021 08:07:10 GMT
Subject: [lworld] RFR: Adjust testing
Message-ID: <wOE6CjL9t4X-E98zqlFK8cXB4EH8CBMVz5XRktOmh1Q=.4984fa89-1037-4a9e-ae6a-606dd1b088cf@github.com>

Problem listed tests

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

Commit messages:
 - Adjust testing

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

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


From shade at openjdk.java.net  Thu Jun 24 08:59:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 08:59:40 GMT
Subject: [lworld] RFR: Adjust testing
In-Reply-To: <wOE6CjL9t4X-E98zqlFK8cXB4EH8CBMVz5XRktOmh1Q=.4984fa89-1037-4a9e-ae6a-606dd1b088cf@github.com>
References: <wOE6CjL9t4X-E98zqlFK8cXB4EH8CBMVz5XRktOmh1Q=.4984fa89-1037-4a9e-ae6a-606dd1b088cf@github.com>
Message-ID: <dPW1ntYnczpQdRoa9dUGQjD-lTu7kCo6ZYUqOcU3B-w=.cd0003bf-06d7-43b0-a954-fb3a6b4531e9@github.com>

On Thu, 24 Jun 2021 08:00:10 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem listed tests

This looks good to me, and `hotspot_valhalla` tests are now clean.

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

Marked as reviewed by shade (no project role).

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


From dsimms at openjdk.java.net  Thu Jun 24 10:27:56 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Jun 2021 10:27:56 GMT
Subject: [lworld] RFR: 8269279: [lworld] 8269231 causes build failures
Message-ID: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>

Removed signed hex formats since "x" is unsigned by definition

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

Commit messages:
 - 8269279: [lworld] 8269231 causes build failures

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

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


From shade at openjdk.java.net  Thu Jun 24 10:33:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 10:33:54 GMT
Subject: [lworld] RFR: 8269279: [lworld] 8269231 causes build failures
In-Reply-To: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
References: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
Message-ID: <CwCtC9i3pmCoMcOCr8-7hVpsY_uMxzm3XnWGeN5LzaU=.b72ab80b-2b7b-4629-b9ef-1e99d274026b@github.com>

On Thu, 24 Jun 2021 10:22:10 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed signed hex formats since "x" is unsigned by definition

Oh! Right. Since we are casting to `uint64_t`, probably better use `UINT64_FORMAT_X` directly?

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

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


From dsimms at openjdk.java.net  Thu Jun 24 10:46:52 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Jun 2021 10:46:52 GMT
Subject: [lworld] RFR: 8269279: [lworld] 8269231 causes build failures
In-Reply-To: <CwCtC9i3pmCoMcOCr8-7hVpsY_uMxzm3XnWGeN5LzaU=.b72ab80b-2b7b-4629-b9ef-1e99d274026b@github.com>
References: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
 <CwCtC9i3pmCoMcOCr8-7hVpsY_uMxzm3XnWGeN5LzaU=.b72ab80b-2b7b-4629-b9ef-1e99d274026b@github.com>
Message-ID: <OZYNXWi5jXN1HXv2oG90T8FLQCfblgS8ZL7m5EN0pso=.80303844-8e0f-449e-be00-5e8af8bb2737@github.com>

On Thu, 24 Jun 2021 10:31:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Oh! Right. Since we are casting to `uint64_t`, probably better use `UINT64_FORMAT_X` directly?

Six of one, half a dozen of the other, the argument is a `jlong` and `JULONG_FORMAT_X` exists which required less typing. `JULONG_FORMAT_X` existence should probably invoke questions with the reader "an unsigned format for a clearly signed type ?".

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

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


From shade at openjdk.java.net  Thu Jun 24 10:51:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 10:51:53 GMT
Subject: [lworld] RFR: 8269279: [lworld] 8269231 causes build failures
In-Reply-To: <OZYNXWi5jXN1HXv2oG90T8FLQCfblgS8ZL7m5EN0pso=.80303844-8e0f-449e-be00-5e8af8bb2737@github.com>
References: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
 <CwCtC9i3pmCoMcOCr8-7hVpsY_uMxzm3XnWGeN5LzaU=.b72ab80b-2b7b-4629-b9ef-1e99d274026b@github.com>
 <OZYNXWi5jXN1HXv2oG90T8FLQCfblgS8ZL7m5EN0pso=.80303844-8e0f-449e-be00-5e8af8bb2737@github.com>
Message-ID: <5LXYhB1vnAjrFIuosrxL5GLovaSQTsK4UPWFWN8n4ls=.b7a9cf90-8272-4976-a9f1-e617c3520823@github.com>

On Thu, 24 Jun 2021 10:43:16 GMT, David Simms <dsimms at openjdk.org> wrote:

> > Oh! Right. Since we are casting to `uint64_t`, probably better use `UINT64_FORMAT_X` directly?
> 
> Six of one, half a dozen of the other, the argument is a `jlong` and `JULONG_FORMAT_X` exists which required less typing. `JULONG_FORMAT_X` existence should probably invoke questions with the reader "an unsigned format for a clearly signed type ?".

Well, it confuses me a bit that we cast `jlong` to `uint64_t` and then format it as `JULONG_FORMAT_X`. Yes, it works right now because `JULONG_FORMAT_X` is defined as `UINT64_FORMAT_X`. I just thought it would be cleaner to say `jlong` -> `uint64_t` ->  `UINT64_FORMAT_X`.

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

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


From dsimms at openjdk.java.net  Thu Jun 24 10:59:18 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Jun 2021 10:59:18 GMT
Subject: [lworld] RFR: 8269279: [lworld] 8269231 causes build failures [v2]
In-Reply-To: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
References: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
Message-ID: <mz6q6GjDfSN0on1l5ljRLj8WCrtWNdLmvt5DNQASKXA=.9e53f834-ebd4-40b7-bdb1-62f1451db663@github.com>

> Removed signed hex formats since "x" is unsigned by definition

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

  Maybe JULONG_FORMAT_X doesn't really deserve to live TBH, reduce usage

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/463/files
  - new: https://git.openjdk.java.net/valhalla/pull/463/files/3885ed27..fca80873

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

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

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


From shade at openjdk.java.net  Thu Jun 24 10:59:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Jun 2021 10:59:20 GMT
Subject: [lworld] RFR: 8269279: [lworld] 8269231 causes build failures [v2]
In-Reply-To: <mz6q6GjDfSN0on1l5ljRLj8WCrtWNdLmvt5DNQASKXA=.9e53f834-ebd4-40b7-bdb1-62f1451db663@github.com>
References: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
 <mz6q6GjDfSN0on1l5ljRLj8WCrtWNdLmvt5DNQASKXA=.9e53f834-ebd4-40b7-bdb1-62f1451db663@github.com>
Message-ID: <eKurNduvSTsYqafW1CkguCA0CzVOq_BoA2WGjl2cLDU=.668e928e-fb97-4631-963e-79a85a2f2a82@github.com>

On Thu, 24 Jun 2021 10:55:58 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Removed signed hex formats since "x" is unsigned by definition
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Maybe JULONG_FORMAT_X doesn't really deserve to live TBH, reduce usage

Cool, thanks.

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

Marked as reviewed by shade (no project role).

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


From dsimms at openjdk.java.net  Thu Jun 24 10:59:21 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Jun 2021 10:59:21 GMT
Subject: [lworld] Integrated: 8269279: [lworld] 8269231 causes build failures
In-Reply-To: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
References: <lYXFU6rQaidd8BRL8Ze47juw7srzLcCj6Ow2Llq1V9A=.eb0f4efd-cbaf-4754-8500-aea8c722e396@github.com>
Message-ID: <x5yIoiOTNrRMOLQQqTdJTgl6nWbkArphA_KeHTxLfeE=.2312d720-cca0-4131-93f8-b15140afd532@github.com>

On Thu, 24 Jun 2021 10:22:10 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed signed hex formats since "x" is unsigned by definition

This pull request has now been integrated.

Changeset: 2b8e9670
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2b8e9670688bb85da7c3c81b6822ecd50ef0a395
Stats:     19 lines in 3 files changed: 6 ins; 6 del; 7 mod

8269279: [lworld] 8269231 causes build failures

Reviewed-by: shade

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

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


From dsimms at openjdk.java.net  Thu Jun 24 10:59:49 2021
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 24 Jun 2021 10:59:49 GMT
Subject: [lworld] Integrated: Adjust testing
In-Reply-To: <wOE6CjL9t4X-E98zqlFK8cXB4EH8CBMVz5XRktOmh1Q=.4984fa89-1037-4a9e-ae6a-606dd1b088cf@github.com>
References: <wOE6CjL9t4X-E98zqlFK8cXB4EH8CBMVz5XRktOmh1Q=.4984fa89-1037-4a9e-ae6a-606dd1b088cf@github.com>
Message-ID: <S6Z_sbzkP9V1lCaTm8wmBwuRh0qRHWwPcODB47XFc1k=.c7e8b2af-8e21-40a4-8775-32dd3a3917d9@github.com>

On Thu, 24 Jun 2021 08:00:10 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem listed tests

This pull request has now been integrated.

Changeset: bfd6f2ca
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bfd6f2ca1ed66289423cb4746abe77ce472daa59
Stats:     15 lines in 2 files changed: 15 ins; 0 del; 0 mod

Adjust testing

Reviewed-by: shade

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

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


From roland at openjdk.java.net  Thu Jun 24 13:52:48 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 24 Jun 2021 13:52:48 GMT
Subject: [lworld] RFR: 8268021: [lworld] [AArch64] fix support for
 InlineTypeReturnedAsFields
In-Reply-To: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
References: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
Message-ID: <Wv6pguDOfY_livZXhiNX30NRkqH7gzF1FpbEBDurR3A=.40e8998e-0e71-4f1b-9918-df2986156380@github.com>

On Thu, 24 Jun 2021 05:53:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The code to support this on AArch64 was already mostly written but
> untested or bit-rotted. This patch also contains the allocation
> optimisation to MacroAssembler::store_inline_type_fields_to_buf() from
> JDK-8263067.

I didn't review this in details but given this is all aarch64 specific (except for one minor change), this is good to integrate. Do you want me to sponsor it?

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

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


From ngasson at openjdk.java.net  Fri Jun 25 07:59:26 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 25 Jun 2021 07:59:26 GMT
Subject: [lworld] RFR: 8268021: [lworld] [AArch64] fix support for
 InlineTypeReturnedAsFields
In-Reply-To: <Wv6pguDOfY_livZXhiNX30NRkqH7gzF1FpbEBDurR3A=.40e8998e-0e71-4f1b-9918-df2986156380@github.com>
References: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
 <Wv6pguDOfY_livZXhiNX30NRkqH7gzF1FpbEBDurR3A=.40e8998e-0e71-4f1b-9918-df2986156380@github.com>
Message-ID: <1Gp_jMqRyMr8-ByPMMpIWeFwfVaRyQ7yIBHArB6A3TU=.9223ff0d-0cae-4e5d-938e-1929365d93ee@github.com>

On Thu, 24 Jun 2021 13:49:53 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I didn't review this in details but given this is all aarch64 specific (except for one minor change), this is good to integrate. Do you want me to sponsor it?

Yes that would be great, thanks.

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

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


From roland at openjdk.java.net  Fri Jun 25 09:07:24 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 25 Jun 2021 09:07:24 GMT
Subject: [lworld] RFR: 8268021: [lworld] [AArch64] fix support for
 InlineTypeReturnedAsFields
In-Reply-To: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
References: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
Message-ID: <Fcuoo3U_f62TKkNx8RzPKzhWXJGim24PtDIXvryOZSc=.b62cf88d-1d86-4057-9969-c61fb2f1f31a@github.com>

On Thu, 24 Jun 2021 05:53:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The code to support this on AArch64 was already mostly written but
> untested or bit-rotted. This patch also contains the allocation
> optimisation to MacroAssembler::store_inline_type_fields_to_buf() from
> JDK-8263067.

First time I sponsor a change. It seems you have to do /integrate first.

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

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


From ngasson at openjdk.java.net  Fri Jun 25 09:21:15 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 25 Jun 2021 09:21:15 GMT
Subject: [lworld] Integrated: 8268021: [lworld] [AArch64] fix support for
 InlineTypeReturnedAsFields
In-Reply-To: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
References: <GSXt00dvjmYMGOPBzNXV0VfvdJ8RUd47abF6PXj9U40=.be21f626-108c-42ca-8e0c-6f45a35d9741@github.com>
Message-ID: <mzuYohFQgD6M1An0YVU8p1GQJuHC0u6gfaqgFHuVBuY=.94957aa6-7328-49d7-94af-94d3bda073d6@github.com>

On Thu, 24 Jun 2021 05:53:14 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> The code to support this on AArch64 was already mostly written but
> untested or bit-rotted. This patch also contains the allocation
> optimisation to MacroAssembler::store_inline_type_fields_to_buf() from
> JDK-8263067.

This pull request has now been integrated.

Changeset: 21090e04
Author:    Nick Gasson <ngasson at openjdk.org>
Committer: Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/21090e0447e66f527cb80265ac0418a655f862be
Stats:     260 lines in 8 files changed: 88 ins; 86 del; 86 mod

8268021: [lworld] [AArch64] fix support for InlineTypeReturnedAsFields

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

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


From hseigel at openjdk.java.net  Fri Jun 25 12:51:53 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 25 Jun 2021 12:51:53 GMT
Subject: [lworld] RFR: 8269274: [lworld] Withfield instruction fails to verify
 when operand stack contains LPrimitiveClass; 
Message-ID: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>

Please remove this small lworld fix to the verifier to no longer require that the withfield operand be a Q-type.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows.

Thanks, Harold

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

Commit messages:
 - 8269274: [lworld] Withfield instruction fails to verify when operand stack contains LPrimitiveClass;

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

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


From fparain at openjdk.java.net  Fri Jun 25 20:02:34 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 25 Jun 2021 20:02:34 GMT
Subject: RFR: JDK-8269408: [lworld] [lqagain] Withfield and field resolution
 update
Message-ID: <PK5JD4RiMBeI8gYhH3ejNsoEs5BxnNQ4hAcqJSdyHPE=.2374bc0e-52ff-405f-ba12-c69c1f23bf74@github.com>

Please review those changes in the interpreter and the field resolution code.

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

Thank you,

Fred

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

Commit messages:
 - More efficient interpreted withfield

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

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


From fparain at openjdk.java.net  Fri Jun 25 20:06:13 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 25 Jun 2021 20:06:13 GMT
Subject: [lworld] RFR: 8269274: [lworld] Withfield instruction fails to
 verify when operand stack contains LPrimitiveClass; 
In-Reply-To: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>
References: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>
Message-ID: <jTNzUDT_cVY233TFlJjVTfW2uCtoPZUwMDeWsRDdblo=.bbb99d32-05dc-49f8-a155-0b1e20671a63@github.com>

On Fri, 25 Jun 2021 12:45:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please remove this small lworld fix to the verifier to no longer require that the withfield operand be a Q-type.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

Looks good to me.

Fred

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

Marked as reviewed by fparain (Committer).

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


From forax at univ-mlv.fr  Sat Jun 26 16:52:41 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 26 Jun 2021 18:52:41 +0200 (CEST)
Subject: Release of ASM 9.2
Message-ID: <1786664033.1344516.1624726361471.JavaMail.zimbra@u-pem.fr>

Hi everybody,
we are happy to announce the release of ASM 9.2 which support Java 18 (available via Maven Central).

I still hope to find the time this summer to work of the support of Valhalla new bytecodes.

R?mi


From hseigel at openjdk.java.net  Mon Jun 28 12:51:11 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 28 Jun 2021 12:51:11 GMT
Subject: [lworld] Integrated: 8269274: [lworld] Withfield instruction fails to
 verify when operand stack contains LPrimitiveClass; 
In-Reply-To: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>
References: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>
Message-ID: <-7wBPuu6V7h7GGW05G2hRJI7Z7TXWJ2b7CvUIB4oCeI=.0658584a-6fdd-4656-bf66-e88ebacb701e@github.com>

On Fri, 25 Jun 2021 12:45:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please remove this small lworld fix to the verifier to no longer require that the withfield operand be a Q-type.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: b62a66e3
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/b62a66e379fda00a5ba4622da7661c89b380ecdf
Stats:     153 lines in 3 files changed: 142 ins; 8 del; 3 mod

8269274: [lworld] Withfield instruction fails to verify when operand stack contains LPrimitiveClass;

Reviewed-by: fparain

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

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


From hseigel at openjdk.java.net  Mon Jun 28 12:51:11 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 28 Jun 2021 12:51:11 GMT
Subject: [lworld] RFR: 8269274: [lworld] Withfield instruction fails to
 verify when operand stack contains LPrimitiveClass; 
In-Reply-To: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>
References: <4TetsLN6wK4lrTp6XUwieX7KGJ6vqxCLUtPpLSJNiUE=.d5ce187e-47f3-4fdd-8fd5-b5498c95d4a5@github.com>
Message-ID: <WE5_6NyQzy1lbBzTplbePC-sTFLwd2AQRL1DfbHBZ9M=.a26450f1-0e80-44e5-b24b-57af1f27f31b@github.com>

On Fri, 25 Jun 2021 12:45:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please remove this small lworld fix to the verifier to no longer require that the withfield operand be a Q-type.  The fix was tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

Thanks Fred!

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

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


From hseigel at openjdk.java.net  Mon Jun 28 18:17:55 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 28 Jun 2021 18:17:55 GMT
Subject: [lworld] RFR: 8269536: Fix verifier withfield test
Message-ID: <pQYiCIM6jOSJG9QJaGDDarAXQG6DqGLqKTbXxigbvxQ=.a59d817a-a397-4c29-97ac-a4090d048fb9@github.com>

Please review this small change to fix test VerifierInlineTypes.java.  The fix removes, from the jcod classes, improper and unneeded <init> methods that were causing unwanted ClassFormatError exceptions.  The change also removes tests that are no longer applicable.

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

Thanks, Harold

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

Commit messages:
 - 8269536: Fix verifier withfield test

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

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


From ngasson at openjdk.java.net  Tue Jun 29 10:33:35 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 29 Jun 2021 10:33:35 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after JDK-8267824
Message-ID: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>

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

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

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

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

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


From fparain at openjdk.java.net  Tue Jun 29 12:17:39 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 29 Jun 2021 12:17:39 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
Message-ID: <yzLFdTvTNowqOLAxySBTvt2gniGycRlhZhIKbUQr4Xg=.633eed11-cfc5-49cd-bb96-800f56e9fa93@github.com>

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

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

Looks good to me (I'm not an aarch64 expert, but changes seem to align aarch64 code with the changes made to the x86 code).

Fred

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

Marked as reviewed by fparain (Committer).

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


From hseigel at openjdk.java.net  Tue Jun 29 14:52:12 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 29 Jun 2021 14:52:12 GMT
Subject: RFR: 8269274: [lworld] Withfield instruction fails to verify when
 operand stack contains LPrimitiveClass; 
Message-ID: <m_dIagEHZpIHN0-GwtXBPwrexWBm8V5wpAmpJmVntOo=.a883a662-8fe1-4377-8ae3-4c4de0842c71@github.com>

Please review this backport of the fix for JDK-8269274 from lworld to lqagain.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.

Thanks, Harold

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

Commit messages:
 - 8269274: [lworld] Withfield instruction fails to verify when operand stack contains LPrimitiveClass;

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

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


From shade at openjdk.java.net  Tue Jun 29 14:58:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 29 Jun 2021 14:58:25 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
Message-ID: <ftYFBEO1heGTnvAn_KzhoYquKYfjoI5Mk8SCYitRs_Q=.7abb8da1-1798-4b5e-aa20-ff4806bcd51f@github.com>

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

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

This is nice! I meant to address this build failure this week. It builds on aarch64 machine for me. There are seem to be some unrelated C2 test failures.

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

Marked as reviewed by shade (no project role).

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


From hseigel at openjdk.java.net  Tue Jun 29 17:14:25 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 29 Jun 2021 17:14:25 GMT
Subject: Integrated: 8269274: [lworld] Withfield instruction fails to verify
 when operand stack contains LPrimitiveClass; 
In-Reply-To: <m_dIagEHZpIHN0-GwtXBPwrexWBm8V5wpAmpJmVntOo=.a883a662-8fe1-4377-8ae3-4c4de0842c71@github.com>
References: <m_dIagEHZpIHN0-GwtXBPwrexWBm8V5wpAmpJmVntOo=.a883a662-8fe1-4377-8ae3-4c4de0842c71@github.com>
Message-ID: <Py5iTTFgs6NgKI8yLgEV3KzX_loSCsalkgUNZ64w7tQ=.37dd1d62-76aa-4bc9-9516-3ebe8af37821@github.com>

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

> Please review this backport of the fix for JDK-8269274 from lworld to lqagain.  The fix was tested by running Mach5 tiers 1 and 2 on Linux, Mac OS, and Windows.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: 770e5f3b
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/770e5f3bfc454a8a1fd212544c4c0da9abfbf7c6
Stats:     153 lines in 3 files changed: 142 ins; 8 del; 3 mod

8269274: [lworld] Withfield instruction fails to verify when operand stack contains LPrimitiveClass;

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

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


From hseigel at openjdk.java.net  Tue Jun 29 20:44:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 29 Jun 2021 20:44:44 GMT
Subject: RFR: 8269536: Fix verifier withfield test
Message-ID: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>

Please review this small change to fix test VerifierInlineTypes.java. The fix removes from the jcod classes improper and unneeded methods that were causing unwanted ClassFormatError exceptions. The change also removes tests that are no longer applicable. Finally, it merges NoNullVT.jcod into verifierTests.jcod.

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

Thanks, Harold

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

Commit messages:
 - 8269536: Fix verifier withfield test

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

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


From hseigel at openjdk.java.net  Tue Jun 29 20:54:13 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 29 Jun 2021 20:54:13 GMT
Subject: [lworld] Withdrawn: 8269536: Fix verifier withfield test
In-Reply-To: <pQYiCIM6jOSJG9QJaGDDarAXQG6DqGLqKTbXxigbvxQ=.a59d817a-a397-4c29-97ac-a4090d048fb9@github.com>
References: <pQYiCIM6jOSJG9QJaGDDarAXQG6DqGLqKTbXxigbvxQ=.a59d817a-a397-4c29-97ac-a4090d048fb9@github.com>
Message-ID: <PovdNZVEPVHPDd_a3wzYtbttKDNv-qEqKyzfdvWzDrk=.2f34d82b-0c21-4f98-b5e8-e79a458fde9a@github.com>

On Mon, 28 Jun 2021 18:11:07 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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


From hseigel at openjdk.java.net  Tue Jun 29 20:54:13 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 29 Jun 2021 20:54:13 GMT
Subject: [lworld] RFR: 8269536: Fix verifier withfield test
In-Reply-To: <pQYiCIM6jOSJG9QJaGDDarAXQG6DqGLqKTbXxigbvxQ=.a59d817a-a397-4c29-97ac-a4090d048fb9@github.com>
References: <pQYiCIM6jOSJG9QJaGDDarAXQG6DqGLqKTbXxigbvxQ=.a59d817a-a397-4c29-97ac-a4090d048fb9@github.com>
Message-ID: <lXlV7b0GZuWwRE3ZCIlVgSpq4GbXgNl1Y_oGdI2PYpw=.4f15b014-bea1-4abb-9676-4d30657a5924@github.com>

On Mon, 28 Jun 2021 18:11:07 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

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

Pushing this fix into branch lqagain instead of lworld.

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

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


From ngasson at openjdk.java.net  Wed Jun 30 01:48:20 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 30 Jun 2021 01:48:20 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <yzLFdTvTNowqOLAxySBTvt2gniGycRlhZhIKbUQr4Xg=.633eed11-cfc5-49cd-bb96-800f56e9fa93@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
 <yzLFdTvTNowqOLAxySBTvt2gniGycRlhZhIKbUQr4Xg=.633eed11-cfc5-49cd-bb96-800f56e9fa93@github.com>
Message-ID: <EWE5YjIwpnkXF_z6CiKEm7N3m1IV5UOnIcbchrrTOy4=.c1d43cd6-3b80-464a-af81-6334fb4c173c@github.com>

On Tue, 29 Jun 2021 12:13:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Replace ConstantPoolCacheEntry::is_inline_type_shift with
>> is_null_free_inline_type_shift and change inline_type to
>> null_free_inline_type in a few other places to match x86.
>
> Looks good to me (I'm not an aarch64 expert, but changes seem to align aarch64 code with the changes made to the x86 code).
> 
> Fred

Thanks for the reviews @fparain, @shipilev

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

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


From ngasson at openjdk.java.net  Wed Jun 30 01:48:19 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 30 Jun 2021 01:48:19 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <ftYFBEO1heGTnvAn_KzhoYquKYfjoI5Mk8SCYitRs_Q=.7abb8da1-1798-4b5e-aa20-ff4806bcd51f@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
 <ftYFBEO1heGTnvAn_KzhoYquKYfjoI5Mk8SCYitRs_Q=.7abb8da1-1798-4b5e-aa20-ff4806bcd51f@github.com>
Message-ID: <nFj6XiCCrWy5le2u1seWDpsC_6GaYtO2tcY0HSPQdH8=.82dab6e8-f813-4cd1-83fd-6ef253555f69@github.com>

On Tue, 29 Jun 2021 14:55:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are seem to be some unrelated C2 test failures.

The ones I know about are:

compiler/valhalla/inlinetypes/TestLWorld.java

Assertion failure in OopFlow::build_oop_map(). I raised JDK-8264340 for this.

compiler/valhalla/inlinetypes/TestArrays.java
compiler/valhalla/inlinetypes/TestNullableArrays.java

Fail to find some expected patterns in the opto assembly output. This should be trivial to fix - just need to adjust the regexps to match the AArch64 output - but conflicts with #457.

Did you see any other failures?

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

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


From shade at openjdk.java.net  Wed Jun 30 09:03:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Jun 2021 09:03:25 GMT
Subject: [lworld] RFR: 8269578: [lworld] fix AArch64 build after
 JDK-8267824
In-Reply-To: <nFj6XiCCrWy5le2u1seWDpsC_6GaYtO2tcY0HSPQdH8=.82dab6e8-f813-4cd1-83fd-6ef253555f69@github.com>
References: <rnDZiboxFgAqcZRlNIbK0XqEDqjzzChcL43G82zHb9M=.4201c196-b3d7-4a05-a247-a9b515cecf91@github.com>
 <ftYFBEO1heGTnvAn_KzhoYquKYfjoI5Mk8SCYitRs_Q=.7abb8da1-1798-4b5e-aa20-ff4806bcd51f@github.com>
 <nFj6XiCCrWy5le2u1seWDpsC_6GaYtO2tcY0HSPQdH8=.82dab6e8-f813-4cd1-83fd-6ef253555f69@github.com>
Message-ID: <Z-1UwuUbdv_4_BUsJ-TNzUnE8Gh-uI-hcM-jOaU-uNw=.b6d72b58-9394-4409-b0f5-679d53c52f69@github.com>

On Wed, 30 Jun 2021 01:45:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Did you see any other failures?

No, only those. I think this PR should be integrated first anyhow.

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

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


From fparain at openjdk.java.net  Wed Jun 30 20:27:20 2021
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 30 Jun 2021 20:27:20 GMT
Subject: RFR: 8269536: Fix verifier withfield test
In-Reply-To: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>
References: <8Hc4AfLsaFGvLAUJu3deVxkwE-O37gb-OnjK5yG44sE=.b293aac6-5352-4d05-b75a-e2876c51ea85@github.com>
Message-ID: <ZpNQQFDp2OpCwrnw6CExr7nMDi92tfbCiUyPs4pCmOA=.1dcfc6a2-5916-42d5-81a7-07a45caebe76@github.com>

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

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

Looks good to me.
However, we should re-implement those tests for the runtime (instead of the verifier) because this is where checks are performed now (could be a follow-up CR).

Fred

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

Marked as reviewed by fparain (Committer).

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