From sadayapalam at openjdk.java.net  Mon Nov  2 07:46:10 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 2 Nov 2020 07:46:10 GMT
Subject: [lworld] Integrated: 8255727: [lworld] Withdraw support for
 @java.lang.ValueBased
Message-ID: <RqHruv67Sxn50fonQwQZBDyO-y4bXAMnEYor9SBmwho=.63fb9805-163c-4943-86c1-db19bdd15011@github.com>

Withdraw support for @java.lang.ValueBased types as such support has become stale in many ways, gathered bitrot and will in anycase be superceded by jep390 when merged in.

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

Commit messages:
 - 8255727: [lworld] Withdraw support for @java.lang.ValueBased

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

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


From sadayapalam at openjdk.java.net  Mon Nov  2 07:46:11 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 2 Nov 2020 07:46:11 GMT
Subject: [lworld] Integrated: 8255727: [lworld] Withdraw support for
 @java.lang.ValueBased
In-Reply-To: <RqHruv67Sxn50fonQwQZBDyO-y4bXAMnEYor9SBmwho=.63fb9805-163c-4943-86c1-db19bdd15011@github.com>
References: <RqHruv67Sxn50fonQwQZBDyO-y4bXAMnEYor9SBmwho=.63fb9805-163c-4943-86c1-db19bdd15011@github.com>
Message-ID: <bq21vXE5HDBTTKgMIyNZxDJIqNOJL_yHS8K_EsgHO60=.5e4e4545-d398-4a2b-9cb1-b8fa4ba73a73@github.com>

On Mon, 2 Nov 2020 07:38:38 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Withdraw support for @java.lang.ValueBased types as such support has become stale in many ways, gathered bitrot and will in anycase be superceded by jep390 when merged in.

This pull request has now been integrated.

Changeset: 25a3ae8e
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/25a3ae8e
Stats:     386 lines in 25 files changed: 2 ins; 379 del; 5 mod

8255727: [lworld] Withdraw support for @java.lang.ValueBased

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

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


From sadayapalam at openjdk.java.net  Mon Nov  2 09:59:10 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Mon, 2 Nov 2020 09:59:10 GMT
Subject: RFR: 8255733: [type-restrictions] Enhance Javac to help with
 generation of test files for type restrictions experiments
Message-ID: <CNled7tI6-pLLr_RGMY6QbVcqEfWwVpeDUAgB2W6AqU=.797ac016-e8d1-44fb-b6c8-1a6c0eb9e0f7@github.com>

Added option -XDflattenWithErasure to generate class files without the RestrictedField attribute

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

Commit messages:
 - 8255733: [type-restrictions] Enhance Javac to help with generation of test files for type restrictions experiments

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

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


From dsimms at openjdk.java.net  Mon Nov  2 11:43:13 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 2 Nov 2020 11:43:13 GMT
Subject: [lworld] Integrated: GitHub actions ignore main project branches
Message-ID: <LfqNziEiPvzdNFG85cAkdCHJXoupJTAeWKa8muzOSpk=.96f3d577-f4e6-4aa4-9023-dc66938d8d8a@github.com>

Ignore branches (when sync-ing in PF, causes extra work)

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

Commit messages:
 - Syntax 4
 - Syntax 3
 - Syntax 2
 - Syntax 1
 - GH actions ignore main branches

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

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


From dsimms at openjdk.java.net  Mon Nov  2 11:43:14 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 2 Nov 2020 11:43:14 GMT
Subject: [lworld] Integrated: GitHub actions ignore main project branches
In-Reply-To: <LfqNziEiPvzdNFG85cAkdCHJXoupJTAeWKa8muzOSpk=.96f3d577-f4e6-4aa4-9023-dc66938d8d8a@github.com>
References: <LfqNziEiPvzdNFG85cAkdCHJXoupJTAeWKa8muzOSpk=.96f3d577-f4e6-4aa4-9023-dc66938d8d8a@github.com>
Message-ID: <T9pILi43XOeJUUdNGD4KDZpTp_uFEfWlgq5jBFESFZI=.d513bffa-0913-40a0-850d-f771bba630b1@github.com>

On Mon, 2 Nov 2020 11:35:57 GMT, David Simms <dsimms at openjdk.org> wrote:

> Ignore branches (when sync-ing in PF, causes extra work)

This pull request has now been integrated.

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

GitHub actions ignore main project branches

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

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


From dsimms at openjdk.java.net  Mon Nov  2 12:11:10 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 2 Nov 2020 12:11:10 GMT
Subject: [lworld] RFR: GH workflow syntax
Message-ID: <kaelBT4-9kg-m4o7RVlKGlH6Tc7slSeuLGWBbLatpMo=.51ade0a9-023e-4386-841b-78a6b710a67e@github.com>

type-restrictions still triggered

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

Commit messages:
 - Syntax 5

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

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


From dsimms at openjdk.java.net  Mon Nov  2 12:18:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 2 Nov 2020 12:18:11 GMT
Subject: [lworld] Integrated: GH workflow syntax
In-Reply-To: <kaelBT4-9kg-m4o7RVlKGlH6Tc7slSeuLGWBbLatpMo=.51ade0a9-023e-4386-841b-78a6b710a67e@github.com>
References: <kaelBT4-9kg-m4o7RVlKGlH6Tc7slSeuLGWBbLatpMo=.51ade0a9-023e-4386-841b-78a6b710a67e@github.com>
Message-ID: <blKOgD7RJEgAs_03vTVXa6mMiSwNFgStfTu7YrGVgro=.9830651b-a18c-472d-9599-251490152890@github.com>

On Mon, 2 Nov 2020 12:05:36 GMT, David Simms <dsimms at openjdk.org> wrote:

> type-restrictions still triggered

This pull request has now been integrated.

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

GH workflow syntax

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

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


From fparain at openjdk.java.net  Mon Nov  2 16:02:13 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 2 Nov 2020 16:02:13 GMT
Subject: [lworld] RFR: 8255522: [lworld] References to biased pattern
 remain in markWord::is_unlocked()
In-Reply-To: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
References: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
Message-ID: <slBsaOhiSP37J-eMGOHLkmwjvB_bBI-D9fko-mwYG9g=.90447694-7906-4923-b1ad-1994ce012ba3@github.com>

On Wed, 28 Oct 2020 14:56:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> * more gtest mark word tests
> * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking")
> * remove biased_lock_mask_in_place from is_unlocked

Guarding around the bias pattern seems good.

I'm wondering if  is_neutral() could benefit from a comment that both the 2 lock bits and the inline type bit are tested in a single operation (unlocked_value is usually used on the two last bits, but in this case, it is used on the last three bits).

There're still a lot of calls to has_bias_pattern() in the zero interpreter, but I'm not sure would should take care of that.

Fred

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

Marked as reviewed by fparain (Committer).

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


From rriggs at openjdk.java.net  Mon Nov  2 20:04:01 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 2 Nov 2020 20:04:01 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v4]
In-Reply-To: <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
Message-ID: <AX2KyDdtDmuiD4HhDvvcpohjXBBOS49DKhTjkVo-IJA=.4f9280c9-d43b-414f-acd5-b42c45f5e8ff@github.com>

On Fri, 16 Oct 2020 22:51:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
>> 
>> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing additional review comments for ValueBased.html

src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 42:

> 40:     <li>the class declares implementations of <code>equals</code>,
> 41:         <code>hashCode</code>, and <code>toString</code> which are computed
> 42:         solely from the values of the class's instance fields (and properties of

Can the word "properties" be avoided,m here and above? It it a loaded term.  Perhaps attributes?

src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 50:

> 48:     <li>the class performs no synchronization using an instance's monitor;</li>
> 49:     <li>the class does not declare (or has deprecated any) accessible constructors;</li>
> 50:     <li>the class does not provide any other instance creation mechanism that promises

The "other" in "any other" is unnecessary.  
`The class does not provide any instance creation mechanism that promises a unique identity.`
<full stop>
I don't know that the second part means in practice.  What does 'allow for the possibility', apply to?
It seems apply to the factory method. Is there an example where the factory method needs to take some particular action or make some condition true?  If two instances are `==` then it is more likely that other methods would be interested in that, not the factory method.

src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 60:

> 58:     <li>
> 59: </ul>
> 60: 

Perhaps as an intro to the following points to make it clear these are about what a program should and should not do.
Should use equals(); should use explicit synchronization using lock objects or instances that are not value-based classes, etc.
`Programs should not attempt to distinguish the identities of value based class instances, otherwise the result may be unpredictable.`

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

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


From rriggs at openjdk.java.net  Mon Nov  2 21:20:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 2 Nov 2020 21:20:06 GMT
Subject: RFR: 8254271: Development to deprecate wrapper class constructors
 for removal
In-Reply-To: <fPv90KEourOVaZyxSKrEHpG76FWaaDnKYLBHrSTEE30=.9301b064-38cf-41d5-9952-7c238c943b2d@github.com>
References: <UAUHQ3O4Ocw_FajCm1pmUOcdQ_cwToYMgh2FLsSDcQc=.757acf75-5d99-4f45-95a5-37ef58acc09a@github.com>
 <f9WfxbuKd4xkZzqWpcDP7Y261ffXKPhymgj_sSNDueI=.79a9a857-6ab9-47f6-b74b-8d13bd33af2d@github.com>
 <VUN33Qr443HtgSkJvweIsAfYPtPqBi05kVRe9HyxXIk=.44863d24-0192-4e12-884d-f8a9a13746c2@github.com>
 <fPv90KEourOVaZyxSKrEHpG76FWaaDnKYLBHrSTEE30=.9301b064-38cf-41d5-9952-7c238c943b2d@github.com>
Message-ID: <Z75cI86hTQAnThpp1yh5lsojcsp4seLq7OBN6dX9ZjA=.44f01c79-f616-45db-af19-dbc14ba7fccc@github.com>

On Tue, 13 Oct 2020 21:40:09 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Have you considered rephrasing the reference to constructors in the `valueOf` methods?:
> 
> ```
>      * If a new {@code Byte} instance is not required, this method
>      * should generally be used in preference to the constructor
>      * {@link #Byte(byte)}
> ```
> 
> The message now is "Don't use the constructors! Don't try to get a new instance!"

I think "if ... is not required" covers the case already. The behavior of Integer is not changing.
The valueOf() method is already the recommendation.

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

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


From mchung at openjdk.java.net  Mon Nov  2 22:04:06 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 2 Nov 2020 22:04:06 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v4]
In-Reply-To: <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
Message-ID: <_netsCVXfd6Ja_ON5eL73L0qrRfdhViJig7mv4-t0dk=.1bea8c6b-9428-4188-8893-d7a5f0043723@github.com>

On Fri, 16 Oct 2020 22:51:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
>> 
>> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing additional review comments for ValueBased.html

Marked as reviewed by mchung (Reviewer).

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

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


From skuksenko at openjdk.java.net  Tue Nov  3 06:06:09 2020
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Tue, 3 Nov 2020 06:06:09 GMT
Subject: [lworld] RFR: 8255522: [lworld] References to biased pattern
 remain in markWord::is_unlocked()
In-Reply-To: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
References: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
Message-ID: <xHxjnPgRGxclLOIsQxkEzzoS1fwStmJIW4f6CNPawRg=.1ec1c602-bcb4-47db-95ec-08683137de82@github.com>

On Wed, 28 Oct 2020 14:56:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> * more gtest mark word tests
> * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking")
> * remove biased_lock_mask_in_place from is_unlocked

It looks good for me.
With very minor notes.
Now biased_lock_pattern and inline_type_pattern are equals.The comment that EnableValhalla and UseBiasedLocking can't be set to true both is located higher in the markWord.hpp text. Maybe it's make sense to repeat it near that constants? To make it more clear.

How frequently "markWord::print_on" is used? Should we add printing "inline type" markword info?

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

Marked as reviewed by skuksenko (Committer).

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


From romanowski.mateusz at gmail.com  Wed Nov  4 20:07:35 2020
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Wed, 4 Nov 2020 21:07:35 +0100
Subject: Keeping `new Integer` source compatibility with unnamed factory method
Message-ID: <CAL-BTSqc+NywzQz-LzCeEjdMMbkhAJzmJdmrA5+Gsx3ubXKeBQ@mail.gmail.com>

Hi All,
regarding the summary of the last EG meeting (2020-11-04) [1], I can see a
future me being frustrated with having to keep some dusty `javac` only
because of some _mature_ code generation tool that "optimizes" by using
`Integer::new`.

Is the "something special" to keep `Integer::new` source compatibility
adding an `Integer::new` (and similarly `Object::new`) unnamed factory
method?

Sorry if I have missed any material discussions related to such an idea.

Cheers,
Mateusz Romanowski

[1]
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-November/001446.html
[2]
http://cr.openjdk.java.net/~dlsmith/special-methods/special-methods-20200210/specs/factory-methods-jvms.html#jvms-2.9.4


From forax at univ-mlv.fr  Wed Nov  4 21:16:36 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 4 Nov 2020 22:16:36 +0100 (CET)
Subject: Keeping `new Integer` source compatibility with unnamed factory
 method
In-Reply-To: <CAL-BTSqc+NywzQz-LzCeEjdMMbkhAJzmJdmrA5+Gsx3ubXKeBQ@mail.gmail.com>
References: <CAL-BTSqc+NywzQz-LzCeEjdMMbkhAJzmJdmrA5+Gsx3ubXKeBQ@mail.gmail.com>
Message-ID: <251040858.2360587.1604524596252.JavaMail.zimbra@u-pem.fr>

Hi Mateusz,

----- Mail original -----
> De: "Mateusz Romanowski" <romanowski.mateusz at gmail.com>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Mercredi 4 Novembre 2020 21:07:35
> Objet: Keeping `new Integer` source compatibility with unnamed factory method

> Hi All,
> regarding the summary of the last EG meeting (2020-11-04) [1], I can see a
> future me being frustrated with having to keep some dusty `javac` only
> because of some _mature_ code generation tool that "optimizes" by using
> `Integer::new`.

You can pro-actively already create a pull request to ask this mature tool to use Integer::valueOf instead of Integer::new.
But you're right that this is a real issue that will hinder the adoption of Valhalla.

> 
> Is the "something special" to keep `Integer::new` source compatibility
> adding an `Integer::new` (and similarly `Object::new`) unnamed factory
> method?
> 
> Sorry if I have missed any material discussions related to such an idea.

In the Valhalla world, Integer is not a concrete class anymore but a subtype of int, exactly a subtype of int sees as a primitive object), that why you can not instantiate it directly anymore.

So currently, we are weighting our option more than we are making decision on which backward compatible strategy we want to use, source backward compatible vs binary backward compatible.

So we may still allow to use new Integer()/Integer::new in the source code, to allow any tools that generates Java code to still work but it means that the compiler will have to rewrite it to be Integer.valueOf, which can be very surprising,
by example,
  new Integer(2) == new Integer(2)
will now return true.

And in that case, we have several ways to do it. We can do that in the library, creating an unnamed factory method that calls Integer.valueOf() as you are suggesting or we can do it directly in the compiler by rewriting all occurrences of new Integer().

> 
> Cheers,
> Mateusz Romanowski

regards,
R?mi

> 
> [1]
> https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-November/001446.html
> [2]
> http://cr.openjdk.java.net/~dlsmith/special-methods/special-methods-20200210/specs/factory-methods-jvms.html#jvms-2.9.4


From dlsmith at openjdk.java.net  Thu Nov  5 00:27:07 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Thu, 5 Nov 2020 00:27:07 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v4]
In-Reply-To: <AX2KyDdtDmuiD4HhDvvcpohjXBBOS49DKhTjkVo-IJA=.4f9280c9-d43b-414f-acd5-b42c45f5e8ff@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
 <AX2KyDdtDmuiD4HhDvvcpohjXBBOS49DKhTjkVo-IJA=.4f9280c9-d43b-414f-acd5-b42c45f5e8ff@github.com>
Message-ID: <LO9-fscUeFSV2-Lel1d8J2jX0jnMBkGzHgf7IBVhgy8=.7049c540-6080-439f-9d81-3e7e1f96fa3f@github.com>

On Mon, 2 Nov 2020 19:43:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing additional review comments for ValueBased.html
>
> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 42:
> 
>> 40:     <li>the class declares implementations of <code>equals</code>,
>> 41:         <code>hashCode</code>, and <code>toString</code> which are computed
>> 42:         solely from the values of the class's instance fields (and properties of
> 
> Can the word "properties" be avoided,m here and above? It it a loaded term.  Perhaps attributes?

"members" would be the idiomatic Java word, I suppose

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

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


From dlsmith at openjdk.java.net  Thu Nov  5 00:34:06 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Thu, 5 Nov 2020 00:34:06 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v4]
In-Reply-To: <AX2KyDdtDmuiD4HhDvvcpohjXBBOS49DKhTjkVo-IJA=.4f9280c9-d43b-414f-acd5-b42c45f5e8ff@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
 <AX2KyDdtDmuiD4HhDvvcpohjXBBOS49DKhTjkVo-IJA=.4f9280c9-d43b-414f-acd5-b42c45f5e8ff@github.com>
Message-ID: <IJKqwlKZAm203NbRijxT6l_q1hohLUCAhQYRY9Poms4=.e50f3d09-5692-4e3b-8c39-f54874aeb674@github.com>

On Mon, 2 Nov 2020 19:48:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressing additional review comments for ValueBased.html
>
> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 50:
> 
>> 48:     <li>the class performs no synchronization using an instance's monitor;</li>
>> 49:     <li>the class does not declare (or has deprecated any) accessible constructors;</li>
>> 50:     <li>the class does not provide any other instance creation mechanism that promises
> 
> The "other" in "any other" is unnecessary.  
> `The class does not provide any instance creation mechanism that promises a unique identity.`
> <full stop>
> I don't know that the second part means in practice.  What does 'allow for the possibility', apply to?
> It seems apply to the factory method. Is there an example where the factory method needs to take some particular action or make some condition true?  If two instances are `==` then it is more likely that other methods would be interested in that, not the factory method.

Agree, I can drop "other".

The intent is that there's a restriction on a factory method's *contract*. I can make that explicit: "any factory method's contract must allow for the possibility..."

> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 60:
> 
>> 58:     <li>
>> 59: </ul>
>> 60: 
> 
> Perhaps as an intro to the following points to make it clear these are about what a program should and should not do.
> Should use equals(); should use explicit synchronization using lock objects or instances that are not value-based classes, etc.
> `Programs should not attempt to distinguish the identities of value based class instances, otherwise the result may be unpredictable.`

I'm not totally following. This is a revision to the "When two instances" paragraph? Can you propose an alternative phrasing for the entire paragraph?

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

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


From rriggs at openjdk.java.net  Thu Nov  5 16:26:03 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 Nov 2020 16:26:03 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v4]
In-Reply-To: <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
Message-ID: <YdJKyC5LYOhQN1Omk15jFuaKWuAwU_WKYwSp2298pJ4=.0330988c-567b-4c1a-bb3e-5f3781f414ee@github.com>

On Fri, 16 Oct 2020 22:51:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
>> 
>> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing additional review comments for ValueBased.html

Marked as reviewed by rriggs (Reviewer).

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

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


From rriggs at openjdk.java.net  Thu Nov  5 16:26:04 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 Nov 2020 16:26:04 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v4]
In-Reply-To: <IJKqwlKZAm203NbRijxT6l_q1hohLUCAhQYRY9Poms4=.e50f3d09-5692-4e3b-8c39-f54874aeb674@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <lkzLq6G7jbAty6zgdt990GFAl0p5XHpZwkMxQgvZYAk=.90cd2629-96e9-40a6-8dbb-36897040a402@github.com>
 <AX2KyDdtDmuiD4HhDvvcpohjXBBOS49DKhTjkVo-IJA=.4f9280c9-d43b-414f-acd5-b42c45f5e8ff@github.com>
 <IJKqwlKZAm203NbRijxT6l_q1hohLUCAhQYRY9Poms4=.e50f3d09-5692-4e3b-8c39-f54874aeb674@github.com>
Message-ID: <AeUzqRaFgHWiJakB2ylhCtQfDHOq69b40TuytRrASik=.8ea17e4e-e0ae-46fe-97ac-a45472234040@github.com>

On Thu, 5 Nov 2020 00:30:57 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 60:
>> 
>>> 58:     <li>
>>> 59: </ul>
>>> 60: 
>> 
>> Perhaps as an intro to the following points to make it clear these are about what a program should and should not do.
>> Should use equals(); should use explicit synchronization using lock objects or instances that are not value-based classes, etc.
>> `Programs should not attempt to distinguish the identities of value based class instances, otherwise the result may be unpredictable.`
>
> I'm not totally following. This is a revision to the "When two instances" paragraph? Can you propose an alternative phrasing for the entire paragraph?

These two paragraphs are fine, they express the negative, not what a developer should do.

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

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


From sergey.kuksenko at oracle.com  Thu Nov  5 18:09:52 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Thu, 5 Nov 2020 10:09:52 -0800
Subject: Question about hack in templateTable_x86.cpp
Message-ID: <a5edf7b3-6712-ca7e-0150-45a823ff6f1e@oracle.com>

Here is the code:

void TemplateTable::if_acmp(Condition cc) {
   transition(atos,vtos);
   // assume branch is more often taken than not (loops use backward 
branches) Label taken, not_taken;
   __ pop_ptr(rdx);

   __ profile_acmp(rbx, rdx, rax, rcx);

   if (EnableValhalla) {
       __ cmpoop(rdx, rax);
       __ jcc(Assembler::equal, (cc ==equal) ? taken : not_taken);

     // might be substitutable, test if either rax or rdx is null __ testptr(rdx, rax);
     __ jcc(Assembler::zero, (cc ==equal) ? not_taken : taken);

The last "test" does simultaneous check either one of oops is null. I 
really like that hack, but I am not sure.

What if we've got two non-null pointers which just have different bits? 
That hack may work only if we know that ANY two pointers have some ones 
at the same bit position. Do we have such assurance?




From john.r.rose at oracle.com  Thu Nov  5 23:09:00 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 5 Nov 2020 15:09:00 -0800
Subject: Question about hack in templateTable_x86.cpp
In-Reply-To: <a5edf7b3-6712-ca7e-0150-45a823ff6f1e@oracle.com>
References: <a5edf7b3-6712-ca7e-0150-45a823ff6f1e@oracle.com>
Message-ID: <94978B59-5F0A-4A42-946E-7F685F8439D5@oracle.com>

On Nov 5, 2020, at 10:09 AM, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
> 
>    // might be substitutable, test if either rax or rdx is null __ testptr(rdx, rax);
>    __ jcc(Assembler::zero, (cc ==equal) ? not_taken : taken);
> 
> The last "test" does simultaneous check either one of oops is null. I really like that hack, but I am not sure.
> 
> What if we've got two non-null pointers which just have different bits? That hack may work only if we know that ANY two pointers have some ones at the same bit position. Do we have such assurance?

Not in general.  If you look at verify_oop_mask and verify_oop_bits,
you might be able to reassure yourself that this works out OK.
In particular, we need both values to be non-zero.

The macro here should do this, and fall back to reliable code (such
as a CC-testing bitwise OR) if the reassurance fails, or at least fail
to boot the JVM.

See Universe::calculate_verify_data for where these bits come from.

? John

From sergey.kuksenko at oracle.com  Fri Nov  6 01:34:45 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Thu, 5 Nov 2020 17:34:45 -0800
Subject: Question about hack in templateTable_x86.cpp
In-Reply-To: <94978B59-5F0A-4A42-946E-7F685F8439D5@oracle.com>
References: <a5edf7b3-6712-ca7e-0150-45a823ff6f1e@oracle.com>
 <94978B59-5F0A-4A42-946E-7F685F8439D5@oracle.com>
Message-ID: <92edcc47-766d-fa10-a467-0e9f92d9f150@oracle.com>


On 11/5/20 3:09 PM, John Rose wrote:
> On Nov 5, 2020, at 10:09 AM, Sergey Kuksenko 
> <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>>
>> ???// might be substitutable, test if either rax or rdx is null __ 
>> testptr(rdx, rax);
>> ???__ jcc(Assembler::zero, (cc ==equal) ? not_taken : taken);
>>
>> The last "test" does simultaneous check either one of oops is null. I 
>> really like that hack, but I am not sure.
>>
>> What if we've got two non-null pointers which just have different 
>> bits? That hack may work only if we know that ANY two pointers have 
>> some ones at the same bit position. Do we have such assurance?
>
> Not in general. ?If you look at?verify_oop_mask and?verify_oop_bits,
> you might be able to reassure yourself that this works out OK.
> In particular, we need both values to be non-zero.
>
> The macro here should do this, and fall back to reliable code (such
> as a CC-testing bitwise OR) if the reassurance fails, or at least fail
> to boot the JVM.
>
> See?Universe::calculate_verify_data for where these bits come from.

I don't want to be boring, just want to understand it for myself.

"calculate_verify_data" finds high bits common prefix for min/max heap 
addresses. What if that high common prefix is all zeros or even zero length?

For example, in ZGC we use:

Universe::calculate_verify_data((HeapWord*)0, (HeapWord*)UINTPTR_MAX);

In that case prefix mask/bits will be zeros.





From john.r.rose at oracle.com  Fri Nov  6 01:40:53 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 5 Nov 2020 17:40:53 -0800
Subject: Question about hack in templateTable_x86.cpp
In-Reply-To: <92edcc47-766d-fa10-a467-0e9f92d9f150@oracle.com>
References: <a5edf7b3-6712-ca7e-0150-45a823ff6f1e@oracle.com>
 <94978B59-5F0A-4A42-946E-7F685F8439D5@oracle.com>
 <92edcc47-766d-fa10-a467-0e9f92d9f150@oracle.com>
Message-ID: <ED6061AE-067E-48B7-A354-68B1B0BB84FC@oracle.com>

On Nov 5, 2020, at 5:34 PM, Sergey Kuksenko <sergey.kuksenko at oracle.com> wrote:
> On 11/5/20 3:09 PM, John Rose wrote:
>> On Nov 5, 2020, at 10:09 AM, Sergey Kuksenko <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>>> 
>>>    // might be substitutable, test if either rax or rdx is null __ testptr(rdx, rax);
>>>    __ jcc(Assembler::zero, (cc ==equal) ? not_taken : taken);
>>> 
>>> The last "test" does simultaneous check either one of oops is null. I really like that hack, but I am not sure.
>>> 
>>> What if we've got two non-null pointers which just have different bits? That hack may work only if we know that ANY two pointers have some ones at the same bit position. Do we have such assurance?
>> 
>> Not in general.  If you look at verify_oop_mask and verify_oop_bits,
>> you might be able to reassure yourself that this works out OK.
>> In particular, we need both values to be non-zero.
>> 
>> The macro here should do this, and fall back to reliable code (such
>> as a CC-testing bitwise OR) if the reassurance fails, or at least fail
>> to boot the JVM.
>> 
>> See Universe::calculate_verify_data for where these bits come from.
> I don't want to be boring, just want to understand it for myself.
> 
> "calculate_verify_data" finds high bits common prefix for min/max heap addresses. What if that high common prefix is all zeros or even zero length?
> 
> For example, in ZGC we use:
> 
> Universe::calculate_verify_data((HeapWord*)0, (HeapWord*)UINTPTR_MAX);
> 
> In that case prefix mask/bits will be zeros.
> 

Yes, that?s why I said ?we need both values to be non-zero?.

So, the code you found is buggy but just happens to work
out sometimes.  It should be changed.  It clearly wasn?t
written with calculate_verify_data in mind; that?s just
something that I was reminded of when you wrote your
note.

Good find!

? John

From rriggs at openjdk.java.net  Fri Nov  6 18:00:16 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 6 Nov 2020 18:00:16 GMT
Subject: Integrated: 8254271: Development to deprecate wrapper class
 constructors for removal
In-Reply-To: <UAUHQ3O4Ocw_FajCm1pmUOcdQ_cwToYMgh2FLsSDcQc=.757acf75-5d99-4f45-95a5-37ef58acc09a@github.com>
References: <UAUHQ3O4Ocw_FajCm1pmUOcdQ_cwToYMgh2FLsSDcQc=.757acf75-5d99-4f45-95a5-37ef58acc09a@github.com>
Message-ID: <uaN-7vEIDnaXg_V37EqQnngp8l4948WVOsAN2XuKVAI=.eac3c048-9f41-417f-b495-6801ddb52f31@github.com>

On Fri, 9 Oct 2020 17:49:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The public constructors of the following classes have been deprecated since SE 9, and should be deprecated for removal in anticipation of these classes becoming inline classes.
> 
> java.lang.Boolean, Byte, Short, Integer, Long, Float, Double, and Character.
> 
> Existing uses of the constructors are converted to use the .valueOf(xxx) methods in classes and tests.

This pull request has now been integrated.

Changeset: 0c2ef39c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0c2ef39c
Stats:     115 lines in 21 files changed: 66 ins; 0 del; 49 mod

8254271: Development to deprecate wrapper class constructors for removal

Reviewed-by: mchung

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

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


From sergey.kuksenko at oracle.com  Fri Nov  6 18:47:39 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Fri, 6 Nov 2020 10:47:39 -0800
Subject: Question about hack in templateTable_x86.cpp
In-Reply-To: <ED6061AE-067E-48B7-A354-68B1B0BB84FC@oracle.com>
References: <a5edf7b3-6712-ca7e-0150-45a823ff6f1e@oracle.com>
 <94978B59-5F0A-4A42-946E-7F685F8439D5@oracle.com>
 <92edcc47-766d-fa10-a467-0e9f92d9f150@oracle.com>
 <ED6061AE-067E-48B7-A354-68B1B0BB84FC@oracle.com>
Message-ID: <e0e72e75-1b1f-544f-532b-c776640c7595@oracle.com>

Created: https://bugs.openjdk.java.net/browse/JDK-8255995

On 11/5/20 5:40 PM, John Rose wrote:
> On Nov 5, 2020, at 5:34 PM, Sergey Kuksenko 
> <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>> On 11/5/20 3:09 PM, John Rose wrote:
>>> On Nov 5, 2020, at 10:09 AM, Sergey Kuksenko 
>>> <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
>>>>
>>>> ???// might be substitutable, test if either rax or rdx is null __ 
>>>> testptr(rdx, rax);
>>>> ???__ jcc(Assembler::zero, (cc ==equal) ? not_taken : taken);
>>>>
>>>> The last "test" does simultaneous check either one of oops is null. 
>>>> I really like that hack, but I am not sure.
>>>>
>>>> What if we've got two non-null pointers which just have different 
>>>> bits? That hack may work only if we know that ANY two pointers have 
>>>> some ones at the same bit position. Do we have such assurance?
>>>
>>> Not in general. ?If you look at?verify_oop_mask and?verify_oop_bits,
>>> you might be able to reassure yourself that this works out OK.
>>> In particular, we need both values to be non-zero.
>>>
>>> The macro here should do this, and fall back to reliable code (such
>>> as a CC-testing bitwise OR) if the reassurance fails, or at least fail
>>> to boot the JVM.
>>>
>>> See?Universe::calculate_verify_data for where these bits come from.
>>
>> I don't want to be boring, just want to understand it for myself.
>>
>> "calculate_verify_data" finds high bits common prefix for min/max 
>> heap addresses. What if that high common prefix is all zeros or even 
>> zero length?
>>
>> For example, in ZGC we use:
>>
>> Universe::calculate_verify_data((HeapWord*)0, (HeapWord*)UINTPTR_MAX);
>>
>> In that case prefix mask/bits will be zeros.
>>
>
> Yes, that?s why I said ?we need both values to be non-zero?.
>
> So, the code you found is buggy but just happens to work
> out sometimes. ?It should be changed. ?It clearly wasn?t
> written with calculate_verify_data in mind; that?s just
> something that I was reminded of when you wrote your
> note.
>
> Good find!
>
> ? John


From romanowski.mateusz at gmail.com  Sun Nov  8 17:38:52 2020
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Sun, 8 Nov 2020 18:38:52 +0100
Subject: Keeping `new Integer` source compatibility with unnamed factory
 method
In-Reply-To: <251040858.2360587.1604524596252.JavaMail.zimbra@u-pem.fr>
References: <CAL-BTSqc+NywzQz-LzCeEjdMMbkhAJzmJdmrA5+Gsx3ubXKeBQ@mail.gmail.com>
 <251040858.2360587.1604524596252.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAL-BTSrJDRcOMBNEUASrEJXSHy5muBGEePb_bGfHSbb1Ry1qyQ@mail.gmail.com>

Hi Remi,
Thanks for your reply.

I completely forgot about code which needs the two references for new
Integer(2) to be different... no silver bullets here..

Unless... could specialization help -- int being a primitive species of
Integer while having another reference species available for _mature_ code?
I dimly remember both Fred and John, I think, making such remarks...

Regards,
Mateusz


On Wed, Nov 4, 2020 at 10:16 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Mateusz,
>
> ----- Mail original -----
> > De: "Mateusz Romanowski" <romanowski.mateusz at gmail.com>
> > ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> > Envoy?: Mercredi 4 Novembre 2020 21:07:35
> > Objet: Keeping `new Integer` source compatibility with unnamed factory
> method
>
> > Hi All,
> > regarding the summary of the last EG meeting (2020-11-04) [1], I can see
> a
> > future me being frustrated with having to keep some dusty `javac` only
> > because of some _mature_ code generation tool that "optimizes" by using
> > `Integer::new`.
>
> You can pro-actively already create a pull request to ask this mature tool
> to use Integer::valueOf instead of Integer::new.
> But you're right that this is a real issue that will hinder the adoption
> of Valhalla.
>
> >
> > Is the "something special" to keep `Integer::new` source compatibility
> > adding an `Integer::new` (and similarly `Object::new`) unnamed factory
> > method?
> >
> > Sorry if I have missed any material discussions related to such an idea.
>
> In the Valhalla world, Integer is not a concrete class anymore but a
> subtype of int, exactly a subtype of int sees as a primitive object), that
> why you can not instantiate it directly anymore.
>
> So currently, we are weighting our option more than we are making decision
> on which backward compatible strategy we want to use, source backward
> compatible vs binary backward compatible.
>
> So we may still allow to use new Integer()/Integer::new in the source
> code, to allow any tools that generates Java code to still work but it
> means that the compiler will have to rewrite it to be Integer.valueOf,
> which can be very surprising,
> by example,
>   new Integer(2) == new Integer(2)
> will now return true.
>
> And in that case, we have several ways to do it. We can do that in the
> library, creating an unnamed factory method that calls Integer.valueOf() as
> you are suggesting or we can do it directly in the compiler by rewriting
> all occurrences of new Integer().
>
> >
> > Cheers,
> > Mateusz Romanowski
>
> regards,
> R?mi
>
> >
> > [1]
> >
> https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2020-November/001446.html
> > [2]
> >
> http://cr.openjdk.java.net/~dlsmith/special-methods/special-methods-20200210/specs/factory-methods-jvms.html#jvms-2.9.4
>


From dsimms at openjdk.java.net  Mon Nov  9 09:25:45 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 09:25:45 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <dWQ_t8IzYpJTGmp4B9VupwtaLWx4SNDFZWbAYFlUnMY=.56f2cb52-a69b-47a8-83c8-2cca32caf7d7@github.com>

Merge tag 'jdk-16+23'
Added missing tag types for cell count (JDK-8255720)

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

Commit messages:
 - Added missing tag types for cell count (JDK-8255720)
 - Merge tag 'jdk-16+23' into lworld_merge_jdk_16_23
 - 8255900: x86: Reduce impact when VerifyOops is disabled
 - 8255886: Shenandoah: Resolve cset address truncation and register clash in interpreter LRB
 - 8252870: Finalize (remove "incubator" from) jpackage
 - 8255128: linux x86 build failure with libJNIPoint.c
 - 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64
 - 8255863: Clean up test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
 - 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
 - 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE
 - ... and 125 more: https://git.openjdk.java.net/valhalla/compare/a133d8fb...57c3bbe2

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

Changes: https://git.openjdk.java.net/valhalla/pull/254/files
  Stats: 15039 lines in 713 files changed: 7521 ins; 4933 del; 2585 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/254.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/254/head:pull/254

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


From dsimms at openjdk.java.net  Mon Nov  9 10:22:37 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 10:22:37 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <dWQ_t8IzYpJTGmp4B9VupwtaLWx4SNDFZWbAYFlUnMY=.56f2cb52-a69b-47a8-83c8-2cca32caf7d7@github.com>
References: <dWQ_t8IzYpJTGmp4B9VupwtaLWx4SNDFZWbAYFlUnMY=.56f2cb52-a69b-47a8-83c8-2cca32caf7d7@github.com>
Message-ID: <TYMLlMQyqJd4XIrB8_5sfLNa3Ubr_IS6WujzIPYUmHM=.6e831a5c-5c13-4c95-ba15-1b7348979fc4@github.com>

> Merge tag 'jdk-16+23'
> Added missing tag types for cell count (JDK-8255720)

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

 - Added missing tag types for cell count (JDK-8255720)
 - Merge tag 'jdk-16+23' into lworld_merge_jdk_16_23
   
   Added tag jdk-16+23 for changeset a0ade220
   
   # Conflicts:
   #	.github/workflows/submit.yml
   #	make/test/BuildMicrobenchmark.gmk
   #	src/hotspot/share/ci/ciReplay.cpp
   #	src/hotspot/share/opto/callnode.hpp
   #	src/hotspot/share/opto/cfgnode.cpp
   #	src/hotspot/share/opto/type.cpp
   #	src/hotspot/share/runtime/deoptimization.cpp
   #	src/java.base/share/classes/java/lang/ref/PhantomReference.java
 - GH workflow syntax
 - GitHub actions ignore main project branches
 - 8255727: [lworld] Withdraw support for @java.lang.ValueBased
 - 8255600: [lworld] C2 compilation fails with assert: modified node was not processed by IGVN.transform_old()
 - Merge jdk
   
   Merge tag 'jdk-16+22'
 - 8255541: [lworld] Improve array layout checks in C2 compiled code
 - Remove 32-bit builds from GH actions
 - 8255130: [lworld] Adjust github actions
 - ... and 1025 more: https://git.openjdk.java.net/valhalla/compare/a0ade220...57c3bbe2

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

Changes: https://git.openjdk.java.net/valhalla/pull/254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=254&range=01
  Stats: 151222 lines in 1335 files changed: 144640 ins; 2090 del; 4492 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/254.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/254/head:pull/254

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


From dsimms at openjdk.java.net  Mon Nov  9 10:22:40 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 10:22:40 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <dWQ_t8IzYpJTGmp4B9VupwtaLWx4SNDFZWbAYFlUnMY=.56f2cb52-a69b-47a8-83c8-2cca32caf7d7@github.com>
References: <dWQ_t8IzYpJTGmp4B9VupwtaLWx4SNDFZWbAYFlUnMY=.56f2cb52-a69b-47a8-83c8-2cca32caf7d7@github.com>
Message-ID: <4ax-PETtl5uFQnts2McMwZ9QnGjwFjsPNVzyEoCaBRI=.f5b6b674-86fb-44ae-8c49-64c90d73459d@github.com>

On Mon, 9 Nov 2020 09:20:30 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+23'
> Added missing tag types for cell count (JDK-8255720)

This pull request has now been integrated.

Changeset: a833bd80
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a833bd80
Stats:     15039 lines in 713 files changed: 7521 ins; 4933 del; 2585 mod

Merge jdk

Merge tag 'jdk-16+23'

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

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


From dsimms at openjdk.java.net  Mon Nov  9 13:12:26 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 13:12:26 GMT
Subject: RFR: Merge lworld
Message-ID: <RE19b8z2QuXT2qG2isTWPx4iCvH6frvx-EnWW_8qJ1w=.5c686688-a846-41e7-8526-ed7b956fcca0@github.com>

Merge tag 'jdk-16+23'

Merge branch 'lworld' into type-restrictions_merge_lworld_16_23
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java

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

Commit messages:
 - Merge branch 'lworld' into type-restrictions_merge_lworld_16_23
 - Merge jdk
 - 8255900: x86: Reduce impact when VerifyOops is disabled
 - 8255886: Shenandoah: Resolve cset address truncation and register clash in interpreter LRB
 - 8252870: Finalize (remove "incubator" from) jpackage
 - 8255128: linux x86 build failure with libJNIPoint.c
 - 8255838: Use 32-bit immediate movslq in macro assembler if 64-bit value fits in 32 bits on x86_64
 - 8255863: Clean up test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
 - 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
 - 8255855: appcds/jigsaw/NewModuleFinderTest.java test failed due to unexpected NPE
 - ... and 129 more: https://git.openjdk.java.net/valhalla/compare/696076f2...a89530d7

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

Changes: https://git.openjdk.java.net/valhalla/pull/255/files
  Stats: 15433 lines in 738 files changed: 7531 ins; 5312 del; 2590 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/255.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/255/head:pull/255

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


From dsimms at openjdk.java.net  Mon Nov  9 14:40:21 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 14:40:21 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <RE19b8z2QuXT2qG2isTWPx4iCvH6frvx-EnWW_8qJ1w=.5c686688-a846-41e7-8526-ed7b956fcca0@github.com>
References: <RE19b8z2QuXT2qG2isTWPx4iCvH6frvx-EnWW_8qJ1w=.5c686688-a846-41e7-8526-ed7b956fcca0@github.com>
Message-ID: <Ii1-LKX-8QktlMM4qj1bEmlLgyehisHVkeZNLyq1sJw=.00c5582e-3433-47ad-8888-7ae769106d13@github.com>

> Merge tag 'jdk-16+23'
> 
> Merge branch 'lworld' into type-restrictions_merge_lworld_16_23
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java

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

 - Merge branch 'lworld' into type-restrictions_merge_lworld_16_23
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
 - Merge lworld
   
   Merge tag jdk-16+22
 - Merge lworld
   
   Merge lworld at tag jdk-16+21
 - Merge lworld
   
   Merge jdk-16+20
 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK
   
   Reviewed-by: lfoltan
 - Merge lworld
   
   Merge tag 'jdk-16+19'
 - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField
   
   Reviewed-by: dsimms
 - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type
 - 8253312: Enable JVM experiments in specialization under an opt-in mode

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

Changes: https://git.openjdk.java.net/valhalla/pull/255/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=255&range=01
  Stats: 813 lines in 37 files changed: 638 ins; 103 del; 72 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/255.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/255/head:pull/255

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


From dsimms at openjdk.java.net  Mon Nov  9 14:40:24 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 14:40:24 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <RE19b8z2QuXT2qG2isTWPx4iCvH6frvx-EnWW_8qJ1w=.5c686688-a846-41e7-8526-ed7b956fcca0@github.com>
References: <RE19b8z2QuXT2qG2isTWPx4iCvH6frvx-EnWW_8qJ1w=.5c686688-a846-41e7-8526-ed7b956fcca0@github.com>
Message-ID: <NrnHQ3MT_j_Sn_s2OKCn4qgaFhyyFLugE7ydnRdb0sI=.4803c5c2-8326-4094-b57f-a7f16a9ee813@github.com>

On Mon, 9 Nov 2020 13:06:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+23'
> 
> Merge branch 'lworld' into type-restrictions_merge_lworld_16_23
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java

This pull request has now been integrated.

Changeset: 92f115ae
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/92f115ae
Stats:     15433 lines in 738 files changed: 7531 ins; 5312 del; 2590 mod

Merge lworld

Merge tag 'jdk-16+23'

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

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


From dsimms at openjdk.java.net  Mon Nov  9 15:23:07 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Mon, 9 Nov 2020 15:23:07 GMT
Subject: [lworld] Withdrawn: 8255522: [lworld] References to biased pattern
 remain in markWord::is_unlocked()
In-Reply-To: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
References: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
Message-ID: <ZLg_cBP6l15Zk3LkR6WXM0oCWSkYe70qdWKT5hDMvtM=.0e41a4d3-924e-4c1a-b84f-41c08947bc33@github.com>

On Wed, 28 Oct 2020 14:56:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> * more gtest mark word tests
> * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking")
> * remove biased_lock_mask_in_place from is_unlocked

This pull request has been closed without being integrated.

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

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


From mandy.chung at oracle.com  Tue Nov 10 00:12:23 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 9 Nov 2020 16:12:23 -0800
Subject: JDK-8230501: Class data support for hidden classes
Message-ID: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>

I'd like to get the discussion on the proposal APIs for class data
support for hidden classes before posting PR.

The patch is in https://github.com/mlchung/jdk/tree/class-data.

This patch also updates the implementation of lambda meta factory and
Memory Access API to use class data.? I ran the jdk.incubator.foreign
microbenchmarks and no performance difference.? I'm running more
performance testing.

Specdiff
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html


Summary
-------

Provide `Lookup::defineHiddenClassWithClassData` API that allow live objects
be shared between a hidden class and other classes.? A hidden class can load
these live objects as dynamically-computed constants via 
`MethodHandles::classData`
and `MethodHandles::classDataAt` bootstrap methods.

With this class data support and hidden classes, 
`sun.misc.Unsafe::defineAnonymousClass`
will be deprecated for removal.? Existing libraries should replace their
calls to `sun.misc.Unsafe::defineAnonymousClass` with 
`Lookup::defineHiddenClass`
or `Lookup::defineHiddenClassWithClassData`.


Background
----------

This is an enhancement following up JEP 371: Hidden Classes w.r.t.
"Constant-pool patching" in the "Risks and Assumption" section.

A VM-anonymous class can be defined with its constant-pool entries already
resolved to concrete values. This allows critical constants to be shared
between a VM-anonymous class and the language runtime that defines it, and
between multiple VM-anonymous classes. For example, a language runtime will
often have `MethodHandle` objects in its address space that would be useful
to newly-defined VM-anonymous classes. Instead of the runtime serializing
the objects to constant-pool entries in VM-anonymous classes and then
generating bytecode in those classes to laboriously `ldc` the entries,
the runtime can simply supply `Unsafe::defineAnonymousClass` with references
to its live objects. The relevant constant-pool entries in the newly-defined
VM-anonymous class are pre-linked to those objects, improving performance
and reducing footprint. In addition, this allows VM-anonymous classes to
refer to each other: Constant-pool entries in a class file are based on 
names.
They thus cannot refer to nameless VM-anonymous classes. A language 
runtime can,
however, easily track the live Class objects for its VM-anonymous 
classes and
supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new 
class's
constant pool entries to other VM-anonymous classes.

This extends the hidden classes to allow live objects to be injected
in a hidden class and loaded them via condy.

Details
-------

Provide `Lookup::defineHiddenClassWithClassData` API that takes additional
`classData` argument compared to `Lookup::defineHiddenClass`
class data can be method handles, lookup objects, arbitrary user objects
or collections of all of the above.

 ?? This method behaves as if calling `Lookup::defineHiddenClass` to define
 ?? a hidden class with a private static unnamed field that is initialized
 ?? with `classData` at the first instruction of the class initializer.

`MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
is a bootstrap method for the class data of the given lookup's lookup class.

`MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, 
int index)`
is a bootstrap method for the element at the given index in the class data
of the given lookup's lookup class, if the class data is a `List`.

The hidden class will be initialized when `classData` or `classDataAt` 
method
is called if the hidden class has not been initialized.

Bootstrap methods for class data of other type such as `Map` can be 
considered
in the future while this version also provides a bootstrap method for
class data list.

Frameworks sometimes want to dynamically create a hidden class (HC) and 
add it
it the lookup class nest and have HC to carry secrets hidden from that nest.
In this case, frameworks should not to use private static finals (in the HCs
they spin) to hold secrets because a nestmate of HC may obtain access to
such a private static final and observe the framework's secret. It should
use condy.

In addition, we need to differentiate if a lookup object is created from
the original lookup class or created from teleporting e.g. `Lookup::in`
and `MethodHandles::privateLookupIn`.

This proposes to add a new `ORIGINAL` bit that is only set if the lookup
object is created by `MethodHandles::lookup` or by bootstrap method 
invocation.
`Lookup::hasFullPrivilegeAccess` returns true only if it has private, module
and originl access.

`MethodHandles::privateLookupIn` spec is updated to check if the caller 
lookup
has private and module access.? It does not check for original access so 
that
a caller can pass a lookup without original access to a framework for
deep reflection if desired.? It addition, the resulting Lookup object
does not have the original access.



Compatibility Risks
-------------------

The Lookup object returned by `MethodHandles::privateLookupIn` does not have
the original access.? If the caller lookup class and target class is in 
the same
module, it will return a Lookup object with private and module access but
no original access. The return Lookup object no longer has full 
privilege access.

Existing code calling `Lookup::hasFullPrivilegeAccess` on a Lookup object
returned from `privateLookupIn` is impacted since the resulting Lookup 
object
has private access but not full privilege access. `privateLookupIn` is 
designed
for frameworks to teleport to a target class with private access for deep
reflection.? It is believed that `hasFullPrivilegeAccess` is not popularly
used (it was introduced in 14) and the compatibility risk is expected to 
be low.

`Lookup::toString` on the return Lookup object from 
`MethodHandles::privateLookupIn`
will have "/allaccess" suffix as opposed to no suffix to indicate full
privilege access.


From john.r.rose at oracle.com  Tue Nov 10 02:57:36 2020
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 9 Nov 2020 18:57:36 -0800
Subject: Keeping `new Integer` source compatibility with unnamed factory
 method
In-Reply-To: <CAL-BTSrJDRcOMBNEUASrEJXSHy5muBGEePb_bGfHSbb1Ry1qyQ@mail.gmail.com>
References: <CAL-BTSqc+NywzQz-LzCeEjdMMbkhAJzmJdmrA5+Gsx3ubXKeBQ@mail.gmail.com>
 <251040858.2360587.1604524596252.JavaMail.zimbra@u-pem.fr>
 <CAL-BTSrJDRcOMBNEUASrEJXSHy5muBGEePb_bGfHSbb1Ry1qyQ@mail.gmail.com>
Message-ID: <AC78E85B-307B-4BC0-9742-F24A087CEDE7@oracle.com>

On Nov 8, 2020, at 9:38 AM, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> Unless... could specialization help -- int being a primitive species of
> Integer while having another reference species available for _mature_ code?
> I dimly remember both Fred and John, I think, making such remarks...

Yes, something like that might be possible.

We know we want to allow fields to change their
storage types in different species.

We also know we want to support some kind of
?raw species? for each class C, that emulates the
legacy characteristics of the class C, including
erased (invariant) field types.  From that POV,
the ?raw type? for Integer should, clearly, be
a type that has object identity, while the factory
methods should return the new-and-cool
non-identity instances.

(Would we want to inject object identity for
the raw species of *any* inline/primitive class?
I can see pros and cons.  Mostly cons.  Identity
injection is a migration trick for legacy classes.)

Having an object type conditionally possess an
object identity is *a little* like having it have
a conditional field.  But I hope to model conditional
fields and methods using, not retractable declarations,
but rather type restrictions to an ?empty type?, such
as ?void?.  It?s not clear how to do that to an optional
object identity property.

In this case we would want something a little more
difficult:  A conditional *super*, of IdentityObject.
We don?t have any specific plans to do conditional
supers, but we might be able to create a compromise
that gets this job done.  I can think of two or three,
potentially.  I?d rather build the basics first, though,
and then return to this question.

So, maybe.

? John

From mandy.chung at oracle.com  Tue Nov 10 19:54:09 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2020 11:54:09 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
Message-ID: <e0e36607-0933-051c-d472-7626d78f4b92@oracle.com>

I like John's suggestion (an offline discussion) that no need to change
to MethodHandles::hasFullPrivilegeAccess and Lookup::toString. Most clients
can ignore ORIGINAL bit.

I revise the spec change that full privilege access remains unchanged
and it means private and module access.? The operations requiring
original access are:
- obtain class data associated with a lookup class
- create method handles for caller-sensitive methods.

The compatibility risk only applies to existing code that obtain
caller-sensitive methods using a Lookup created using privateLookupIn.
This should be very few, if not none.

Mandy

On 11/9/20 4:12 PM, Mandy Chung wrote:
> I'd like to get the discussion on the proposal APIs for class data
> support for hidden classes before posting PR.
>
> The patch is in https://github.com/mlchung/jdk/tree/class-data.
>
> This patch also updates the implementation of lambda meta factory and
> Memory Access API to use class data.? I ran the jdk.incubator.foreign
> microbenchmarks and no performance difference.? I'm running more
> performance testing.
>
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html 
>
>
>
> Summary
> -------
>
> Provide `Lookup::defineHiddenClassWithClassData` API that allow live 
> objects
> be shared between a hidden class and other classes.? A hidden class 
> can load
> these live objects as dynamically-computed constants via 
> `MethodHandles::classData`
> and `MethodHandles::classDataAt` bootstrap methods.
>
> With this class data support and hidden classes, 
> `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.? Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with 
> `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
>
>
> Background
> ----------
>
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
>
> A VM-anonymous class can be defined with its constant-pool entries 
> already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, 
> and
> between multiple VM-anonymous classes. For example, a language runtime 
> will
> often have `MethodHandle` objects in its address space that would be 
> useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with 
> references
> to its live objects. The relevant constant-pool entries in the 
> newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based 
> on names.
> They thus cannot refer to nameless VM-anonymous classes. A language 
> runtime can,
> however, easily track the live Class objects for its VM-anonymous 
> classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the 
> new class's
> constant pool entries to other VM-anonymous classes.
>
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
>
> Details
> -------
>
> Provide `Lookup::defineHiddenClassWithClassData` API that takes 
> additional
> `classData` argument compared to `Lookup::defineHiddenClass`
> class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
>
> ?? This method behaves as if calling `Lookup::defineHiddenClass` to 
> define
> ?? a hidden class with a private static unnamed field that is initialized
> ?? with `classData` at the first instruction of the class initializer.
>
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method for the class data of the given lookup's lookup 
> class.
>
> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, 
> int index)`
> is a bootstrap method for the element at the given index in the class 
> data
> of the given lookup's lookup class, if the class data is a `List`.
>
> The hidden class will be initialized when `classData` or `classDataAt` 
> method
> is called if the hidden class has not been initialized.
>
> Bootstrap methods for class data of other type such as `Map` can be 
> considered
> in the future while this version also provides a bootstrap method for
> class data list.
>
> Frameworks sometimes want to dynamically create a hidden class (HC) 
> and add it
> it the lookup class nest and have HC to carry secrets hidden from that 
> nest.
> In this case, frameworks should not to use private static finals (in 
> the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret. It should
> use condy.
>
> In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
>
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method 
> invocation.
> `Lookup::hasFullPrivilegeAccess` returns true only if it has private, 
> module
> and originl access.
>
> `MethodHandles::privateLookupIn` spec is updated to check if the 
> caller lookup
> has private and module access.? It does not check for original access 
> so that
> a caller can pass a lookup without original access to a framework for
> deep reflection if desired.? It addition, the resulting Lookup object
> does not have the original access.
>
>
>
> Compatibility Risks
> -------------------
>
> The Lookup object returned by `MethodHandles::privateLookupIn` does 
> not have
> the original access.? If the caller lookup class and target class is 
> in the same
> module, it will return a Lookup object with private and module access but
> no original access. The return Lookup object no longer has full 
> privilege access.
>
> Existing code calling `Lookup::hasFullPrivilegeAccess` on a Lookup object
> returned from `privateLookupIn` is impacted since the resulting Lookup 
> object
> has private access but not full privilege access. `privateLookupIn` is 
> designed
> for frameworks to teleport to a target class with private access for deep
> reflection.? It is believed that `hasFullPrivilegeAccess` is not 
> popularly
> used (it was introduced in 14) and the compatibility risk is expected 
> to be low.
>
> `Lookup::toString` on the return Lookup object from 
> `MethodHandles::privateLookupIn`
> will have "/allaccess" suffix as opposed to no suffix to indicate full
> privilege access.



From forax at univ-mlv.fr  Tue Nov 10 20:55:08 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 10 Nov 2020 21:55:08 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
Message-ID: <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>

Hi Mandy,
thanks to working on this.

I don't think that adding classDataAt is a good idea, you can emulate it with classData and it's better to get the list once from the class data instead of doing all the checks for each index of the List like classDataAt does.

I understand that the vector API implementation needs to have several arguments (my own test also needs that [1]) but it can be a helper method inside the vector API implementation and not a public method in java.lang.invoke API.

regards,
R?mi


[1] https://github.com/forax/panama-vector/blob/master/fr.umlv.jruntime/src/main/java/fr/umlv/jruntime/Cell.java#L851  

----- Mail original -----
> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Mardi 10 Novembre 2020 01:12:23
> Objet: JDK-8230501: Class data support for hidden classes

> I'd like to get the discussion on the proposal APIs for class data
> support for hidden classes before posting PR.
> 
> The patch is in https://github.com/mlchung/jdk/tree/class-data.
> 
> This patch also updates the implementation of lambda meta factory and
> Memory Access API to use class data.? I ran the jdk.incubator.foreign
> microbenchmarks and no performance difference.? I'm running more
> performance testing.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> 
> Summary
> -------
> 
> Provide `Lookup::defineHiddenClassWithClassData` API that allow live objects
> be shared between a hidden class and other classes.? A hidden class can load
> these live objects as dynamically-computed constants via
> `MethodHandles::classData`
> and `MethodHandles::classDataAt` bootstrap methods.
> 
> With this class data support and hidden classes,
> `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.? Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with
> `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on
> names.
> They thus cannot refer to nameless VM-anonymous classes. A language
> runtime can,
> however, easily track the live Class objects for its VM-anonymous
> classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new
> class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> Provide `Lookup::defineHiddenClassWithClassData` API that takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`
> class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> ?? This method behaves as if calling `Lookup::defineHiddenClass` to define
> ?? a hidden class with a private static unnamed field that is initialized
> ?? with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method for the class data of the given lookup's lookup class.
> 
> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type,
> int index)`
> is a bootstrap method for the element at the given index in the class data
> of the given lookup's lookup class, if the class data is a `List`.
> 
> The hidden class will be initialized when `classData` or `classDataAt`
> method
> is called if the hidden class has not been initialized.
> 
> Bootstrap methods for class data of other type such as `Map` can be
> considered
> in the future while this version also provides a bootstrap method for
> class data list.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and
> add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret. It should
> use condy.
> 
> In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method
> invocation.
> `Lookup::hasFullPrivilegeAccess` returns true only if it has private, module
> and originl access.
> 
> `MethodHandles::privateLookupIn` spec is updated to check if the caller
> lookup
> has private and module access.? It does not check for original access so
> that
> a caller can pass a lookup without original access to a framework for
> deep reflection if desired.? It addition, the resulting Lookup object
> does not have the original access.
> 
> 
> 
> Compatibility Risks
> -------------------
> 
> The Lookup object returned by `MethodHandles::privateLookupIn` does not have
> the original access.? If the caller lookup class and target class is in
> the same
> module, it will return a Lookup object with private and module access but
> no original access. The return Lookup object no longer has full
> privilege access.
> 
> Existing code calling `Lookup::hasFullPrivilegeAccess` on a Lookup object
> returned from `privateLookupIn` is impacted since the resulting Lookup
> object
> has private access but not full privilege access. `privateLookupIn` is
> designed
> for frameworks to teleport to a target class with private access for deep
> reflection.? It is believed that `hasFullPrivilegeAccess` is not popularly
> used (it was introduced in 14) and the compatibility risk is expected to
> be low.
> 
> `Lookup::toString` on the return Lookup object from
> `MethodHandles::privateLookupIn`
> will have "/allaccess" suffix as opposed to no suffix to indicate full
> privilege access.


From mandy.chung at oracle.com  Tue Nov 10 21:17:04 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2020 13:17:04 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
Message-ID: <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>

Hi Remi,

This is not intended only for the vector API implementation but rather 
for clients who define hidden classes? with more than one live objects 
as class data.?? Otherwise each client will have to write a similar 
convenience method which also needs to handle the unboxing conversion if 
the constant is a primitive type.

I see the downside for this convenience method is only for List 
(recommending to use immutable list) which can be extended when we have 
frozen array.

Any other issues you see for this convenience method?

Mandy

On 11/10/20 12:55 PM, Remi Forax wrote:
> Hi Mandy,
> thanks to working on this.
>
> I don't think that adding classDataAt is a good idea, you can emulate it with classData and it's better to get the list once from the class data instead of doing all the checks for each index of the List like classDataAt does.
>
> I understand that the vector API implementation needs to have several arguments (my own test also needs that [1]) but it can be a helper method inside the vector API implementation and not a public method in java.lang.invoke API.
>
> regards,
> R?mi
>
>
> [1] https://urldefense.com/v3/__https://github.com/forax/panama-vector/blob/master/fr.umlv.jruntime/src/main/java/fr/umlv/jruntime/Cell.java*L851__;Iw!!GqivPVa7Brio!JZmRSoc-X98rznCWzxyjtsp-_Zskmz43hgmEGqPUUdsoVa9pGHyxU5tWdQCMLeUTFg$
>
> ----- Mail original -----
>> De: "mandy chung" <mandy.chung at oracle.com>
>> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Mardi 10 Novembre 2020 01:12:23
>> Objet: JDK-8230501: Class data support for hidden classes
>> I'd like to get the discussion on the proposal APIs for class data
>> support for hidden classes before posting PR.
>>
>> The patch is in https://urldefense.com/v3/__https://github.com/mlchung/jdk/tree/class-data__;!!GqivPVa7Brio!JZmRSoc-X98rznCWzxyjtsp-_Zskmz43hgmEGqPUUdsoVa9pGHyxU5tWdQBdnWA7CQ$ .
>>
>> This patch also updates the implementation of lambda meta factory and
>> Memory Access API to use class data.? I ran the jdk.incubator.foreign
>> microbenchmarks and no performance difference.? I'm running more
>> performance testing.
>>
>> Specdiff
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>>
>>
>> Summary
>> -------
>>
>> Provide `Lookup::defineHiddenClassWithClassData` API that allow live objects
>> be shared between a hidden class and other classes.? A hidden class can load
>> these live objects as dynamically-computed constants via
>> `MethodHandles::classData`
>> and `MethodHandles::classDataAt` bootstrap methods.
>>
>> With this class data support and hidden classes,
>> `sun.misc.Unsafe::defineAnonymousClass`
>> will be deprecated for removal.? Existing libraries should replace their
>> calls to `sun.misc.Unsafe::defineAnonymousClass` with
>> `Lookup::defineHiddenClass`
>> or `Lookup::defineHiddenClassWithClassData`.
>>
>>
>> Background
>> ----------
>>
>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>> "Constant-pool patching" in the "Risks and Assumption" section.
>>
>> A VM-anonymous class can be defined with its constant-pool entries already
>> resolved to concrete values. This allows critical constants to be shared
>> between a VM-anonymous class and the language runtime that defines it, and
>> between multiple VM-anonymous classes. For example, a language runtime will
>> often have `MethodHandle` objects in its address space that would be useful
>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>> the objects to constant-pool entries in VM-anonymous classes and then
>> generating bytecode in those classes to laboriously `ldc` the entries,
>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>> to its live objects. The relevant constant-pool entries in the newly-defined
>> VM-anonymous class are pre-linked to those objects, improving performance
>> and reducing footprint. In addition, this allows VM-anonymous classes to
>> refer to each other: Constant-pool entries in a class file are based on
>> names.
>> They thus cannot refer to nameless VM-anonymous classes. A language
>> runtime can,
>> however, easily track the live Class objects for its VM-anonymous
>> classes and
>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new
>> class's
>> constant pool entries to other VM-anonymous classes.
>>
>> This extends the hidden classes to allow live objects to be injected
>> in a hidden class and loaded them via condy.
>>
>> Details
>> -------
>>
>> Provide `Lookup::defineHiddenClassWithClassData` API that takes additional
>> `classData` argument compared to `Lookup::defineHiddenClass`
>> class data can be method handles, lookup objects, arbitrary user objects
>> or collections of all of the above.
>>
>>  ?? This method behaves as if calling `Lookup::defineHiddenClass` to define
>>  ?? a hidden class with a private static unnamed field that is initialized
>>  ?? with `classData` at the first instruction of the class initializer.
>>
>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
>> is a bootstrap method for the class data of the given lookup's lookup class.
>>
>> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type,
>> int index)`
>> is a bootstrap method for the element at the given index in the class data
>> of the given lookup's lookup class, if the class data is a `List`.
>>
>> The hidden class will be initialized when `classData` or `classDataAt`
>> method
>> is called if the hidden class has not been initialized.
>>
>> Bootstrap methods for class data of other type such as `Map` can be
>> considered
>> in the future while this version also provides a bootstrap method for
>> class data list.
>>
>> Frameworks sometimes want to dynamically create a hidden class (HC) and
>> add it
>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>> In this case, frameworks should not to use private static finals (in the HCs
>> they spin) to hold secrets because a nestmate of HC may obtain access to
>> such a private static final and observe the framework's secret. It should
>> use condy.
>>
>> In addition, we need to differentiate if a lookup object is created from
>> the original lookup class or created from teleporting e.g. `Lookup::in`
>> and `MethodHandles::privateLookupIn`.
>>
>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>> object is created by `MethodHandles::lookup` or by bootstrap method
>> invocation.
>> `Lookup::hasFullPrivilegeAccess` returns true only if it has private, module
>> and originl access.
>>
>> `MethodHandles::privateLookupIn` spec is updated to check if the caller
>> lookup
>> has private and module access.? It does not check for original access so
>> that
>> a caller can pass a lookup without original access to a framework for
>> deep reflection if desired.? It addition, the resulting Lookup object
>> does not have the original access.
>>
>>
>>
>> Compatibility Risks
>> -------------------
>>
>> The Lookup object returned by `MethodHandles::privateLookupIn` does not have
>> the original access.? If the caller lookup class and target class is in
>> the same
>> module, it will return a Lookup object with private and module access but
>> no original access. The return Lookup object no longer has full
>> privilege access.
>>
>> Existing code calling `Lookup::hasFullPrivilegeAccess` on a Lookup object
>> returned from `privateLookupIn` is impacted since the resulting Lookup
>> object
>> has private access but not full privilege access. `privateLookupIn` is
>> designed
>> for frameworks to teleport to a target class with private access for deep
>> reflection.? It is believed that `hasFullPrivilegeAccess` is not popularly
>> used (it was introduced in 14) and the compatibility risk is expected to
>> be low.
>>
>> `Lookup::toString` on the return Lookup object from
>> `MethodHandles::privateLookupIn`
>> will have "/allaccess" suffix as opposed to no suffix to indicate full
>> privilege access.



From forax at univ-mlv.fr  Tue Nov 10 21:35:10 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 10 Nov 2020 22:35:10 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
Message-ID: <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Mardi 10 Novembre 2020 22:17:04
> Objet: Re: JDK-8230501: Class data support for hidden classes

> Hi Remi,

> This is not intended only for the vector API implementation but rather for
> clients who define hidden classes with more than one live objects as class
> data. Otherwise each client will have to write a similar convenience method
> which also needs to handle the unboxing conversion if the constant is a
> primitive type.

> I see the downside for this convenience method is only for List (recommending to
> use immutable list) which can be extended when we have frozen array.

> Any other issues you see for this convenience method?
I think it's better to use a structured object like a record instead of using a list which requires all objects to have the same type. 

> Mandy
R?mi 

> On 11/10/20 12:55 PM, Remi Forax wrote:

>> Hi Mandy,
>> thanks to working on this.

>> I don't think that adding classDataAt is a good idea, you can emulate it with
>> classData and it's better to get the list once from the class data instead of
>> doing all the checks for each index of the List like classDataAt does.

>> I understand that the vector API implementation needs to have several arguments
>> (my own test also needs that [1]) but it can be a helper method inside the
>> vector API implementation and not a public method in java.lang.invoke API.

>> regards,
>> R?mi

>> [1] [
>> https://urldefense.com/v3/__https://github.com/forax/panama-vector/blob/master/fr.umlv.jruntime/src/main/java/fr/umlv/jruntime/Cell.java*L851__;Iw!!GqivPVa7Brio!JZmRSoc-X98rznCWzxyjtsp-_Zskmz43hgmEGqPUUdsoVa9pGHyxU5tWdQCMLeUTFg$
>> |
>> https://urldefense.com/v3/__https://github.com/forax/panama-vector/blob/master/fr.umlv.jruntime/src/main/java/fr/umlv/jruntime/Cell.java*L851__;Iw!!GqivPVa7Brio!JZmRSoc-X98rznCWzxyjtsp-_Zskmz43hgmEGqPUUdsoVa9pGHyxU5tWdQCMLeUTFg$
>> ] ----- Mail original -----

>>> De: "mandy chung" [ mailto:mandy.chung at oracle.com | <mandy.chung at oracle.com> ]
>>> ?: "valhalla-dev" [ mailto:valhalla-dev at openjdk.java.net |
>>> <valhalla-dev at openjdk.java.net> ] Envoy?: Mardi 10 Novembre 2020 01:12:23
>>> Objet: JDK-8230501: Class data support for hidden classes

>>> I'd like to get the discussion on the proposal APIs for class data
>>> support for hidden classes before posting PR.

>>> The patch is in [
>>> https://urldefense.com/v3/__https://github.com/mlchung/jdk/tree/class-data__;!!GqivPVa7Brio!JZmRSoc-X98rznCWzxyjtsp-_Zskmz43hgmEGqPUUdsoVa9pGHyxU5tWdQBdnWA7CQ$
>>> |
>>> https://urldefense.com/v3/__https://github.com/mlchung/jdk/tree/class-data__;!!GqivPVa7Brio!JZmRSoc-X98rznCWzxyjtsp-_Zskmz43hgmEGqPUUdsoVa9pGHyxU5tWdQBdnWA7CQ$
>>> ] .

>>> This patch also updates the implementation of lambda meta factory and
>>> Memory Access API to use class data.? I ran the jdk.incubator.foreign
>>> microbenchmarks and no performance difference.? I'm running more
>>> performance testing.

>>> Specdiff [
>>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>>> |
>>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>>> ] Summary
>>> -------

>>> Provide `Lookup::defineHiddenClassWithClassData` API that allow live objects
>>> be shared between a hidden class and other classes.? A hidden class can load
>>> these live objects as dynamically-computed constants via
>>> `MethodHandles::classData`
>>> and `MethodHandles::classDataAt` bootstrap methods.

>>> With this class data support and hidden classes,
>>> `sun.misc.Unsafe::defineAnonymousClass`
>>> will be deprecated for removal.? Existing libraries should replace their
>>> calls to `sun.misc.Unsafe::defineAnonymousClass` with
>>> `Lookup::defineHiddenClass`
>>> or `Lookup::defineHiddenClassWithClassData`.

>>> Background
>>> ----------

>>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>>> "Constant-pool patching" in the "Risks and Assumption" section.

>>> A VM-anonymous class can be defined with its constant-pool entries already
>>> resolved to concrete values. This allows critical constants to be shared
>>> between a VM-anonymous class and the language runtime that defines it, and
>>> between multiple VM-anonymous classes. For example, a language runtime will
>>> often have `MethodHandle` objects in its address space that would be useful
>>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>>> the objects to constant-pool entries in VM-anonymous classes and then
>>> generating bytecode in those classes to laboriously `ldc` the entries,
>>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>>> to its live objects. The relevant constant-pool entries in the newly-defined
>>> VM-anonymous class are pre-linked to those objects, improving performance
>>> and reducing footprint. In addition, this allows VM-anonymous classes to
>>> refer to each other: Constant-pool entries in a class file are based on
>>> names.
>>> They thus cannot refer to nameless VM-anonymous classes. A language
>>> runtime can,
>>> however, easily track the live Class objects for its VM-anonymous
>>> classes and
>>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new
>>> class's
>>> constant pool entries to other VM-anonymous classes.

>>> This extends the hidden classes to allow live objects to be injected
>>> in a hidden class and loaded them via condy.

>>> Details
>>> -------

>>> Provide `Lookup::defineHiddenClassWithClassData` API that takes additional
>>> `classData` argument compared to `Lookup::defineHiddenClass`
>>> class data can be method handles, lookup objects, arbitrary user objects
>>> or collections of all of the above.

>>> ?? This method behaves as if calling `Lookup::defineHiddenClass` to define
>>> ?? a hidden class with a private static unnamed field that is initialized
>>> ?? with `classData` at the first instruction of the class initializer.

>>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
>>> is a bootstrap method for the class data of the given lookup's lookup class.

>>> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type,
>>> int index)`
>>> is a bootstrap method for the element at the given index in the class data
>>> of the given lookup's lookup class, if the class data is a `List`.

>>> The hidden class will be initialized when `classData` or `classDataAt`
>>> method
>>> is called if the hidden class has not been initialized.

>>> Bootstrap methods for class data of other type such as `Map` can be
>>> considered
>>> in the future while this version also provides a bootstrap method for
>>> class data list.

>>> Frameworks sometimes want to dynamically create a hidden class (HC) and
>>> add it
>>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>>> In this case, frameworks should not to use private static finals (in the HCs
>>> they spin) to hold secrets because a nestmate of HC may obtain access to
>>> such a private static final and observe the framework's secret. It should
>>> use condy.

>>> In addition, we need to differentiate if a lookup object is created from
>>> the original lookup class or created from teleporting e.g. `Lookup::in`
>>> and `MethodHandles::privateLookupIn`.

>>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>>> object is created by `MethodHandles::lookup` or by bootstrap method
>>> invocation.
>>> `Lookup::hasFullPrivilegeAccess` returns true only if it has private, module
>>> and originl access.

>>> `MethodHandles::privateLookupIn` spec is updated to check if the caller
>>> lookup
>>> has private and module access.? It does not check for original access so
>>> that
>>> a caller can pass a lookup without original access to a framework for
>>> deep reflection if desired.? It addition, the resulting Lookup object
>>> does not have the original access.

>>> Compatibility Risks
>>> -------------------

>>> The Lookup object returned by `MethodHandles::privateLookupIn` does not have
>>> the original access.? If the caller lookup class and target class is in
>>> the same
>>> module, it will return a Lookup object with private and module access but
>>> no original access. The return Lookup object no longer has full
>>> privilege access.

>>> Existing code calling `Lookup::hasFullPrivilegeAccess` on a Lookup object
>>> returned from `privateLookupIn` is impacted since the resulting Lookup
>>> object
>>> has private access but not full privilege access. `privateLookupIn` is
>>> designed
>>> for frameworks to teleport to a target class with private access for deep
>>> reflection.? It is believed that `hasFullPrivilegeAccess` is not popularly
>>> used (it was introduced in 14) and the compatibility risk is expected to
>>> be low.

>>> `Lookup::toString` on the return Lookup object from
>>> `MethodHandles::privateLookupIn`
>>> will have "/allaccess" suffix as opposed to no suffix to indicate full
>>> privilege access.


From mandy.chung at oracle.com  Tue Nov 10 23:31:15 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 10 Nov 2020 15:31:15 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
Message-ID: <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>



On 11/10/20 1:35 PM, forax at univ-mlv.fr wrote:
>
> I think it's better to use a structured object like a record instead 
> of using a list which requires all objects to have the same type.
>

Requiring all objects of the same type may be too restrictive.

OTOH, it is not a bad idea to hold off `classDataAt` and wait until more 
demands and usages to tell if such a convenience API is needed and in 
what form.?? I'm okay with hiding this method for now.

Mandy


From maurizio.cimadamore at oracle.com  Wed Nov 11 21:16:16 2020
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 11 Nov 2020 21:16:16 +0000
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
Message-ID: <318f3b72-5e22-3fa4-48d5-177f4b0f7bf6@oracle.com>

Hi Mandy,
this looks like a nice API, and using condy directly to access class 
data seems a very convenient solution for code generators.

The only comment I have is that the Foreign Memory Access generator is 
about to go as part of the third incubator round (which we'll push very 
shortly), so you might want to use some other examples to assess 
performances.

Cheers
Maurizio

On 10/11/2020 00:12, Mandy Chung wrote:
> I'd like to get the discussion on the proposal APIs for class data
> support for hidden classes before posting PR.
>
> The patch is in https://github.com/mlchung/jdk/tree/class-data.
>
> This patch also updates the implementation of lambda meta factory and
> Memory Access API to use class data.? I ran the jdk.incubator.foreign
> microbenchmarks and no performance difference.? I'm running more
> performance testing.
>
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html 
>
>
>
> Summary
> -------
>
> Provide `Lookup::defineHiddenClassWithClassData` API that allow live 
> objects
> be shared between a hidden class and other classes.? A hidden class 
> can load
> these live objects as dynamically-computed constants via 
> `MethodHandles::classData`
> and `MethodHandles::classDataAt` bootstrap methods.
>
> With this class data support and hidden classes, 
> `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.? Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with 
> `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
>
>
> Background
> ----------
>
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
>
> A VM-anonymous class can be defined with its constant-pool entries 
> already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, 
> and
> between multiple VM-anonymous classes. For example, a language runtime 
> will
> often have `MethodHandle` objects in its address space that would be 
> useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with 
> references
> to its live objects. The relevant constant-pool entries in the 
> newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based 
> on names.
> They thus cannot refer to nameless VM-anonymous classes. A language 
> runtime can,
> however, easily track the live Class objects for its VM-anonymous 
> classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the 
> new class's
> constant pool entries to other VM-anonymous classes.
>
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
>
> Details
> -------
>
> Provide `Lookup::defineHiddenClassWithClassData` API that takes 
> additional
> `classData` argument compared to `Lookup::defineHiddenClass`
> class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
>
> ?? This method behaves as if calling `Lookup::defineHiddenClass` to 
> define
> ?? a hidden class with a private static unnamed field that is initialized
> ?? with `classData` at the first instruction of the class initializer.
>
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method for the class data of the given lookup's lookup 
> class.
>
> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, 
> int index)`
> is a bootstrap method for the element at the given index in the class 
> data
> of the given lookup's lookup class, if the class data is a `List`.
>
> The hidden class will be initialized when `classData` or `classDataAt` 
> method
> is called if the hidden class has not been initialized.
>
> Bootstrap methods for class data of other type such as `Map` can be 
> considered
> in the future while this version also provides a bootstrap method for
> class data list.
>
> Frameworks sometimes want to dynamically create a hidden class (HC) 
> and add it
> it the lookup class nest and have HC to carry secrets hidden from that 
> nest.
> In this case, frameworks should not to use private static finals (in 
> the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret. It should
> use condy.
>
> In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
>
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method 
> invocation.
> `Lookup::hasFullPrivilegeAccess` returns true only if it has private, 
> module
> and originl access.
>
> `MethodHandles::privateLookupIn` spec is updated to check if the 
> caller lookup
> has private and module access.? It does not check for original access 
> so that
> a caller can pass a lookup without original access to a framework for
> deep reflection if desired.? It addition, the resulting Lookup object
> does not have the original access.
>
>
>
> Compatibility Risks
> -------------------
>
> The Lookup object returned by `MethodHandles::privateLookupIn` does 
> not have
> the original access.? If the caller lookup class and target class is 
> in the same
> module, it will return a Lookup object with private and module access but
> no original access. The return Lookup object no longer has full 
> privilege access.
>
> Existing code calling `Lookup::hasFullPrivilegeAccess` on a Lookup object
> returned from `privateLookupIn` is impacted since the resulting Lookup 
> object
> has private access but not full privilege access. `privateLookupIn` is 
> designed
> for frameworks to teleport to a target class with private access for deep
> reflection.? It is believed that `hasFullPrivilegeAccess` is not 
> popularly
> used (it was introduced in 14) and the compatibility risk is expected 
> to be low.
>
> `Lookup::toString` on the return Lookup object from 
> `MethodHandles::privateLookupIn`
> will have "/allaccess" suffix as opposed to no suffix to indicate full
> privilege access.


From john.r.rose at oracle.com  Wed Nov 11 21:47:42 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Nov 2020 13:47:42 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
Message-ID: <891C498B-52C6-4549-BD67-8DA3869A20A8@oracle.com>

On Nov 10, 2020, at 1:35 PM, forax at univ-mlv.fr wrote:
> 
>> De: "mandy chung" <mandy.chung at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Mardi 10 Novembre 2020 22:17:04
>> Objet: Re: JDK-8230501: Class data support for hidden classes
> 
>> Hi Remi,
> 
>> This is not intended only for the vector API implementation but rather for
>> clients who define hidden classes with more than one live objects as class
>> data. Otherwise each client will have to write a similar convenience method
>> which also needs to handle the unboxing conversion if the constant is a
>> primitive type.
> 
>> I see the downside for this convenience method is only for List (recommending to
>> use immutable list) which can be extended when we have frozen array.
> 
>> Any other issues you see for this convenience method?
> I think it's better to use a structured object like a record instead of using a list which requires all objects to have the same type. 

Using a record here would be cute, but overkill.  The resulting
constant pool would be burdened by the need to fully name
each record accessor (unless you made a convention for by-name
access, somehow, but we might as well do by-index at that point).

Each record accessor requires a C_NameAndType, a C_Methodref,
and a C_MethodHandle, plus 2 C_Utf8?s to represent the field
name and descriptor.  By contrast, each by-index access point
needs a distinct C_Integer and a bootstrap specifier to refer to it,
or (alternatively) a distinct C_Utf8 and C_NameAndType, if the
index is encoded in the name argument of a common BSM.
It?s not even close:  The by-index accessor puts much less
pressure on the constant pool than the by-record-element
accessor.  And that?s what counts, when designing condy
BSMs.

The constant pool is *not* a place where type-ful programming
is a great benefit.  Assuming that the code generator isn?t broken,
we can trust that the various (probably heterogenous) elements
of a ClassData list will be correctly typed for their individual
uses.

Finally, note that Mandy?s (and my) index-based convention
here *is type-ful where it counts*:  The type argument to the
BSM (which also requires a C_Utf8 and the same
C_NameAndType as used by the name) provides the same
full static type information as the ?cute? record accessor.
So, even though the ClassData is a List.of, apparently
untyped, each indexed element is pulled out of the list
with a full static type (enforced by a cast, of course).

Remi, I don?t think you?ve made a case for omitting
classDataAt, after all, and certainly not a case for a
competing record-like classDataAt.  Mandy is right
that every client is going to have to design an
alternative, so let?s just do it right in common code.

? John

P.S. One idea for cutting two functions down to one:
Encode the selection process into the (otherwise useless)
name argument of the C_NameAndType in the condy.

NAME   VALUE
$*      the ClassData object itself
$0      element 0 of the ClassData
$1      element 1 of the ClassData (and so on $2, ?)
(other)  reserved for future use



From john.r.rose at oracle.com  Wed Nov 11 21:52:59 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Nov 2020 13:52:59 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
Message-ID: <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>

On Nov 10, 2020, at 3:31 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Requiring all objects of the same type may be too restrictive.
> 
> OTOH, it is not a bad idea to hold off `classDataAt` and wait until more demands and usages to tell if such a convenience API is needed and in what form.   I'm okay with hiding this method for now.

After we talked off-line, I realized that the ?all
elements are the same type? line is a canard,
a red herring, or some other unwelcome animal.

I think we were right the first time!

? John

From forax at univ-mlv.fr  Wed Nov 11 22:41:50 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 11 Nov 2020 23:41:50 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <891C498B-52C6-4549-BD67-8DA3869A20A8@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <891C498B-52C6-4549-BD67-8DA3869A20A8@oracle.com>
Message-ID: <1148233579.2398322.1605134510525.JavaMail.zimbra@u-pem.fr>

> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "mandy chung" <mandy.chung at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoy?: Mercredi 11 Novembre 2020 22:47:42
> Objet: Re: JDK-8230501: Class data support for hidden classes

> On Nov 10, 2020, at 1:35 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>>> De: "mandy chung" < [ mailto:mandy.chung at oracle.com | mandy.chung at oracle.com ] >
>>> ?: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "valhalla-dev" < [ mailto:valhalla-dev at openjdk.java.net |
>>> valhalla-dev at openjdk.java.net ] >
>>> Envoy?: Mardi 10 Novembre 2020 22:17:04
>>> Objet: Re: JDK-8230501: Class data support for hidden classes

>>> Hi Remi,

>>> This is not intended only for the vector API implementation but rather for
>>> clients who define hidden classes with more than one live objects as class
>>> data. Otherwise each client will have to write a similar convenience method
>>> which also needs to handle the unboxing conversion if the constant is a
>>> primitive type.

>>> I see the downside for this convenience method is only for List (recommending to
>>> use immutable list) which can be extended when we have frozen array.

>>> Any other issues you see for this convenience method?

>> I think it's better to use a structured object like a record instead of using a
>> list which requires all objects to have the same type.

> Using a record here would be cute, but overkill. The resulting
> constant pool would be burdened by the need to fully name
> each record accessor (unless you made a convention for by-name
> access, somehow, but we might as well do by-index at that point).

> Each record accessor requires a C_NameAndType, a C_Methodref,
> and a C_MethodHandle, plus 2 C_Utf8?s to represent the field
> name and descriptor. By contrast, each by-index access point
> needs a distinct C_Integer and a bootstrap specifier to refer to it,
> or (alternatively) a distinct C_Utf8 and C_NameAndType, if the
> index is encoded in the name argument of a common BSM.
> It?s not even close: The by-index accessor puts much less
> pressure on the constant pool than the by-record-element
> accessor. And that?s what counts, when designing condy
> BSMs.

> The constant pool is *not* a place where type-ful programming
> is a great benefit. Assuming that the code generator isn?t broken,
> we can trust that the various (probably heterogenous) elements
> of a ClassData list will be correctly typed for their individual
> uses.

I suppose i'e to explain to you diabolic plan to rules the world :) 

You want to use a condy per value inside the class data, i don't, 
i want one condy to rule them all, because the record fields are trusted final fields, so in term of bytecode, 
i propose to generate 
LDC condy 
invokevirtual MyRecord accessor() 

The JIT will convert it to the right constant easily. 

> Finally, note that Mandy?s (and my) index-based convention
> here *is type-ful where it counts*: The type argument to the
> BSM (which also requires a C_Utf8 and the same
> C_NameAndType as used by the name) provides the same
> full static type information as the ?cute? record accessor.
> So, even though the ClassData is a List.of, apparently
> untyped, each indexed element is pulled out of the list
> with a full static type (enforced by a cast, of course).

> Remi, I don?t think you?ve made a case for omitting
> classDataAt, after all, and certainly not a case for a
> competing record-like classDataAt. Mandy is right
> that every client is going to have to design an
> alternative, so let?s just do it right in common code.

Is it better now ? 

> ? John

R?mi 

> P.S. One idea for cutting two functions down to one:
> Encode the selection process into the (otherwise useless)
> name argument of the C_NameAndType in the condy.

> NAME VALUE
> $* the ClassData object itself
> $0 element 0 of the ClassData
> $1 element 1 of the ClassData (and so on $2, ?)
> (other) reserved for future use


From mandy.chung at oracle.com  Wed Nov 11 23:28:56 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 11 Nov 2020 15:28:56 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
Message-ID: <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>



On 11/11/20 1:52 PM, John Rose wrote:
> After we talked off-line, I realized that the ?all
> elements are the same type? line is a canard,
> a red herring, or some other unwelcome animal.
>

I didn't think all elements should be of the same type.?? Class data can 
be a bag of live objects with different types.

> I think we were right the first time!

I do think the index-based convention with the specified type is right.? 
What I wasn't fully happy with `classDataAt` is why supporting List but 
not an array or Map.? We don't (and probably shouldn't) enforce the 
class data be an immutable list and map. `classDataAt` taking a (frozen) 
array may probably be more satisfying option although it's the user's 
error if they mutate the class data.

> P.S. One idea for cutting two functions down to one:
> Encode the selection process into the (otherwise useless)
> name argument of the C_NameAndType in the condy.
>
> NAME ? VALUE
> $* ? ? ?the ClassData object itself
> $0 ? ? ?element 0 of the ClassData
> $1 ? ? ?element 1 of the ClassData (and so on $2, ?)
> (other) ?reserved for future use
>

I went through this route but I like a distinct method taking an index 
parameter than using the name argument - the method signature and 
javadoc is clearer and explicit.??? I won't concern one additional function.

Mandy



From thartmann at openjdk.java.net  Thu Nov 12 13:41:23 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 12 Nov 2020 13:41:23 GMT
Subject: [lworld] RFR: 8255046: [lworld] JIT should make use of array layout
 encoding in markWord
Message-ID: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>

This patch re-implements the flat array check in C1 and C2 by using the mark word bits instead of the layout helper from the array Klass (see [JDK-8247299](https://bugs.openjdk.java.net/browse/JDK-8247299)). Unfortunately, this turned out to be far from trivial to implement in C2.

I've introduced a new FlatArrayCheck macro node to wrap the logic of the new check and to make it easier for the loop unswitching optimization to detect and hoist the check. One major problem is that we can't use immutable memory anymore because we are loading the mark word which is mutable (`AliasType::_is_rewritable` is `true`). Although the bits we are interested in are in fact immutable (we check for `markWord::unlocked_value`), we need to use raw memory to not break anti dependency analysis. As a result, flat array checks are not hoisted out of loops anymore and loop unswitching fails. `PhaseIdealLoop::move_flat_array_check_out_of_loop` will attempt to still move flat array checks out of loops by walking up the memory edge to before the loop and re-wiring the check accordingly.

This patch also fixes an existing issue in Escape Analysis that was only triggered now that we are able to fold the flat array check in more cases due to the `::Ideal`/`::Value `transformations.

@kuksenko, could you please evaluate performance of this change? Disabling the `UseArrayMarkWordCheck` flag allows to switch back to the old check using the layout helper.

Thanks,
Tobias

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

Commit messages:
 - Removed trailing whitespace
 - 8255046: [lworld] JIT should make use of array layout encoding in markWord

Changes: https://git.openjdk.java.net/valhalla/pull/256/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=256&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255046
  Stats: 665 lines in 19 files changed: 570 ins; 42 del; 53 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/256.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/256/head:pull/256

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


From roland at openjdk.java.net  Thu Nov 12 14:51:05 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 12 Nov 2020 14:51:05 GMT
Subject: [lworld] RFR: 8255046: [lworld] JIT should make use of array
 layout encoding in markWord
In-Reply-To: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
References: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
Message-ID: <QGOH7i-xUDQfrYIILFaOTXSA3Rnx__4DOpw4G-VwYZU=.6c69c9ff-7d5c-4f11-977b-e2dd196b0aba@github.com>

On Thu, 12 Nov 2020 13:34:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch re-implements the flat array check in C1 and C2 by using the mark word bits instead of the layout helper from the array Klass (see [JDK-8247299](https://bugs.openjdk.java.net/browse/JDK-8247299)). Unfortunately, this turned out to be far from trivial to implement in C2.
> 
> I've introduced a new FlatArrayCheck macro node to wrap the logic of the new check and to make it easier for the loop unswitching optimization to detect and hoist the check. One major problem is that we can't use immutable memory anymore because we are loading the mark word which is mutable (`AliasType::_is_rewritable` is `true`). Although the bits we are interested in are in fact immutable (we check for `markWord::unlocked_value`), we need to use raw memory to not break anti dependency analysis. As a result, flat array checks are not hoisted out of loops anymore and loop unswitching fails. `PhaseIdealLoop::move_flat_array_check_out_of_loop` will attempt to still move flat array checks out of loops by walking up the memory edge to before the loop and re-wiring the check accordingly.
> 
> This patch also fixes an existing issue in Escape Analysis that was only triggered now that we are able to fold the flat array check in more cases due to the `::Ideal`/`::Value `transformations.
> 
> @kuksenko, could you please evaluate performance of this change? Disabling the `UseArrayMarkWordCheck` flag allows to switch back to the old check using the layout helper.
> 
> Thanks,
> Tobias

Looks good to me.

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

Marked as reviewed by roland (Committer).

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


From skuksenko at openjdk.java.net  Fri Nov 13 02:58:10 2020
From: skuksenko at openjdk.java.net (Sergey Kuksenko)
Date: Fri, 13 Nov 2020 02:58:10 GMT
Subject: [lworld] RFR: 8255046: [lworld] JIT should make use of array
 layout encoding in markWord
In-Reply-To: <QGOH7i-xUDQfrYIILFaOTXSA3Rnx__4DOpw4G-VwYZU=.6c69c9ff-7d5c-4f11-977b-e2dd196b0aba@github.com>
References: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
 <QGOH7i-xUDQfrYIILFaOTXSA3Rnx__4DOpw4G-VwYZU=.6c69c9ff-7d5c-4f11-977b-e2dd196b0aba@github.com>
Message-ID: <Snp5PaAxlFO6EcoWhaxLBkyRP9TsEi4q73p9vunzTq8=.d084510b-5585-4a70-a8a8-a9203190f957@github.com>

On Thu, 12 Nov 2020 14:47:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This patch re-implements the flat array check in C1 and C2 by using the mark word bits instead of the layout helper from the array Klass (see [JDK-8247299](https://bugs.openjdk.java.net/browse/JDK-8247299)). Unfortunately, this turned out to be far from trivial to implement in C2.
>> 
>> I've introduced a new FlatArrayCheck macro node to wrap the logic of the new check and to make it easier for the loop unswitching optimization to detect and hoist the check. One major problem is that we can't use immutable memory anymore because we are loading the mark word which is mutable (`AliasType::_is_rewritable` is `true`). Although the bits we are interested in are in fact immutable (we check for `markWord::unlocked_value`), we need to use raw memory to not break anti dependency analysis. As a result, flat array checks are not hoisted out of loops anymore and loop unswitching fails. `PhaseIdealLoop::move_flat_array_check_out_of_loop` will attempt to still move flat array checks out of loops by walking up the memory edge to before the loop and re-wiring the check accordingly.
>> 
>> This patch also fixes an existing issue in Escape Analysis that was only triggered now that we are able to fold the flat array check in more cases due to the `::Ideal`/`::Value `transformations.
>> 
>> @kuksenko, could you please evaluate performance of this change? Disabling the `UseArrayMarkWordCheck` flag allows to switch back to the old check using the layout helper.
>> 
>> Thanks,
>> Tobias
>
> Looks good to me.

Cool.
Performance behavior is as expected.
aaload operation got speedup up +15% on some scenarios.
In general, cost of aaload operation now is 103%-106% from legacy (non valhalla) cost.
and it looks like the minimally possible overhead of aaload operation.
Unfortunately, if array is locked aaload got 20% slowdown (also expected). locking on an array object is quite rare situation. 

As for aastore operation - performance unchanged. aastore operation has the same cost in valhalla and in legacy world long before that. The reason of that is either hotspot has precise type information (and doesn't generate checks) or ArrayStoreException check is generated (ArrayStoreException check dominates aastore performance).

Note: I considered benchmarks when ArrayFlattened check can't be hoisted out loop (ref to array is loaded on every loop iteration).

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

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


From dsimms at openjdk.java.net  Fri Nov 13 09:37:48 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 13 Nov 2020 09:37:48 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <C8ACK1xSFVw9IejELhlM54MupgdXxkzROoEZLQihR1I=.1620080c-4477-4648-8820-c7b172cb9001@github.com>

Merge tag 'jdk-16+24' into lworld_merge_jdk_16_24
Added tag jdk-16+24 for changeset bfa060f0

# Conflicts:
#	src/hotspot/share/classfile/classFileParser.cpp
#	src/hotspot/share/oops/fieldInfo.hpp
#	src/hotspot/share/oops/fieldStreams.hpp
#	src/hotspot/share/opto/arraycopynode.cpp
#	src/hotspot/share/opto/arraycopynode.hpp
#	src/hotspot/share/runtime/synchronizer.cpp

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

Commit messages:
 - Merge tag 'jdk-16+24' into lworld_merge_jdk_16_24
 - 8256051: nmethod_entry_barrier stub miscalculates xmm spill size on x86_32
 - 8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer
 - 8256020: Shenandoah: Don't resurrect objects during evacuation on AS_NO_KEEPALIVE
 - 8253064: monitor list simplifications and getting rid of TSM
 - 8256182: Update qemu-debootstrap cross-compilation recipe
 - 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
 - 8256166: [C2] Registers get confused on Big Endian after 8221404
 - 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
 - 8254661: arm32: additional cleanup after fixing SIGSEGV
 - ... and 83 more: https://git.openjdk.java.net/valhalla/compare/a833bd80...0f62c4f5

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

Changes: https://git.openjdk.java.net/valhalla/pull/257/files
  Stats: 59227 lines in 766 files changed: 32476 ins; 17832 del; 8919 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/257.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/257/head:pull/257

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


From thartmann at openjdk.java.net  Fri Nov 13 10:31:26 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 13 Nov 2020 10:31:26 GMT
Subject: [lworld] RFR: 8255046: [lworld] JIT should make use of array
 layout encoding in markWord [v2]
In-Reply-To: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
References: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
Message-ID: <mQG9Qm9u0bz1Z9yo_pFP_bywbjky1d-bztIvnUNSq6g=.7b73e908-3aef-4a2b-8e48-2b57132f0d31@github.com>

> This patch re-implements the flat array check in C1 and C2 by using the mark word bits instead of the layout helper from the array Klass (see [JDK-8247299](https://bugs.openjdk.java.net/browse/JDK-8247299)). Unfortunately, this turned out to be far from trivial to implement in C2.
> 
> I've introduced a new FlatArrayCheck macro node to wrap the logic of the new check and to make it easier for the loop unswitching optimization to detect and hoist the check. One major problem is that we can't use immutable memory anymore because we are loading the mark word which is mutable (`AliasType::_is_rewritable` is `true`). Although the bits we are interested in are in fact immutable (we check for `markWord::unlocked_value`), we need to use raw memory to not break anti dependency analysis. As a result, flat array checks are not hoisted out of loops anymore and loop unswitching fails. `PhaseIdealLoop::move_flat_array_check_out_of_loop` will attempt to still move flat array checks out of loops by walking up the memory edge to before the loop and re-wiring the check accordingly.
> 
> This patch also fixes an existing issue in Escape Analysis that was only triggered now that we are able to fold the flat array check in more cases due to the `::Ideal`/`::Value `transformations.
> 
> @kuksenko, could you please evaluate performance of this change? Disabling the `UseArrayMarkWordCheck` flag allows to switch back to the old check using the layout helper.
> 
> Thanks,
> Tobias

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

  EA fix

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/256/files
  - new: https://git.openjdk.java.net/valhalla/pull/256/files/565d64d7..8320b34d

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

  Stats: 35 lines in 1 file changed: 10 ins; 17 del; 8 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/256.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/256/head:pull/256

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


From thartmann at openjdk.java.net  Fri Nov 13 10:31:27 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 13 Nov 2020 10:31:27 GMT
Subject: [lworld] RFR: 8255046: [lworld] JIT should make use of array
 layout encoding in markWord [v2]
In-Reply-To: <QGOH7i-xUDQfrYIILFaOTXSA3Rnx__4DOpw4G-VwYZU=.6c69c9ff-7d5c-4f11-977b-e2dd196b0aba@github.com>
References: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
 <QGOH7i-xUDQfrYIILFaOTXSA3Rnx__4DOpw4G-VwYZU=.6c69c9ff-7d5c-4f11-977b-e2dd196b0aba@github.com>
Message-ID: <a07tI0eS98fDynN4rlcCNf_7p2MEGjHbh8JQe6463JM=.2d2caf9e-041a-457e-8fcd-929efb6df6ae@github.com>

On Thu, 12 Nov 2020 14:47:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   EA fix
>
> Looks good to me.

Thanks @rwestrel for the review and thanks @kuksenko for the evaluation! I've added as small follow-up fix for EA.

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

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


From thartmann at openjdk.java.net  Fri Nov 13 12:04:10 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 13 Nov 2020 12:04:10 GMT
Subject: [lworld] Integrated: 8255046: [lworld] JIT should make use of array
 layout encoding in markWord
In-Reply-To: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
References: <Qt4xniv3lDKEzmP67DtnEjMa0PeRXaRBCkFuNcMlOw0=.f7ca2f76-69e2-4720-b10d-da10d08e77e8@github.com>
Message-ID: <UoFzy8Eqnm77hE-s_8sRcKj2f8o1qO4vi0NITwN-_v4=.769a0f34-6603-4afd-83b5-623249f6c233@github.com>

On Thu, 12 Nov 2020 13:34:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This patch re-implements the flat array check in C1 and C2 by using the mark word bits instead of the layout helper from the array Klass (see [JDK-8247299](https://bugs.openjdk.java.net/browse/JDK-8247299)). Unfortunately, this turned out to be far from trivial to implement in C2.
> 
> I've introduced a new FlatArrayCheck macro node to wrap the logic of the new check and to make it easier for the loop unswitching optimization to detect and hoist the check. One major problem is that we can't use immutable memory anymore because we are loading the mark word which is mutable (`AliasType::_is_rewritable` is `true`). Although the bits we are interested in are in fact immutable (we check for `markWord::unlocked_value`), we need to use raw memory to not break anti dependency analysis. As a result, flat array checks are not hoisted out of loops anymore and loop unswitching fails. `PhaseIdealLoop::move_flat_array_check_out_of_loop` will attempt to still move flat array checks out of loops by walking up the memory edge to before the loop and re-wiring the check accordingly.
> 
> This patch also fixes an existing issue in Escape Analysis that was only triggered now that we are able to fold the flat array check in more cases due to the `::Ideal`/`::Value `transformations.
> 
> @kuksenko, could you please evaluate performance of this change? Disabling the `UseArrayMarkWordCheck` flag allows to switch back to the old check using the layout helper.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 1b1aefaa
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1b1aefaa
Stats:     666 lines in 19 files changed: 565 ins; 44 del; 57 mod

8255046: [lworld] JIT should make use of array layout encoding in markWord

Reviewed-by: roland

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

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


From dsimms at openjdk.java.net  Fri Nov 13 12:12:44 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 13 Nov 2020 12:12:44 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <C8ACK1xSFVw9IejELhlM54MupgdXxkzROoEZLQihR1I=.1620080c-4477-4648-8820-c7b172cb9001@github.com>
References: <C8ACK1xSFVw9IejELhlM54MupgdXxkzROoEZLQihR1I=.1620080c-4477-4648-8820-c7b172cb9001@github.com>
Message-ID: <HRLocmylZk09HfeMsXEAig-2W1_3Y4tLb61QnWO-dlo=.159e55d3-a9c2-4adc-aa53-9db115bb726f@github.com>

> Merge tag 'jdk-16+24' into lworld_merge_jdk_16_24
> Added tag jdk-16+24 for changeset bfa060f0
> 
> # Conflicts:
> #	src/hotspot/share/classfile/classFileParser.cpp
> #	src/hotspot/share/oops/fieldInfo.hpp
> #	src/hotspot/share/oops/fieldStreams.hpp
> #	src/hotspot/share/opto/arraycopynode.cpp
> #	src/hotspot/share/opto/arraycopynode.hpp
> #	src/hotspot/share/runtime/synchronizer.cpp

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

  Avoid 8255665 more stringent asserts

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/257/files
  - new: https://git.openjdk.java.net/valhalla/pull/257/files/0f62c4f5..811c73d0

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

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

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


From dsimms at openjdk.java.net  Fri Nov 13 12:36:10 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 13 Nov 2020 12:36:10 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <C8ACK1xSFVw9IejELhlM54MupgdXxkzROoEZLQihR1I=.1620080c-4477-4648-8820-c7b172cb9001@github.com>
References: <C8ACK1xSFVw9IejELhlM54MupgdXxkzROoEZLQihR1I=.1620080c-4477-4648-8820-c7b172cb9001@github.com>
Message-ID: <q_JdKoSPHbdOgg5BYHT6Aw8cLWgnuyhx4AaqzqdjuCA=.8be5d8f0-e26a-4d9e-854d-8ff16001963a@github.com>

On Fri, 13 Nov 2020 09:30:53 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+24' into lworld_merge_jdk_16_24
> Added tag jdk-16+24 for changeset bfa060f0
> 
> # Conflicts:
> #	src/hotspot/share/classfile/classFileParser.cpp
> #	src/hotspot/share/oops/fieldInfo.hpp
> #	src/hotspot/share/oops/fieldStreams.hpp
> #	src/hotspot/share/opto/arraycopynode.cpp
> #	src/hotspot/share/opto/arraycopynode.hpp
> #	src/hotspot/share/runtime/synchronizer.cpp

This pull request has now been integrated.

Changeset: 74e40a56
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/74e40a56
Stats:     59225 lines in 766 files changed: 32476 ins; 17832 del; 8917 mod

Merge jdk

Merge tag 'jdk-16+24'

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

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


From thartmann at openjdk.java.net  Fri Nov 13 12:49:17 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 13 Nov 2020 12:49:17 GMT
Subject: [lworld] Integrated: 8256329: [lworld] C2 compilation fails with
 assert(!t->is_flat() && !t->is_not_flat()) failed: Should have been optimized
 out
Message-ID: <EaKChLNOgb9ZSMiCLxSpqI6sB8kEkjlgJPaPwP-01To=.0f4cabd3-fb3d-4581-869d-4c5670d3fa22@github.com>

In rare cases, the flat array check is not processed by IGVN and therefore not optimized out. The fix is to simply add it to the worklist during parsing.

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

Commit messages:
 - 8256329: [lworld] C2 compilation fails with assert(>is_flat() && >is_not_flat()) failed: Should have been optimized out

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

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


From thartmann at openjdk.java.net  Fri Nov 13 12:49:17 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 13 Nov 2020 12:49:17 GMT
Subject: [lworld] Integrated: 8256329: [lworld] C2 compilation fails with
 assert(!t->is_flat() && !t->is_not_flat()) failed: Should have been optimized
 out
In-Reply-To: <EaKChLNOgb9ZSMiCLxSpqI6sB8kEkjlgJPaPwP-01To=.0f4cabd3-fb3d-4581-869d-4c5670d3fa22@github.com>
References: <EaKChLNOgb9ZSMiCLxSpqI6sB8kEkjlgJPaPwP-01To=.0f4cabd3-fb3d-4581-869d-4c5670d3fa22@github.com>
Message-ID: <LyR1B3KZwIWxJUMSG7G1rji8_94rNHBlHzrYfbM2ikw=.8c33ea17-5118-42ad-aedb-791c4cb47b7b@github.com>

On Fri, 13 Nov 2020 12:40:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In rare cases, the flat array check is not processed by IGVN and therefore not optimized out. The fix is to simply add it to the worklist during parsing.

This pull request has now been integrated.

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

8256329: [lworld] C2 compilation fails with assert(!t->is_flat() && !t->is_not_flat()) failed: Should have been optimized out

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

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


From dsimms at openjdk.java.net  Fri Nov 13 14:41:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 13 Nov 2020 14:41:25 GMT
Subject: RFR: Merge lworld
Message-ID: <ZJQOu5nXqvNUeVXyjs4jS_mWLzuyH56cDAeG55LM5aU=.07924a2e-1c5e-46e5-bba8-507ac93b3c3d@github.com>

Merge jdk-16+24

Merge branch 'lworld' into type-restrictions_merge_jdk_16_24
# Conflicts:
#	src/hotspot/share/classfile/classFileParser.cpp
#	src/hotspot/share/oops/fieldInfo.hpp

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

Commit messages:
 - Merge branch 'lworld' into type-restrictions_merge_jdk_16_24
 - Merge jdk
 - 8256051: nmethod_entry_barrier stub miscalculates xmm spill size on x86_32
 - 8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer
 - 8256020: Shenandoah: Don't resurrect objects during evacuation on AS_NO_KEEPALIVE
 - 8253064: monitor list simplifications and getting rid of TSM
 - 8256182: Update qemu-debootstrap cross-compilation recipe
 - 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
 - 8256166: [C2] Registers get confused on Big Endian after 8221404
 - 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
 - ... and 85 more: https://git.openjdk.java.net/valhalla/compare/92f115ae...69b360d6

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

Changes: https://git.openjdk.java.net/valhalla/pull/259/files
  Stats: 59761 lines in 776 files changed: 33038 ins; 17773 del; 8950 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/259.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/259/head:pull/259

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


From dsimms at openjdk.java.net  Fri Nov 13 14:45:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 13 Nov 2020 14:45:25 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <ZJQOu5nXqvNUeVXyjs4jS_mWLzuyH56cDAeG55LM5aU=.07924a2e-1c5e-46e5-bba8-507ac93b3c3d@github.com>
References: <ZJQOu5nXqvNUeVXyjs4jS_mWLzuyH56cDAeG55LM5aU=.07924a2e-1c5e-46e5-bba8-507ac93b3c3d@github.com>
Message-ID: <ue49FwnyFYRldQ209X49ukswPxQ43rY9GAyYlXLSSCo=.0ac7ebf4-5917-4b37-ac05-a99c04fe4ff1@github.com>

> Merge jdk-16+24
> 
> Merge branch 'lworld' into type-restrictions_merge_jdk_16_24
> # Conflicts:
> #	src/hotspot/share/classfile/classFileParser.cpp
> #	src/hotspot/share/oops/fieldInfo.hpp

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

 - Merge branch 'lworld' into type-restrictions_merge_jdk_16_24
   
   # Conflicts:
   #	src/hotspot/share/classfile/classFileParser.cpp
   #	src/hotspot/share/oops/fieldInfo.hpp
 - Merge lworld
   
   Merge tag 'jdk-16+23'
 - Merge lworld
   
   Merge tag jdk-16+22
 - Merge lworld
   
   Merge lworld at tag jdk-16+21
 - Merge lworld
   
   Merge jdk-16+20
 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK
   
   Reviewed-by: lfoltan
 - Merge lworld
   
   Merge tag 'jdk-16+19'
 - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField
   
   Reviewed-by: dsimms
 - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type
 - 8253312: Enable JVM experiments in specialization under an opt-in mode

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

Changes: https://git.openjdk.java.net/valhalla/pull/259/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=259&range=01
  Stats: 691 lines in 36 files changed: 640 ins; 5 del; 46 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/259.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/259/head:pull/259

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


From dsimms at openjdk.java.net  Fri Nov 13 14:45:28 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 13 Nov 2020 14:45:28 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <ZJQOu5nXqvNUeVXyjs4jS_mWLzuyH56cDAeG55LM5aU=.07924a2e-1c5e-46e5-bba8-507ac93b3c3d@github.com>
References: <ZJQOu5nXqvNUeVXyjs4jS_mWLzuyH56cDAeG55LM5aU=.07924a2e-1c5e-46e5-bba8-507ac93b3c3d@github.com>
Message-ID: <YTpMgCJ0SwaVKswLYHWpN16Vp62ZTc5Ij88k4oEtf4w=.a0335050-4b0f-4521-abc2-c3b33b7c4a95@github.com>

On Fri, 13 Nov 2020 14:34:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-16+24
> 
> Merge branch 'lworld' into type-restrictions_merge_jdk_16_24
> # Conflicts:
> #	src/hotspot/share/classfile/classFileParser.cpp
> #	src/hotspot/share/oops/fieldInfo.hpp

This pull request has now been integrated.

Changeset: 45d36103
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/45d36103
Stats:     59761 lines in 776 files changed: 33038 ins; 17773 del; 8950 mod

Merge lworld

Merge jdk-16+24

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

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


From mandy.chung at oracle.com  Fri Nov 13 19:12:11 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Nov 2020 11:12:11 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
Message-ID: <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>



On 11/11/20 3:28 PM, Mandy Chung wrote:
> I do think the index-based convention with the specified type is 
> right.? What I wasn't fully happy with `classDataAt` is why supporting 
> List but not an array or Map.? We don't (and probably shouldn't) 
> enforce the class data be an immutable list and map. `classDataAt` 
> taking a (frozen) array may probably be more satisfying option 
> although it's the user's error if they mutate the class data.

Talking with Paul, he inspires to take the `List<?> classData` argument 
that we always copy it to an unmodifable List.??? (It would be nice if 
this method can take a varargs of live objects but the options argument 
is already a varargs).? This guarantees that the class data is immutable 
and can be trusted.? So `classDataAt` returns an element from an 
unmodifable list.

public Lookup defineHiddenClassWithClassData(byte[] bytes, List<?> 
classData, boolean initialize, ClassOption... options);

public static <T> List<T> classData(Lookup caller, String name, Class<T> 
type) throws IllegalAccessException

public static <T> T classDataAt(Lookup caller, String name, Class<T> 
type, int index)
 ??????????? throws IllegalAccessException

Otherwise, if a class data can be modifiable, we would warn the 
developers to do the right thing.

I like making `classData` argument as a List<?>.?? Feedback?

Mandy


From forax at univ-mlv.fr  Fri Nov 13 20:32:50 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 13 Nov 2020 21:32:50 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
Message-ID: <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "John Rose" <john.r.rose at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoy?: Vendredi 13 Novembre 2020 20:12:11
> Objet: Re: JDK-8230501: Class data support for hidden classes

> On 11/11/20 3:28 PM, Mandy Chung wrote:

>> I do think the index-based convention with the specified type is right. What I
>> wasn't fully happy with `classDataAt` is why supporting List but not an array
>> or Map. We don't (and probably shouldn't) enforce the class data be an
>> immutable list and map. `classDataAt` taking a (frozen) array may probably be
>> more satisfying option although it's the user's error if they mutate the class
>> data.

> Talking with Paul, he inspires to take the `List<?> classData` argument that we
> always copy it to an unmodifable List. (It would be nice if this method can
> take a varargs of live objects but the options argument is already a varargs).
> This guarantees that the class data is immutable and can be trusted.
No, the list will be unmodifiable not immutable, a List<Date> is a valid argument but is not immutable because you can change the content of the each date whenever you want. 
Java only provides shallow unmodifiability not true immutability. 

Also, List.copyOf() doesn't allow null as element. 

And, it will also makes classData() pretty useless as a BSM of a condy. 

> So `classDataAt` returns an element from an unmodifable list.

> public Lookup defineHiddenClassWithClassData(byte[] bytes, List<?> classData,
> boolean initialize, ClassOption... options);

> public static <T> List<T> classData(Lookup caller, String name, Class<T> type)
> throws IllegalAccessException

> public static <T> T classDataAt(Lookup caller, String name, Class<T> type, int
> index)
> throws IllegalAccessException

> Otherwise, if a class data can be modifiable, we would warn the developers to do
> the right thing.

> I like making `classData` argument as a List<?>. Feedback?

> Mandy

R?mi 


From mandy.chung at oracle.com  Fri Nov 13 21:50:41 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Nov 2020 13:50:41 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1390263802.2049008.1605041708699.JavaMail.zimbra@u-pem.fr>
 <b59b5200-ba38-3727-556f-5853fef4bf1a@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
Message-ID: <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>



On 11/13/20 12:32 PM, forax at univ-mlv.fr wrote:
>
> No, the list will be unmodifiable not immutable, a List<Date> is a 
> valid argument but is not immutable because you can change the content 
> of the each date whenever you want.
> Java only provides shallow unmodifiability not true immutability.
>

The unmodifiable list can ensure that class data list behaves as if 
declared as private static final fields, one for each element. W.r.t the 
immutability, there is no difference to 
ConstantBootstraps::getStaticFinal on "private static final Date d".

> Also, List.copyOf() doesn't allow null as element.
>

This is good too.? Why does one want a class list with null elements?


> And, it will also makes classData() pretty useless as a BSM of a condy.

I am also considering the single-item case and allowing Constable 
classdata (after I sent the mail).? In which case, classData() can be 
used to return T (the given type) and classDataAt returns an element at 
the given index of the class data if it's a list.

Mandy


From forax at univ-mlv.fr  Fri Nov 13 22:02:06 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 13 Nov 2020 23:02:06 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
Message-ID: <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoy?: Vendredi 13 Novembre 2020 22:50:41
> Objet: Re: JDK-8230501: Class data support for hidden classes

> On 11/13/20 12:32 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> No, the list will be unmodifiable not immutable, a List<Date> is a valid
>> argument but is not immutable because you can change the content of the each
>> date whenever you want.
>> Java only provides shallow unmodifiability not true immutability.

> The unmodifiable list can ensure that class data list behaves as if declared as
> private static final fields, one for each element. W.r.t the immutability,
> there is no difference to ConstantBootstraps::getStaticFinal on "private static
> final Date d".

>> Also, List.copyOf() doesn't allow null as element.

> This is good too. Why does one want a class list with null elements?
I want it, null is easy to check in term of bytecode and is aggressively propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by putting nulls in the right holes. 
It's also pretty useful when you have object that have a double representation, i.e. a value that can be a primitive value or a box, again testing if the box is null is a common operation. 

>> And, it will also makes classData() pretty useless as a BSM of a condy.

> I am also considering the single-item case and allowing Constable classdata
> (after I sent the mail). In which case, classData() can be used to return T
> (the given type) and classDataAt returns an element at the given index of the
> class data if it's a list.
If the object is Constable, it already has a bytecode representation, so there is no need to send it has a live object. 

> Mandy

R?mi 


From mandy.chung at oracle.com  Fri Nov 13 22:18:36 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 13 Nov 2020 14:18:36 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
Message-ID: <b7dd8b2b-ac8e-122f-4d76-322a48b5f594@oracle.com>



On 11/13/20 2:02 PM, forax at univ-mlv.fr wrote:
> If the object is Constable, it already has a bytecode representation, 
> so there is no need to send it has a live object.

Not for Class, MethodType, or MethodHandle referencing a hidden class or 
its members.?? No need for primitive values which is true.

Mandy


From forax at univ-mlv.fr  Fri Nov 13 22:41:13 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 13 Nov 2020 23:41:13 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <b7dd8b2b-ac8e-122f-4d76-322a48b5f594@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
 <b7dd8b2b-ac8e-122f-4d76-322a48b5f594@oracle.com>
Message-ID: <139005230.1684116.1605307273390.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "John Rose" <john.r.rose at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoy?: Vendredi 13 Novembre 2020 23:18:36
> Objet: Re: JDK-8230501: Class data support for hidden classes

> On 11/13/20 2:02 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> If the object is Constable, it already has a bytecode representation, so there
>> is no need to send it has a live object.
> Not for Class, MethodType, or MethodHandle referencing a hidden class or its
> members. No need for primitive values which is true.
yes, very true, but it's only one use case, being able to pass an arbitrary object helps many more. 

> Mandy

R?mi 


From john.r.rose at oracle.com  Fri Nov 13 22:46:24 2020
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 13 Nov 2020 14:46:24 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <1074603771.2070095.1605044110239.JavaMail.zimbra@u-pem.fr>
 <a0fde139-ab11-f60b-0729-053450b21558@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
Message-ID: <26D3C9FB-4495-49A4-A139-C8F51493DF68@oracle.com>

On Nov 13, 2020, at 2:02 PM, forax at univ-mlv.fr wrote:
> 
> I want it, null is easy to check in term of bytecode and is aggressively propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by putting nulls in the right holes.
> It's also pretty useful when you have object that have a double representation, i.e. a value that can be a primitive value or a box, again testing if the box is null is a common operation.

Null as a static constant can be created easily by other means,
so in most use cases, there?s no need to plumb a null through
a ClassData.  Just use aconst_null or ili.CBs::nullConstant.

Maybe what you are hoping for is statically generated bytecodes
which are invariant across nullable ?holes?, where the holes
are filled by a ClassData.  Fine, in that case use a nullable
container, such as Stuart Marks? Stream::asList.

? John

From forax at univ-mlv.fr  Fri Nov 13 23:25:53 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sat, 14 Nov 2020 00:25:53 +0100 (CET)
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <26D3C9FB-4495-49A4-A139-C8F51493DF68@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
 <26D3C9FB-4495-49A4-A139-C8F51493DF68@oracle.com>
Message-ID: <507694931.1691845.1605309953085.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "mandy chung" <mandy.chung at oracle.com>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoy?: Vendredi 13 Novembre 2020 23:46:24
> Objet: Re: JDK-8230501: Class data support for hidden classes

> On Nov 13, 2020, at 2:02 PM, forax at univ-mlv.fr wrote:
>> 
>> I want it, null is easy to check in term of bytecode and is aggressively
>> propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by
>> putting nulls in the right holes.
>> It's also pretty useful when you have object that have a double representation,
>> i.e. a value that can be a primitive value or a box, again testing if the box
>> is null is a common operation.
> 
> Null as a static constant can be created easily by other means,
> so in most use cases, there?s no need to plumb a null through
> a ClassData.  Just use aconst_null or ili.CBs::nullConstant.

yes,
but i was thinking about using it to define things like a capability, being null meaning the capability doesn't exist,
so you still also need to be able to pass a real object if the capability exists.

something like
  if (ldc condy != null) {
    ldc condy
    invokevirtual ...
  }

> 
> Maybe what you are hoping for is statically generated bytecodes
> which are invariant across nullable ?holes?, where the holes
> are filled by a ClassData. 

yes,
it's the same bytecode specialized using holes, so you don't have to generate it at runtime, only to specialize it at runtime.

> Fine, in that case use a nullable container, such as Stuart Marks? Stream::asList.

First, you can not using the result of toList() if it's a null friendly List because Mandy propose to use a List.copyOf() in between that will choke is there is a null inside the List.
Moreover if Stuart still want to use ListN to both this kind of List and List.of(...) then the result of ListN.get() will not be a constant if the value is null (because of the semantics of @Stable).
Which means that classData() will be useless, the only way will be to use classDataAt().

To summarize, if the only thing you can inject is a List which will be copy into an immutable list, passing null will not be easy, I can still wrap it and then unwrap it with you own condy BSM, it makes classData() useless as a BSM and makes passing only one object far more complex than the previous proposal.

> 
> ? John

R?mi


From john.r.rose at oracle.com  Sat Nov 14 01:11:31 2020
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 13 Nov 2020 17:11:31 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <507694931.1691845.1605309953085.JavaMail.zimbra@u-pem.fr>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
 <26D3C9FB-4495-49A4-A139-C8F51493DF68@oracle.com>
 <507694931.1691845.1605309953085.JavaMail.zimbra@u-pem.fr>
Message-ID: <902383DC-00D5-4D33-91F4-5DF355FEDDB7@oracle.com>

I see your point; it?s the unconditional use of List.{copy,}of
that is the hard problem (with nulls).  The problem with
@Stable is a minor internal perf. bug, not a problem with
the API.

I agree that the basic single ClassData should not be
restricted to a List.  (But if it were, it should be copied
by Stuart?s null-friendly immutable list-maker.)

I also think it?s reasonable to trust users of condy
to take adequate care of mutability issues.  I suggest
adding an @apiNote which says ?Think twice before
passing an array or other mutable structure through
the ClassData.  If you use a List, make it unmodifiable,
using List.of or Stream.asList.?


On Nov 13, 2020, at 3:25 PM, forax at univ-mlv.fr wrote:
> 
> ----- Mail original -----
>> De: "John Rose" <john.r.rose at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "mandy chung" <mandy.chung at oracle.com>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Envoy?: Vendredi 13 Novembre 2020 23:46:24
>> Objet: Re: JDK-8230501: Class data support for hidden classes
> 
>> On Nov 13, 2020, at 2:02 PM, forax at univ-mlv.fr wrote:
>>> 
>>> I want it, null is easy to check in term of bytecode and is aggressively
>>> propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by
>>> putting nulls in the right holes.
>>> It's also pretty useful when you have object that have a double representation,
>>> i.e. a value that can be a primitive value or a box, again testing if the box
>>> is null is a common operation.
>> 
>> Null as a static constant can be created easily by other means,
>> so in most use cases, there?s no need to plumb a null through
>> a ClassData.  Just use aconst_null or ili.CBs::nullConstant.
> 
> yes,
> but i was thinking about using it to define things like a capability, being null meaning the capability doesn't exist,
> so you still also need to be able to pass a real object if the capability exists.
> 
> something like
>  if (ldc condy != null) {
>    ldc condy
>    invokevirtual ...
>  }
> 
>> 
>> Maybe what you are hoping for is statically generated bytecodes
>> which are invariant across nullable ?holes?, where the holes
>> are filled by a ClassData. 
> 
> yes,
> it's the same bytecode specialized using holes, so you don't have to generate it at runtime, only to specialize it at runtime.
> 
>> Fine, in that case use a nullable container, such as Stuart Marks? Stream::asList.
> 
> First, you can not using the result of toList() if it's a null friendly List because Mandy propose to use a List.copyOf() in between that will choke is there is a null inside the List.
> Moreover if Stuart still want to use ListN to both this kind of List and List.of(...) then the result of ListN.get() will not be a constant if the value is null (because of the semantics of @Stable).
> Which means that classData() will be useless, the only way will be to use classDataAt().
> 
> To summarize, if the only thing you can inject is a List which will be copy into an immutable list, passing null will not be easy, I can still wrap it and then unwrap it with you own condy BSM, it makes classData() useless as a BSM and makes passing only one object far more complex than the previous proposal.
> 
>> 
>> ? John
> 
> R?mi



From thartmann at openjdk.java.net  Mon Nov 16 12:56:51 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 Nov 2020 12:56:51 GMT
Subject: [lworld] RFR: 8256391: [lworld] C2 compilation fails with
 assert(EnableValhalla) failed: should only be used for inline types
Message-ID: <aXaiWOGH_rqq-QFdO4OqnYZBFk0PBv5uUauTX-ikH9o=.1c972622-cb1f-4de5-ba05-c5f371842ee4@github.com>

The assert is too strong, AndLNodes with constant markWord::inline_type_pattern (= 5) input can also be generated without EnableValhalla. Moved the assert and strengthened the checks.

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

Commit messages:
 - 8256391: [lworld] C2 compilation fails with assert(EnableValhalla) failed: should only be used for inline types

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

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


From thartmann at openjdk.java.net  Mon Nov 16 13:17:17 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 Nov 2020 13:17:17 GMT
Subject: [lworld] Integrated: 8256391: [lworld] C2 compilation fails with
 assert(EnableValhalla) failed: should only be used for inline types
In-Reply-To: <aXaiWOGH_rqq-QFdO4OqnYZBFk0PBv5uUauTX-ikH9o=.1c972622-cb1f-4de5-ba05-c5f371842ee4@github.com>
References: <aXaiWOGH_rqq-QFdO4OqnYZBFk0PBv5uUauTX-ikH9o=.1c972622-cb1f-4de5-ba05-c5f371842ee4@github.com>
Message-ID: <OuRUaj8MsKcAvIN-kvyq9ZafRImD9A8kyQ-BAUsJ8K4=.50c0d69d-db65-48cc-825a-f7a93dcf4c9d@github.com>

On Mon, 16 Nov 2020 12:47:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The assert is too strong, AndLNodes with constant markWord::inline_type_pattern (= 5) input can also be generated without EnableValhalla. Moved the assert and strengthened the checks.

This pull request has now been integrated.

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

8256391: [lworld] C2 compilation fails with assert(EnableValhalla) failed: should only be used for inline types

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

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


From thartmann at openjdk.java.net  Mon Nov 16 15:25:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 Nov 2020 15:25:18 GMT
Subject: [lworld] Integrated: 8256400: [lworld] C2 compilation fails with
 assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead
 nodes
Message-ID: <obxxQPPegzCVgYxQ2VCaOCH6tsb0lJFl33ch2trxBE8=.1a9b07e5-8a9e-4140-8f48-fff912c478b1@github.com>

Escape analysis does not like dead AddP nodes. We should only create them in `ArrayCopyNode::prepare_array_copy` after we've checked for bailout.

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

Commit messages:
 - 8256400: [lworld] C2 compilation fails with assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead nodes

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

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


From thartmann at openjdk.java.net  Mon Nov 16 15:25:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 16 Nov 2020 15:25:18 GMT
Subject: [lworld] Integrated: 8256400: [lworld] C2 compilation fails with
 assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead
 nodes
In-Reply-To: <obxxQPPegzCVgYxQ2VCaOCH6tsb0lJFl33ch2trxBE8=.1a9b07e5-8a9e-4140-8f48-fff912c478b1@github.com>
References: <obxxQPPegzCVgYxQ2VCaOCH6tsb0lJFl33ch2trxBE8=.1a9b07e5-8a9e-4140-8f48-fff912c478b1@github.com>
Message-ID: <so210yr56OyBxm28woeo_y7bNODyOVyaGY4nR95XYlg=.755364c8-2f34-4020-9677-e244ec876422@github.com>

On Mon, 16 Nov 2020 15:19:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Escape analysis does not like dead AddP nodes. We should only create them in `ArrayCopyNode::prepare_array_copy` after we've checked for bailout.

This pull request has now been integrated.

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

8256400: [lworld] C2 compilation fails with assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead nodes

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

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


From dlsmith at openjdk.java.net  Tue Nov 17 00:34:24 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 17 Nov 2020 00:34:24 GMT
Subject: RFR: Merge valhalla:master
Message-ID: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>

Merge from tag jdk-16+24

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

Commit messages:
 - Merge commit 'bfa060f098e477fb45bc466f87fd66842161b73f' into jep390_merge_jdk_16_24
 - 8256051: nmethod_entry_barrier stub miscalculates xmm spill size on x86_32
 - 8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer
 - 8256020: Shenandoah: Don't resurrect objects during evacuation on AS_NO_KEEPALIVE
 - 8253064: monitor list simplifications and getting rid of TSM
 - 8256182: Update qemu-debootstrap cross-compilation recipe
 - 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
 - 8256166: [C2] Registers get confused on Big Endian after 8221404
 - 4907798: MEMORY LEAK: javax.swing.plaf.basic.BasicPopupMenuUI$MenuKeyboardHelper
 - 8254661: arm32: additional cleanup after fixing SIGSEGV
 - ... and 553 more: https://git.openjdk.java.net/valhalla/compare/0c2ef39c...a539ac26

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

Changes: https://git.openjdk.java.net/valhalla/pull/263/files
  Stats: 501028 lines in 3046 files changed: 419569 ins; 60778 del; 20681 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/263.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/263/head:pull/263

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


From dsimms at openjdk.java.net  Tue Nov 17 08:24:24 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 08:24:24 GMT
Subject: [lworld] RFR: 8255522: [lworld] References to biased pattern
 remain in markWord::is_unlocked() [v2]
In-Reply-To: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
References: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
Message-ID: <mZme1BKCmXhDdHm1p76KhTiy9t_PsZibZK2qb9ez5kw=.885333b7-543d-441a-9613-e4a07367a90a@github.com>

> * more gtest mark word tests
> * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking")
> * remove biased_lock_mask_in_place from is_unlocked

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

  Comments applied

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/245/files
  - new: https://git.openjdk.java.net/valhalla/pull/245/files/a1f25a77..aa579a9a

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

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

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


From dsimms at openjdk.java.net  Tue Nov 17 08:24:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 08:24:25 GMT
Subject: [lworld] Integrated: 8255522: [lworld] References to biased pattern
 remain in markWord::is_unlocked()
In-Reply-To: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
References: <TkcnkAMEZ6r7JZvrjiEdI8sMQqfP5dpvZOX9Lp94VnI=.1e018854-0486-4cb7-906b-e580076b8267@github.com>
Message-ID: <p2UCqn1XB3Q2T3ncQdQvAacUZWrbECO1Ggu0cFdkLCU=.b6e17e78-ce2e-47c3-991f-5523eb458bd0@github.com>

On Wed, 28 Oct 2020 14:56:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> * more gtest mark word tests
> * assert any use of "biased locking" (there are some existing "has_biased_pattern()" asserts not guarded "UseBiasedLocking")
> * remove biased_lock_mask_in_place from is_unlocked

This pull request has now been integrated.

Changeset: a3fb1485
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/a3fb1485
Stats:     149 lines in 11 files changed: 135 ins; 1 del; 13 mod

8255522: [lworld] References to biased pattern remain in markWord::is_unlocked()

Reviewed-by: fparain, skuksenko

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

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


From dsimms at openjdk.java.net  Tue Nov 17 08:48:25 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 08:48:25 GMT
Subject: [lworld] RFR: Disable further BiasedLocking tests
Message-ID: <w4wLn-ulH42Y6djQzx4ry6dbAODp3j99ZTaoqZ0dQ2U=.66d67a99-d585-4dc1-b14d-29b58b25d4ce@github.com>

Disabled jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java

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

Commit messages:
 - Disable further BiasedLocking tests

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

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


From dsimms at openjdk.java.net  Tue Nov 17 12:11:17 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 12:11:17 GMT
Subject: [lworld] RFR: 8238369: [lworld] Incorrect layout of inline type in
 flattened array.
Message-ID: <VUW5Sd_KVyL3MZim-XmQ3pwePZRVIt95Na7XqhGPLGE=.89eb58a6-0fd1-433d-96fb-3492007d40e2@github.com>

Removed obsolete and incorrect raw_value_byte_size

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

Commit messages:
 - 8238369: [lworld] Incorrect layout of inline type in flattened array

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

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


From dsimms at openjdk.java.net  Tue Nov 17 12:11:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 12:11:11 GMT
Subject: [lworld] Integrated: Disable further BiasedLocking tests
In-Reply-To: <w4wLn-ulH42Y6djQzx4ry6dbAODp3j99ZTaoqZ0dQ2U=.66d67a99-d585-4dc1-b14d-29b58b25d4ce@github.com>
References: <w4wLn-ulH42Y6djQzx4ry6dbAODp3j99ZTaoqZ0dQ2U=.66d67a99-d585-4dc1-b14d-29b58b25d4ce@github.com>
Message-ID: <PYbWbOFoM7DcwZcDx9JDBnEoUTHdTtAkrUxmHTCk-2Q=.79de8c04-a063-4e3f-bcce-43bc18c64087@github.com>

On Tue, 17 Nov 2020 08:44:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Disabled jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java

This pull request has now been integrated.

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

Disable further BiasedLocking tests

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

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


From rriggs at openjdk.java.net  Tue Nov 17 15:17:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Nov 2020 15:17:12 GMT
Subject: RFR: Merge valhalla:master
In-Reply-To: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>
References: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>
Message-ID: <K0N2oBzXLLr1e00j15VtEWlzXFFIDxQ1m_Jj4a_8tJk=.58f39984-e1b2-4106-8530-eb248c9cd55e@github.com>

On Tue, 17 Nov 2020 00:23:38 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Merge from tag jdk-16+24

Marked as reviewed by rriggs (Reviewer).

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

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


From dsimms at openjdk.java.net  Tue Nov 17 16:19:22 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 16:19:22 GMT
Subject: [lworld] RFR: 8238369: [lworld] Incorrect layout of inline type
 in flattened array. [v2]
In-Reply-To: <VUW5Sd_KVyL3MZim-XmQ3pwePZRVIt95Na7XqhGPLGE=.89eb58a6-0fd1-433d-96fb-3492007d40e2@github.com>
References: <VUW5Sd_KVyL3MZim-XmQ3pwePZRVIt95Na7XqhGPLGE=.89eb58a6-0fd1-433d-96fb-3492007d40e2@github.com>
Message-ID: <Ct29k1u4UAtP5O7nZvS7NNrjSYzHxCbeLDMNcVw-_TE=.858f11f7-5ca8-4696-9c19-8a3d97e6a35d@github.com>

> Removed obsolete and incorrect raw_value_byte_size

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

  Further testing

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/265/files
  - new: https://git.openjdk.java.net/valhalla/pull/265/files/acba87df..78157e07

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

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

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


From fparain at openjdk.java.net  Tue Nov 17 16:25:15 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 17 Nov 2020 16:25:15 GMT
Subject: [lworld] RFR: 8238369: [lworld] Incorrect layout of inline type
 in flattened array. [v2]
In-Reply-To: <Ct29k1u4UAtP5O7nZvS7NNrjSYzHxCbeLDMNcVw-_TE=.858f11f7-5ca8-4696-9c19-8a3d97e6a35d@github.com>
References: <VUW5Sd_KVyL3MZim-XmQ3pwePZRVIt95Na7XqhGPLGE=.89eb58a6-0fd1-433d-96fb-3492007d40e2@github.com>
 <Ct29k1u4UAtP5O7nZvS7NNrjSYzHxCbeLDMNcVw-_TE=.858f11f7-5ca8-4696-9c19-8a3d97e6a35d@github.com>
Message-ID: <e9AP0TymXQydPyVv9jJN_o0PHgZvhXQYJdTHO-kVDFo=.16e3ee21-0845-45b8-9dd6-52a62a1dc167@github.com>

On Tue, 17 Nov 2020 16:19:22 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Removed obsolete and incorrect raw_value_byte_size
>
> David Simms has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further testing

Looks good to me.
Thank you for the additional tests.

Fred

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

Marked as reviewed by fparain (Committer).

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


From dsimms at openjdk.java.net  Tue Nov 17 16:35:18 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 16:35:18 GMT
Subject: [lworld] Integrated: 8238369: [lworld] Incorrect layout of inline
 type in flattened array.
In-Reply-To: <VUW5Sd_KVyL3MZim-XmQ3pwePZRVIt95Na7XqhGPLGE=.89eb58a6-0fd1-433d-96fb-3492007d40e2@github.com>
References: <VUW5Sd_KVyL3MZim-XmQ3pwePZRVIt95Na7XqhGPLGE=.89eb58a6-0fd1-433d-96fb-3492007d40e2@github.com>
Message-ID: <k19oJvy70TvLX5ssd2AX7g7vxO-XAyFh1jIhSifjlgE=.c1b3fc4a-f563-47d4-9d47-b22b099e7a66@github.com>

On Tue, 17 Nov 2020 12:05:21 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed obsolete and incorrect raw_value_byte_size

This pull request has now been integrated.

Changeset: cc1f08e1
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/cc1f08e1
Stats:     122 lines in 4 files changed: 78 ins; 41 del; 3 mod

8238369: [lworld] Incorrect layout of inline type in flattened array.

Reviewed-by: fparain

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

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


From dsimms at openjdk.java.net  Tue Nov 17 17:58:20 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 17 Nov 2020 17:58:20 GMT
Subject: [lworld] RFR: 8255995: templateTable_x86.cpp (TemplateTable::if_acmp)
 not always do correct null check.
Message-ID: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>

Testing both pointers at the same time, doesn't account for the case where bits
completely miss each other, resulting in zero as result e.g.

  test(0x10, 0x01) == 0x10 & 0x01 == 0, yet neither are null

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

Commit messages:
 - 8255995: templateTable_x86.cpp (TemplateTable::if_acmp) not always do correct null check.

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

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


From fparain at openjdk.java.net  Tue Nov 17 18:56:09 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Tue, 17 Nov 2020 18:56:09 GMT
Subject: [lworld] RFR: 8255995: templateTable_x86.cpp
 (TemplateTable::if_acmp) not always do correct null check.
In-Reply-To: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>
References: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>
Message-ID: <CMNcnc_c2kebXjppa_j6gDAYAV18LUrQBrwoF5CVi0A=.3eec4e8f-08ec-4c97-9253-b2925514a9f9@github.com>

On Tue, 17 Nov 2020 17:54:36 GMT, David Simms <dsimms at openjdk.org> wrote:

> Testing both pointers at the same time, doesn't account for the case where bits
> completely miss each other, resulting in zero as result e.g.
> 
>   test(0x10, 0x01) == 0x10 & 0x01 == 0, yet neither are null

LGTM

Fred

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

Marked as reviewed by fparain (Committer).

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


From rriggs at openjdk.java.net  Tue Nov 17 19:42:20 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Nov 2020 19:42:20 GMT
Subject: RFR: 8253962: Add @ValueBased to unmodifable Collection
 implementation classes
Message-ID: <UPOFPdYEm1FjOp-S6o0EXRZ5_Wtwp4cqFoX409OaRu8=.4b7e8e4c-eb3d-4a1b-bc92-7fa2dfc41c19@github.com>

As per JEP 390, The implementations of ImmutableCollections are marked as being @ValueBased.

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

Commit messages:
 - 8253962: Add @ValueBased to unmodifable Collection implementation classes

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

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


From rriggs at openjdk.java.net  Tue Nov 17 19:48:29 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Nov 2020 19:48:29 GMT
Subject: RFR: 8253962: Add @ValueBased to unmodifable Collection
 implementation classes [v2]
In-Reply-To: <UPOFPdYEm1FjOp-S6o0EXRZ5_Wtwp4cqFoX409OaRu8=.4b7e8e4c-eb3d-4a1b-bc92-7fa2dfc41c19@github.com>
References: <UPOFPdYEm1FjOp-S6o0EXRZ5_Wtwp4cqFoX409OaRu8=.4b7e8e4c-eb3d-4a1b-bc92-7fa2dfc41c19@github.com>
Message-ID: <Xql-4ETHGBHLXRHJu_439aTOm1XRXcJK3XR1lXxfgXM=.0da02775-71bc-4444-81a6-164d8d38f2d8@github.com>

> As per JEP 390, The implementations of ImmutableCollections are marked as being @ValueBased.

Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:

 - remove blank line
 - Merge branch 'valuebased-collections-8253962' of https://github.com/RogerRiggs/valhalla into valuebased-collections-8253962
 - 8253962: Add @ValueBased to unmodifable Collection implementation classes

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/267/files
  - new: https://git.openjdk.java.net/valhalla/pull/267/files/d2891569..b6d88175

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

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

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


From mandy.chung at oracle.com  Tue Nov 17 20:43:19 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 17 Nov 2020 12:43:19 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <902383DC-00D5-4D33-91F4-5DF355FEDDB7@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
 <26D3C9FB-4495-49A4-A139-C8F51493DF68@oracle.com>
 <507694931.1691845.1605309953085.JavaMail.zimbra@u-pem.fr>
 <902383DC-00D5-4D33-91F4-5DF355FEDDB7@oracle.com>
Message-ID: <c8f9682a-eb86-e3a0-79bb-31da50bc26f6@oracle.com>

Thanks for the feedback, John and Remi.

Here is the updated specdiff:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/

I added @apiNote in `defineClassHiddenWithClassData` about mutability.
I keep `classData` that can be used for a single-item class data or of 
type other than List like array, map, or even record. `classDataAt` 
makes it easier for those who use a list as the class data (that can be 
extended for frozen arrays in the future). ?? The @apiNote suggests the 
good practice to use unmodifiable List. (Stream::asList is not yet 
integrated and no reference from the @apiNote).

I will update https://github.com/openjdk/jdk/pull/1171

Mandy

On 11/13/20 5:11 PM, John Rose wrote:
> I see your point; it?s the unconditional use of List.{copy,}of
> that is the hard problem (with nulls).  The problem with
> @Stable is a minor internal perf. bug, not a problem with
> the API.
>
> I agree that the basic single ClassData should not be
> restricted to a List.  (But if it were, it should be copied
> by Stuart?s null-friendly immutable list-maker.)
>
> I also think it?s reasonable to trust users of condy
> to take adequate care of mutability issues.  I suggest
> adding an @apiNote which says ?Think twice before
> passing an array or other mutable structure through
> the ClassData.  If you use a List, make it unmodifiable,
> using List.of or Stream.asList.?
>
>
> On Nov 13, 2020, at 3:25 PM, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "John Rose" <john.r.rose at oracle.com>
>>> ?: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "mandy chung" <mandy.chung at oracle.com>, "valhalla-dev" <valhalla-dev at openjdk.java.net>
>>> Envoy?: Vendredi 13 Novembre 2020 23:46:24
>>> Objet: Re: JDK-8230501: Class data support for hidden classes
>>> On Nov 13, 2020, at 2:02 PM, forax at univ-mlv.fr wrote:
>>>> I want it, null is easy to check in term of bytecode and is aggressively
>>>> propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by
>>>> putting nulls in the right holes.
>>>> It's also pretty useful when you have object that have a double representation,
>>>> i.e. a value that can be a primitive value or a box, again testing if the box
>>>> is null is a common operation.
>>> Null as a static constant can be created easily by other means,
>>> so in most use cases, there?s no need to plumb a null through
>>> a ClassData.  Just use aconst_null or ili.CBs::nullConstant.
>> yes,
>> but i was thinking about using it to define things like a capability, being null meaning the capability doesn't exist,
>> so you still also need to be able to pass a real object if the capability exists.
>>
>> something like
>>   if (ldc condy != null) {
>>     ldc condy
>>     invokevirtual ...
>>   }
>>
>>> Maybe what you are hoping for is statically generated bytecodes
>>> which are invariant across nullable ?holes?, where the holes
>>> are filled by a ClassData.
>> yes,
>> it's the same bytecode specialized using holes, so you don't have to generate it at runtime, only to specialize it at runtime.
>>
>>> Fine, in that case use a nullable container, such as Stuart Marks? Stream::asList.
>> First, you can not using the result of toList() if it's a null friendly List because Mandy propose to use a List.copyOf() in between that will choke is there is a null inside the List.
>> Moreover if Stuart still want to use ListN to both this kind of List and List.of(...) then the result of ListN.get() will not be a constant if the value is null (because of the semantics of @Stable).
>> Which means that classData() will be useless, the only way will be to use classDataAt().
>>
>> To summarize, if the only thing you can inject is a List which will be copy into an immutable list, passing null will not be easy, I can still wrap it and then unwrap it with you own condy BSM, it makes classData() useless as a BSM and makes passing only one object far more complex than the previous proposal.
>>
>>> ? John
>> R?mi



From thartmann at openjdk.java.net  Wed Nov 18 06:23:08 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 18 Nov 2020 06:23:08 GMT
Subject: [lworld] RFR: 8255995: templateTable_x86.cpp
 (TemplateTable::if_acmp) not always do correct null check.
In-Reply-To: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>
References: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>
Message-ID: <mSEjkb0bXS-lp1JnA2mA7OSCYb7H4y6WVlTIoTc-SrU=.ada6423f-082f-4762-9450-e0689ab9bce3@github.com>

On Tue, 17 Nov 2020 17:54:36 GMT, David Simms <dsimms at openjdk.org> wrote:

> Testing both pointers at the same time, doesn't account for the case where bits
> completely miss each other, resulting in zero as result e.g.
> 
>   test(0x10, 0x01) == 0x10 & 0x01 == 0, yet neither are null

Marked as reviewed by thartmann (Committer).

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

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


From john.r.rose at oracle.com  Wed Nov 18 08:15:03 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 18 Nov 2020 00:15:03 -0800
Subject: JDK-8230501: Class data support for hidden classes
In-Reply-To: <c8f9682a-eb86-e3a0-79bb-31da50bc26f6@oracle.com>
References: <b4ddec32-d17b-654d-f6d8-78deba721d6e@oracle.com>
 <B6E0D0F3-D0CA-4C5B-B546-27D9E643984D@oracle.com>
 <d4f7ed60-7fd0-4cfd-eecc-ea9452594085@oracle.com>
 <f028f271-e9d2-49b0-b91b-071436157aac@oracle.com>
 <1462497101.1656763.1605299570723.JavaMail.zimbra@u-pem.fr>
 <35bd0d32-7336-12c6-847f-a78281298e7c@oracle.com>
 <900775067.1677030.1605304926732.JavaMail.zimbra@u-pem.fr>
 <26D3C9FB-4495-49A4-A139-C8F51493DF68@oracle.com>
 <507694931.1691845.1605309953085.JavaMail.zimbra@u-pem.fr>
 <902383DC-00D5-4D33-91F4-5DF355FEDDB7@oracle.com>
 <c8f9682a-eb86-e3a0-79bb-31da50bc26f6@oracle.com>
Message-ID: <13AB8043-29D4-4552-94CF-B7B74E7D42F1@oracle.com>

Thanks; that looks good to go.  ? John

> On Nov 17, 2020, at 12:43 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
> 
> Thanks for the feedback, John and Remi.
> 
> Here is the updated specdiff:
>    http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/ <http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/>
> 
> I added @apiNote in `defineClassHiddenWithClassData` about mutability.
> I keep `classData` that can be used for a single-item class data or of type other than List like array, map, or even record.   `classDataAt` makes it easier for those who use a list as the class data (that can be extended for frozen arrays in the future).    The @apiNote suggests the good practice to use unmodifiable List.   (Stream::asList is not yet integrated and no reference from the @apiNote).
> 
> I will update https://github.com/openjdk/jdk/pull/1171 <https://github.com/openjdk/jdk/pull/1171> 
> 
> Mandy
> 
> On 11/13/20 5:11 PM, John Rose wrote:
>> I see your point; it?s the unconditional use of List.{copy,}of
>> that is the hard problem (with nulls).  The problem with
>> @Stable is a minor internal perf. bug, not a problem with
>> the API.
>> 
>> I agree that the basic single ClassData should not be
>> restricted to a List.  (But if it were, it should be copied
>> by Stuart?s null-friendly immutable list-maker.)
>> 
>> I also think it?s reasonable to trust users of condy
>> to take adequate care of mutability issues.  I suggest
>> adding an @apiNote which says ?Think twice before
>> passing an array or other mutable structure through
>> the ClassData.  If you use a List, make it unmodifiable,
>> using List.of or Stream.asList.?
>> 
>> 
>> On Nov 13, 2020, at 3:25 PM, forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> wrote:
>>> ----- Mail original -----
>>>> De: "John Rose" <john.r.rose at oracle.com> <mailto:john.r.rose at oracle.com>
>>>> ?: "Remi Forax" <forax at univ-mlv.fr> <mailto:forax at univ-mlv.fr>
>>>> Cc: "mandy chung" <mandy.chung at oracle.com> <mailto:mandy.chung at oracle.com>, "valhalla-dev" <valhalla-dev at openjdk.java.net> <mailto:valhalla-dev at openjdk.java.net>
>>>> Envoy?: Vendredi 13 Novembre 2020 23:46:24
>>>> Objet: Re: JDK-8230501: Class data support for hidden classes
>>>> On Nov 13, 2020, at 2:02 PM, forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> wrote:
>>>>> I want it, null is easy to check in term of bytecode and is aggressively
>>>>> propagated by c1 and c2 so you can write the equivalent IFDEF at runtine by
>>>>> putting nulls in the right holes.
>>>>> It's also pretty useful when you have object that have a double representation,
>>>>> i.e. a value that can be a primitive value or a box, again testing if the box
>>>>> is null is a common operation.
>>>> Null as a static constant can be created easily by other means,
>>>> so in most use cases, there?s no need to plumb a null through
>>>> a ClassData.  Just use aconst_null or ili.CBs::nullConstant.
>>> yes,
>>> but i was thinking about using it to define things like a capability, being null meaning the capability doesn't exist,
>>> so you still also need to be able to pass a real object if the capability exists.
>>> 
>>> something like
>>>  if (ldc condy != null) {
>>>    ldc condy
>>>    invokevirtual ...
>>>  }
>>> 
>>>> Maybe what you are hoping for is statically generated bytecodes
>>>> which are invariant across nullable ?holes?, where the holes
>>>> are filled by a ClassData. 
>>> yes,
>>> it's the same bytecode specialized using holes, so you don't have to generate it at runtime, only to specialize it at runtime.
>>> 
>>>> Fine, in that case use a nullable container, such as Stuart Marks? Stream::asList.
>>> First, you can not using the result of toList() if it's a null friendly List because Mandy propose to use a List.copyOf() in between that will choke is there is a null inside the List.
>>> Moreover if Stuart still want to use ListN to both this kind of List and List.of(...) then the result of ListN.get() will not be a constant if the value is null (because of the semantics of @Stable).
>>> Which means that classData() will be useless, the only way will be to use classDataAt().
>>> 
>>> To summarize, if the only thing you can inject is a List which will be copy into an immutable list, passing null will not be easy, I can still wrap it and then unwrap it with you own condy BSM, it makes classData() useless as a BSM and makes passing only one object far more complex than the previous proposal.
>>> 
>>>> ? John
>>> R?mi
> 



From dsimms at openjdk.java.net  Wed Nov 18 08:31:14 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 18 Nov 2020 08:31:14 GMT
Subject: [lworld] Integrated: 8255995: templateTable_x86.cpp
 (TemplateTable::if_acmp) not always do correct null check.
In-Reply-To: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>
References: <4zuLfF49uzuPyYuNG3rnTtyUMlMGVUBuK-wat2g0ZeE=.61b587e5-64f3-4da0-be16-2583fac104c3@github.com>
Message-ID: <mJ2sVxmNV3YkNFeSy4IijVJgs2ZjS82ZChJMh2UShaE=.8161402d-74e3-4b2c-a104-abf1203b1516@github.com>

On Tue, 17 Nov 2020 17:54:36 GMT, David Simms <dsimms at openjdk.org> wrote:

> Testing both pointers at the same time, doesn't account for the case where bits
> completely miss each other, resulting in zero as result e.g.
> 
>   test(0x10, 0x01) == 0x10 & 0x01 == 0, yet neither are null

This pull request has now been integrated.

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

8255995: templateTable_x86.cpp (TemplateTable::if_acmp) not always do correct null check.

Reviewed-by: fparain, thartmann

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

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


From thartmann at openjdk.java.net  Wed Nov 18 13:35:18 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 18 Nov 2020 13:35:18 GMT
Subject: [lworld] RFR: 8256481: [lworld] C2 fails to eliminate GC barriers
 when replacing in line type buffer allocation
Message-ID: <IxCRsg7rwS18FLXwtiZ7W3Wtqc6JkE-NFA3GnvngKIE=.d2b35cc6-e534-4198-92e6-326c538d191d@github.com>

In Valhalla code, `G1BarrierSetC2::eliminate_gc_barrier` is not only used at macro expansion but also during IGVN to remove inline type buffer allocations. Current code is not robust enough to handle duplicate barriers and other IR shapes that were not yet folded by IGVN. This fix makes it more robust.

Thanks,
Tobias

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

Commit messages:
 - 8256481: [lworld] C2 fails to eliminate GC barriers when replacing inline type buffer allocation

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

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


From dlsmith at openjdk.java.net  Wed Nov 18 16:04:32 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Wed, 18 Nov 2020 16:04:32 GMT
Subject: RFR: Merge openjdk/valhalla:master [v2]
In-Reply-To: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>
References: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>
Message-ID: <t3MAYZcWJNLVVUW-JremxDg8rgU-zRrTupXgtP_33dA=.edf28280-f8e2-431c-92c2-581458c114ae@github.com>

> Merge from tag jdk-16+24

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

 - Merge commit 'bfa060f098e477fb45bc466f87fd66842161b73f' into jep390_merge_jdk_16_24
 - 8254271: Development to deprecate wrapper class constructors for removal
   
   Reviewed-by: mchung
 - 8254274: Development to add 'lint' warning for @ValueBased classes
   
   Reviewed-by: dlsmith, jlaskey
 - 8255125: [Development] copy jdk.internal.ValueBased to jep390 branch
   
   Reviewed-by: mchung

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/263/files
  - new: https://git.openjdk.java.net/valhalla/pull/263/files/a539ac26..a539ac26

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

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

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


From dlsmith at openjdk.java.net  Wed Nov 18 16:04:36 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Wed, 18 Nov 2020 16:04:36 GMT
Subject: Integrated: Merge openjdk/valhalla:master
In-Reply-To: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>
References: <F6jb4aF4dV8riyXztUpoAr5ZkTkeXDlbcIugGCPa-ts=.d5cb3fb9-b15f-4e0c-8000-2199f27ebd94@github.com>
Message-ID: <VxpF9BaJTG42GE8yZHijCgLbt3uHJ9I89ggPwQb9Pjs=.3aac8103-b456-4543-b66b-43756048bc62@github.com>

On Tue, 17 Nov 2020 00:23:38 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Merge from tag jdk-16+24

This pull request has now been integrated.

Changeset: de62f4e5
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/de62f4e5
Stats:     501028 lines in 3046 files changed: 419569 ins; 60778 del; 20681 mod

Merge

Reviewed-by: rriggs

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

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


From thartmann at openjdk.java.net  Wed Nov 18 16:47:20 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 18 Nov 2020 16:47:20 GMT
Subject: [lworld] Integrated: 8256481: [lworld] C2 fails to eliminate GC
 barriers when replacing inline type buffer allocation
In-Reply-To: <IxCRsg7rwS18FLXwtiZ7W3Wtqc6JkE-NFA3GnvngKIE=.d2b35cc6-e534-4198-92e6-326c538d191d@github.com>
References: <IxCRsg7rwS18FLXwtiZ7W3Wtqc6JkE-NFA3GnvngKIE=.d2b35cc6-e534-4198-92e6-326c538d191d@github.com>
Message-ID: <e51bSU8pE3Aec1NDYD8sL-d4EpqpBW3tNAbnMXn2D7s=.28117542-1755-4b17-a093-0a7a3531d237@github.com>

On Wed, 18 Nov 2020 13:31:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In Valhalla code, `G1BarrierSetC2::eliminate_gc_barrier` is not only used at macro expansion but also during IGVN to remove inline type buffer allocations. Current code is not robust enough to handle duplicate barriers and other IR shapes that were not yet folded by IGVN. This fix makes it more robust.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 39c775ff
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/39c775ff
Stats:     36 lines in 2 files changed: 6 ins; 4 del; 26 mod

8256481: [lworld] C2 fails to eliminate GC barriers when replacing inline type buffer allocation

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

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


From rriggs at openjdk.java.net  Wed Nov 18 18:58:15 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 18:58:15 GMT
Subject: RFR: 8256002: Cleanup of Wrapper changes
Message-ID: <6s-3BhQ1RqfmbKp0tAx4cRod_LtzCBaJUOnpe_pbq1k=.c0b14b21-3b2a-4e80-bc5e-f8ad151088bf@github.com>

Cleanup of commit deprecating for removal the primitive wrapper classes.
 - Removed the unneeded test.
 - Restored the original code in some graal tests to avoid merge problems.
 - Removed unnecessary use of valueOf, when implicit casts were sufficient (in RMI classes).
 - Added a few SuppressWarnings for "removal" and "synchronization" to keep tests working.

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

Commit messages:
 - Suppress removal and synchronization warning and make JapaneseDate fields final
 - 8256002: Cleanup of Wrapper changes

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

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


From mchung at openjdk.java.net  Wed Nov 18 21:45:10 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 Nov 2020 21:45:10 GMT
Subject: RFR: 8256002: Cleanup of Wrapper changes
In-Reply-To: <6s-3BhQ1RqfmbKp0tAx4cRod_LtzCBaJUOnpe_pbq1k=.c0b14b21-3b2a-4e80-bc5e-f8ad151088bf@github.com>
References: <6s-3BhQ1RqfmbKp0tAx4cRod_LtzCBaJUOnpe_pbq1k=.c0b14b21-3b2a-4e80-bc5e-f8ad151088bf@github.com>
Message-ID: <jUcGYcclQAFPIG-WZ8ZXzXzxqvuVAM5XyFpmNXkYvJ4=.cd0b3975-23ca-4758-90e2-7b445f118c53@github.com>

On Tue, 17 Nov 2020 19:53:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup of commit deprecating for removal the primitive wrapper classes.
>  - Removed the unneeded test.
>  - Restored the original code in some graal tests to avoid merge problems.
>  - Removed unnecessary use of valueOf, when implicit casts were sufficient (in RMI classes).
>  - Added a few SuppressWarnings for "removal" and "synchronization" to keep tests working.

Marked as reviewed by mchung (Reviewer).

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

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


From rriggs at openjdk.java.net  Wed Nov 18 21:58:13 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 21:58:13 GMT
Subject: RFR: 8256002: Cleanup of Wrapper changes
In-Reply-To: <jUcGYcclQAFPIG-WZ8ZXzXzxqvuVAM5XyFpmNXkYvJ4=.cd0b3975-23ca-4758-90e2-7b445f118c53@github.com>
References: <6s-3BhQ1RqfmbKp0tAx4cRod_LtzCBaJUOnpe_pbq1k=.c0b14b21-3b2a-4e80-bc5e-f8ad151088bf@github.com>
 <jUcGYcclQAFPIG-WZ8ZXzXzxqvuVAM5XyFpmNXkYvJ4=.cd0b3975-23ca-4758-90e2-7b445f118c53@github.com>
Message-ID: <DwneLChgd0eWdWTshASAQXkElZMuUIME_nMvVdVOuWk=.fef97166-dca1-4008-a264-f9001e7ffc93@github.com>

On Wed, 18 Nov 2020 21:42:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Cleanup of commit deprecating for removal the primitive wrapper classes.
>>  - Removed the unneeded test.
>>  - Restored the original code in some graal tests to avoid merge problems.
>>  - Removed unnecessary use of valueOf, when implicit casts were sufficient (in RMI classes).
>>  - Added a few SuppressWarnings for "removal" and "synchronization" to keep tests working.
>
> Marked as reviewed by mchung (Reviewer).

Thanks Mandy,

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

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


From rriggs at openjdk.java.net  Wed Nov 18 21:58:14 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 21:58:14 GMT
Subject: Integrated: 8256002: Cleanup of Wrapper changes
In-Reply-To: <6s-3BhQ1RqfmbKp0tAx4cRod_LtzCBaJUOnpe_pbq1k=.c0b14b21-3b2a-4e80-bc5e-f8ad151088bf@github.com>
References: <6s-3BhQ1RqfmbKp0tAx4cRod_LtzCBaJUOnpe_pbq1k=.c0b14b21-3b2a-4e80-bc5e-f8ad151088bf@github.com>
Message-ID: <9qRfrmQLbzYlu26VcVfJCMbmOQYzKx_3Q1mMPgtGnAw=.25699659-95d1-4ed5-8dda-cae8e3ec82ed@github.com>

On Tue, 17 Nov 2020 19:53:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Cleanup of commit deprecating for removal the primitive wrapper classes.
>  - Removed the unneeded test.
>  - Restored the original code in some graal tests to avoid merge problems.
>  - Removed unnecessary use of valueOf, when implicit casts were sufficient (in RMI classes).
>  - Added a few SuppressWarnings for "removal" and "synchronization" to keep tests working.

This pull request has now been integrated.

Changeset: c6385a21
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c6385a21
Stats:     79 lines in 8 files changed: 1 ins; 62 del; 16 mod

8256002: Cleanup of Wrapper changes

Reviewed-by: mchung

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

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


From mchung at openjdk.java.net  Wed Nov 18 22:03:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 Nov 2020 22:03:16 GMT
Subject: RFR: 8253962: Add @ValueBased to unmodifable Collection
 implementation classes [v2]
In-Reply-To: <Xql-4ETHGBHLXRHJu_439aTOm1XRXcJK3XR1lXxfgXM=.0da02775-71bc-4444-81a6-164d8d38f2d8@github.com>
References: <UPOFPdYEm1FjOp-S6o0EXRZ5_Wtwp4cqFoX409OaRu8=.4b7e8e4c-eb3d-4a1b-bc92-7fa2dfc41c19@github.com>
 <Xql-4ETHGBHLXRHJu_439aTOm1XRXcJK3XR1lXxfgXM=.0da02775-71bc-4444-81a6-164d8d38f2d8@github.com>
Message-ID: <zU5UzzYiPSvcRMH7Og4A6yxDo1bJkxjrokhLOxK3Hx8=.c4d07c78-3af0-4d37-81a1-471ef846607b@github.com>

On Tue, 17 Nov 2020 19:48:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> As per JEP 390, The implementations of ImmutableCollections are marked as being @ValueBased.
>
> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - remove blank line
>  - Merge branch 'valuebased-collections-8253962' of https://github.com/RogerRiggs/valhalla into valuebased-collections-8253962
>  - 8253962: Add @ValueBased to unmodifable Collection implementation classes

Marked as reviewed by mchung (Reviewer).

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

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


From rriggs at openjdk.java.net  Thu Nov 19 15:24:22 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 Nov 2020 15:24:22 GMT
Subject: Integrated: 8253962: Add @ValueBased to unmodifable Collection
 implementation classes
In-Reply-To: <UPOFPdYEm1FjOp-S6o0EXRZ5_Wtwp4cqFoX409OaRu8=.4b7e8e4c-eb3d-4a1b-bc92-7fa2dfc41c19@github.com>
References: <UPOFPdYEm1FjOp-S6o0EXRZ5_Wtwp4cqFoX409OaRu8=.4b7e8e4c-eb3d-4a1b-bc92-7fa2dfc41c19@github.com>
Message-ID: <R69QVRTAESiNS8jevyD4BC7e89bGFXKj0f0TMuQ59WU=.9feff555-bc35-4153-af74-8363e6b20a48@github.com>

On Tue, 17 Nov 2020 19:37:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> As per JEP 390, The implementations of ImmutableCollections are marked as being @ValueBased.

This pull request has now been integrated.

Changeset: 12f93ebf
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/12f93ebf
Stats:     10 lines in 1 file changed: 10 ins; 0 del; 0 mod

8253962: Add @ValueBased to unmodifable Collection implementation classes

Reviewed-by: mchung

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

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


From rriggs at openjdk.java.net  Thu Nov 19 20:42:37 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 Nov 2020 20:42:37 GMT
Subject: RFR: 8256663: [test] Deprecated use of new Double in jshell ImportTest
Message-ID: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>

The jep-390 warnings caused a couple of tests to fail.
Suppressing the warnings to re-enable the tests.

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

Commit messages:
 - Fix tests broken by new warnings

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

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


From lfoltan at openjdk.java.net  Thu Nov 19 20:56:17 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Thu, 19 Nov 2020 20:56:17 GMT
Subject: RFR: 8256663: [test] Deprecated use of new Double in jshell
 ImportTest
In-Reply-To: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>
References: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>
Message-ID: <jxtRiMp7doeN-9khz58e908SBC3al57YdGXO7RaGE_g=.ab119a0d-17f1-4dbf-aa40-d1532a690eca@github.com>

On Thu, 19 Nov 2020 20:37:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The jep-390 warnings caused a couple of tests to fail.
> Suppressing the warnings to re-enable the tests.

Looks good.

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

Marked as reviewed by lfoltan (Reviewer).

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


From mchung at openjdk.java.net  Thu Nov 19 21:19:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 19 Nov 2020 21:19:19 GMT
Subject: RFR: 8256663: [test] Deprecated use of new Double in jshell
 ImportTest
In-Reply-To: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>
References: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>
Message-ID: <vgzuztZ60aRhj-FDa4rIOzWHAhuuLKUevJKjq4lfdlQ=.a8b820ef-8163-47f2-8f0a-a4fa85fdb531@github.com>

On Thu, 19 Nov 2020 20:37:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The jep-390 warnings caused a couple of tests to fail.
> Suppressing the warnings to re-enable the tests.

Marked as reviewed by mchung (Reviewer).

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

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


From rriggs at openjdk.java.net  Thu Nov 19 22:38:09 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 Nov 2020 22:38:09 GMT
Subject: Integrated: 8256663: [test] Deprecated use of new Double in jshell
 ImportTest
In-Reply-To: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>
References: <Zw-mKip8KJb2gGXtDAbZDmKebfsF57GFTFVbrhqKXYA=.39683ab7-5ceb-4c07-9989-cd76b1617419@github.com>
Message-ID: <WwECfW29C4oMdyI7QxrWkivUKw86AvRWMIFnYG1hkw8=.9cbb1ee6-d9cb-498b-bbae-47060baf5f77@github.com>

On Thu, 19 Nov 2020 20:37:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The jep-390 warnings caused a couple of tests to fail.
> Suppressing the warnings to re-enable the tests.

This pull request has now been integrated.

Changeset: eb31a05a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/eb31a05a
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8256663: [test] Deprecated use of new Double in jshell ImportTest
8256667: [test] Unexpected warnings in javac test T8074381a

Reviewed-by: lfoltan, mchung

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

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


From dsimms at openjdk.java.net  Fri Nov 20 08:20:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 20 Nov 2020 08:20:11 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <IiLH_zD-wx3v-9C7RZHQIn8CVzYTv7LBZJCmqUqr1uQ=.ed5c3621-332d-4aab-9a06-b7391fd92686@github.com>

Merge tag 'jdk-16+25'

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

Commit messages:
 - Accidentally removed java_return_convention
 - Merge tag 'jdk-16+25' into lworld_merge_jdk_16_25
 - 8255936: "parsing found no loops but there are some" assertion failure with Shenandoah
 - 8256461: AbstractFileSystemProvider.getSunPathForSocketCall for empty Path returns '.'
 - 8253081: G1 fails on stale objects in archived module graph in Open Archive regions
 - 8255368: Math.exp() gives wrong result for large values on x86 32-bit platforms
 - 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose
 - 8256435: [TESTBUG] java/foreign/TestHandshake.java fails with direct buffer memory OOM
 - 8255448: Fastdebug JVM crashes with Vector API when PrintAssembly is turned on
 - 8134630: make code and comments consistent for stack lock optimization
 - ... and 74 more: https://git.openjdk.java.net/valhalla/compare/39c775ff...7e9e4dc1

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

Changes: https://git.openjdk.java.net/valhalla/pull/272/files
  Stats: 20136 lines in 466 files changed: 12280 ins; 5157 del; 2699 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/272.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/272/head:pull/272

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


From dsimms at openjdk.java.net  Fri Nov 20 08:30:21 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 20 Nov 2020 08:30:21 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <IiLH_zD-wx3v-9C7RZHQIn8CVzYTv7LBZJCmqUqr1uQ=.ed5c3621-332d-4aab-9a06-b7391fd92686@github.com>
References: <IiLH_zD-wx3v-9C7RZHQIn8CVzYTv7LBZJCmqUqr1uQ=.ed5c3621-332d-4aab-9a06-b7391fd92686@github.com>
Message-ID: <zA81GLiWXvRSglY9buNVClV-hCIzTuTaAPE5EOYTAno=.85771b57-0931-4521-beac-c46e4bfcb967@github.com>

On Fri, 20 Nov 2020 08:15:06 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+25'

This pull request has now been integrated.

Changeset: 0e48aeb4
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0e48aeb4
Stats:     20136 lines in 466 files changed: 12280 ins; 5157 del; 2699 mod

Merge jdk

Merge tag 'jdk-16+25'

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

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


From dsimms at openjdk.java.net  Fri Nov 20 09:22:40 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 20 Nov 2020 09:22:40 GMT
Subject: RFR: Merge lworld
Message-ID: <T1i4OM2VREueTy6vOI-eoVf-K1i7nn5PGllifxtsaYk=.a863abd6-de8f-4469-8f03-184f176aa57e@github.com>

Merge jdk-16+25

Merge branch 'lworld' into type-restrictions_merge_jdk_16_25

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

Commit messages:
 - Merge branch 'lworld' into type-restrictions_merge_jdk_16_25
 - Merge jdk
 - 8255936: "parsing found no loops but there are some" assertion failure with Shenandoah
 - 8256461: AbstractFileSystemProvider.getSunPathForSocketCall for empty Path returns '.'
 - 8253081: G1 fails on stale objects in archived module graph in Open Archive regions
 - 8255368: Math.exp() gives wrong result for large values on x86 32-bit platforms
 - 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose
 - 8256435: [TESTBUG] java/foreign/TestHandshake.java fails with direct buffer memory OOM
 - 8255448: Fastdebug JVM crashes with Vector API when PrintAssembly is turned on
 - 8134630: make code and comments consistent for stack lock optimization
 - ... and 82 more: https://git.openjdk.java.net/valhalla/compare/45d36103...a8a19616

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

Changes: https://git.openjdk.java.net/valhalla/pull/273/files
  Stats: 20483 lines in 486 files changed: 12525 ins; 5213 del; 2745 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/273/head:pull/273

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


From dsimms at openjdk.java.net  Fri Nov 20 09:32:31 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 20 Nov 2020 09:32:31 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <T1i4OM2VREueTy6vOI-eoVf-K1i7nn5PGllifxtsaYk=.a863abd6-de8f-4469-8f03-184f176aa57e@github.com>
References: <T1i4OM2VREueTy6vOI-eoVf-K1i7nn5PGllifxtsaYk=.a863abd6-de8f-4469-8f03-184f176aa57e@github.com>
Message-ID: <V1p0sZeWFtdB-h9Wg6ghCV4pcRR4YrzAH9MNnqwtCP8=.2ace558b-3998-4e66-9a25-a468e7983c6d@github.com>

On Fri, 20 Nov 2020 09:17:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-16+25
> 
> Merge branch 'lworld' into type-restrictions_merge_jdk_16_25

This pull request has now been integrated.

Changeset: 46d09bb0
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/46d09bb0
Stats:     20483 lines in 486 files changed: 12525 ins; 5213 del; 2745 mod

Merge lworld

Merge jdk-16+25

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

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


From dsimms at openjdk.java.net  Fri Nov 20 09:32:29 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Fri, 20 Nov 2020 09:32:29 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <T1i4OM2VREueTy6vOI-eoVf-K1i7nn5PGllifxtsaYk=.a863abd6-de8f-4469-8f03-184f176aa57e@github.com>
References: <T1i4OM2VREueTy6vOI-eoVf-K1i7nn5PGllifxtsaYk=.a863abd6-de8f-4469-8f03-184f176aa57e@github.com>
Message-ID: <tLkiqpaw1UIMVcMZM0wLperVbbEok2yUUyQvqWHGgSY=.e32014de-dc4e-40e2-8e17-f075962e0c34@github.com>

> Merge jdk-16+25
> 
> Merge branch 'lworld' into type-restrictions_merge_jdk_16_25

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

 - Merge branch 'lworld' into type-restrictions_merge_jdk_16_25
 - Merge lworld
   
   Merge jdk-16+24
 - Merge lworld
   
   Merge tag 'jdk-16+23'
 - Merge lworld
   
   Merge tag jdk-16+22
 - Merge lworld
   
   Merge lworld at tag jdk-16+21
 - Merge lworld
   
   Merge jdk-16+20
 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK
   
   Reviewed-by: lfoltan
 - Merge lworld
   
   Merge tag 'jdk-16+19'
 - 8254022: [lworld] [type-restrictions] Initial support for RestrictedField
   
   Reviewed-by: dsimms
 - 8253760: [type-restrictions] Static inline fields are not "erased" to the ref type
 - ... and 1 more: https://git.openjdk.java.net/valhalla/compare/0e48aeb4...a8a19616

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

Changes: https://git.openjdk.java.net/valhalla/pull/273/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=273&range=01
  Stats: 691 lines in 36 files changed: 640 ins; 5 del; 46 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/273.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/273/head:pull/273

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


From lfoltan at openjdk.java.net  Fri Nov 20 20:59:38 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Fri, 20 Nov 2020 20:59:38 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes
Message-ID: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>

Please review the following changes to add JVM support for @ValueBased class annotation.

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

Commit messages:
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

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

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


From dlsmith at openjdk.java.net  Sat Nov 21 00:22:20 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 21 Nov 2020 00:22:20 GMT
Subject: RFR: Merge valhalla:master
Message-ID: <HicLvv7uJHc5Nf8aMLjCzwnfrZ-MB_MLv963Ldj9Y2M=.2996e5f0-9490-455e-aa2c-2bf89196dd16@github.com>

Merge from jdk tag 'jdk-16+25'.

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

Commit messages:
 - Merge jdk tag 'jdk-16+25' into jep390-merge/jdk-16+25
 - 8255936: "parsing found no loops but there are some" assertion failure with Shenandoah
 - 8256461: AbstractFileSystemProvider.getSunPathForSocketCall for empty Path returns '.'
 - 8253081: G1 fails on stale objects in archived module graph in Open Archive regions
 - 8255368: Math.exp() gives wrong result for large values on x86 32-bit platforms
 - 8256476: Assert in vmIntrinsics::flags_for with -XX:+Verbose
 - 8256435: [TESTBUG] java/foreign/TestHandshake.java fails with direct buffer memory OOM
 - 8255448: Fastdebug JVM crashes with Vector API when PrintAssembly is turned on
 - 8134630: make code and comments consistent for stack lock optimization
 - 8256484: ZGC: Rename ZRelocationSetSelector::register_garbage_page()
 - ... and 73 more: https://git.openjdk.java.net/valhalla/compare/eb31a05a...07c20aaf

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

Changes: https://git.openjdk.java.net/valhalla/pull/275/files
  Stats: 20691 lines in 466 files changed: 12836 ins; 5156 del; 2699 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/275.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/275/head:pull/275

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


From dlsmith at openjdk.java.net  Sat Nov 21 00:31:36 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 21 Nov 2020 00:31:36 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v5]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <Ku0LfJcwRZIb7fl6zNVRmfn5uwzC0y7o4PYLfym0fBs=.cfe34553-83a4-425f-aad9-44ef481113d1@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/222/files
  - new: https://git.openjdk.java.net/valhalla/pull/222/files/3288f433..14487248

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

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

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


From dlsmith at openjdk.java.net  Sat Nov 21 06:07:16 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 21 Nov 2020 06:07:16 GMT
Subject: Integrated: Merge valhalla:master
In-Reply-To: <HicLvv7uJHc5Nf8aMLjCzwnfrZ-MB_MLv963Ldj9Y2M=.2996e5f0-9490-455e-aa2c-2bf89196dd16@github.com>
References: <HicLvv7uJHc5Nf8aMLjCzwnfrZ-MB_MLv963Ldj9Y2M=.2996e5f0-9490-455e-aa2c-2bf89196dd16@github.com>
Message-ID: <teWCOqVIKtwt-5JlIko_xU5usFzmMOYtzo7XvQQcPoY=.70f4ba99-8178-4fa2-a9b2-bcc744d81875@github.com>

On Sat, 21 Nov 2020 00:16:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Merge from jdk tag 'jdk-16+25'.

This pull request has now been integrated.

Changeset: db8e604f
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/db8e604f
Stats:     20691 lines in 466 files changed: 12836 ins; 5156 del; 2699 mod

Merge

>From jdk tag 'jdk-16+25'

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

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


From fparain at openjdk.java.net  Mon Nov 23 13:32:13 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 23 Nov 2020 13:32:13 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <KJ_ldyYGDZoXs-fY0m-bfsx0IpRPYUenGGtIMOCoMnk=.07f396d2-1cde-432b-afa7-48c8dfbca775@github.com>

On Fri, 20 Nov 2020 20:50:58 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

> Please review the following changes to add JVM support for @ValueBased class annotation.

Looks good to me.
Just one comment: The ValueBased annotation is ignored for non-privileged classes, this would prevent users from testing their own code with the DiagnoseSyncOnValueBasedClasses flag. Is there a particular reason to not enforce the ValueBased annotation on user code?

Fred

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

Marked as reviewed by fparain (Committer).

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


From hseigel at openjdk.java.net  Mon Nov 23 13:54:08 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 23 Nov 2020 13:54:08 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <agZEvfzm54qylpaWRg_v175CD1J09T86KWk90T8lIwo=.8737b75c-18c0-4926-b954-5e194cd8a24f@github.com>

On Fri, 20 Nov 2020 20:50:58 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

> Please review the following changes to add JVM support for @ValueBased class annotation.

The changes look good!  Can the check for "DiagnoseSyncOnPrimitveWrappers != 0" be removed from lines 330 and 442?  I don't think "obj->klass()->is_value_based()" will be TRUE unless "DiagnoseSyncOnPrimitiveWrappers != 0".

Perhaps do an assert instead?

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

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


From rriggs at openjdk.java.net  Mon Nov 23 18:55:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 Nov 2020 18:55:06 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes
In-Reply-To: <KJ_ldyYGDZoXs-fY0m-bfsx0IpRPYUenGGtIMOCoMnk=.07f396d2-1cde-432b-afa7-48c8dfbca775@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
 <KJ_ldyYGDZoXs-fY0m-bfsx0IpRPYUenGGtIMOCoMnk=.07f396d2-1cde-432b-afa7-48c8dfbca775@github.com>
Message-ID: <_5tcjnEo3E0wTMw3YQ3ZCYKFQ7Qhhsd996PcaKPGSAw=.f0bf436c-e24a-48db-bda6-b4868ee78798@github.com>

On Mon, 23 Nov 2020 13:29:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Looks good to me.
> Just one comment: The ValueBased annotation is ignored for non-privileged classes, this would prevent users from testing their own code with the DiagnoseSyncOnValueBasedClasses flag. Is there a particular reason to not enforce the ValueBased annotation on user code?
> 
> Fred

The jdk.internal.ValueBased annotation is internal to the base module and only defined for use by the JDK implementation as per JEP 390. It is intended to indicate that an application or library is using a system class instance incorrectly.

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

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


From FREDERIC.PARAIN at ORACLE.COM  Mon Nov 23 19:09:22 2020
From: FREDERIC.PARAIN at ORACLE.COM (Frederic Parain)
Date: Mon, 23 Nov 2020 14:09:22 -0500
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes
In-Reply-To: <_5tcjnEo3E0wTMw3YQ3ZCYKFQ7Qhhsd996PcaKPGSAw=.f0bf436c-e24a-48db-bda6-b4868ee78798@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
 <KJ_ldyYGDZoXs-fY0m-bfsx0IpRPYUenGGtIMOCoMnk=.07f396d2-1cde-432b-afa7-48c8dfbca775@github.com>
 <_5tcjnEo3E0wTMw3YQ3ZCYKFQ7Qhhsd996PcaKPGSAw=.f0bf436c-e24a-48db-bda6-b4868ee78798@github.com>
Message-ID: <9BCA1DBB-844E-4029-84E4-CEAFB7F608F8@ORACLE.COM>

Thank you for the explanation.

Fred


> On Nov 23, 2020, at 1:55 PM, Roger Riggs <rriggs at openjdk.java.net> wrote:
> 
> On Mon, 23 Nov 2020 13:29:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:
> 
>> Looks good to me.
>> Just one comment: The ValueBased annotation is ignored for non-privileged classes, this would prevent users from testing their own code with the DiagnoseSyncOnValueBasedClasses flag. Is there a particular reason to not enforce the ValueBased annotation on user code?
>> 
>> Fred
> 
> The jdk.internal.ValueBased annotation is internal to the base module and only defined for use by the JDK implementation as per JEP 390. It is intended to indicate that an application or library is using a system class instance incorrectly.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/valhalla/pull/274



From rriggs at openjdk.java.net  Mon Nov 23 19:44:10 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 Nov 2020 19:44:10 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v5]
In-Reply-To: <Ku0LfJcwRZIb7fl6zNVRmfn5uwzC0y7o4PYLfym0fBs=.cfe34553-83a4-425f-aad9-44ef481113d1@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <Ku0LfJcwRZIb7fl6zNVRmfn5uwzC0y7o4PYLfym0fBs=.cfe34553-83a4-425f-aad9-44ef481113d1@github.com>
Message-ID: <ISkIrLmHki8Gr88iqH4OFtzc-feNqNgwKsOYz6ue4mQ=.f2bd570c-8607-4a68-987b-3c80de8e25af@github.com>

On Sat, 21 Nov 2020 00:31:36 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
>> 
>> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 40:

> 38:     <li>the class declares only final instance fields (though these may contain references
> 39:         to mutable objects);</li>
> 40:     <li>the class declares implementations of <code>equals</code>,

Does saying the class "declares" the methods apply to Records and other classes that have provided or generated methods for equals, hashcode, and toString?  Must the class explicitly declare the methods to meet the criteria?

Perhaps "the implementations of equals, hashCode, and tostring use only the instance's state...".

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

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


From lfoltan at openjdk.java.net  Mon Nov 23 21:34:29 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 23 Nov 2020 21:34:29 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v2]
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <QEC0KbCZigY6-3AJXw7iXHVkEJPkSQq_Fdl-QQuOgKU=.73c17bf3-1587-4dc6-bcaf-657f57547ec0@github.com>

> Please review the following changes to add JVM support for @ValueBased class annotation.

Lois Foltan 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 'jep390' into bug_8252182
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

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

Changes: https://git.openjdk.java.net/valhalla/pull/274/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=274&range=01
  Stats: 314 lines in 34 files changed: 135 ins; 101 del; 78 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/274.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/274/head:pull/274

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


From lfoltan at openjdk.java.net  Mon Nov 23 22:43:34 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 23 Nov 2020 22:43:34 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v3]
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <vTZ6P3MLYRmagaxhd5E9m0X2GhqIP8Yc3th46mYT9h8=.189b5f0a-01c5-484b-bf06-912985e21806@github.com>

> Please review the following changes to add JVM support for @ValueBased class annotation.

Lois Foltan has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'bug_8252182' of github.com:lfoltan/valhalla into bug_8252182
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/274/files
  - new: https://git.openjdk.java.net/valhalla/pull/274/files/dbfeff58..62ba8356

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

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

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


From lfoltan at openjdk.java.net  Mon Nov 23 22:49:09 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 23 Nov 2020 22:49:09 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v3]
In-Reply-To: <_5tcjnEo3E0wTMw3YQ3ZCYKFQ7Qhhsd996PcaKPGSAw=.f0bf436c-e24a-48db-bda6-b4868ee78798@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
 <KJ_ldyYGDZoXs-fY0m-bfsx0IpRPYUenGGtIMOCoMnk=.07f396d2-1cde-432b-afa7-48c8dfbca775@github.com>
 <_5tcjnEo3E0wTMw3YQ3ZCYKFQ7Qhhsd996PcaKPGSAw=.f0bf436c-e24a-48db-bda6-b4868ee78798@github.com>
Message-ID: <-c0ZK1UeInkRC-ACB04FIA7E3fyzzmxRPAktu1XHjJc=.810816c9-66bc-4a9e-882b-75f7da7ccc1d@github.com>

On Mon, 23 Nov 2020 18:52:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Looks good to me.
>> Just one comment: The ValueBased annotation is ignored for non-privileged classes, this would prevent users from testing their own code with the DiagnoseSyncOnValueBasedClasses flag. Is there a particular reason to not enforce the ValueBased annotation on user code?
>> 
>> Fred
>
>> Looks good to me.
>> Just one comment: The ValueBased annotation is ignored for non-privileged classes, this would prevent users from testing their own code with the DiagnoseSyncOnValueBasedClasses flag. Is there a particular reason to not enforce the ValueBased annotation on user code?
>> 
>> Fred
> 
> The jdk.internal.ValueBased annotation is internal to the base module and only defined for use by the JDK implementation as per JEP 390. It is intended to indicate that an application or library is using a system class instance incorrectly.

Thank you Harold, I have made your suggested changes to runtime/synchronizer.cpp

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

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


From lfoltan at openjdk.java.net  Mon Nov 23 22:49:09 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 23 Nov 2020 22:49:09 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v3]
In-Reply-To: <-c0ZK1UeInkRC-ACB04FIA7E3fyzzmxRPAktu1XHjJc=.810816c9-66bc-4a9e-882b-75f7da7ccc1d@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
 <KJ_ldyYGDZoXs-fY0m-bfsx0IpRPYUenGGtIMOCoMnk=.07f396d2-1cde-432b-afa7-48c8dfbca775@github.com>
 <_5tcjnEo3E0wTMw3YQ3ZCYKFQ7Qhhsd996PcaKPGSAw=.f0bf436c-e24a-48db-bda6-b4868ee78798@github.com>
 <-c0ZK1UeInkRC-ACB04FIA7E3fyzzmxRPAktu1XHjJc=.810816c9-66bc-4a9e-882b-75f7da7ccc1d@github.com>
Message-ID: <xvCWxQmypSbjCuSRWpfpdWG1rpyQxIWI-_p75FFVcXA=.e54794c0-170f-47d5-a7b8-2b0d22210dc7@github.com>

On Mon, 23 Nov 2020 22:45:25 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>>> Looks good to me.
>>> Just one comment: The ValueBased annotation is ignored for non-privileged classes, this would prevent users from testing their own code with the DiagnoseSyncOnValueBasedClasses flag. Is there a particular reason to not enforce the ValueBased annotation on user code?
>>> 
>>> Fred
>> 
>> The jdk.internal.ValueBased annotation is internal to the base module and only defined for use by the JDK implementation as per JEP 390. It is intended to indicate that an application or library is using a system class instance incorrectly.
>
> Thank you Harold, I have made your suggested changes to runtime/synchronizer.cpp

Thank you Fred for the review.

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

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


From lfoltan at openjdk.java.net  Mon Nov 23 23:25:23 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 23 Nov 2020 23:25:23 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v4]
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <5sPf_tHBBE1Z-AJBdyyVRSw8Rg3e_DzKeE5XDe4-bcc=.2b762942-562d-4063-b81d-b758c14a45a3@github.com>

> Please review the following changes to add JVM support for @ValueBased class annotation.

Lois Foltan has updated the pull request incrementally with one additional commit since the last revision:

  8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/274/files
  - new: https://git.openjdk.java.net/valhalla/pull/274/files/62ba8356..15938b3d

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

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

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


From sergey.kuksenko at oracle.com  Tue Nov 24 00:35:21 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Mon, 23 Nov 2020 16:35:21 -0800
Subject: UseACmpProfile question.
Message-ID: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>

Hi Roland and Tobias.

I am trying to evaluate UseACmpProfile option behavior. Rough results 
are quite controversial. There are scenarios where +UseACmpProfile is 
faster than -UseACmpProfile and vice versa.

In order to understand the difference I am digging into generated code. 
I found that even having -XX:-UseACmpProfile (turn off cmp profile) type 
checks are still generated:

 ? 0.67%? ????????? ????? 0x00007faef4126e00:?? mov 
0x10(%rbx,%r12,8),%r10?????? ;*aaload {reexecute=0 rethrow=0 
return_oop=0 return_vt=0}
 ???????? ???????? ?? ; - 
org.openjdk.bench.valhalla.sandbox.acmp.array.CompIdentityStates::comp0 at 32 
(line 33)
 ? 0.65%? ????????? ????? 0x00007faef4126e05:?? mov 
0x10(%rcx,%r12,8),%rbp?????? ;*aaload {reexecute=0 rethrow=0 
return_oop=0 return_vt=0}
 ???????? ???????? ?? ; - 
org.openjdk.bench.valhalla.sandbox.acmp.array.CompIdentityStates::comp0 at 28 
(line 33)
 ?12.69%? ????????? ????? 0x00007faef4126e0a:?? cmp %r10,%rbp
 ???????? ????????? ????? 0x00007faef4126e0d:?? je 0x00007faef4126e65
 ? 0.88%? ????????? ????? 0x00007faef4126e0f:?? mov 
0x8(%rbp),%r11d????????????? ; implicit exception: dispatches to 
0x00007faef4126f45
 ? 8.74%? ????????? ????? 0x00007faef4126e13:?? cmp 
$0x20554e,%r11d????????????? ; 
{metadata(&apos;org/openjdk/bench/valhalla/types/R64long&apos;)}
 ???????? ????????? ????? 0x00007faef4126e1a:?? jne 
0x00007faef4126ef8?????????? ;*if_acmpne {reexecute=0 rethrow=0 
return_oop=0 return_vt=0}
 ???????? ????????? ?? ; - 
org.openjdk.bench.valhalla.sandbox.acmp.array.CompIdentityStates::comp0 at 33 
(line 33)


Am I right?

How to disable type checks for "amp" completely?

Best regards,

Sergey Kuksenko.



From dlsmith at openjdk.java.net  Tue Nov 24 01:25:17 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 01:25:17 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v6]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <eKq3EKIq3SMUJncejarMjfeTsw2so38r9M_Paz7fmpQ=.39b8ccf5-08f7-48c0-b317-a13292007827@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Don't claim ConstantDescs or DynamicCallSiteDescs are value-based

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/222/files
  - new: https://git.openjdk.java.net/valhalla/pull/222/files/14487248..3c8fa53f

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

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

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


From dsimms at openjdk.java.net  Tue Nov 24 08:19:13 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 24 Nov 2020 08:19:13 GMT
Subject: [lworld] Integrated: 8256929: [lworld] Fails to compile with
 --with-debug-level=optimized
Message-ID: <rxZbya_neLyZZIzxfw6jrvASDn36vmlkbzkV7WuXRWo=.123d2fac-8fb7-4a81-9f9e-d1f44493bcf5@github.com>

Guard use of debug "valid_itable_index()" assert macro

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

Commit messages:
 - 8256929: [lworld] Fails to compile with --with-debug-level=optimized

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

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


From dsimms at openjdk.java.net  Tue Nov 24 08:19:14 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 24 Nov 2020 08:19:14 GMT
Subject: [lworld] Integrated: 8256929: [lworld] Fails to compile with
 --with-debug-level=optimized
In-Reply-To: <rxZbya_neLyZZIzxfw6jrvASDn36vmlkbzkV7WuXRWo=.123d2fac-8fb7-4a81-9f9e-d1f44493bcf5@github.com>
References: <rxZbya_neLyZZIzxfw6jrvASDn36vmlkbzkV7WuXRWo=.123d2fac-8fb7-4a81-9f9e-d1f44493bcf5@github.com>
Message-ID: <hM-CyWY55CB6LqHuyxfR2tG5s6_BXrDoBV1DGV_21lA=.67b0a04d-69c6-4afa-84ec-8647e73a1ffa@github.com>

On Tue, 24 Nov 2020 08:13:56 GMT, David Simms <dsimms at openjdk.org> wrote:

> Guard use of debug "valid_itable_index()" assert macro

This pull request has now been integrated.

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

8256929: [lworld] Fails to compile with --with-debug-level=optimized

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

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


From sadayapalam at openjdk.java.net  Tue Nov 24 11:39:29 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 24 Nov 2020 11:39:29 GMT
Subject: Integrated: 8255856: Generate RestrictedField attributes from
 annotations
Message-ID: <vOf6ih3c681Lqx2Qsx4wQn0giIrCVPLKM3q4tZ3Becs=.3f3ad4fe-62dd-420d-8193-a9b814667bf1@github.com>

Enable restricted type experiments with a fine grained control.

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

Commit messages:
 - Fix white space issues
 - 8255856: Generate RestrictedField attributes from annotations

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

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


From sadayapalam at openjdk.java.net  Tue Nov 24 11:39:33 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Tue, 24 Nov 2020 11:39:33 GMT
Subject: Integrated: 8255856: Generate RestrictedField attributes from
 annotations
In-Reply-To: <vOf6ih3c681Lqx2Qsx4wQn0giIrCVPLKM3q4tZ3Becs=.3f3ad4fe-62dd-420d-8193-a9b814667bf1@github.com>
References: <vOf6ih3c681Lqx2Qsx4wQn0giIrCVPLKM3q4tZ3Becs=.3f3ad4fe-62dd-420d-8193-a9b814667bf1@github.com>
Message-ID: <fhlztUEGaMZ7MClJXhAkjRwjeWV3InbmmCsCOQqlpms=.962b8ab4-4a43-47a5-9d86-4b9c04b04b4e@github.com>

On Tue, 24 Nov 2020 10:50:09 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> Enable restricted type experiments with a fine grained control.

This pull request has now been integrated.

Changeset: 0602e1ea
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0602e1ea
Stats:     157 lines in 4 files changed: 156 ins; 0 del; 1 mod

8255856: Generate RestrictedField attributes from annotations

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

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


From rwestrel at redhat.com  Tue Nov 24 12:52:34 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Tue, 24 Nov 2020 13:52:34 +0100
Subject: UseACmpProfile question.
In-Reply-To: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
Message-ID: <87tutekjcd.fsf@redhat.com>


Hi Sergey,

> How to disable type checks for "amp" completely?

Can you try -XX:-UseTypeSpeculation?

Roland.



From lfoltan at openjdk.java.net  Tue Nov 24 13:59:19 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Tue, 24 Nov 2020 13:59:19 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v5]
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <GhAXkD0RQU0cYvQX4n080oyFYE60SKr6qMC9aMDbVVU=.fba8486d-8370-4240-95ca-74ef6052fa26@github.com>

> Please review the following changes to add JVM support for @ValueBased class annotation.

Lois Foltan has updated the pull request incrementally with one additional commit since the last revision:

  8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/274/files
  - new: https://git.openjdk.java.net/valhalla/pull/274/files/15938b3d..ac5fc322

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

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

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


From hseigel at openjdk.java.net  Tue Nov 24 14:10:08 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 24 Nov 2020 14:10:08 GMT
Subject: RFR: 8252182: [JEP 390] Diagnose synchronization on @ValueBased
 classes [v5]
In-Reply-To: <GhAXkD0RQU0cYvQX4n080oyFYE60SKr6qMC9aMDbVVU=.fba8486d-8370-4240-95ca-74ef6052fa26@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
 <GhAXkD0RQU0cYvQX4n080oyFYE60SKr6qMC9aMDbVVU=.fba8486d-8370-4240-95ca-74ef6052fa26@github.com>
Message-ID: <PhW9uH-VADV24_N4y92HUvLr7fL635H3V-kRqFSmvV0=.de255191-9253-4872-ab79-1eeb5c68a4e5@github.com>

On Tue, 24 Nov 2020 13:59:19 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Please review the following changes to add JVM support for @ValueBased class annotation.
>
> Lois Foltan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

Changes look good.  Thanks for doing this!

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

Marked as reviewed by hseigel (Reviewer).

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


From lfoltan at openjdk.java.net  Tue Nov 24 14:13:16 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Tue, 24 Nov 2020 14:13:16 GMT
Subject: Integrated: 8252182: [JEP 390] Diagnose synchronization on
 @ValueBased classes
In-Reply-To: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
References: <RrjfFNeyKdK5FfiQ6eAACeOau1IosNipLb8gNDvaIRo=.08ece4ae-9223-49d7-922b-9214511a7f96@github.com>
Message-ID: <ojWxm4SKH5sMNHqaTa2hFTlnSuvul29i4Ib2tBv_S30=.c0befc2b-55c1-442a-8be9-4e85ee6c5b47@github.com>

On Fri, 20 Nov 2020 20:50:58 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

> Please review the following changes to add JVM support for @ValueBased class annotation.

This pull request has now been integrated.

Changeset: eec3823f
Author:    Lois Foltan <lfoltan at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/eec3823f
Stats:     313 lines in 34 files changed: 134 ins; 101 del; 78 mod

8252182: [JEP 390] Diagnose synchronization on @ValueBased classes

Reviewed-by: fparain, hseigel

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

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


From dlsmith at openjdk.java.net  Tue Nov 24 18:46:43 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 18:46:43 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v7]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <Tjx_VnXDYafo0V6dTyl7VSRn3tPSvvvqBp9wTKHG9Po=.a6be61e2-0c47-44cb-ab75-4f77c35216e9@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html

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

 - Merge branch 'jep390' into 8254275
 - Don't claim ConstantDescs or DynamicCallSiteDescs are value-based
 - Review comments
 - Addressing additional review comments for ValueBased.html
 - Addressing review comments in ValueBased.html
 - Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references.
 - 8254275: Development to revise ValueBased.html for consistency with inline class migration

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/222/files
  - new: https://git.openjdk.java.net/valhalla/pull/222/files/3c8fa53f..77464629

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=05-06

  Stats: 501347 lines in 3107 files changed: 419833 ins; 60779 del; 20735 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/222.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/222/head:pull/222

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


From dlsmith at openjdk.java.net  Tue Nov 24 18:56:20 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 18:56:20 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v8]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <p9wIzXj3j5sBmSHdy46IKauqZ5lcQ9SL0Y1HNl0BgdE=.7dd95e36-61be-4548-85e2-6db5f859d6fe@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html

Dan Smith has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'jep390' into 8254275
 - Merge branch 'jep390' into 8254275
 - Don't claim ConstantDescs or DynamicCallSiteDescs are value-based
 - Review comments
 - Addressing additional review comments for ValueBased.html
 - Addressing review comments in ValueBased.html
 - Revise definition for more flexible ==. Apply revised boilerplate to wrappers and existing references.
 - 8254275: Development to revise ValueBased.html for consistency with inline class migration

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

Changes: https://git.openjdk.java.net/valhalla/pull/222/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=07
  Stats: 258 lines in 48 files changed: 60 ins; 20 del; 178 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/222.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/222/head:pull/222

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


From dlsmith at openjdk.java.net  Tue Nov 24 19:16:06 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 19:16:06 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v5]
In-Reply-To: <ISkIrLmHki8Gr88iqH4OFtzc-feNqNgwKsOYz6ue4mQ=.f2bd570c-8607-4a68-987b-3c80de8e25af@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <Ku0LfJcwRZIb7fl6zNVRmfn5uwzC0y7o4PYLfym0fBs=.cfe34553-83a4-425f-aad9-44ef481113d1@github.com>
 <ISkIrLmHki8Gr88iqH4OFtzc-feNqNgwKsOYz6ue4mQ=.f2bd570c-8607-4a68-987b-3c80de8e25af@github.com>
Message-ID: <RG36TIVWv51SE5ndecxEJZKwfpvcN5FnIKCfqPfupWk=.ab0fbe3c-158f-4f34-940b-60f32f75200e@github.com>

On Mon, 23 Nov 2020 19:40:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/java.base/share/classes/java/lang/doc-files/ValueBased.html line 40:
> 
>> 38:     <li>the class declares only final instance fields (though these may contain references
>> 39:         to mutable objects);</li>
>> 40:     <li>the class declares implementations of <code>equals</code>,
> 
> Does saying the class "declares" the methods apply to Records and other classes that have provided or generated methods for equals, hashcode, and toString?  Must the class explicitly declare the methods to meet the criteria?
> 
> Perhaps "the implementations of equals, hashCode, and tostring use only the instance's state...".

Generated fields and methods are "implicitly declared". But I suppose acceptable implementations could be inherited from a superclass, if the superclass isn't Object. I'll fix.

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

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


From dlsmith at openjdk.java.net  Tue Nov 24 19:49:17 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 19:49:17 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v9]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <HIk6RphmFDHTjMpJcq8NQoIx6IX4ttgekDVaci_S95w=.56e3cd63-850c-44c0-b438-593ecdb6d5f7@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201013/api/index.html

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  review feedback: toString, equals, hashCode in ValueBased.html

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/222/files
  - new: https://git.openjdk.java.net/valhalla/pull/222/files/a327a32d..4c21b225

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=07-08

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

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


From dlsmith at openjdk.java.net  Tue Nov 24 20:09:20 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 20:09:20 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v10]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <R2V2P1pYjgrFFoWFMnhkHWytjhEm7sTAjsjHOSXKHg8=.fb3d8751-79a7-4d9b-935a-c227cb879902@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Update cross-references from existing value-based classes and the primitive wrapper classes.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201124/api/index.html

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  fix typo

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/222/files
  - new: https://git.openjdk.java.net/valhalla/pull/222/files/4c21b225..61914127

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=08-09

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

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


From dlsmith at openjdk.java.net  Tue Nov 24 21:10:22 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 21:10:22 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v11]
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <DO6iJ3yi-Z23iNMT0tDN4AoqQRFXHENzx4-1Y-0yrdo=.614d51c6-3d04-4f9e-afce-ae462cd863f4@github.com>

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Update cross-references from existing value-based classes and the primitive wrapper classes.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201124/api/index.html

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  rephrase toString/equals/hashCode bullet

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/222/files
  - new: https://git.openjdk.java.net/valhalla/pull/222/files/61914127..63db13ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=222&range=09-10

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

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


From rriggs at openjdk.java.net  Tue Nov 24 21:13:07 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 24 Nov 2020 21:13:07 GMT
Subject: RFR: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers [v11]
In-Reply-To: <DO6iJ3yi-Z23iNMT0tDN4AoqQRFXHENzx4-1Y-0yrdo=.614d51c6-3d04-4f9e-afce-ae462cd863f4@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
 <DO6iJ3yi-Z23iNMT0tDN4AoqQRFXHENzx4-1Y-0yrdo=.614d51c6-3d04-4f9e-afce-ae462cd863f4@github.com>
Message-ID: <K8xAa9XVAzxvuRcQOjqoVJqkgT4laqrb0wlottV27N0=.02c822fa-7302-4404-8b90-400bdff8dc4e@github.com>

On Tue, 24 Nov 2020 21:10:22 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
>> 
>> Update cross-references from existing value-based classes and the primitive wrapper classes.
>> 
>> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201124/api/index.html
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rephrase toString/equals/hashCode bullet

Looks good, thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

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


From dlsmith at openjdk.java.net  Tue Nov 24 22:34:04 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 24 Nov 2020 22:34:04 GMT
Subject: Integrated: 8254275: [valhalla/jep390] Revise "value-based class" &
 apply to wrappers
In-Reply-To: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
References: <CKwCEX_J7ptgx1hskRvoD05bjvIUy-UAKoEUo1yksA4=.7ad006f6-207d-489b-8f36-26446205c19a@github.com>
Message-ID: <li_U2hxY6uRa_agd_rFddk7lkL5BnvgdC7mgflLHUsM=.0893ec24-b61c-44bb-8011-1e2e742d1799@github.com>

On Fri, 9 Oct 2020 20:26:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Polishing the specification of "value-based class" to align with requirements of inline classes, allow classes (like Integer) with deprecated constructors, and clarify expectations for clients.
> 
> Update cross-references from existing value-based classes and the primitive wrapper classes.
> 
> Full docs build: http://cr.openjdk.java.net/~dlsmith/8254275/8254275-20201124/api/index.html

This pull request has now been integrated.

Changeset: cdaf144f
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/cdaf144f
Stats:     258 lines in 48 files changed: 59 ins; 20 del; 179 mod

8254275: [valhalla/jep390] Revise "value-based class" & apply to wrappers

Reviewed-by: mchung, rriggs

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

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


From sergey.kuksenko at oracle.com  Wed Nov 25 03:04:24 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Tue, 24 Nov 2020 19:04:24 -0800
Subject: UseACmpProfile question.
In-Reply-To: <87tutekjcd.fsf@redhat.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
 <87tutekjcd.fsf@redhat.com>
Message-ID: <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>

Thank you. It's better, but not end.

How to turn off null values profiling?

I run with? -XX:-UseACmpProfile -XX:-UseCompressedOops 
-XX:-UseTypeSpeculation

Here the code where there are no null values in acmp:

 ?19.43%?? ? ???? 0x00007fc1b8127fd1:?? cmp??? %rcx,%rbx
 ????????? ?????? 0x00007fc1b8127fd4:?? je 0x00007fc1b812801d
 ? 2.66%?? ?????? 0x00007fc1b8127fd6:?? mov??? $0x5,%r11d
 ?13.61%?? ?????? 0x00007fc1b8127fdc:?? and (%rcx),%r11????????????????? 
; implicit exception: dispatches to 0x00007fc1b812808c
 ? 3.56%?? ?????? 0x00007fc1b8127fdf:?? cmp??? $0x5,%r11
 ????????? ?????? 0x00007fc1b8127fe3:?? jne 0x00007fc1b8127fc0
 ????????? ?? ??? 0x00007fc1b8127fe5:?? mov 0x8(%rbx),%r8d?????????????? 
; implicit exception: dispatches to 0x00007fc1b81280ac
 ????????? ?? ??? 0x00007fc1b8127fe9:?? mov 0x8(%rcx),%r11d
 ????????? ?? ??? 0x00007fc1b8127fed:?? cmp??? %r11d,%r8d
 ????????? ?? ??? 0x00007fc1b8127ff0:?? jne 0x00007fc1b8127fc0?????????? 
;*if_acmpne {reexecute=0 rethrow=0 return_oop=0 return_vt=0}
 ????????? ?? 
???????????????????????????????????????????????????????????? ; - 
org.openjdk.bench.valhalla.sandbox.acmp.array.CompIdentityStates::comp0 at 33 
(line 33)

There are no explicit null checks here.

The same code when there are null values:

10.70%?? ? ?????? 0x00007f5998127ad1:?? cmp??? %rbx,%r11
 ????????? ???????? 0x00007f5998127ad4:?? je 0x00007f5998127b25
 ? 6.50%?? ???????? 0x00007f5998127ad6:?? test?? %rbx,%rbx
 ????????? ???????? 0x00007f5998127ad9:?? je 0x00007f5998127ac0
 ? 6.74%?? ?? ????? 0x00007f5998127adb:?? mov $0x5,%r10d
 ? 6.16%?? ?? ????? 0x00007f5998127ae1:?? and (%rbx),%r10
 ?16.20%?? ?? ????? 0x00007f5998127ae4:?? cmp??? $0x5,%r10
 ????????? ?? ????? 0x00007f5998127ae8:?? jne 0x00007f5998127ac0
 ????????? ??? ???? 0x00007f5998127aea:?? test?? %r11,%r11
 ????????? ??? ???? 0x00007f5998127aed:?? je 0x00007f5998127ac0
 ????????? ???? ??? 0x00007f5998127aef:?? mov 0x8(%r11),%r10d
 ????????? ???? ??? 0x00007f5998127af3:?? mov 0x8(%rbx),%r8d
 ????????? ???? ??? 0x00007f5998127af7:?? cmp %r8d,%r10d
 ????????? ???? ??? 0x00007f5998127afa:?? jne 
0x00007f5998127ac0?????????? ;*if_acmpne {reexecute=0 rethrow=0 
return_oop=0 return_vt=0}
 ????????? ?? 
???????????????????????????????????????????????????????????? ; - 
org.openjdk.bench.valhalla.sandbox.acmp.array.CompIdentityStates::comp0 at 33 
(line 33)

Explicit null checks are here.

I just want to compare performance of code generated with type and null 
profiles vs generic without any profile.

On 11/24/20 4:52 AM, Roland Westrelin wrote:
> Hi Sergey,
>
>> How to disable type checks for "amp" completely?
> Can you try -XX:-UseTypeSpeculation?
>
> Roland.
>


From sadayapalam at openjdk.java.net  Wed Nov 25 06:52:26 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 25 Nov 2020 06:52:26 GMT
Subject: Integrated: 8257028: [type-restrictions] Assorted issues with
 generation of RestrictedField attributes from annotations
Message-ID: <MTUUzMe9VPr9_5TrQ2vaDCTUWKa11xvqVG3Hc5af3Bs=.ea6bfb6f-cec3-48f0-a0f8-f6d006156600@github.com>

- Fix trouble with type annotating reference projection type
    - Change retention of experimental annotation to SOURCE
    - Fix javac crash with separate compilation
    - Improve robusness of tests

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

Commit messages:
 - 8257028: [type-restrictions] Assorted issues with generation of RestrictedField attributes from annotations

Changes: https://git.openjdk.java.net/valhalla/pull/278/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=278&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257028
  Stats: 171 lines in 6 files changed: 119 ins; 21 del; 31 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/278.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/278/head:pull/278

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


From sadayapalam at openjdk.java.net  Wed Nov 25 06:52:30 2020
From: sadayapalam at openjdk.java.net (Srikanth Adayapalam)
Date: Wed, 25 Nov 2020 06:52:30 GMT
Subject: Integrated: 8257028: [type-restrictions] Assorted issues with
 generation of RestrictedField attributes from annotations
In-Reply-To: <MTUUzMe9VPr9_5TrQ2vaDCTUWKa11xvqVG3Hc5af3Bs=.ea6bfb6f-cec3-48f0-a0f8-f6d006156600@github.com>
References: <MTUUzMe9VPr9_5TrQ2vaDCTUWKa11xvqVG3Hc5af3Bs=.ea6bfb6f-cec3-48f0-a0f8-f6d006156600@github.com>
Message-ID: <Iqldo9IRZIMhi-m9QQIRvAA6Dys7mUGA0kVd2xALmFw=.73638f39-127c-4cdc-9b77-e0426b9b8f28@github.com>

On Wed, 25 Nov 2020 06:46:29 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

> - Fix trouble with type annotating reference projection type
>     - Change retention of experimental annotation to SOURCE
>     - Fix javac crash with separate compilation
>     - Improve robusness of tests

This pull request has now been integrated.

Changeset: 4902cf9c
Author:    Srikanth Adayapalam <sadayapalam at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/4902cf9c
Stats:     171 lines in 6 files changed: 119 ins; 21 del; 31 mod

8257028: [type-restrictions] Assorted issues with generation of RestrictedField attributes from annotations

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

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


From dsimms at openjdk.java.net  Wed Nov 25 12:03:09 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 25 Nov 2020 12:03:09 GMT
Subject: [lworld] RFR: 8231500: [lworld] Merge the experimental bytecode API
Message-ID: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>

* Moved to a single bytecode testing API
* Cleaned out vbytecodes
* Cleanup of tests not actually using the API
* Removed TestNativeClone's API usage since cooking the method handle could no
longer bypass the verifier's bad access check

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

Commit messages:
 - Added defaultvalue & withfield to test API and realigned Valhalla test to the test API
 - Remove TYPED bytecode
 - Remove vbytecodes
 - Bytecode API in one place

Changes: https://git.openjdk.java.net/valhalla/pull/279/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=279&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8231500
  Stats: 9334 lines in 65 files changed: 280 ins; 8939 del; 115 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/279.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/279/head:pull/279

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


From thartmann at openjdk.java.net  Thu Nov 26 11:22:19 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 26 Nov 2020 11:22:19 GMT
Subject: [lworld] RFR: 8257154: [lworld] AndLNode::Identity optimization does
 not handle top input
Message-ID: <PJiX02oXepIn4A3iYkrEH_JpaVqWE5qqIuOxrGzY1K0=.40783fbd-890a-4fb1-b3f1-885cffb3ce17@github.com>

The memory input of the load can be top if the subgraph is dead but has not been removed. The fix is to simply reorder the checks to bail out if the input is not a pointer.

Thanks,
Tobias

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

Commit messages:
 - 8257154: [lworld] AndLNode::Identity optimization does not handle top input

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

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


From thartmann at openjdk.java.net  Thu Nov 26 12:09:13 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 26 Nov 2020 12:09:13 GMT
Subject: [lworld] RFR: 8251966: [lworld] TestArrays.java fails with
 -XX:+ExpandSubTypeCheckAtParseTime
Message-ID: <up2w0EhwpNU7Hd2jG9CqLOfBQl5B9w_TDgcH0luYhGM=.4f1ea4ef-b362-4b1d-8c33-f3cd143b286a@github.com>

[JDK-8251442](https://bugs.openjdk.java.net/browse/JDK-8251442) added SubTypeCheckNode optimizations that make sure that the control path consistently dies with the data path. These need to be implemented in `CmpPNode::sub` as well which requires `TypeKlassPtr` to keep track of not null-free/flat properties for array klasses.

Thanks,
Tobias

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

Commit messages:
 - 8251966: [lworld] TestArrays.java fails with -XX:+ExpandSubTypeCheckAtParseTime

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

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


From thartmann at openjdk.java.net  Thu Nov 26 12:43:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 26 Nov 2020 12:43:07 GMT
Subject: [lworld] Integrated: 8257154: [lworld] AndLNode::Identity
 optimization does not handle top input
In-Reply-To: <PJiX02oXepIn4A3iYkrEH_JpaVqWE5qqIuOxrGzY1K0=.40783fbd-890a-4fb1-b3f1-885cffb3ce17@github.com>
References: <PJiX02oXepIn4A3iYkrEH_JpaVqWE5qqIuOxrGzY1K0=.40783fbd-890a-4fb1-b3f1-885cffb3ce17@github.com>
Message-ID: <KdD16pHTB_j00olbQ-di2GP48Os_-zk6JchNCL8WUKg=.d80e14c7-0348-4bfd-b637-9a4278f50fa3@github.com>

On Thu, 26 Nov 2020 11:17:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The memory input of the load can be top if the subgraph is dead but has not been removed. The fix is to simply reorder the checks to bail out if the input is not a pointer.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8257154: [lworld] AndLNode::Identity optimization does not handle top input

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

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


From thartmann at openjdk.java.net  Thu Nov 26 13:05:12 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 26 Nov 2020 13:05:12 GMT
Subject: [lworld] Integrated: 8251966: [lworld] TestArrays.java fails with
 -XX:+ExpandSubTypeCheckAtParseTime
In-Reply-To: <up2w0EhwpNU7Hd2jG9CqLOfBQl5B9w_TDgcH0luYhGM=.4f1ea4ef-b362-4b1d-8c33-f3cd143b286a@github.com>
References: <up2w0EhwpNU7Hd2jG9CqLOfBQl5B9w_TDgcH0luYhGM=.4f1ea4ef-b362-4b1d-8c33-f3cd143b286a@github.com>
Message-ID: <7xslSxETVx2zVVzsvvtJCiZaXiBXitZAC-qiC8-G-x4=.0fa40a20-e405-4f1f-ae93-195e88f28d4b@github.com>

On Thu, 26 Nov 2020 12:05:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8251442](https://bugs.openjdk.java.net/browse/JDK-8251442) added SubTypeCheckNode optimizations that make sure that the control path consistently dies with the data path. These need to be implemented in `CmpPNode::sub` as well which requires `TypeKlassPtr` to keep track of not null-free/flat properties for array klasses.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: c2b5f11c
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c2b5f11c
Stats:     71 lines in 6 files changed: 30 ins; 3 del; 38 mod

8251966: [lworld] TestArrays.java fails with -XX:+ExpandSubTypeCheckAtParseTime

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

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


From rwestrel at redhat.com  Thu Nov 26 13:13:48 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 26 Nov 2020 14:13:48 +0100
Subject: UseACmpProfile question.
In-Reply-To: <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
 <87tutekjcd.fsf@redhat.com>
 <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>
Message-ID: <87im9sjm5v.fsf@redhat.com>


> Thank you. It's better, but not end.
>
> How to turn off null values profiling?

There's no command line option for that. C2 guesses that there are no
null values and if that triggers a deoptimization then on recompilation
it doesn't try to guess anymore. You would have to edit the code:

https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/parse2.cpp#L2058

and pass false instead.

Roland.



From thartmann at openjdk.java.net  Fri Nov 27 08:09:11 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 27 Nov 2020 08:09:11 GMT
Subject: [lworld] RFR: 8257166: [lworld] CCP fails to optimize
 FlatArrayCheckNode
Message-ID: <lPHO9TueDXTzMrBx4ELG2UmwicPEunJO7OKSfB9GgGw=.51d1a3d3-1c56-4028-9a32-a6221f2b41ff@github.com>

We hit `assert(!t->is_flat() && !t->is_not_flat()) failed: Should have been optimized out` during macro expansion of a FlatArrayCheckNode because the input array is known to be not flat but the check hasn't been optimized out by IGVN. The problem is that when CCP processes the node via `FlatArrayCheckNode::Value` the type immediately goes from TOP to BOTTOM because the input array hasn't been processed yet (still has type TOP). Afterwards, the node is not processed anymore although the type could be improved once the input array has been processed and is now known to be not flat.

We should add verification code that catches such cases. I've filed [JDK-8257197](https://bugs.openjdk.java.net/browse/JDK-8257197) to do this in mainline. A quick prototype suggests that we have multiple similar issues in mainline code.

Thanks,
Tobias

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

Commit messages:
 - 8257166: [lworld] CCP fails to optimize FlatArrayCheckNode

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

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


From thartmann at openjdk.java.net  Fri Nov 27 09:29:06 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 27 Nov 2020 09:29:06 GMT
Subject: [lworld] Integrated: 8257166: [lworld] CCP fails to optimize
 FlatArrayCheckNode
In-Reply-To: <lPHO9TueDXTzMrBx4ELG2UmwicPEunJO7OKSfB9GgGw=.51d1a3d3-1c56-4028-9a32-a6221f2b41ff@github.com>
References: <lPHO9TueDXTzMrBx4ELG2UmwicPEunJO7OKSfB9GgGw=.51d1a3d3-1c56-4028-9a32-a6221f2b41ff@github.com>
Message-ID: <LErsNYAMQO7VBfA9Fx-0Q9-K7l8K6R5moWbHdU10I88=.d0129a4b-d8aa-4a0b-8f79-be173f9ea7fa@github.com>

On Fri, 27 Nov 2020 08:05:12 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit `assert(!t->is_flat() && !t->is_not_flat()) failed: Should have been optimized out` during macro expansion of a FlatArrayCheckNode because the input array is known to be not flat but the check hasn't been optimized out by IGVN. The problem is that when CCP processes the node via `FlatArrayCheckNode::Value` the type immediately goes from TOP to BOTTOM because the input array hasn't been processed yet (still has type TOP). Afterwards, the node is not processed anymore although the type could be improved once the input array has been processed and is now known to be not flat.
> 
> We should add verification code that catches such cases. I've filed [JDK-8257197](https://bugs.openjdk.java.net/browse/JDK-8257197) to do this in mainline. A quick prototype suggests that we have multiple similar issues in mainline code.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8257166: [lworld] CCP fails to optimize FlatArrayCheckNode

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

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


From scolebourne at joda.org  Mon Nov 30 00:13:00 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 30 Nov 2020 00:13:00 +0000
Subject: Typed variants of primitives
Message-ID: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>

I wanted to raise a concept that I don't remember seeing as part of
the valhalla work so far, and I'll do so via a java.time.* example.


`java.time.*` contains a `Year` value-based class that effectively
acts as a "typed int" with two key purposes:
- to provide additional type safety if desired for the concept of "year"
- to restrict the valid int values to -999_999_999 to 999_999_999.

`LocalDate` has a method `getYear()`, but it returns an `int`, rather
than the `Year` class. Was this a mistake? Not really, it was a
pragmatic decision to say that most users of the API would want the
int, not the `Year` value type (and the performance hit of an
additional object).

In an ideal valhalla world, `LocalDate.getYear()` would be changed to
return `Year`, not `int`, and this change would be entirely backwards
compatible. The implication is that a valhalla `Year` value type could
be freely unboxed to an `int`.


Now of course, it is almost certainly pie-in-the-sky to try and make
something this backwards compatible. But what about new types? In API
design terms, there is appeal in defining a type that restricts the
valid set of ints, for example a `PositiveInt` value type. But without
the associated boxing/unboxing to `int` and maths operator-overloading
it is generally more pain than it is worth to design an API that way.
Has this concept been considered?

Stephen


From fparain at openjdk.java.net  Mon Nov 30 19:26:12 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 30 Nov 2020 19:26:12 GMT
Subject: [lworld] RFR: 8257446: [lworld] VM flag PrintInlineLayout doesn't
 work anymore
Message-ID: <1v5Mf-LqZxQVruZoPghfhHnl5Ut7uyzCyzFN7bzQk8Q=.a65436f4-3a4d-440d-bdba-b3b21b340baf@github.com>

Trivial fix to restore the PrintInlineLayout feature.

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

Commit messages:
 - Fix PrintInlineLayout VM flag

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

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


From hseigel at openjdk.java.net  Mon Nov 30 19:40:11 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 30 Nov 2020 19:40:11 GMT
Subject: [lworld] RFR: 8257446: [lworld] VM flag PrintInlineLayout doesn't
 work anymore
In-Reply-To: <1v5Mf-LqZxQVruZoPghfhHnl5Ut7uyzCyzFN7bzQk8Q=.a65436f4-3a4d-440d-bdba-b3b21b340baf@github.com>
References: <1v5Mf-LqZxQVruZoPghfhHnl5Ut7uyzCyzFN7bzQk8Q=.a65436f4-3a4d-440d-bdba-b3b21b340baf@github.com>
Message-ID: <-MTUtGXjpr_plHzZax3RbwYUZ476-1G5gt1OBCkWkPk=.e1caaa62-e34b-4844-b3ee-73ff92b3981c@github.com>

On Mon, 30 Nov 2020 19:22:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Trivial fix to restore the PrintInlineLayout feature.

The changes look good and trivial.

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

Marked as reviewed by hseigel (Committer).

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


From fparain at openjdk.java.net  Mon Nov 30 20:01:07 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Mon, 30 Nov 2020 20:01:07 GMT
Subject: [lworld] Integrated: 8257446: [lworld] VM flag PrintInlineLayout
 doesn't work anymore
In-Reply-To: <1v5Mf-LqZxQVruZoPghfhHnl5Ut7uyzCyzFN7bzQk8Q=.a65436f4-3a4d-440d-bdba-b3b21b340baf@github.com>
References: <1v5Mf-LqZxQVruZoPghfhHnl5Ut7uyzCyzFN7bzQk8Q=.a65436f4-3a4d-440d-bdba-b3b21b340baf@github.com>
Message-ID: <g5MFPYOD3gXFO-Wwsr-hBW1Y5NfucPQfVTJwHPu401Q=.1ce631f5-a480-4d3d-8650-6175ce78ee4b@github.com>

On Mon, 30 Nov 2020 19:22:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Trivial fix to restore the PrintInlineLayout feature.

This pull request has now been integrated.

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

8257446: [lworld] VM flag PrintInlineLayout doesn't work anymore

Reviewed-by: hseigel

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

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