From vromero at openjdk.org  Tue Jun  4 18:52:25 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 4 Jun 2024 18:52:25 GMT
Subject: [lworld] RFR: 8333563: [lworld] do not strip the @MigratedValueClass
 annotation when generating ct.sym
Message-ID: <tXokCAJke71LhQjAf17Hn9gerS9WEBgvBw9Gvx7m_Ow=.5048d290-14db-4754-ac62-e3ceb1fdd0a2@github.com>

do not strip @MigratedValueClass when generating ct.sym

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

Commit messages:
 - 8333563: [lworld] do not strip the @MigratedValueClass annotation when generating ct.sym

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

PR: https://git.openjdk.org/valhalla/pull/1113


From vromero at openjdk.org  Tue Jun  4 22:46:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 4 Jun 2024 22:46:33 GMT
Subject: [lworld] RFR: 8333563: [lworld] do not strip the
 @MigratedValueClass annotation when generating ct.sym [v2]
In-Reply-To: <tXokCAJke71LhQjAf17Hn9gerS9WEBgvBw9Gvx7m_Ow=.5048d290-14db-4754-ac62-e3ceb1fdd0a2@github.com>
References: <tXokCAJke71LhQjAf17Hn9gerS9WEBgvBw9Gvx7m_Ow=.5048d290-14db-4754-ac62-e3ceb1fdd0a2@github.com>
Message-ID: <zmSyxmAgjJfacLQi_6TDWuXSUDhLlcLt1iPN-AnNH44=.cca50a84-b741-47ba-a1ba-9888872abfba@github.com>

> do not strip @MigratedValueClass when generating ct.sym

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional change needed

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1113/files
  - new: https://git.openjdk.org/valhalla/pull/1113/files/3c75b986..02c48e47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1113&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1113&range=00-01

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

PR: https://git.openjdk.org/valhalla/pull/1113


From vromero at openjdk.org  Tue Jun  4 22:46:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 4 Jun 2024 22:46:34 GMT
Subject: [lworld] Integrated: 8333563: [lworld] do not strip the
 @MigratedValueClass annotation when generating ct.sym
In-Reply-To: <tXokCAJke71LhQjAf17Hn9gerS9WEBgvBw9Gvx7m_Ow=.5048d290-14db-4754-ac62-e3ceb1fdd0a2@github.com>
References: <tXokCAJke71LhQjAf17Hn9gerS9WEBgvBw9Gvx7m_Ow=.5048d290-14db-4754-ac62-e3ceb1fdd0a2@github.com>
Message-ID: <GYaPAAfdMutBezNdL3YhbR_Xo6XpUnCY3pubNXF9QtE=.f735f55b-c065-4330-a291-bf57205eb2d6@github.com>

On Tue, 4 Jun 2024 18:48:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> do not strip @MigratedValueClass when generating ct.sym

This pull request has now been integrated.

Changeset: ec59503c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ec59503cc04b0a4b15f21a8d8727c6c92924d052
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8333563: [lworld] do not strip the @MigratedValueClass annotation when generating ct.sym

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

PR: https://git.openjdk.org/valhalla/pull/1113


From vromero at openjdk.org  Thu Jun  6 11:34:18 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 6 Jun 2024 11:34:18 GMT
Subject: [lworld] Integrated: 8333712: [lworld] update and rename test
 IllegalMonitorStateExceptionTest.java to check for IdentityException
Message-ID: <7duqsFX41S-AfFNATtn4w_ek49HGFRcF296nebEGJdI=.27a279cb-1272-45ce-8bc7-6ece8ee8b239@github.com>

adapting test IllegalMonitorStateExceptionTest.java to latest spec changes, now the IdentityException will be thrown instead

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

Commit messages:
 - 8333712: [lworld] update and rename test IllegalMonitorStateExceptionTest.java to check for IdentityException

Changes: https://git.openjdk.org/valhalla/pull/1115/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1115&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333712
  Stats: 92 lines in 2 files changed: 46 ins; 46 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1115.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1115/head:pull/1115

PR: https://git.openjdk.org/valhalla/pull/1115


From vromero at openjdk.org  Thu Jun  6 11:34:19 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 6 Jun 2024 11:34:19 GMT
Subject: [lworld] Integrated: 8333712: [lworld] update and rename test
 IllegalMonitorStateExceptionTest.java to check for IdentityException
In-Reply-To: <7duqsFX41S-AfFNATtn4w_ek49HGFRcF296nebEGJdI=.27a279cb-1272-45ce-8bc7-6ece8ee8b239@github.com>
References: <7duqsFX41S-AfFNATtn4w_ek49HGFRcF296nebEGJdI=.27a279cb-1272-45ce-8bc7-6ece8ee8b239@github.com>
Message-ID: <C048rkmL2mUx5lVmoeJNDHmyWwefYhCQR0Jw8pw8q4I=.fb70f7f0-ef8b-4d02-b917-c3364875b6f8@github.com>

On Thu, 6 Jun 2024 11:29:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adapting test IllegalMonitorStateExceptionTest.java to latest spec changes, now the IdentityException will be thrown instead

This pull request has now been integrated.

Changeset: 49a048a2
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/49a048a2f6ac1430d66d84e611371db7686dc2bd
Stats:     92 lines in 2 files changed: 46 ins; 46 del; 0 mod

8333712: [lworld] update and rename test IllegalMonitorStateExceptionTest.java to check for IdentityException

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

PR: https://git.openjdk.org/valhalla/pull/1115


From chagedorn at openjdk.org  Thu Jun  6 11:57:25 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 6 Jun 2024 11:57:25 GMT
Subject: [lworld] RFR: 8331912: [lworld] C2: assert(!had_error) failed: bad
 dominance with TestFlatInArraysFolding.java
Message-ID: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>

In this bug, we have a broken graph due to data being folded while control is not. 

#### A Problem that's (almost) Fixed 

In this particular case, a `CheckCastPP` pinned to a sub type check becomes top due not non-matching (i.e impossible) flatness information but the sub type check fails to detect that and is not being folded. This was actually fixed with [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734) such that the `SubTypeCheckNode` is properly folded as well.

#### Still a Problem with `ExpandSubTypeCheckAtParseTime`
This bug manifests when running the following test case of JDK-8321734 with `ExpandSubTypeCheckAtParseTime`:

https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java#L99-L104

We load an element from `oArrArr` which could be an inline type and thus be flat in array - but we do not know that. Therefore, we have a `Phi` that merges a flat-in-array version and a normal version.

#### How Does `ExpandSubTypeCheckAtParseTime` Work
Setting `ExpandSubTypeCheckAtParseTime` will eagerly expand any sub type check at parse time. This means that we do not emit any `SubTypeCheckNode` but instead directly expand it. We only check once if the sub type check could be statically determined to be true or false and thus be removed:

https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/src/hotspot/share/opto/graphKit.cpp#L2858-L2879

If that's not the case - as in `testSubTypeCheck()` - we emit all the expanded nodes like checking the secondary super cache etc.

#### The Actual Problem With Eager Sub Type Check Expansion

Later, when unswitching the loop, we have one version of the loop where the `CheckCastPP` for `oArrArr[i]` is flat-in-array which goes into `373 CheckCastPP` with an array type:

![image](https://github.com/openjdk/valhalla/assets/17833009/23109401-8f4c-46b4-a13a-c9cbc83954b6)

Arrays can never be flat in array, so the `373 CheckCastPP` is replaced by top. The corresponding `SubTypeCheckNode` would also detect this - but there is none since we already expanded it. This improved flat-in-array type information is not propagated to `365 CmpP` through the emitted sub type check nodes (e.g. secondary super cache checks etc.) after the expansion. As a result, we fail to fold the check.

#### Solution
There is no good solution to fix this but to just not run with `ExpandSubTypeCheckAtParseTime`. We've removed `ExpandSubTypeCheckAtParseTime` in mainline with [JDK-8332032](https://bugs.openjdk.org/browse/JDK-8332032) due to this reason and other maintenance cost considerations in general. I'm therefore now downstreaming this patch already to fix this. It needed some adaptations due to missing code in Valhalla and Valhalla specific occurrences.

Thanks,
Christian

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

Commit messages:
 - 8331912: [lworld] C2: assert(!had_error) failed: bad dominance with TestFlatInArraysFolding.java

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

PR: https://git.openjdk.org/valhalla/pull/1116


From thartmann at openjdk.org  Thu Jun  6 12:53:07 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 6 Jun 2024 12:53:07 GMT
Subject: [lworld] RFR: 8331912: [lworld] C2: assert(!had_error) failed: bad
 dominance with TestFlatInArraysFolding.java
In-Reply-To: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
References: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
Message-ID: <RArXg5_saDIO_7V7FXwsGXmxhMBsZeq2OsFxCdPBHH4=.9ea92fb5-5791-490a-acd3-e93e8bae65ee@github.com>

On Thu, 6 Jun 2024 11:51:24 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> In this bug, we have a broken graph due to data being folded while control is not. 
> 
> #### A Problem that's (almost) Fixed 
> 
> In this particular case, a `CheckCastPP` pinned to a sub type check becomes top due not non-matching (i.e impossible) flatness information but the sub type check fails to detect that and is not being folded. This was actually fixed with [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734) such that the `SubTypeCheckNode` is properly folded as well.
> 
> #### Still a Problem with `ExpandSubTypeCheckAtParseTime`
> This bug manifests when running the following test case of JDK-8321734 with `ExpandSubTypeCheckAtParseTime`:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java#L99-L104
> 
> We load an element from `oArrArr` which could be an inline type and thus be flat in array - but we do not know that. Therefore, we have a `Phi` that merges a flat-in-array version and a normal version.
> 
> #### How Does `ExpandSubTypeCheckAtParseTime` Work
> Setting `ExpandSubTypeCheckAtParseTime` will eagerly expand any sub type check at parse time. This means that we do not emit any `SubTypeCheckNode` but instead directly expand it. We only check once if the sub type check could be statically determined to be true or false and thus be removed:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/src/hotspot/share/opto/graphKit.cpp#L2858-L2879
> 
> If that's not the case - as in `testSubTypeCheck()` - we emit all the expanded nodes like checking the secondary super cache etc.
> 
> #### The Actual Problem With Eager Sub Type Check Expansion
> 
> Later, when unswitching the loop, we have one version of the loop where the `CheckCastPP` for `oArrArr[i]` is flat-in-array which goes into `373 CheckCastPP` with an array type:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/23109401-8f4c-46b4-a13a-c9cbc83954b6)
> 
> Arrays can never be flat in array, so the `373 CheckCastPP` is replaced by top. The corresponding `SubTypeCheckNode` would also detect this - but there is none since we already expanded it. This improved flat-in-array type information is not propagated to `365 CmpP` through the emitted sub type check nodes (e.g. secondary super cache checks etc.) after the expansion. As a result, we fail to fold the check.
> 
> #### Solution
> There is no good solution to fix this but to just not run with `ExpandSubTypeCheckAtParseTime`. We've rem...

Looks good otherwise. Thanks for fixing!

src/hotspot/share/opto/graphKit.cpp line 2862:

> 2860:     // being expanded here because we always perform the static sub type
> 2861:     // check in SubTypeCheckNode::sub() regardless of whether
> 2862:     //

Suggestion:

    // check in SubTypeCheckNode::sub() regardless of whether

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1116#pullrequestreview-2101846822
PR Review Comment: https://git.openjdk.org/valhalla/pull/1116#discussion_r1629473703


From chagedorn at openjdk.org  Thu Jun  6 13:49:41 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 6 Jun 2024 13:49:41 GMT
Subject: [lworld] RFR: 8331912: [lworld] C2: assert(!had_error) failed: bad
 dominance with TestFlatInArraysFolding.java [v2]
In-Reply-To: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
References: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
Message-ID: <UXwhzqy0-s2NiBJUcG_LiVyN_4KzAToGy7Br2fQhd9Y=.b6675cd6-4d9a-4b57-a04b-428cb54e9bef@github.com>

> In this bug, we have a broken graph due to data being folded while control is not. 
> 
> #### A Problem that's (almost) Fixed 
> 
> In this particular case, a `CheckCastPP` pinned to a sub type check becomes top due not non-matching (i.e impossible) flatness information but the sub type check fails to detect that and is not being folded. This was actually fixed with [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734) such that the `SubTypeCheckNode` is properly folded as well.
> 
> #### Still a Problem with `ExpandSubTypeCheckAtParseTime`
> This bug manifests when running the following test case of JDK-8321734 with `ExpandSubTypeCheckAtParseTime`:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java#L99-L104
> 
> We load an element from `oArrArr` which could be an inline type and thus be flat in array - but we do not know that. Therefore, we have a `Phi` that merges a flat-in-array version and a normal version.
> 
> #### How Does `ExpandSubTypeCheckAtParseTime` Work
> Setting `ExpandSubTypeCheckAtParseTime` will eagerly expand any sub type check at parse time. This means that we do not emit any `SubTypeCheckNode` but instead directly expand it. We only check once if the sub type check could be statically determined to be true or false and thus be removed:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/src/hotspot/share/opto/graphKit.cpp#L2858-L2879
> 
> If that's not the case - as in `testSubTypeCheck()` - we emit all the expanded nodes like checking the secondary super cache etc.
> 
> #### The Actual Problem With Eager Sub Type Check Expansion
> 
> Later, when unswitching the loop, we have one version of the loop where the `CheckCastPP` for `oArrArr[i]` is flat-in-array which goes into `373 CheckCastPP` with an array type:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/23109401-8f4c-46b4-a13a-c9cbc83954b6)
> 
> Arrays can never be flat in array, so the `373 CheckCastPP` is replaced by top. The corresponding `SubTypeCheckNode` would also detect this - but there is none since we already expanded it. This improved flat-in-array type information is not propagated to `365 CmpP` through the emitted sub type check nodes (e.g. secondary super cache checks etc.) after the expansion. As a result, we fail to fold the check.
> 
> #### Solution
> There is no good solution to fix this but to just not run with `ExpandSubTypeCheckAtParseTime`. We've rem...

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/graphKit.cpp
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1116/files
  - new: https://git.openjdk.org/valhalla/pull/1116/files/d31daad7..73369ade

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1116&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1116&range=00-01

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

PR: https://git.openjdk.org/valhalla/pull/1116


From chagedorn at openjdk.org  Thu Jun  6 13:49:41 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 6 Jun 2024 13:49:41 GMT
Subject: [lworld] RFR: 8331912: [lworld] C2: assert(!had_error) failed: bad
 dominance with TestFlatInArraysFolding.java
In-Reply-To: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
References: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
Message-ID: <XtaAPHvFL6Z7zNzG0Kj5PAVfJaEJhWUfxKTERcaYcUE=.edc04f19-4b2b-4150-a179-a3f313223124@github.com>

On Thu, 6 Jun 2024 11:51:24 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> In this bug, we have a broken graph due to data being folded while control is not. 
> 
> #### A Problem that's (almost) Fixed 
> 
> In this particular case, a `CheckCastPP` pinned to a sub type check becomes top due not non-matching (i.e impossible) flatness information but the sub type check fails to detect that and is not being folded. This was actually fixed with [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734) such that the `SubTypeCheckNode` is properly folded as well.
> 
> #### Still a Problem with `ExpandSubTypeCheckAtParseTime`
> This bug manifests when running the following test case of JDK-8321734 with `ExpandSubTypeCheckAtParseTime`:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java#L99-L104
> 
> We load an element from `oArrArr` which could be an inline type and thus be flat in array - but we do not know that. Therefore, we have a `Phi` that merges a flat-in-array version and a normal version.
> 
> #### How Does `ExpandSubTypeCheckAtParseTime` Work
> Setting `ExpandSubTypeCheckAtParseTime` will eagerly expand any sub type check at parse time. This means that we do not emit any `SubTypeCheckNode` but instead directly expand it. We only check once if the sub type check could be statically determined to be true or false and thus be removed:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/src/hotspot/share/opto/graphKit.cpp#L2858-L2879
> 
> If that's not the case - as in `testSubTypeCheck()` - we emit all the expanded nodes like checking the secondary super cache etc.
> 
> #### The Actual Problem With Eager Sub Type Check Expansion
> 
> Later, when unswitching the loop, we have one version of the loop where the `CheckCastPP` for `oArrArr[i]` is flat-in-array which goes into `373 CheckCastPP` with an array type:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/23109401-8f4c-46b4-a13a-c9cbc83954b6)
> 
> Arrays can never be flat in array, so the `373 CheckCastPP` is replaced by top. The corresponding `SubTypeCheckNode` would also detect this - but there is none since we already expanded it. This improved flat-in-array type information is not propagated to `365 CmpP` through the emitted sub type check nodes (e.g. secondary super cache checks etc.) after the expansion. As a result, we fail to fold the check.
> 
> #### Solution
> There is no good solution to fix this but to just not run with `ExpandSubTypeCheckAtParseTime`. We've rem...

Thanks Tobias for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1116#issuecomment-2152568030


From chagedorn at openjdk.org  Thu Jun  6 14:03:06 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 6 Jun 2024 14:03:06 GMT
Subject: [lworld] Integrated: 8331912: [lworld] C2: assert(!had_error) failed:
 bad dominance with TestFlatInArraysFolding.java
In-Reply-To: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
References: <mxUz0EojqJCAfoSaIzB6_xa5OuK7dq78Jd7wIRJZLyI=.9385002d-1111-47c2-85df-3791d57d5dd6@github.com>
Message-ID: <vGGbU28Ok3wMS1r0TAT8EEFlvde2kKC4bKAUoXuRjrY=.a063f84b-e6d4-4d76-9cce-b2da6bcd799a@github.com>

On Thu, 6 Jun 2024 11:51:24 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> In this bug, we have a broken graph due to data being folded while control is not. 
> 
> #### A Problem that's (almost) Fixed 
> 
> In this particular case, a `CheckCastPP` pinned to a sub type check becomes top due not non-matching (i.e impossible) flatness information but the sub type check fails to detect that and is not being folded. This was actually fixed with [JDK-8321734](https://bugs.openjdk.org/browse/JDK-8321734) such that the `SubTypeCheckNode` is properly folded as well.
> 
> #### Still a Problem with `ExpandSubTypeCheckAtParseTime`
> This bug manifests when running the following test case of JDK-8321734 with `ExpandSubTypeCheckAtParseTime`:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatInArraysFolding.java#L99-L104
> 
> We load an element from `oArrArr` which could be an inline type and thus be flat in array - but we do not know that. Therefore, we have a `Phi` that merges a flat-in-array version and a normal version.
> 
> #### How Does `ExpandSubTypeCheckAtParseTime` Work
> Setting `ExpandSubTypeCheckAtParseTime` will eagerly expand any sub type check at parse time. This means that we do not emit any `SubTypeCheckNode` but instead directly expand it. We only check once if the sub type check could be statically determined to be true or false and thus be removed:
> 
> https://github.com/openjdk/valhalla/blob/ec59503cc04b0a4b15f21a8d8727c6c92924d052/src/hotspot/share/opto/graphKit.cpp#L2858-L2879
> 
> If that's not the case - as in `testSubTypeCheck()` - we emit all the expanded nodes like checking the secondary super cache etc.
> 
> #### The Actual Problem With Eager Sub Type Check Expansion
> 
> Later, when unswitching the loop, we have one version of the loop where the `CheckCastPP` for `oArrArr[i]` is flat-in-array which goes into `373 CheckCastPP` with an array type:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/23109401-8f4c-46b4-a13a-c9cbc83954b6)
> 
> Arrays can never be flat in array, so the `373 CheckCastPP` is replaced by top. The corresponding `SubTypeCheckNode` would also detect this - but there is none since we already expanded it. This improved flat-in-array type information is not propagated to `365 CmpP` through the emitted sub type check nodes (e.g. secondary super cache checks etc.) after the expansion. As a result, we fail to fold the check.
> 
> #### Solution
> There is no good solution to fix this but to just not run with `ExpandSubTypeCheckAtParseTime`. We've rem...

This pull request has now been integrated.

Changeset: f5a7cc63
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f5a7cc63e8f421871f36bea5d79740a02c21edc6
Stats:     15 lines in 4 files changed: 6 ins; 6 del; 3 mod

8331912: [lworld] C2: assert(!had_error) failed: bad dominance with TestFlatInArraysFolding.java

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1116


From darcy at openjdk.org  Fri Jun  7 04:28:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 7 Jun 2024 04:28:46 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
Message-ID: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>

Sketch of a more full-featured API for Float16.

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

Commit messages:
 - JDK-8329817: Augment prototype Float16 class

Changes: https://git.openjdk.org/valhalla/pull/1117/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329817
  Stats: 512 lines in 1 file changed: 491 ins; 6 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Fri Jun  7 04:28:47 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 7 Jun 2024 04:28:47 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>

On Fri, 7 Jun 2024 04:17:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Sketch of a more full-featured API for Float16.

This PR has some known to-do items, including testing, but does provide a more full featured API set on par with Float or Double.

One to-do item is writing the double -> float16 conversion routine. Other items include adjusting the binary <-> decimal conversion routines to deal with the reduced precision of float16.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2153900769


From jbhateja at openjdk.org  Fri Jun  7 18:18:37 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 7 Jun 2024 18:18:37 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <_xTeeZMoMxi1eW5oAtJ9hkDLOz5wXhkZhm82_1b6kGM=.0d820c5e-866b-449e-a9f5-071b68c4cebe@github.com>

On Fri, 7 Jun 2024 04:17:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Sketch of a more full-featured API for Float16.

src/java.base/share/classes/java/lang/Float16.java line 60:

> 58: // Currently Float16 is a primitive class but in future will be aligned with
> 59: // Enhanced Primitive Boxes described by JEP-402 (https://openjdk.org/jeps/402)
> 60: public /*primitive*/ class Float16 extends Number

Shouldn't this be attributed with jdk.internal.ValueBased annotation like other primitive boxes to facilitate creation of an InlineKlass for it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1630945669


From darcy at openjdk.org  Fri Jun  7 18:30:23 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 7 Jun 2024 18:30:23 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
In-Reply-To: <_xTeeZMoMxi1eW5oAtJ9hkDLOz5wXhkZhm82_1b6kGM=.0d820c5e-866b-449e-a9f5-071b68c4cebe@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <_xTeeZMoMxi1eW5oAtJ9hkDLOz5wXhkZhm82_1b6kGM=.0d820c5e-866b-449e-a9f5-071b68c4cebe@github.com>
Message-ID: <DstM-WBVizhD1P5H7DzruaNaEyUH2hmbGgcV9BlNsqM=.3e82ea85-ce14-4da8-8413-87e4375666e4@github.com>

On Fri, 7 Jun 2024 09:38:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> src/java.base/share/classes/java/lang/Float16.java line 60:
> 
>> 58: // Currently Float16 is a primitive class but in future will be aligned with
>> 59: // Enhanced Primitive Boxes described by JEP-402 (https://openjdk.org/jeps/402)
>> 60: public /*primitive*/ class Float16 extends Number
> 
> Shouldn't this be attributed with jdk.internal.ValueBased annotation like other primitive boxes to facilitate creation of an InlineKlass for it.

I don't know the proper idiom for that use. (I commented out the "primitive" modifier so I could get the doc build to work for the class.)

Do you know what the plans are for syncing in changes from Valhalla mainline into lworld+fp16?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1631559537


From vromero at openjdk.org  Fri Jun  7 20:44:52 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 7 Jun 2024 20:44:52 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with the
 latest spec
Message-ID: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>

Renaming the Preload attribute plus changing its contents. Side-effects, changes to class file API, javap,etc

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

Commit messages:
 - changes to java.base and jdk.jdeps
 - 8333757: [lworld] sync javac code generation with the latest spec

Changes: https://git.openjdk.org/valhalla/pull/1118/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1118&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333757
  Stats: 354 lines in 22 files changed: 123 ins; 140 del; 91 mod
  Patch: https://git.openjdk.org/valhalla/pull/1118.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1118/head:pull/1118

PR: https://git.openjdk.org/valhalla/pull/1118


From vromero at openjdk.org  Fri Jun  7 21:44:03 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 7 Jun 2024 21:44:03 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with
 the latest spec [v2]
In-Reply-To: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
Message-ID: <wXt8oxn5AY4nLrB-6gXmAQyKU35xG0EzSwcDEvAqNMg=.155199cb-be6b-4cec-8113-5854b3f67f3c@github.com>

> Renaming the Preload attribute plus changing its contents. Side-effects, changes to class file API, javap,etc

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8333757' of https://github.com/vicente-romero-oracle/valhalla into JDK-8333757
 - changes to java.base and jdk.jdeps

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1118/files
  - new: https://git.openjdk.org/valhalla/pull/1118/files/0a5b998a..5b063a45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1118&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1118&range=00-01

  Stats: 706 lines in 9 files changed: 350 ins; 348 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1118.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1118/head:pull/1118

PR: https://git.openjdk.org/valhalla/pull/1118


From darcy at openjdk.org  Sat Jun  8 00:17:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 8 Jun 2024 00:17:31 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v2]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <lGLtu-IXG99WeJzv5BIkQSShSNyJG--ejTChGSjD5ac=.61ec9045-6f1e-4027-a4cc-f3f2d7c9f1c3@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Add @value tags to javadoc.
 - Adjust list of possible future work.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/c4dbf5b9..dc31ccfb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=00-01

  Stats: 16 lines in 1 file changed: 7 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From rotanolexandr842 at gmail.com  Sat Jun  8 20:16:58 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Sat, 8 Jun 2024 23:16:58 +0300
Subject: Can immutable value objects be pulled?
Message-ID: <CAL5bRt8fw=qrtMMyeQfX=8iNa=+w8s5rwUs9Q-QgV=rPNWqL8Q@mail.gmail.com>

Hi! I am writing to express some thoughts that have been crossing my mind
pretty often recently. So basically, what I am wondering is can value
objects be pooled, just like Strings are pooled now?

My thoughts originated from the question of pooling value records and
records in general Value objects seem like ideal candidates to be pooled:
they don't have identity, so there are no things like two different value
objects with the same state but not "completely" equal. Things like
optionals tend to often repeat values, as well as some things that records
are used for such as DTOs and other plain data carriers.

The thing that kind of doubts me is that usual records also are a good
candidate for pooling, but, AFAIK, they aren't for some reason, so I am
wondering maybe this idea has been considered previously but discarded for
some reason like inacceptable performance overhead associated with pooling
mechanism.

But still, widening mechanism that used for String pooling currently I`m
not familiar with exact implementation of String pooling and I suspect it
somehow tied to inlining string literals and that's why it doesn't work for
any other way to create string, so it seems like adapting it to any
constructor will require significant change in pooling mechanism, but it
seems like it potentially could save up ton of memory. I'm not sure about
the performance side of this though.

This letter is more of a question as I am not familiar with string pooling
internals at all, but it seems like a natural thing to me.So, has this been
considered?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240608/d47a726f/attachment.htm>

From chen.l.liang at oracle.com  Sun Jun  9 08:47:32 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 9 Jun 2024 08:47:32 +0000
Subject: Can immutable value objects be pulled?
In-Reply-To: <CAL5bRt8fw=qrtMMyeQfX=8iNa=+w8s5rwUs9Q-QgV=rPNWqL8Q@mail.gmail.com>
References: <CAL5bRt8fw=qrtMMyeQfX=8iNa=+w8s5rwUs9Q-QgV=rPNWqL8Q@mail.gmail.com>
Message-ID: <SJ2PR10MB766961A133B0B51CAE4BC15EA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Evemose,
Pooling of value object is already there; it is a VM implementation detail not visible to users, unlike the identity of String objects. In fact, according to JEP 401, JVM is also free to duplicate value objects for faster access (locality). If you declare your record value, it will be eligible for pooling like any value object.

For String pooling, I believe JVM currently uses a hash table, but it is somewhat less efficient if the table grows too large; String.intern, the public API for String pooling, is slower than putting String into your own HashMap to deduplicate. However, some String objects are known to be pooled, such as the literal constant strings in Java source code or class file string constants and method names. I have seen user string pooling in handling of configuration for remapping Java class files, where many descriptors and class names duplicate. (On a side note, annotation string values are not pooled, and this causes significant memory usage in some applications with duplicate string annotation values)

Another object that's pooled is MethodType, and its pooling is completed mandated by Java code. Its pooling via a ReferencedKeySet is more valuable than String pooling, as in addition to reducing allocations, MethodType also caches Invokers, which are relevant utilities for working with MethodHandles of the type.

Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Olexandr Rotan <rotanolexandr842 at gmail.com>
Sent: Saturday, June 8, 2024 3:16 PM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: Can immutable value objects be pulled?

Hi! I am writing to express some thoughts that have been crossing my mind pretty often recently. So basically, what I am wondering is can value objects be pooled, just like Strings are pooled now?

My thoughts originated from the question of pooling value records and records in general Value objects seem like ideal candidates to be pooled: they don't have identity, so there are no things like two different value objects with the same state but not "completely" equal. Things like optionals tend to often repeat values, as well as some things that records are used for such as DTOs and other plain data carriers.

The thing that kind of doubts me is that usual records also are a good candidate for pooling, but, AFAIK, they aren't for some reason, so I am wondering maybe this idea has been considered previously but discarded for some reason like inacceptable performance overhead associated with pooling mechanism.

But still, widening mechanism that used for String pooling currently I`m not familiar with exact implementation of String pooling and I suspect it somehow tied to inlining string literals and that's why it doesn't work for any other way to create string, so it seems like adapting it to any constructor will require significant change in pooling mechanism, but it seems like it potentially could save up ton of memory. I'm not sure about the performance side of this though.

This letter is more of a question as I am not familiar with string pooling internals at all, but it seems like a natural thing to me.So, has this been considered?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240609/71046d37/attachment.htm>

From chen.l.liang at oracle.com  Sun Jun  9 09:04:03 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 9 Jun 2024 09:04:03 +0000
Subject: Null restriction on interface typed fields
Message-ID: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hello valhalla community,
In our current iteration of valhalla, we only support null restriction on value fields, as for references, null is a valid default value. Meanwhile, interfaces are not restricted to be value or identity, yet some value classes will only be represented via interfaces, most notably Map.entry().

In addition, consider this scenario in the ClassFile API: we have ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>) and withMethodBody(xxx, Consumer<CodeBuilder>). A straightforward implementation of withMethodBody would be withMethod(xxx, new WithCode(cbConsumer)), where WithCode is (value) record WithCode(Consumer<CodeBuilder> build) implements Consumer<MethodBuilder>...
In this WithCode record, we can see that we are interested in declaring "build" null-restricted; if build is a value lambda that simply captures context variables, then WithCode can be inlined to the same captures should "build" be NR, without concerns about representing a null build value in the inlined form.

Another example is in Algebraic types:
sealed interface Operation permits O1, O2, ...
Record O1(Interface1 xxx)
Record O2(Interface2 xxx)
For value-based Interface1 and Interface2 values, we might seek to NR the fields so the record representations can be simpler.

Thus, I recommend considering support for NR on interface fields in addition to on explicit value type fields. Though this might lead down to the rabbit hole of "heap pollution of null on reference pointers", I still believe its benefit outweighs its cost, especially in cases where these values can be restricted on the stack in escape analysis, as in most functional APIs (function only invoked conditionally, function objects not stored when method exits).

Chen Liang

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240609/00f007ca/attachment.htm>

From chen.l.liang at oracle.com  Sun Jun  9 14:24:23 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sun, 9 Jun 2024 14:24:23 +0000
Subject: [External] : Re: Can immutable value objects be pulled?
In-Reply-To: <CAL5bRt8TLcH4iKJjo6KhWkvy5gFAs_5uPEEvotRF8L2ndKWDNA@mail.gmail.com>
References: <CAL5bRt8fw=qrtMMyeQfX=8iNa=+w8s5rwUs9Q-QgV=rPNWqL8Q@mail.gmail.com>
 <SJ2PR10MB766961A133B0B51CAE4BC15EA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CAL5bRt8TLcH4iKJjo6KhWkvy5gFAs_5uPEEvotRF8L2ndKWDNA@mail.gmail.com>
Message-ID: <SJ2PR10MB76694216AB255F00AF94B819A2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Olex,
In Valhalla, immutability will be easy: value is immutability. And the depth of immutability is easy, too: you have immutability until you reach a reference pointer in the tree. And yes, when Valhalla is out, the famous -128 to 127 Integer cache range will be gone; all Integer will == each other if their values pass ==.

String and MethodType "pooling" are reduction of instances, which is more of a feature on the Java code side and only matters for reference objects. Their storage devices, arrays, are not simple values, thus we seek to pool them. They are unlikely to be affected by Valhalla, and VM can't duplicate or eliminate them as it treats value objects.

> I feel like creating a new instance of sume numeric type, even if it is done by duplicating an existing one, is still a pretty significant overhead compared to just returning pointer to existing one, given that object is immutable, and, therefore, can have as many immutable refs as possible.

Your concerns are very valid, that reference pointers are much smaller than a majority of objects' full layout. In these cases, JVM has the full freedom to decide if a value object is small enough to be allocated directly (for small values like Float16, UnsignedInt, both are smaller than a 64-bit pointer), or if allocating a pointer to a heap value object (either existing or newly allocated) is better (for larger ones, maybe like 4*4 square matrix used in graphic transformations). These choices are often made according to platform attributes, so leaving them to the VM instead of the Java code (which should "build once, run everywhere") is the correct choice.

P.S. I believe your question is valuable; therefore, I have forwarded to valhalla-dev, so people with similar questions can find their answers.

Chen Liang
________________________________
From: Olexandr Rotan <rotanolexandr842 at gmail.com>
Sent: Sunday, June 9, 2024 6:22 AM
To: Chen Liang <chen.l.liang at oracle.com>
Subject: [External] : Re: Can immutable value objects be pulled?

Hi Chen!

Thanks for the answer. I am writing to you privately to not pollute valhalla list traffic. I have a few questions about the VM implementation of this pooling. As you said, VM is free to duplicate objects. What I am wondering is: there are types that are not shallowly immutable by declaration, but are immutable effectively. As I understand, boxed types and optional fall under this umbrella as they are not records, but still effectively immutable. Does VM just have a list of built-in types that are "effectively immutable" and knows that it can pool its instances instead of duplication, or It decides whether type is mutable or not based on some features (like all fields are final, type is final etc.)?

I feel like creating a new instance of sume numeric type, even if it is done by duplicating an existing one, is still a pretty significant overhead compared to just returning pointer to existing one, given that object is immutable, and, therefore, can have as many immutable refs as possible.

Thanks for your time,
Regards

On Sun, Jun 9, 2024 at 11:47?AM Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>> wrote:
Hi Evemose,
Pooling of value object is already there; it is a VM implementation detail not visible to users, unlike the identity of String objects. In fact, according to JEP 401, JVM is also free to duplicate value objects for faster access (locality). If you declare your record value, it will be eligible for pooling like any value object.

For String pooling, I believe JVM currently uses a hash table, but it is somewhat less efficient if the table grows too large; String.intern, the public API for String pooling, is slower than putting String into your own HashMap to deduplicate. However, some String objects are known to be pooled, such as the literal constant strings in Java source code or class file string constants and method names. I have seen user string pooling in handling of configuration for remapping Java class files, where many descriptors and class names duplicate. (On a side note, annotation string values are not pooled, and this causes significant memory usage in some applications with duplicate string annotation values)

Another object that's pooled is MethodType, and its pooling is completed mandated by Java code. Its pooling via a ReferencedKeySet is more valuable than String pooling, as in addition to reducing allocations, MethodType also caches Invokers, which are relevant utilities for working with MethodHandles of the type.

Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org<mailto:valhalla-dev-retn at openjdk.org>> on behalf of Olexandr Rotan <rotanolexandr842 at gmail.com<mailto:rotanolexandr842 at gmail.com>>
Sent: Saturday, June 8, 2024 3:16 PM
To: valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org> <valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org>>
Subject: Can immutable value objects be pulled?

Hi! I am writing to express some thoughts that have been crossing my mind pretty often recently. So basically, what I am wondering is can value objects be pooled, just like Strings are pooled now?

My thoughts originated from the question of pooling value records and records in general Value objects seem like ideal candidates to be pooled: they don't have identity, so there are no things like two different value objects with the same state but not "completely" equal. Things like optionals tend to often repeat values, as well as some things that records are used for such as DTOs and other plain data carriers.

The thing that kind of doubts me is that usual records also are a good candidate for pooling, but, AFAIK, they aren't for some reason, so I am wondering maybe this idea has been considered previously but discarded for some reason like inacceptable performance overhead associated with pooling mechanism.

But still, widening mechanism that used for String pooling currently I`m not familiar with exact implementation of String pooling and I suspect it somehow tied to inlining string literals and that's why it doesn't work for any other way to create string, so it seems like adapting it to any constructor will require significant change in pooling mechanism, but it seems like it potentially could save up ton of memory. I'm not sure about the performance side of this though.

This letter is more of a question as I am not familiar with string pooling internals at all, but it seems like a natural thing to me.So, has this been considered?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240609/ae9ba02c/attachment.htm>

From jbhateja at openjdk.org  Sun Jun  9 19:14:49 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 9 Jun 2024 19:14:49 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
Message-ID: <9sQDNWvC30_glZLBXypF45r5KNb2czjAvT8HuqUpzLg=.db35513f-f18e-4970-ab94-7aec8dac6d56@github.com>

Summary of changes:-

Merge latest lworld into lworld+fp16.
Make Float16 a ValueBased and ImplicitlyConstructible class. It encapsulates a 'short' field to hold an IEEE 754 binary16 encoded value.
Facilitate a flat array layout for array allocations whose elements type is an implicitly constructible value class.

Best Regards,
Jatin

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

Commit messages:
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_lworld_into_fp16
 - Merge lworld
 - [lworld+fp16] Merge lworld
 - 8308363: Initial compiler support for FP16 scalar operations.
 - Merge lworld

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

Changes: https://git.openjdk.org/valhalla/pull/1120/files
  Stats: 1592 lines in 42 files changed: 1553 ins; 3 del; 36 mod
  Patch: https://git.openjdk.org/valhalla/pull/1120.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1120/head:pull/1120

PR: https://git.openjdk.org/valhalla/pull/1120


From jbhateja at openjdk.org  Sun Jun  9 19:14:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 9 Jun 2024 19:14:54 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
In-Reply-To: <9sQDNWvC30_glZLBXypF45r5KNb2czjAvT8HuqUpzLg=.db35513f-f18e-4970-ab94-7aec8dac6d56@github.com>
References: <9sQDNWvC30_glZLBXypF45r5KNb2czjAvT8HuqUpzLg=.db35513f-f18e-4970-ab94-7aec8dac6d56@github.com>
Message-ID: <Fj6FuZZRC9b1-aooqpG4cDEcnbprb2IZZgeikw1ceOI=.5912ef49-3804-4eb2-809f-c5161d5a04ed@github.com>

On Sun, 9 Jun 2024 19:08:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary of changes:-
> 
> Merge latest lworld into lworld+fp16.
> Make Float16 a ValueBased and ImplicitlyConstructible class. It encapsulates a 'short' field to hold an IEEE 754 binary16 encoded value.
> Facilitate a flat array layout for array allocations whose elements type is an implicitly constructible value class.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 56d1a83f
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/56d1a83f0a3919f2ef2674173c2b8e0a91bcac00
Stats:     967535 lines in 8458 files changed: 262726 ins; 591911 del; 112898 mod

Merge lworld

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

PR: https://git.openjdk.org/valhalla/pull/1120


From jbhateja at openjdk.org  Sun Jun  9 19:20:28 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 9 Jun 2024 19:20:28 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v2]
In-Reply-To: <DstM-WBVizhD1P5H7DzruaNaEyUH2hmbGgcV9BlNsqM=.3e82ea85-ce14-4da8-8413-87e4375666e4@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <_xTeeZMoMxi1eW5oAtJ9hkDLOz5wXhkZhm82_1b6kGM=.0d820c5e-866b-449e-a9f5-071b68c4cebe@github.com>
 <DstM-WBVizhD1P5H7DzruaNaEyUH2hmbGgcV9BlNsqM=.3e82ea85-ce14-4da8-8413-87e4375666e4@github.com>
Message-ID: <Kw76rxZJZBKEZ1Yc03mhe-4qU5k9FbqTIw7JgVQTNJo=.6aa1741b-bf25-4737-b3a5-d1beeb317856@github.com>

On Fri, 7 Jun 2024 18:27:16 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Float16.java line 60:
>> 
>>> 58: // Currently Float16 is a primitive class but in future will be aligned with
>>> 59: // Enhanced Primitive Boxes described by JEP-402 (https://openjdk.org/jeps/402)
>>> 60: public /*primitive*/ class Float16 extends Number
>> 
>> Shouldn't this be attributed with jdk.internal.ValueBased annotation like other primitive boxes to facilitate creation of an InlineKlass for it.
>
> I don't know the proper idiom for that use. (I commented out the "primitive" modifier so I could get the doc build to work for the class.)
> 
> Do you know what the plans are for syncing in changes from Valhalla mainline into lworld+fp16?

Hi @jddarcy , I have just integrated a [merge pull request](https://github.com/openjdk/valhalla/pull/1120) to merge latest lworld code into lworld+fp16. With this I made Floar16 an implicitly constructible value based class in order to facilitate flat layout representation for Float16 arrays.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1632374099


From darcy at openjdk.org  Mon Jun 10 16:53:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jun 2024 16:53:00 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v3]
In-Reply-To: <Kw76rxZJZBKEZ1Yc03mhe-4qU5k9FbqTIw7JgVQTNJo=.6aa1741b-bf25-4737-b3a5-d1beeb317856@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <_xTeeZMoMxi1eW5oAtJ9hkDLOz5wXhkZhm82_1b6kGM=.0d820c5e-866b-449e-a9f5-071b68c4cebe@github.com>
 <DstM-WBVizhD1P5H7DzruaNaEyUH2hmbGgcV9BlNsqM=.3e82ea85-ce14-4da8-8413-87e4375666e4@github.com>
 <Kw76rxZJZBKEZ1Yc03mhe-4qU5k9FbqTIw7JgVQTNJo=.6aa1741b-bf25-4737-b3a5-d1beeb317856@github.com>
Message-ID: <zzHVYBaXG-tfjWIUR-rGvCbzshIl4dSZPLoHIJr2Z48=.87e6504e-cbcd-4b3e-9094-53414592a249@github.com>

On Sun, 9 Jun 2024 19:16:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I don't know the proper idiom for that use. (I commented out the "primitive" modifier so I could get the doc build to work for the class.)
>> 
>> Do you know what the plans are for syncing in changes from Valhalla mainline into lworld+fp16?
>
> Hi @jddarcy , I have just integrated a [merge pull request](https://github.com/openjdk/valhalla/pull/1120) to merge latest lworld code into lworld+fp16. With this I made Floar16 an implicitly constructible value based class in order to facilitate[ flat layout representation](https://github.com/openjdk/valhalla/blob/lworld%2Bfp16/src/hotspot/share/interpreter/interpreterRuntime.cpp#L383) for Float16 arrays. 
> 
> Please note that ImplicitlyConstructible annotation was enforced on generated source of Float16 value based class.

Thanks @jatin-bhateja . I merged in the changes and updated the Float16 tests to pass.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1633550870


From darcy at openjdk.org  Mon Jun 10 16:53:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 10 Jun 2024 16:53:00 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v3]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <q3E40gdK0UkHWL8dGvKnHxluaXJd6PFbScYxxSDFhOc=.c9cc434a-e91d-40b8-b760-e92a16306b9b@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Add methods to Float16, use them in Float.
 - Update tests about merge.
 - Merge remote-tracking branch 'refs/remotes/origin/lworld+fp16' into JDK-8329817
 - Add @value tags to javadoc.
 - Adjust list of possible future work.
 - JDK-8329817: Augment prototype Float16 class

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

Changes: https://git.openjdk.org/valhalla/pull/1117/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=02
  Stats: 628 lines in 4 files changed: 572 ins; 8 del; 48 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From vromero at openjdk.org  Mon Jun 10 23:31:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 10 Jun 2024 23:31:58 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with
 the latest spec [v3]
In-Reply-To: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
Message-ID: <C9h4k05LlQPygd1a0VlYjdCi4nHTw8vdKurPmqdcWGk=.b9250124-3509-4f2e-89a4-d0a16a287fe0@github.com>

> Renaming the Preload attribute plus changing its contents. Side-effects, changes to class file API, javap,etc

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  do not include arrays in the LoadableDescriptors attribute in InnerClassLambdaMetafactory, plus some refacts

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1118/files
  - new: https://git.openjdk.org/valhalla/pull/1118/files/5b063a45..329db7f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1118&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1118&range=01-02

  Stats: 37 lines in 8 files changed: 10 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1118.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1118/head:pull/1118

PR: https://git.openjdk.org/valhalla/pull/1118


From liach at openjdk.org  Tue Jun 11 00:16:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jun 2024 00:16:31 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with
 the latest spec [v3]
In-Reply-To: <C9h4k05LlQPygd1a0VlYjdCi4nHTw8vdKurPmqdcWGk=.b9250124-3509-4f2e-89a4-d0a16a287fe0@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
 <C9h4k05LlQPygd1a0VlYjdCi4nHTw8vdKurPmqdcWGk=.b9250124-3509-4f2e-89a4-d0a16a287fe0@github.com>
Message-ID: <N9PJgWl9-4waXhraVKoFTs42Dt9gRJLhXhnITW1EXlI=.320b0f74-a56b-44e7-a461-767a27bb296a@github.com>

On Mon, 10 Jun 2024 23:31:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Renaming the Preload attribute plus changing its contents. Side-effects, changes to class file API, javap,etc
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not include arrays in the LoadableDescriptors attribute in InnerClassLambdaMetafactory, plus some refacts

src/java.base/share/classes/java/lang/classfile/attribute/LoadableDescriptorsAttribute.java line 68:

> 66:      * @param loadableDescriptors the loadable descriptors
> 67:      */
> 68:     static LoadableDescriptorsAttribute of(Utf8Entry... loadableDescriptors) {

I recommend another set of factory:

static LoadableDescriptorsAttribute ofSymbols(ClassDesc... loadableDescriptors);
static LoadableDescriptorsAttribute ofSymbols(List<ClassDesc> loadableDescriptors);

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1118#discussion_r1633997242


From dsimms at openjdk.org  Tue Jun 11 12:50:26 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 11 Jun 2024 12:50:26 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <CY_Xjtun2jBlec6r4QAB4J7jGl9qQ-y5l292hy-0Oj8=.ba265b12-1099-4576-becd-4ccc480acd83@github.com>

Merge tag 'jdk-23+10' into lworld_merge_23_10
Added tag jdk-23+10 for changeset 8cb9b479

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

Commit messages:
 - Merge tag 'jdk-23+10' into lworld_merge_23_10
 - 8321282: RISC-V: SpinPause() not implemented
 - 8323994: gtest runner repeats test name for every single gtest assertion
 - 8325910: Rename jnihelper.h
 - 8325682: Rename nsk_strace.h
 - 8325574: Shenandoah: Simplify and enhance reporting of requested GCs
 - 8252136: Several methods in hotspot are missing "static"
 - 8316340: (bf) Missing {@inheritDoc} for exception in MappedByteBuffer::compact
 - 8325643: G1: Refactor G1FlushHumongousCandidateRemSets
 - 8325403: Add SystemGC JMH benchmarks
 - ... and 86 more: https://git.openjdk.org/valhalla/compare/0e7fca13...02458ac5

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

Changes: https://git.openjdk.org/valhalla/pull/1121/files
  Stats: 19868 lines in 621 files changed: 7477 ins; 8271 del; 4120 mod
  Patch: https://git.openjdk.org/valhalla/pull/1121.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1121/head:pull/1121

PR: https://git.openjdk.org/valhalla/pull/1121


From vromero at openjdk.org  Tue Jun 11 13:56:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 11 Jun 2024 13:56:28 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with
 the latest spec [v3]
In-Reply-To: <N9PJgWl9-4waXhraVKoFTs42Dt9gRJLhXhnITW1EXlI=.320b0f74-a56b-44e7-a461-767a27bb296a@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
 <C9h4k05LlQPygd1a0VlYjdCi4nHTw8vdKurPmqdcWGk=.b9250124-3509-4f2e-89a4-d0a16a287fe0@github.com>
 <N9PJgWl9-4waXhraVKoFTs42Dt9gRJLhXhnITW1EXlI=.320b0f74-a56b-44e7-a461-767a27bb296a@github.com>
Message-ID: <AaVhDIFPLz9bx96ImWCu21TSChC6-Q1pz82JhLr_bLM=.8df46d60-e737-45aa-a455-c89a102eb9c1@github.com>

On Tue, 11 Jun 2024 00:11:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not include arrays in the LoadableDescriptors attribute in InnerClassLambdaMetafactory, plus some refacts
>
> src/java.base/share/classes/java/lang/classfile/attribute/LoadableDescriptorsAttribute.java line 68:
> 
>> 66:      * @param loadableDescriptors the loadable descriptors
>> 67:      */
>> 68:     static LoadableDescriptorsAttribute of(Utf8Entry... loadableDescriptors) {
> 
> I recommend another set of factory:
> 
> static LoadableDescriptorsAttribute ofSymbols(ClassDesc... loadableDescriptors);
> static LoadableDescriptorsAttribute ofSymbols(List<ClassDesc> loadableDescriptors);

I don't see the benefit tbh

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1118#discussion_r1634935661


From jbhateja at openjdk.org  Tue Jun 11 13:56:30 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Jun 2024 13:56:30 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
In-Reply-To: <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>
Message-ID: <lJ7psWMsau0M6FarsGYahKkx7KJxZ_ixvZySXCK1Iz8=.be8423a7-ef9b-41cc-b79d-9098e89a9d60@github.com>

On Fri, 7 Jun 2024 04:22:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> This PR has some known to-do items, including testing, but the PR does provide a more full featured API set on par with Float or Double, although without all the float/double handling method in Math/StrictMath.
> 
> One to-do item is writing the double -> float16 conversion routine. Other items include adjusting the binary <-> decimal conversion process to deal with the reduced precision of float16.

Hi @jddarcy , 

There are few more tests which may need refinement 
jtreg:test/hotspot/jtreg/compiler/intrinsics/float16/TestFP16ScalarAdd.java
jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2160829238


From vromero at openjdk.org  Tue Jun 11 16:03:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 11 Jun 2024 16:03:41 GMT
Subject: [lworld] Integrated: 8333757: [lworld] sync javac code generation with
 the latest spec
In-Reply-To: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
Message-ID: <vV9zKuNagnqI8eDewHtYteC4QOfeCA2bPeAC4nRGmc0=.6d932429-c52c-4f3c-9916-d18159643c97@github.com>

On Fri, 7 Jun 2024 20:35:55 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Renaming the Preload attribute plus changing its contents. Side-effects, changes to class file API, javap,etc

This pull request has now been integrated.

Changeset: 9473fcdb
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9473fcdbfd358b68afd8a2f12c6f5f9bffd6d96e
Stats:     1072 lines in 29 files changed: 483 ins; 501 del; 88 mod

8333757: [lworld] sync javac code generation with the latest spec

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

PR: https://git.openjdk.org/valhalla/pull/1118


From liach at openjdk.org  Tue Jun 11 16:12:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Jun 2024 16:12:30 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with
 the latest spec [v3]
In-Reply-To: <AaVhDIFPLz9bx96ImWCu21TSChC6-Q1pz82JhLr_bLM=.8df46d60-e737-45aa-a455-c89a102eb9c1@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
 <C9h4k05LlQPygd1a0VlYjdCi4nHTw8vdKurPmqdcWGk=.b9250124-3509-4f2e-89a4-d0a16a287fe0@github.com>
 <N9PJgWl9-4waXhraVKoFTs42Dt9gRJLhXhnITW1EXlI=.320b0f74-a56b-44e7-a461-767a27bb296a@github.com>
 <AaVhDIFPLz9bx96ImWCu21TSChC6-Q1pz82JhLr_bLM=.8df46d60-e737-45aa-a455-c89a102eb9c1@github.com>
Message-ID: <qeSLcziJfhf39mvZ4LMW_gFig81__CNRuJ_1GCKWts0=.198ab19d-5ded-4f9b-af75-e3ed9a61fc52@github.com>

On Tue, 11 Jun 2024 13:53:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/attribute/LoadableDescriptorsAttribute.java line 68:
>> 
>>> 66:      * @param loadableDescriptors the loadable descriptors
>>> 67:      */
>>> 68:     static LoadableDescriptorsAttribute of(Utf8Entry... loadableDescriptors) {
>> 
>> I recommend another set of factory:
>> 
>> static LoadableDescriptorsAttribute ofSymbols(ClassDesc... loadableDescriptors);
>> static LoadableDescriptorsAttribute ofSymbols(List<ClassDesc> loadableDescriptors);
>
> I don't see the benefit tbh

Indeed, this is mostly useful for things like lambda gen once JDK moves such gen to CF API.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1118#discussion_r1635150510


From vromero at openjdk.org  Tue Jun 11 16:22:29 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 11 Jun 2024 16:22:29 GMT
Subject: [lworld] RFR: 8333757: [lworld] sync javac code generation with
 the latest spec [v3]
In-Reply-To: <qeSLcziJfhf39mvZ4LMW_gFig81__CNRuJ_1GCKWts0=.198ab19d-5ded-4f9b-af75-e3ed9a61fc52@github.com>
References: <KFJpNFDFLnmHSwnZ2r-G3D6FqdZF5yaI6xYmQAnUnkg=.6ad7a8be-7efb-4f06-ae5d-14b240377c2c@github.com>
 <C9h4k05LlQPygd1a0VlYjdCi4nHTw8vdKurPmqdcWGk=.b9250124-3509-4f2e-89a4-d0a16a287fe0@github.com>
 <N9PJgWl9-4waXhraVKoFTs42Dt9gRJLhXhnITW1EXlI=.320b0f74-a56b-44e7-a461-767a27bb296a@github.com>
 <AaVhDIFPLz9bx96ImWCu21TSChC6-Q1pz82JhLr_bLM=.8df46d60-e737-45aa-a455-c89a102eb9c1@github.com>
 <qeSLcziJfhf39mvZ4LMW_gFig81__CNRuJ_1GCKWts0=.198ab19d-5ded-4f9b-af75-e3ed9a61fc52@github.com>
Message-ID: <fw8FEI2e1vCXdVqWotzkCPDPxkaIOPBHCdh1RUIiWa4=.92574075-daac-4286-8ade-524f10907e81@github.com>

On Tue, 11 Jun 2024 16:09:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't see the benefit tbh
>
> Indeed, this is mostly useful for things like lambda gen once JDK moves such gen to CF API.

we can always add it if necessary in the future

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1118#discussion_r1635163405


From jbhateja at openjdk.org  Tue Jun 11 17:27:27 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 11 Jun 2024 17:27:27 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
In-Reply-To: <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>
Message-ID: <P3gXBJCb5RPa3nhw4J3DRU_6whvZTsBFLxuLwdDC75c=.f71fd0b2-d09a-4b69-99fb-5c49563d77c0@github.com>

On Fri, 7 Jun 2024 04:22:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> This PR has some known to-do items, including testing, but the PR does provide a more full featured API set on par with Float or Double, although without all the float/double handling method in Math/StrictMath.
> 
> One to-do item is writing the double -> float16 conversion routine. Other items include adjusting the binary <-> decimal conversion process to deal with the reduced precision of float16.

Hey @jddarcy,

Taking the liberty to append some notes on this PR for future extensions for flat layout representation. Your comments and suggestion will be highly appreciated.

Q. What will it take to support a flat layout for an array of Float16 values ?

A.  I will begin by mentioning some basic terminology related to nullity restrictions.

1) ImpliciltyConstructible :  An instance which is always assigned a default value and guarantees non-nullability by construction.
2) NullRestricted              :  A value field if null restricted will never be assigned a null value during its lifetime.  

Another question which I wanted to answer here is about representing a null value, a value object if not null restricted must be able to encode a null value in some form, for example, a value class with just one 32 bit integer field can only accommodate integral value range in 2s complement representation, in order to encode a null value it may need additional bit, thus a 32 bit integer with nullity may need more than 32 bits storage. Thus with a mix of null and non-null values flattening may not be much useful due to heterogeneity in element sizes. To simplify layout flattening we can always assume uniform element size by  always assuming null encoding, but then it may add complexities in auto-vectorizing these contiguously placed values.  

With above definitions in place,  it becomes easy for runtime to generate a flat memory layout for arrays of Float16 types if implicit constructability and non-nullability are always guaranteed.

Existing ValueBased classes under --enable-preview option ensures generating InlineKlass. 

Since we are making Float16 a value based class, hence we can extend the scope of value based classes to imply 1) and 2), but its a behavioral change and may impact semantics of existing value classes. For the time being we can decorate Float16 with 1) and 2) annotations along with some minor modifications in executions engines. to ensure flat layout.

Only doubt I have is w.r.t to application of NullRestricted annotation to an array, since its target type is a FIELD, thus it technically does not cover an array element.  

I have created a follow-up JBS for facilitating flat array layout for Float16 values.
https://bugs.openjdk.org/browse/JDK-8333852

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2161269886


From fparain at openjdk.org  Tue Jun 11 17:42:43 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Jun 2024 17:42:43 GMT
Subject: [lworld] RFR: 8334034: [lworld] The JVM must recognize the new format
 of the Preaload/LoadableDescriptors attribute
Message-ID: <bc2UQzQdp4Ea3gx_611kKu08c0JxeKASh45GKj1D1To=.57d49938-25fd-45aa-9b2b-eae414d254fa@github.com>

VM side changes following JDK-8333757.

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

Commit messages:
 - Fix typos and bugs
 - Support new format of Preload/LoadableDescriptors attribute

Changes: https://git.openjdk.org/valhalla/pull/1122/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334034
  Stats: 122 lines in 13 files changed: 22 ins; 1 del; 99 mod
  Patch: https://git.openjdk.org/valhalla/pull/1122.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1122/head:pull/1122

PR: https://git.openjdk.org/valhalla/pull/1122


From fparain at openjdk.org  Tue Jun 11 18:05:35 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Jun 2024 18:05:35 GMT
Subject: [lworld] Integrated: 8334034: [lworld] The JVM must recognize the new
 format of the Preaload/LoadableDescriptors attribute
In-Reply-To: <bc2UQzQdp4Ea3gx_611kKu08c0JxeKASh45GKj1D1To=.57d49938-25fd-45aa-9b2b-eae414d254fa@github.com>
References: <bc2UQzQdp4Ea3gx_611kKu08c0JxeKASh45GKj1D1To=.57d49938-25fd-45aa-9b2b-eae414d254fa@github.com>
Message-ID: <GTUWrWPT9k3U55m0QyUcaO7JNXCrhhomt53uU3OKK6k=.9a60201e-f491-41b9-b606-1ad7cca02933@github.com>

On Tue, 11 Jun 2024 17:34:49 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> VM side changes following JDK-8333757.

This pull request has now been integrated.

Changeset: 0a87e69c
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0a87e69cddf34dbe1adcec873e83216684c18c2e
Stats:     122 lines in 13 files changed: 22 ins; 1 del; 99 mod

8334034: [lworld] The JVM must recognize the new format of the Preaload/LoadableDescriptors attribute

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

PR: https://git.openjdk.org/valhalla/pull/1122


From fparain at openjdk.org  Tue Jun 11 18:07:25 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Jun 2024 18:07:25 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
Message-ID: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>

Improve detection of invalid class files and test coverage of invalid scenarios.

Tested with Mach5, tier 1 to 3.

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

Commit messages:
 - Remove obsolete tests
 - More tests of VM fixing missing ACC_IDENTITY
 - Fix Copyright years
 - Add test checking that VM fixes missing ACC_IDENTITY in old class files
 - Add field tests for abstract value classes
 - Detect missing exception and other fixes
 - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
 - Improve class validation and test coverage

Changes: https://git.openjdk.org/valhalla/pull/1114/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1114&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333675
  Stats: 4582 lines in 10 files changed: 1417 ins; 3143 del; 22 mod
  Patch: https://git.openjdk.org/valhalla/pull/1114.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1114/head:pull/1114

PR: https://git.openjdk.org/valhalla/pull/1114


From dholmes at openjdk.org  Tue Jun 11 18:07:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 11 Jun 2024 18:07:26 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
In-Reply-To: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
Message-ID: <JQx3CE8WqY7S-KQSKo44SSiPIAyWYSEu9einXgaxujg=.14b4d16f-73e9-4409-944f-ed5897c40cfa@github.com>

On Wed, 5 Jun 2024 20:15:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Improve detection of invalid class files and test coverage of invalid scenarios.
> 
> Tested with Mach5, tier 1 to 3.

test/hotspot/jtreg/runtime/valhalla/inlinetypes/classfileparser/ValueClassValidation.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved.

Remove one copyright year

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1114#discussion_r1628539509


From fparain at openjdk.org  Tue Jun 11 18:07:27 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Jun 2024 18:07:27 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
In-Reply-To: <JQx3CE8WqY7S-KQSKo44SSiPIAyWYSEu9einXgaxujg=.14b4d16f-73e9-4409-944f-ed5897c40cfa@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
 <JQx3CE8WqY7S-KQSKo44SSiPIAyWYSEu9einXgaxujg=.14b4d16f-73e9-4409-944f-ed5897c40cfa@github.com>
Message-ID: <jc7MKxTyBgOhQ9jCRlL3TsP-Kf0nQU57qICthKJHU2M=.376a6a54-75e3-4c9c-a744-36e65fbb9e64@github.com>

On Wed, 5 Jun 2024 22:55:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Improve detection of invalid class files and test coverage of invalid scenarios.
>> 
>> Tested with Mach5, tier 1 to 3.
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/classfileparser/ValueClassValidation.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2024, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Remove one copyright year

Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1114#discussion_r1629583739


From fparain at openjdk.org  Tue Jun 11 19:18:43 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Jun 2024 19:18:43 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
 [v2]
In-Reply-To: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
Message-ID: <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>

> Improve detection of invalid class files and test coverage of invalid scenarios.
> 
> Tested with Mach5, tier 1 to 3.

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

 - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
 - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
 - Remove obsolete tests
 - More tests of VM fixing missing ACC_IDENTITY
 - Fix Copyright years
 - Add test checking that VM fixes missing ACC_IDENTITY in old class files
 - Add field tests for abstract value classes
 - Detect missing exception and other fixes
 - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
 - Improve class validation and test coverage

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1114/files
  - new: https://git.openjdk.org/valhalla/pull/1114/files/bc102323..624c50b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1114&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1114&range=00-01

  Stats: 1313 lines in 49 files changed: 568 ins; 554 del; 191 mod
  Patch: https://git.openjdk.org/valhalla/pull/1114.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1114/head:pull/1114

PR: https://git.openjdk.org/valhalla/pull/1114


From darcy at openjdk.org  Tue Jun 11 19:19:42 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Jun 2024 19:19:42 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v4]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <-5KadwxKO3gJVRt1Mxoeq3k9HPFabVyFRqPDgqMMfQA=.60ed8b65-1906-454f-826d-461336edfc73@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add valueOf(double), ulp, misc refactorings.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/ce070db4..4b85455d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=02-03

  Stats: 174 lines in 1 file changed: 130 ins; 26 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Tue Jun 11 19:46:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Jun 2024 19:46:30 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update regression tests.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/4b85455d..6d27111f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=03-04

  Stats: 18 lines in 2 files changed: 3 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Tue Jun 11 19:46:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Jun 2024 19:46:31 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class
In-Reply-To: <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <RFsFZRTbYmjI-EbgWJaQd0VcGVciGo6TwWPF7IQAPNE=.9321650a-1864-4033-ad55-1f0a9e8e5e37@github.com>
Message-ID: <07OyABO_POfxKwqfYyCOY9Pz73lBvD82jwrVURiSxXk=.72fc1c44-f302-4f7e-90a2-f38d9e3bde27@github.com>

On Fri, 7 Jun 2024 04:22:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> This PR has some known to-do items, including testing, but the PR does provide a more full featured API set on par with Float or Double, although without all the float/double handling method in Math/StrictMath.
> 
> One to-do item is writing the double -> float16 conversion routine. Other items include adjusting the binary <-> decimal conversion process to deal with the reduced precision of float16.

> Hi @jddarcy ,
> 
> There are few more tests which may need refinement jtreg:test/hotspot/jtreg/compiler/intrinsics/float16/TestFP16ScalarAdd.java jtreg:test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java
> 
> Best Regards, Jatin

Okay; I updated both tests to reflect the changes in the Float16 API. While TestFloat16VectorSum.java run successfully, TestFP16ScalarAdd fails at runtime with a message equivalent to "preview not enabled." Given the source of the test, I'm not sure what preview isn't being enabled as needed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2161487279


From darcy at openjdk.org  Tue Jun 11 20:35:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 11 Jun 2024 20:35:40 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
Message-ID: <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>

On Tue, 11 Jun 2024 19:46:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update regression tests.

A few comments on the proposed revised API of Float16:

The Float16 class was generally brought up to static field and method level parity with java.lang.{Float, Double}. Additionally, a number of low-level floating-point handling methods from Math/StrictMath were added to, such as getExponent. These methods are usually an operation or recommended function from IEEE 754. Methods for arithmetic operators {+, -, *, /} and square root were also added. The value(short) method was changed from a bit-level conversion to a value-based one; bit-level conversion is provided by a new shortBitsToFloat16 method.

The current API favors static methods over instances one. Methods to extend the Number abstract class and implement Comparable are of necessity instance methods.

Some more work is needed on the decimal <-> binary conversion methods.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2161559278


From darcy at openjdk.org  Wed Jun 12 02:52:02 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 12 Jun 2024 02:52:02 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v6]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <RcKUiDrOMmxkS8DjabkQsKYSYVwy4nGuQq4TL-72mLE=.9d89f258-edc8-4070-b794-73c4bc241b7f@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Added 2p+2 comment, fma disclaimer, etc.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/6d27111f..bf09c544

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=05
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=04-05

  Stats: 123 lines in 1 file changed: 87 ins; 10 del; 26 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Wed Jun 12 04:43:29 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 12 Jun 2024 04:43:29 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
 <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
Message-ID: <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>

On Tue, 11 Jun 2024 20:32:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A few comments on the proposed revised API of Float16:
> 
> The Float16 class was generally brought up to static field and method level parity with java.lang.{Float, Double}. Additionally, a number of low-level floating-point handling methods from Math/StrictMath were added to, such as getExponent. These methods are usually an operation or recommended function from IEEE 754. Methods for arithmetic operators {+, -, *, /} and square root were also added. The value(short) method was changed from a bit-level conversion to a value-based one; bit-level conversion is provided by a new shortBitsToFloat16 method.
> 
> The current API favors static methods over instances one. Methods to extend the Number abstract class and implement Comparable are of necessity instance methods.
> 
> Some more work is needed on the decimal <-> binary conversion methods.

PS As a design note on the implementation, as many of the methods are expected to be intrinsified on common production platforms, I was looking to favor conciseness and code reuse, say by relying on float and double operations, rather than absolute performance for a native software-based implementation of Float16.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2162092683


From dsimms at openjdk.org  Wed Jun 12 08:51:45 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Jun 2024 08:51:45 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <CY_Xjtun2jBlec6r4QAB4J7jGl9qQ-y5l292hy-0Oj8=.ba265b12-1099-4576-becd-4ccc480acd83@github.com>
References: <CY_Xjtun2jBlec6r4QAB4J7jGl9qQ-y5l292hy-0Oj8=.ba265b12-1099-4576-becd-4ccc480acd83@github.com>
Message-ID: <e5UhmoE_-6IT-RdkHgicy7zvZj2t_RHbHSqCUUjwP3A=.4d159346-78b4-4aab-af9f-c08276ec426f@github.com>

On Tue, 11 Jun 2024 12:43:25 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-23+10' into lworld_merge_23_10
> Added tag jdk-23+10 for changeset 8cb9b479

This pull request has now been integrated.

Changeset: 349c6c22
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/349c6c22990e69aa46d9733407eecf9e370503f9
Stats:     19868 lines in 621 files changed: 7477 ins; 8271 del; 4120 mod

Merge jdk

Merge jdk-23+10

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

PR: https://git.openjdk.org/valhalla/pull/1121


From jbhateja at openjdk.org  Wed Jun 12 14:14:41 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 12 Jun 2024 14:14:41 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v6]
In-Reply-To: <RcKUiDrOMmxkS8DjabkQsKYSYVwy4nGuQq4TL-72mLE=.9d89f258-edc8-4070-b794-73c4bc241b7f@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <RcKUiDrOMmxkS8DjabkQsKYSYVwy4nGuQq4TL-72mLE=.9d89f258-edc8-4070-b794-73c4bc241b7f@github.com>
Message-ID: <1QyA28UsvgJM4w9miVXsdstulrTqcL0CBOH28LXU2fg=.740c1ae9-20d9-4d87-90c8-c74a43a94a21@github.com>

On Wed, 12 Jun 2024 02:52:02 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added 2p+2 comment, fma disclaimer, etc.

Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment. 

Kindly fix and integrate.

src/java.base/share/classes/java/lang/Float16.java line 63:

> 61:  * of equivalent cases by methods in {@code Float}, {@code Double},
> 62:  * {@code Math}, etc.
> 63:  *

May I kindly request you to please append your name to file @author list.

src/java.base/share/classes/java/lang/Float16.java line 616:

> 614:      * @see java.util.function.BinaryOperator
> 615:      * @see Math.max(float, float)
> 616:      * @see Math.max(double, double)

Suggestion:

     * @see Math#max(float, float)
     * @see Math#max(double, double)

src/java.base/share/classes/java/lang/Float16.java line 635:

> 633:      * @see java.util.function.BinaryOperator
> 634:      * @see Math.min(float, float)
> 635:      * @see Math.min(double, double)

Suggestion:

     * @see Math#min(float, float)
     * @see Math#min(double, double)

src/java.base/share/classes/java/lang/Float16.java line 888:

> 886:      * the last place, of a {@code Float16} value is the positive
> 887:      * distance between this floating-point value and the {@code
> 888:      * double} value next larger in magnitude.  Note that for non-NaN

Suggestion:

     * Float16} value next larger in magnitude.  Note that for non-NaN

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1117#pullrequestreview-2112773122
PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1636319783
PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1636313611
PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1636313079
PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1636411997


From dsimms at openjdk.org  Wed Jun 12 16:01:34 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Jun 2024 16:01:34 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
 [v2]
In-Reply-To: <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
 <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>
Message-ID: <iXg5GmoleYFZQqoWBcXrNfpL7kiv8YGlll8k7AlbPkA=.8b3850d9-54c1-4c5f-810d-2706eb934ad8@github.com>

On Tue, 11 Jun 2024 19:18:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Improve detection of invalid class files and test coverage of invalid scenarios.
>> 
>> Tested with Mach5, tier 1 to 3.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Remove obsolete tests
>  - More tests of VM fixing missing ACC_IDENTITY
>  - Fix Copyright years
>  - Add test checking that VM fixes missing ACC_IDENTITY in old class files
>  - Add field tests for abstract value classes
>  - Detect missing exception and other fixes
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Improve class validation and test coverage

Much improved test coverage.

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1114#pullrequestreview-2113480911


From fparain at openjdk.org  Wed Jun 12 16:50:42 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 12 Jun 2024 16:50:42 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
 [v2]
In-Reply-To: <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
 <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>
Message-ID: <MtGstxzLSCkUPx9c0fep-7cQ1BJ9cemmx-t3iL02D4o=.3512ec7d-ea44-4ae3-bf2e-9b022da48ba5@github.com>

On Tue, 11 Jun 2024 19:18:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Improve detection of invalid class files and test coverage of invalid scenarios.
>> 
>> Tested with Mach5, tier 1 to 3.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Remove obsolete tests
>  - More tests of VM fixing missing ACC_IDENTITY
>  - Fix Copyright years
>  - Add test checking that VM fixes missing ACC_IDENTITY in old class files
>  - Add field tests for abstract value classes
>  - Detect missing exception and other fixes
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Improve class validation and test coverage

Thank you for the reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1114#issuecomment-2163491342


From fparain at openjdk.org  Wed Jun 12 16:50:43 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 12 Jun 2024 16:50:43 GMT
Subject: [lworld] Integrated: 8333675: [lworld] Handling of invalid class files
In-Reply-To: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
Message-ID: <Ln5Ej9HafaDH9i8cftqmDTH-P_unDNAa3am8QO7c4do=.48d4b4eb-04a3-46a1-9d92-15ddbc1d8025@github.com>

On Wed, 5 Jun 2024 20:15:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Improve detection of invalid class files and test coverage of invalid scenarios.
> 
> Tested with Mach5, tier 1 to 3.

This pull request has now been integrated.

Changeset: 8b4f9019
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8b4f901908d1389aaf33d1973f3f6c2f1e8af3fd
Stats:     4582 lines in 10 files changed: 1417 ins; 3143 del; 22 mod

8333675: [lworld] Handling of invalid class files

Reviewed-by: dsimms

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

PR: https://git.openjdk.org/valhalla/pull/1114


From vromero at openjdk.org  Wed Jun 12 17:55:36 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jun 2024 17:55:36 GMT
Subject: [lworld] Integrated: 8308779: [lworld] jshell test failures after
 jdk-21+14
Message-ID: <I78A4b0CjrvO81ronjKP0yIpgkdTW2luJSKc8kkQ0gI=.595b09a4-56f7-4288-a53a-378b1d78959d@github.com>

the tests are passing now, this fix is only removing them from the problem list

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

Commit messages:
 - 8308779: [lworld] jshell test failures after jdk-21+14

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

PR: https://git.openjdk.org/valhalla/pull/1123


From vromero at openjdk.org  Wed Jun 12 17:55:36 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 12 Jun 2024 17:55:36 GMT
Subject: [lworld] Integrated: 8308779: [lworld] jshell test failures after
 jdk-21+14
In-Reply-To: <I78A4b0CjrvO81ronjKP0yIpgkdTW2luJSKc8kkQ0gI=.595b09a4-56f7-4288-a53a-378b1d78959d@github.com>
References: <I78A4b0CjrvO81ronjKP0yIpgkdTW2luJSKc8kkQ0gI=.595b09a4-56f7-4288-a53a-378b1d78959d@github.com>
Message-ID: <hmAFEQQgXBAqJ3mX_jv8RyC80mmzwu5DT9fAZrqHq10=.75beb41e-e8ad-4e95-8c70-5535440cab2d@github.com>

On Wed, 12 Jun 2024 17:49:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the tests are passing now, this fix is only removing them from the problem list

This pull request has now been integrated.

Changeset: 38d62168
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/38d621680c20721b12c3898f703cbeb59932ce38
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8308779: [lworld] jshell test failures after jdk-21+14

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

PR: https://git.openjdk.org/valhalla/pull/1123


From rriggs at openjdk.org  Wed Jun 12 20:21:44 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Jun 2024 20:21:44 GMT
Subject: [lworld] RFR: 8334140: [lworld] -XX:LockingMode=0 ignored makes
 MapLoops fail
Message-ID: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>

The MapLoops test uses `-XX:LockingMode=0 -XX:+VerifyHeavyMonitors ` for a debug test run.
However, the LockingMode command line option is overridden in arguments.cpp when 
Valhalla is enabled and it forces the lock mode to be LM_LEGACY.

The default for lightweight locking should only be overridden if Valhalla is enabled.

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

Commit messages:
 - 8334140: [lworld] -XX:LockingMode=0 ignored makes MapLoops fail

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

PR: https://git.openjdk.org/valhalla/pull/1124


From coleenp at openjdk.org  Wed Jun 12 20:27:31 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 12 Jun 2024 20:27:31 GMT
Subject: [lworld] RFR: 8334140: [lworld] -XX:LockingMode=0 ignored makes
 MapLoops fail
In-Reply-To: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
References: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
Message-ID: <wisOfGhn-aPmnNHJlqRGRvxsV1jo9eb9eRnVxFnf92Q=.518223a5-02c1-441a-90fb-c07ec7886485@github.com>

On Wed, 12 Jun 2024 20:16:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The MapLoops test uses `-XX:LockingMode=0 -XX:+VerifyHeavyMonitors ` for a debug test run.
> However, the LockingMode command line option is overridden in arguments.cpp when 
> Valhalla is enabled and it forces the lock mode to be LM_LEGACY.
> 
> The default for lightweight locking should only be overridden if Valhalla is enabled.

Marked as reviewed by coleenp (no project role).

src/hotspot/share/runtime/arguments.cpp line 1833:

> 1831: 
> 1832:   // Valhalla missing LM_LIGHTWEIGHT support just now
> 1833:   if (EnableValhalla && LockingMode == LM_LIGHTWEIGHT ) {

Nit: remove the space after LIGHTWEIGHT.

This should work.  If lightweight locking is specified on the command line, you probably should have a warning, but I assume this is temporary until it is supported.

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

PR Review: https://git.openjdk.org/valhalla/pull/1124#pullrequestreview-2114150534
PR Review Comment: https://git.openjdk.org/valhalla/pull/1124#discussion_r1637037273


From rriggs at openjdk.org  Wed Jun 12 20:37:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Jun 2024 20:37:51 GMT
Subject: [lworld] RFR: 8334140: [lworld] -XX:LockingMode=0 ignored makes
 MapLoops fail [v2]
In-Reply-To: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
References: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
Message-ID: <tDVTUG2qN8lMeWKPihi-yuFKeoas0rHl9l9a9DsKfgw=.c71e90c7-f4e9-4ad0-9d71-226ba1ad8383@github.com>

> The MapLoops test uses `-XX:LockingMode=0 -XX:+VerifyHeavyMonitors ` for a debug test run.
> However, the LockingMode command line option is overridden in arguments.cpp when 
> Valhalla is enabled and it forces the lock mode to be LM_LEGACY.
> 
> The default for lightweight locking should only be overridden if Valhalla is enabled.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove extraneous whitespace

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1124/files
  - new: https://git.openjdk.org/valhalla/pull/1124/files/952ad81f..220ec86f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1124&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1124&range=00-01

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

PR: https://git.openjdk.org/valhalla/pull/1124


From darcy at openjdk.org  Wed Jun 12 20:45:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 12 Jun 2024 20:45:36 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v7]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <HkQJ5jV35AIiBuUP6ye3vGkV_MJ8uG1Vb4qX8a0JAgY=.fabf176e-56e3-4527-a4d5-2d9b15196ee5@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix javadoc typos.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/bf09c544..a15fbc94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=06
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=05-06

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

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Wed Jun 12 20:45:36 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 12 Jun 2024 20:45:36 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
 <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
 <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>
Message-ID: <IejSEGh_XZxAjcQiH-o_YJClCFYiTAJT_cRpLrUzRb4=.3258692e-e6ca-4250-823e-d6d4e822988c@github.com>

On Wed, 12 Jun 2024 04:41:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A few comments on the proposed revised API of Float16:
>> 
>> The Float16 class was generally brought up to static field and method level parity with java.lang.{Float, Double}. Additionally, a number of low-level floating-point handling methods from Math/StrictMath were added to, such as getExponent. These methods are usually an operation or recommended function from IEEE 754. Methods for arithmetic operators {+, -, *, /} and square root were also added. The value(short) method was changed from a bit-level conversion to a value-based one; bit-level conversion is provided by a new shortBitsToFloat16 method.
>> 
>> The current API favors static methods over instances one. Methods to extend the Number abstract class and implement Comparable are of necessity instance methods.
>> 
>> Some more work is needed on the decimal <-> binary conversion methods.
>
>> A few comments on the proposed revised API of Float16:
>> 
>> The Float16 class was generally brought up to static field and method level parity with java.lang.{Float, Double}. Additionally, a number of low-level floating-point handling methods from Math/StrictMath were added to, such as getExponent. These methods are usually an operation or recommended function from IEEE 754. Methods for arithmetic operators {+, -, *, /} and square root were also added. The value(short) method was changed from a bit-level conversion to a value-based one; bit-level conversion is provided by a new shortBitsToFloat16 method.
>> 
>> The current API favors static methods over instances one. Methods to extend the Number abstract class and implement Comparable are of necessity instance methods.
>> 
>> Some more work is needed on the decimal <-> binary conversion methods.
> 
> PS As a design note on the implementation, as many of the methods are expected to be intrinsified on common production platforms, I was looking to favor conciseness and code reuse, say by relying on float and double operations, rather than absolute performance for a native software-based implementation of Float16.

> Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> 
> Kindly fix and integrate.

Oops; sorry for the build breakage -- no change is no small that you shouldn't build before pushing ;-)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2163865948


From darcy at openjdk.org  Wed Jun 12 20:52:27 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 12 Jun 2024 20:52:27 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v6]
In-Reply-To: <1QyA28UsvgJM4w9miVXsdstulrTqcL0CBOH28LXU2fg=.740c1ae9-20d9-4d87-90c8-c74a43a94a21@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <RcKUiDrOMmxkS8DjabkQsKYSYVwy4nGuQq4TL-72mLE=.9d89f258-edc8-4070-b794-73c4bc241b7f@github.com>
 <1QyA28UsvgJM4w9miVXsdstulrTqcL0CBOH28LXU2fg=.740c1ae9-20d9-4d87-90c8-c74a43a94a21@github.com>
Message-ID: <YRxjWDbB6r6x7GExcmuWPh0O0VY-g-psuUtVgH1cY54=.f60adf35-01b0-4723-85bd-6bc646c3ee24@github.com>

On Wed, 12 Jun 2024 11:45:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added 2p+2 comment, fma disclaimer, etc.
>
> src/java.base/share/classes/java/lang/Float16.java line 63:
> 
>> 61:  * of equivalent cases by methods in {@code Float}, {@code Double},
>> 62:  * {@code Math}, etc.
>> 63:  *
> 
> May I kindly request you to please append your name to file @author list.

In the mainline JDK, we've long since stopped adding new `@author` tags. (I've actually removed some of my `@author` tags in some test code.) In preparation for a future where Float16 is in the mainline JDK, I suggest this information be recorded in some other fashion, at least when integrated into the mainline.

The `/contributor ` Skara command can be used to record multiple co-authors of the code in a PR. That is one way this information could be preserved when integrated into the mainline.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1637069837


From darcy at openjdk.org  Wed Jun 12 22:41:23 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 12 Jun 2024 22:41:23 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <IejSEGh_XZxAjcQiH-o_YJClCFYiTAJT_cRpLrUzRb4=.3258692e-e6ca-4250-823e-d6d4e822988c@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
 <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
 <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>
 <IejSEGh_XZxAjcQiH-o_YJClCFYiTAJT_cRpLrUzRb4=.3258692e-e6ca-4250-823e-d6d4e822988c@github.com>
Message-ID: <QTqklzl8dmF_ldRa0ZWfGkJEIq05ZF9DRPayzliEcmw=.a71300c2-893b-4a8c-ac1e-9397e20e6c53@github.com>

On Wed, 12 Jun 2024 20:43:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> 
> Kindly fix and integrate.

Thanks; let me take a pass at writing at least some basic regression tests before pushing.

@jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2164012295


From darcy at openjdk.org  Thu Jun 13 04:49:55 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 13 Jun 2024 04:49:55 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v8]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <Uat5w_-00ZBMT0MQZ_vXsiS3N4WhA35jjjZZo2l81VQ=.bc285049-f419-4cc6-bf11-22eb0ea2658f@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Mostly doc fixes.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/a15fbc94..f3078304

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=07
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=06-07

  Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Thu Jun 13 05:14:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 13 Jun 2024 05:14:34 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v9]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <yJLyuIBzcUK99B9IJr9AfywGsrtJeKRSJZuPI7NOO4g=.3b3e62db-4481-48ad-8753-3e51a899ae5d@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Add test, fix typo.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/f3078304..d60eecef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=08
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=07-08

  Stats: 305 lines in 2 files changed: 304 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From darcy at openjdk.org  Thu Jun 13 05:27:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 13 Jun 2024 05:27:51 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v10]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <9d3UynC1NBgURqkSJZMVrhO8uEVvrozqsr3JW5zNUZ4=.9da63d29-4e74-4e1c-9870-7d2ba448d398@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Appease jcheck; fix copyright year.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/d60eecef..7c1724c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=09
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=08-09

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

PR: https://git.openjdk.org/valhalla/pull/1117


From dsimms at openjdk.org  Thu Jun 13 07:50:21 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 13 Jun 2024 07:50:21 GMT
Subject: [lworld] RFR: 8334140: [lworld] -XX:LockingMode=0 ignored makes
 MapLoops fail [v2]
In-Reply-To: <tDVTUG2qN8lMeWKPihi-yuFKeoas0rHl9l9a9DsKfgw=.c71e90c7-f4e9-4ad0-9d71-226ba1ad8383@github.com>
References: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
 <tDVTUG2qN8lMeWKPihi-yuFKeoas0rHl9l9a9DsKfgw=.c71e90c7-f4e9-4ad0-9d71-226ba1ad8383@github.com>
Message-ID: <wm70DsUt1BhYKuRoIfsEbCrsDpZBLCBYP7XeBvXidRw=.0b60631a-412e-4226-aa3f-377ec35db185@github.com>

On Wed, 12 Jun 2024 20:37:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The MapLoops test uses `-XX:LockingMode=0 -XX:+VerifyHeavyMonitors ` for a debug test run.
>> However, the LockingMode command line option is overridden in arguments.cpp when 
>> Valhalla is enabled and it forces the lock mode to be LM_LEGACY.
>> 
>> The default for lightweight locking should only be overridden if Valhalla is enabled.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extraneous whitespace

LGTM, thanks

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1124#pullrequestreview-2114995763


From rriggs at openjdk.org  Thu Jun 13 13:39:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Jun 2024 13:39:31 GMT
Subject: [lworld] Integrated: 8334140: [lworld] -XX:LockingMode=0 ignored makes
 MapLoops fail
In-Reply-To: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
References: <AKQPrlO9bh4dDlT6HLqxgSqadyqQJxylNjU10MwBIP8=.48c10ad5-a956-4e09-bdc9-fcca2d4a0859@github.com>
Message-ID: <eUq7QkWF2XH_iya9bZ5nu3DdkoAzRpSaKeCCGoFD_sM=.097f2aa3-d56e-441c-9ab3-973da6082a7a@github.com>

On Wed, 12 Jun 2024 20:16:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The MapLoops test uses `-XX:LockingMode=0 -XX:+VerifyHeavyMonitors ` for a debug test run.
> However, the LockingMode command line option is overridden in arguments.cpp when 
> Valhalla is enabled and it forces the lock mode to be LM_LEGACY.
> 
> The default for lightweight locking should only be overridden if Valhalla is enabled.

This pull request has now been integrated.

Changeset: 51349f32
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/51349f32bcb6174b8d2e9339cb2683cc1a93df0b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8334140: [lworld] -XX:LockingMode=0 ignored makes MapLoops fail

Reviewed-by: coleenp, dsimms

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

PR: https://git.openjdk.org/valhalla/pull/1124


From dsimms at openjdk.org  Thu Jun 13 15:27:36 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 13 Jun 2024 15:27:36 GMT
Subject: [lworld] RFR: 8334240: [lworld] cannot find symbol PreloadAttribute
 (renamed to LoadableDescriptors)
Message-ID: <2xRksm7eeL8skXdU4zDB7MYiZYUK9_4j2xA79cw4tkg=.e2f6f3cf-d2cf-4d32-843c-ba1587cce614@github.com>

Renamed

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

Commit messages:
 - 8334240: [lworld] cannot find symbol PreloadAttribute (renamed to LoadableDescriptors)

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

PR: https://git.openjdk.org/valhalla/pull/1125


From darcy at openjdk.org  Thu Jun 13 18:58:40 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 13 Jun 2024 18:58:40 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v11]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <u8H45wcUxOdQQtL-lnnJwTqcOjUtxpKw7QxDap5q4YE=.200408f4-8326-4a81-9865-49fec66396bc@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/7c1724c9..619a031d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=10
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=09-10

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

PR: https://git.openjdk.org/valhalla/pull/1117


From vromero at openjdk.org  Thu Jun 13 18:58:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jun 2024 18:58:58 GMT
Subject: [lworld] Integrated: 8333435: [lworld] javap prints strict field
 incorrectly
Message-ID: <zA58JG5PeCSzk49Mnetj-drDXRw_-sBeEM0SzOkNDyU=.57f6de31-c89c-4b4e-9af8-7b7ade8db5de@github.com>

fixing a bug in javap for which is was incorrectly showing the flags associated to strict fields

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

Commit messages:
 - 8333435: [lworld] javap prints strict field incorrectly

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

PR: https://git.openjdk.org/valhalla/pull/1126


From vromero at openjdk.org  Thu Jun 13 18:58:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 13 Jun 2024 18:58:58 GMT
Subject: [lworld] Integrated: 8333435: [lworld] javap prints strict field
 incorrectly
In-Reply-To: <zA58JG5PeCSzk49Mnetj-drDXRw_-sBeEM0SzOkNDyU=.57f6de31-c89c-4b4e-9af8-7b7ade8db5de@github.com>
References: <zA58JG5PeCSzk49Mnetj-drDXRw_-sBeEM0SzOkNDyU=.57f6de31-c89c-4b4e-9af8-7b7ade8db5de@github.com>
Message-ID: <5hHm_93RxqGOoGm4D73SwniBoiK7YVwVaRB338Ez02k=.67c216fc-93fa-4623-b9e7-0df60c01b022@github.com>

On Thu, 13 Jun 2024 18:53:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing a bug in javap for which is was incorrectly showing the flags associated to strict fields

This pull request has now been integrated.

Changeset: ddacf2c5
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ddacf2c56379f7157df26889a11488f89a055c65
Stats:     30 lines in 4 files changed: 25 ins; 0 del; 5 mod

8333435: [lworld] javap prints strict field incorrectly

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

PR: https://git.openjdk.org/valhalla/pull/1126


From Removed  Thu Jun 13 19:19:29 2024
From: Removed (Removed)
Date: Thu, 13 Jun 2024 19:19:29 -0000
Subject: Removed
Message-ID: <mailman.0.1718376274.110143.valhalla-dev@openjdk.org>

Removed


From redio.development at gmail.com  Thu Jun 13 22:42:41 2024
From: redio.development at gmail.com (Red IO)
Date: Fri, 14 Jun 2024 00:42:41 +0200
Subject: 128 bit Integer type
Message-ID: <CABKyW1sbV7RzZqGY=zVGfGswsa=rdew1uj3wWcOTn4_YLMmLDg@mail.gmail.com>

Hi,
I read somewhere that support for 128bit Integer was in the works and
Valhalla was the place where it's worked on. I couldn't find a document
confirming this or giving more information about the topic.
Some of the follow up questions I had where:
Do we get a new primitive? (probably not)
How else is it implemented?
Is it integrated into the language or just a library construct?
What is the relation to Valhalla?

Thanks in advance

Great regards
RedIODev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240614/a14d1863/attachment.htm>

From dholmes at openjdk.org  Fri Jun 14 02:20:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 02:20:23 GMT
Subject: [lworld] RFR: 8333675: [lworld] Handling of invalid class files
 [v2]
In-Reply-To: <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>
References: <pMb6exHwmVPnYMqkDSyxfm-tgPHgWlJYdbJfnZjpmAY=.7980806d-b601-4544-a37c-7381633709cb@github.com>
 <ZCtW8Dq5Fosa-R3wA7esBfQ785M7lPT2RrX4TfUdRDI=.157d875d-c829-48c6-9db0-057f9af26e5a@github.com>
Message-ID: <aO11U1UR9k80QnEPkgKgMyH7RshhoXZJvrkuGRjAZGA=.53c6cecc-c0e3-4fca-a056-df3b0506d248@github.com>

On Tue, 11 Jun 2024 19:18:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Improve detection of invalid class files and test coverage of invalid scenarios.
>> 
>> Tested with Mach5, tier 1 to 3.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Remove obsolete tests
>  - More tests of VM fixing missing ACC_IDENTITY
>  - Fix Copyright years
>  - Add test checking that VM fixes missing ACC_IDENTITY in old class files
>  - Add field tests for abstract value classes
>  - Detect missing exception and other fixes
>  - Merge remote-tracking branch 'upstream/lworld' into invalid_classes
>  - Improve class validation and test coverage

src/hotspot/share/classfile/classFileParser.cpp line 4744:

> 4742:       class_note = " (a value class must be final or else abstract)";
> 4743:     }
> 4744:     if (!is_identity)  class_note = " (a value class)";

@fparain you needed to delete line 4744 when incorporating my changes. Now you have overwritten the detailed message. I can fix that in my upcoming changes.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1114#discussion_r1639128993


From dholmes at openjdk.org  Fri Jun 14 02:57:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 02:57:46 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
Message-ID: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>

There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.

Changes:
- removed the old Q-type support from the verifier (verifierType.hpp/cpp)
- added the necessary checks for strict fields to the verifier and added some tests
- added missing class modifier checks for value classes in the classfile parse
- brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
- updated existing tests to  support the above

There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

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

Commit messages:
 - Fred's suggestion
 - Merge
 - Refine field modifier checks to reflect current value type rules.
 - Add check that value types are final or else abstract
 - Expand tests and ensure value classes are defined with required class modifiers
 - Ensure value types are enabled before doing strict checks.
 - Merge
 - Provide more details on class format errors in relation to value types and strict fields. Update test to match.
 - Implement verification rules for strict fields and add test
 - Remove Q-type related logic from verifier.cpp
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/ddacf2c5...69855fa0

Changes: https://git.openjdk.org/valhalla/pull/1109/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326597
  Stats: 355 lines in 9 files changed: 202 ins; 126 del; 27 mod
  Patch: https://git.openjdk.org/valhalla/pull/1109.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1109/head:pull/1109

PR: https://git.openjdk.org/valhalla/pull/1109


From dholmes at openjdk.org  Fri Jun 14 02:57:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 02:57:46 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
Message-ID: <7dbDltTabBf2BXl1lkZvLpmsiK5BltIlQYnwCwE_6ps=.f3202ae0-7d73-4185-a269-48784015762b@github.com>

On Fri, 24 May 2024 05:07:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
> 
> Changes:
> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
> - added the necessary checks for strict fields to the verifier and added some tests
> - added missing class modifier checks for value classes in the classfile parse
> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
> - updated existing tests to  support the above
> 
> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

I've merged with https://github.com/openjdk/valhalla/pull/1114 which included the previous changes I had made to the classfile parser. There were a couple of things not merged correctly there so I've adjusted them here.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1109#issuecomment-2167113393


From heidinga at openjdk.org  Fri Jun 14 02:57:46 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 14 Jun 2024 02:57:46 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
Message-ID: <UFnB6LQJ1E0-altOk0s--dWpN5CeP8OjZy9oVynUBRc=.23c8fc8f-d648-4971-8237-e5c601ce690f@github.com>

On Fri, 24 May 2024 05:07:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
> 
> Changes:
> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
> - added the necessary checks for strict fields to the verifier and added some tests
> - added missing class modifier checks for value classes in the classfile parse
> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
> - updated existing tests to  support the above
> 
> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

src/hotspot/share/classfile/classFileParser.cpp line 4722:

> 4720:   const bool major_gte_1_5 = _major_version >= JAVA_1_5_VERSION;
> 4721: 
> 4722:   const bool valid_value_class = is_identity || is_interface ||

Why is `is_identity` included in `valid_value_class`?  I would have expected identity to flag a class as an invalid value class.  Maybe this is just a naming issue with the `valid_value_class` variable?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1109#discussion_r1618905839


From dholmes at openjdk.org  Fri Jun 14 02:57:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 02:57:46 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <UFnB6LQJ1E0-altOk0s--dWpN5CeP8OjZy9oVynUBRc=.23c8fc8f-d648-4971-8237-e5c601ce690f@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
 <UFnB6LQJ1E0-altOk0s--dWpN5CeP8OjZy9oVynUBRc=.23c8fc8f-d648-4971-8237-e5c601ce690f@github.com>
Message-ID: <QcEMh6h8gKh3CRHZmkdzkAiwJXzAInQR4qwfMKKWmSY=.e9ee155b-6e7a-4f8c-ac30-b8cee1aa5000@github.com>

On Wed, 29 May 2024 13:36:51 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
>> 
>> Changes:
>> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
>> - added the necessary checks for strict fields to the verifier and added some tests
>> - added missing class modifier checks for value classes in the classfile parse
>> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
>> - updated existing tests to  support the above
>> 
>> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's
>
> src/hotspot/share/classfile/classFileParser.cpp line 4722:
> 
>> 4720:   const bool major_gte_1_5 = _major_version >= JAVA_1_5_VERSION;
>> 4721: 
>> 4722:   const bool valid_value_class = is_identity || is_interface ||
> 
> Why is `is_identity` included in `valid_value_class`?  I would have expected identity to flag a class as an invalid value class.  Maybe this is just a naming issue with the `valid_value_class` variable?

Yes it is a naming issue. It really means "if this is a value class then it is a valid value class."

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1109#discussion_r1619519528


From fparain at openjdk.org  Fri Jun 14 02:57:46 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 14 Jun 2024 02:57:46 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
Message-ID: <wsFdmXwCoLY1wTPI-JNB4Q2j7rpTXvTn-ZDr1Qs0TIA=.09692d16-7865-4f0d-8c20-523aa8e7956d@github.com>

On Fri, 24 May 2024 05:07:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
> 
> Changes:
> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
> - added the necessary checks for strict fields to the verifier and added some tests
> - added missing class modifier checks for value classes in the classfile parse
> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
> - updated existing tests to  support the above
> 
> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

src/hotspot/share/classfile/verifier.cpp line 2403:

> 2401:           stack_object_type = current_type();
> 2402:         }
> 2403:       } else if (supports_value_types(_klass)) {

The mention of value types here could be confusing.
What about changing `supports_value_types()` to `supports_strict_fields()`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1109#discussion_r1620718165


From dholmes at openjdk.org  Fri Jun 14 02:57:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 02:57:46 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <wsFdmXwCoLY1wTPI-JNB4Q2j7rpTXvTn-ZDr1Qs0TIA=.09692d16-7865-4f0d-8c20-523aa8e7956d@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
 <wsFdmXwCoLY1wTPI-JNB4Q2j7rpTXvTn-ZDr1Qs0TIA=.09692d16-7865-4f0d-8c20-523aa8e7956d@github.com>
Message-ID: <qSNXmiabtjYEqovJ-sDUw_0Ut_eGGqcQfuka8MvQo2s=.736c5631-995c-42c8-b64a-dea8ea5e7579@github.com>

On Thu, 30 May 2024 13:27:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
>> 
>> Changes:
>> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
>> - added the necessary checks for strict fields to the verifier and added some tests
>> - added missing class modifier checks for value classes in the classfile parse
>> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
>> - updated existing tests to  support the above
>> 
>> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's
>
> src/hotspot/share/classfile/verifier.cpp line 2403:
> 
>> 2401:           stack_object_type = current_type();
>> 2402:         }
>> 2403:       } else if (supports_value_types(_klass)) {
> 
> The mention of value types here could be confusing.
> What about changing `supports_value_types()` to `supports_strict_fields()`?

I was copying/emulating the use of `ClassFileParser::supports_inline_types` but changing `inline` to `value`. I can change to `supports_strict_fields` for this new code, but the Classfile parser uses `inline types` to cover both cases (not that I expect to have one without the other).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1109#discussion_r1621737967


From fparain at openjdk.org  Fri Jun 14 02:57:47 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 14 Jun 2024 02:57:47 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <qSNXmiabtjYEqovJ-sDUw_0Ut_eGGqcQfuka8MvQo2s=.736c5631-995c-42c8-b64a-dea8ea5e7579@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
 <wsFdmXwCoLY1wTPI-JNB4Q2j7rpTXvTn-ZDr1Qs0TIA=.09692d16-7865-4f0d-8c20-523aa8e7956d@github.com>
 <qSNXmiabtjYEqovJ-sDUw_0Ut_eGGqcQfuka8MvQo2s=.736c5631-995c-42c8-b64a-dea8ea5e7579@github.com>
Message-ID: <7LImD5wN9C8H3Y5JVbvQOk5wFMKKz3FTOWBuK-7RnTk=.23bdb1ba-6c39-40ed-bba3-c503838f2167@github.com>

On Fri, 31 May 2024 05:22:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/verifier.cpp line 2403:
>> 
>>> 2401:           stack_object_type = current_type();
>>> 2402:         }
>>> 2403:       } else if (supports_value_types(_klass)) {
>> 
>> The mention of value types here could be confusing.
>> What about changing `supports_value_types()` to `supports_strict_fields()`?
>
> I was copying/emulating the use of `ClassFileParser::supports_inline_types` but changing `inline` to `value`. I can change to `supports_strict_fields` for this new code, but the Classfile parser uses `inline types` to cover both cases (not that I expect to have one without the other).

Maybe changing both to `supports_jep_401()` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1109#discussion_r1624525405


From dholmes at openjdk.org  Fri Jun 14 02:57:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 14 Jun 2024 02:57:47 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <7LImD5wN9C8H3Y5JVbvQOk5wFMKKz3FTOWBuK-7RnTk=.23bdb1ba-6c39-40ed-bba3-c503838f2167@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
 <wsFdmXwCoLY1wTPI-JNB4Q2j7rpTXvTn-ZDr1Qs0TIA=.09692d16-7865-4f0d-8c20-523aa8e7956d@github.com>
 <qSNXmiabtjYEqovJ-sDUw_0Ut_eGGqcQfuka8MvQo2s=.736c5631-995c-42c8-b64a-dea8ea5e7579@github.com>
 <7LImD5wN9C8H3Y5JVbvQOk5wFMKKz3FTOWBuK-7RnTk=.23bdb1ba-6c39-40ed-bba3-c503838f2167@github.com>
Message-ID: <1uYkP31JRH1IMrsYKAyIG6GSjZRv3dnjOyswnR8k7hM=.8fe5535b-c28b-45f5-b0b5-1c701a362add@github.com>

On Mon, 3 Jun 2024 14:08:14 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> I was copying/emulating the use of `ClassFileParser::supports_inline_types` but changing `inline` to `value`. I can change to `supports_strict_fields` for this new code, but the Classfile parser uses `inline types` to cover both cases (not that I expect to have one without the other).
>
> Maybe changing both to `supports_jep_401()` ?

`supports_strict_fields()` sounds better than encoding JEP numbers.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1109#discussion_r1639157456


From darcy at openjdk.org  Fri Jun 14 05:08:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jun 2024 05:08:34 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v12]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Refactor code, refine spec, add tests.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/619a031d..553b9325

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=11
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=10-11

  Stats: 283 lines in 2 files changed: 186 ins; 31 del; 66 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117


From jbhateja at openjdk.org  Fri Jun 14 05:26:27 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 14 Jun 2024 05:26:27 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <QTqklzl8dmF_ldRa0ZWfGkJEIq05ZF9DRPayzliEcmw=.a71300c2-893b-4a8c-ac1e-9397e20e6c53@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
 <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
 <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>
 <IejSEGh_XZxAjcQiH-o_YJClCFYiTAJT_cRpLrUzRb4=.3258692e-e6ca-4250-823e-d6d4e822988c@github.com>
 <QTqklzl8dmF_ldRa0ZWfGkJEIq05ZF9DRPayzliEcmw=.a71300c2-893b-4a8c-ac1e-9397e20e6c53@github.com>
Message-ID: <c-N0YCmxxvuoz5m4kHocr66JxB4vBDi0VALLeZXxs_o=.a24c0add-68ab-49b7-b0d0-c66bf0a4fae9@github.com>

On Wed, 12 Jun 2024 22:38:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> > Kindly fix and integrate.
> 
> Thanks; let me take a pass at writing at least some basic regression tests before pushing.
> 
> @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)

Hi @jddarcy , As per specification of [Math.fma(float, float, float)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2494) internal computation of constituent operation (mul and add) should be done at infinite precision and only final result should be rounded, we are now upcasting float16 to double but it will not prevent rounding happening for mul and add.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2167234350


From dsimms at openjdk.org  Fri Jun 14 05:27:24 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 14 Jun 2024 05:27:24 GMT
Subject: [lworld] Integrated: 8334240: [lworld] cannot find symbol
 PreloadAttribute (renamed to LoadableDescriptors)
In-Reply-To: <2xRksm7eeL8skXdU4zDB7MYiZYUK9_4j2xA79cw4tkg=.e2f6f3cf-d2cf-4d32-843c-ba1587cce614@github.com>
References: <2xRksm7eeL8skXdU4zDB7MYiZYUK9_4j2xA79cw4tkg=.e2f6f3cf-d2cf-4d32-843c-ba1587cce614@github.com>
Message-ID: <0gr8FClo_6X4Th6Cte7hA59MMT44LWlM_FylSORyrik=.b1df8e55-6714-45fd-9270-d38aa5565866@github.com>

On Thu, 13 Jun 2024 15:23:18 GMT, David Simms <dsimms at openjdk.org> wrote:

> Renamed

This pull request has now been integrated.

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

8334240: [lworld] cannot find symbol PreloadAttribute (renamed to LoadableDescriptors)

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

PR: https://git.openjdk.org/valhalla/pull/1125


From darcy at openjdk.org  Fri Jun 14 06:07:23 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jun 2024 06:07:23 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v6]
In-Reply-To: <1QyA28UsvgJM4w9miVXsdstulrTqcL0CBOH28LXU2fg=.740c1ae9-20d9-4d87-90c8-c74a43a94a21@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <RcKUiDrOMmxkS8DjabkQsKYSYVwy4nGuQq4TL-72mLE=.9d89f258-edc8-4070-b794-73c4bc241b7f@github.com>
 <1QyA28UsvgJM4w9miVXsdstulrTqcL0CBOH28LXU2fg=.740c1ae9-20d9-4d87-90c8-c74a43a94a21@github.com>
Message-ID: <OpontVDGKGg9T7v1pJcMH5gIffayLWW2Snbfrme0svA=.3a4da6e0-502b-44d7-930f-3445e143f0f4@github.com>

On Wed, 12 Jun 2024 11:45:53 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added 2p+2 comment, fma disclaimer, etc.
>
> src/java.base/share/classes/java/lang/Float16.java line 63:
> 
>> 61:  * of equivalent cases by methods in {@code Float}, {@code Double},
>> 62:  * {@code Math}, etc.
>> 63:  *
> 
> May I kindly request you to please append your name to file @author list.

Hi @jatin-bhateja,
With the latest commit, I think the spec is close to the spec that would be acceptable to include in mainline. Please confirm you're okay with this state of the PR being integrated. Afterward, work can continue refining a few areas binary <-> decimal spec and implementation, fma internal comment and/or implementation, etc. Thanks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1639307670


From darcy at openjdk.org  Fri Jun 14 06:22:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jun 2024 06:22:25 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <QTqklzl8dmF_ldRa0ZWfGkJEIq05ZF9DRPayzliEcmw=.a71300c2-893b-4a8c-ac1e-9397e20e6c53@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
 <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
 <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>
 <IejSEGh_XZxAjcQiH-o_YJClCFYiTAJT_cRpLrUzRb4=.3258692e-e6ca-4250-823e-d6d4e822988c@github.com>
 <QTqklzl8dmF_ldRa0ZWfGkJEIq05ZF9DRPayzliEcmw=.a71300c2-893b-4a8c-ac1e-9397e20e6c53@github.com>
Message-ID: <hz3rXEjl5unIscCZfTEhlqqaSRXxDF_9T6iajI4aMOc=.035d02a2-7b83-4267-bdcd-e0357db8c574@github.com>

On Wed, 12 Jun 2024 22:38:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
>>> 
>>> Kindly fix and integrate.
>> 
>> Oops; sorry for the build breakage -- no change is so small that you shouldn't build before pushing ;-)
>
>> Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
>> 
>> Kindly fix and integrate.
> 
> Thanks; let me take a pass at writing at least some basic regression tests before pushing.
> 
> @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)

> > > Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> > > Kindly fix and integrate.
> > 
> > 
> > Thanks; let me take a pass at writing at least some basic regression tests before pushing.
> > @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)
> 
> Hi @jddarcy , As per specification of [Math.fma(float, float, float)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2494) internal computation of constituent operation (mul and add) should be done at infinite precision and only final result should be rounded, we are now upcasting float16 to double but it will not prevent rounding happening for mul and add.

Right; the fma needs to operate as-if it used infinite precision internally. This could be implemented (slowly) using JDK classes by implementing a BigDecimal -> Float16 conversion after doing a*b+c in BigDeicmal. I've been considering adding BigDecimal -> Float16 conversion anyway for completeness in the platform.

My understanding of how fma is implemented in hardware is that for a format with P bits of precision, there is a ~2P wide internal register to hold the exact product as an intermediate result. Then the value being adding in can be aligned at the right exponent location and the final rounding back to P bits of precision can occur, with logic of any sticky bit for rounding to nearest even, etc.

There are many cases where double (P = 53) will exactly hold the product and sum of three Float16 (P = 11) operands.  However, the product can be so large or so small that rounding  occurs when the third operand is added in.

I haven't worked through if the potential round-offs are all benign with the final rounding to Float16 or if some corrective action would need to be taken to get the effect of a sticky bit. For example, if a*b is so large that the highest exponent position set is more than 53 positions away from the lowest exponent position set on c, if the final result is going to overflow anyway, the round-off in computing a*b+c in double doesn't matter. It might be problematic if a*b is much smaller than c, but that is another case I haven't fully thought through yet.

I'll give an updated on my analysis/research on this fma issue by next week.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2167289949


From chagedorn at openjdk.org  Fri Jun 14 07:17:39 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 14 Jun 2024 07:17:39 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array access
 type check wrongly moves array access before its range check
Message-ID: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>

#### Speculative Inline Type Checks for `aaload`

In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:

![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)

#### Known Problem when Load is Disconnected from Range Check

This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 

#### How this Problem Manifests in Valhalla

In the test case, the very same is happening:

1. Loop Predication hoists `237 If` out of the loop since it's invariant.
2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.

 #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 

I've additionally done some refactoring and added some comments which helped me to better understand the code.

Thanks,
Christian

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

Commit messages:
 - 8333889: [lworld] C2: Hoisting speculative array access type check wrongly moves array access before its range check

Changes: https://git.openjdk.org/valhalla/pull/1127/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8333889
  Stats: 345 lines in 3 files changed: 195 ins; 76 del; 74 mod
  Patch: https://git.openjdk.org/valhalla/pull/1127.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1127/head:pull/1127

PR: https://git.openjdk.org/valhalla/pull/1127


From chagedorn at openjdk.org  Fri Jun 14 07:17:39 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 14 Jun 2024 07:17:39 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check
In-Reply-To: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
Message-ID: <t6PhOJ3qpESF0gnO7wXmMii9UlvFbxklDhUvdaNWtC0=.b4448c65-d9fc-4fd7-b6a6-efcd86742d21@github.com>

On Fri, 14 Jun 2024 07:09:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> #### Speculative Inline Type Checks for `aaload`
> 
> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
> 
> #### Known Problem when Load is Disconnected from Range Check
> 
> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
> 
> #### How this Problem Manifests in Valhalla
> 
> In the test case, the very same is happening:
> 
> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
> 
>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
> 
> I've additionally done some refactoring and added some comments which helped me to better understand the code.
> 
> Thanks,
> Christian

src/hotspot/share/opto/parse2.cpp line 393:

> 391: }
> 392: 
> 393: void Parse::create_range_check(Node* idx, Node* ary, const TypeInt* sizetype) {

Only extracted the code to a separate method without applying any refactoring to it.

src/hotspot/share/opto/parse2.cpp line 442:

> 440: // information turns out to be wrong at runtime.
> 441: Node* Parse::create_speculative_inline_type_array_checks(Node* array, const TypeAryPtr* array_type,
> 442:                                                          const Type*& element_type) {

I did not change the semantics and only applied simplifications like renaming, adding comments, extracted code to methods etc. This should improve the readability.

src/hotspot/share/opto/parse2.cpp line 536:

> 534:       replace_in_map(ary, better_ary);
> 535:       ary = better_ary;
> 536:       arytype = _gvn.type(ary)->is_aryptr();

Dropped this line because `arytype` is not used anymore afterwards.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639372755
PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639376834
PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639373668


From dsimms at openjdk.org  Fri Jun 14 08:08:41 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 14 Jun 2024 08:08:41 GMT
Subject: [lworld] RFR: 8334280: [lworld] Tests failing compilation with
 "use --enable-preview to allow loading of class files which contain preview
 features"
Message-ID: <qUTwXhmDphw1c5zDCPPrhb6zXG5mWjE-3qr9FWfuMQw=.58297e89-62b8-4715-a6bb-5f3dd1ae7e79@github.com>

Remove old combo package, leftover from MVT

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

Commit messages:
 - Remove old combo package, leftover from MVT

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

PR: https://git.openjdk.org/valhalla/pull/1128


From thartmann at openjdk.org  Fri Jun 14 08:14:23 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 14 Jun 2024 08:14:23 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check
In-Reply-To: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
Message-ID: <ai9M7OgoUGVy06OfN5KQhXdTaqWIMBM9-7iH9BNV5tc=.ca908985-19a0-4485-9099-12ca655c115f@github.com>

On Fri, 14 Jun 2024 07:09:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> #### Speculative Inline Type Checks for `aaload`
> 
> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
> 
> #### Known Problem when Load is Disconnected from Range Check
> 
> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
> 
> #### How this Problem Manifests in Valhalla
> 
> In the test case, the very same is happening:
> 
> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
> 
>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
> 
> I've additionally done some refactoring and added some comments which helped me to better understand the code.
> 
> Thanks,
> Christian

Nice analysis and great refactoring Christian!

src/hotspot/share/opto/parse2.cpp line 445:

> 443:   if (!array_type->is_flat() && !array_type->is_not_flat()) {
> 444:     // For array accesses, it can be useful to speculate on flatness such that we can fix the data layout. We only want
> 445:     // to do that when we know nothing about flatness since it requires a trap when profiling turns out to be wrong.

I think we should rephrase this because we don't speculate "on flatness". Maybe something like:
"For arrays that might be flat, speculate that the array has the exact type reported in the profile data such that we can rely on a fixed memory layout".

src/hotspot/share/opto/parse2.cpp line 453:

> 451:   }
> 452: 
> 453:   // Even though the type does not tell us whether we have an inline type or not, we can still check the profile data

Suggestion:

  // Even though the type does not tell us whether we have an inline type array or not, we can still check the profile data

?

src/hotspot/share/opto/parse2.cpp line 555:

> 553: 
> 554: // Speculate that the array is non-flat. We emit a trap when this turns out to be wrong. On the fast path, we add a
> 555: // CheckCastPP to use the non-flat type..

Suggestion:

// CheckCastPP to use the non-flat type.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestSpeculateArrayAccess.java line 70:

> 68:             //
> 69:             // Running with -XX:+StressGCM: We could execute the LoadN before entering the loop.
> 70:             // This crashes when iFld = -1 becauase we then access an out-of-bounds element.

Suggestion:

            // This crashes when iFld = -1 because we then access an out-of-bounds element.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1127#pullrequestreview-2117723860
PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639427815
PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639432283
PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639417853
PR Review Comment: https://git.openjdk.org/valhalla/pull/1127#discussion_r1639414955


From dsimms at openjdk.org  Fri Jun 14 09:34:27 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 14 Jun 2024 09:34:27 GMT
Subject: [lworld] Withdrawn: 8334280: [lworld] Tests failing compilation with
 "use --enable-preview to allow loading of class files which contain
 preview features"
In-Reply-To: <qUTwXhmDphw1c5zDCPPrhb6zXG5mWjE-3qr9FWfuMQw=.58297e89-62b8-4715-a6bb-5f3dd1ae7e79@github.com>
References: <qUTwXhmDphw1c5zDCPPrhb6zXG5mWjE-3qr9FWfuMQw=.58297e89-62b8-4715-a6bb-5f3dd1ae7e79@github.com>
Message-ID: <XSYbtg_aP95aQh9aP4U6IC4ZNsI6uF2OEk3g_Aks6Uo=.aab4614f-3aa7-441c-9393-b6a35801762c@github.com>

On Fri, 14 Jun 2024 08:04:28 GMT, David Simms <dsimms at openjdk.org> wrote:

> Remove old combo package, leftover from MVT

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla/pull/1128


From dsimms at openjdk.org  Fri Jun 14 09:50:57 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 14 Jun 2024 09:50:57 GMT
Subject: [lworld] RFR: 8334291: [lworld] Remove old "combo" package (from MVT
 testing bytecode API)
Message-ID: <A6fn7cjrmuslexqtprPisnTv7txOT-GOeBbeqypN-D4=.2c0c1321-c2c9-402f-aaaf-b027ff8e1ac8@github.com>

Remove old unsed package

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

Commit messages:
 - 8334291: [lworld] Remove old "combo" package (from MVT testing bytecode API)

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

PR: https://git.openjdk.org/valhalla/pull/1129


From dsimms at openjdk.org  Fri Jun 14 10:01:41 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 14 Jun 2024 10:01:41 GMT
Subject: [lworld] Integrated: 8334291: [lworld] Remove old "combo" package
 (from MVT testing bytecode API)
In-Reply-To: <A6fn7cjrmuslexqtprPisnTv7txOT-GOeBbeqypN-D4=.2c0c1321-c2c9-402f-aaaf-b027ff8e1ac8@github.com>
References: <A6fn7cjrmuslexqtprPisnTv7txOT-GOeBbeqypN-D4=.2c0c1321-c2c9-402f-aaaf-b027ff8e1ac8@github.com>
Message-ID: <HhT2u9MkEaOvy1pCRN7uftPn2Tzwa5korZ-ofaIJuts=.57cb43c5-cba3-4579-8693-d58e3f58d27b@github.com>

On Fri, 14 Jun 2024 09:45:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Remove old unsed package

This pull request has now been integrated.

Changeset: 8bd3f10c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8bd3f10c13e69a6a3b282526b951d15fc3f010d9
Stats:     1471 lines in 5 files changed: 0 ins; 1471 del; 0 mod

8334291: [lworld] Remove old "combo" package (from MVT testing bytecode API)

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

PR: https://git.openjdk.org/valhalla/pull/1129


From bkilambi at openjdk.org  Fri Jun 14 11:08:32 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 14 Jun 2024 11:08:32 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v12]
In-Reply-To: <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>
Message-ID: <Z8dBv_xh29_sc5o6IrMReWmVYPNRqXgxGdtgQkBRwqk=.25c0ec81-b0cf-4d3f-b47c-0289acdeaa4b@github.com>

On Fri, 14 Jun 2024 05:08:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor code, refine spec, add tests.

src/java.base/share/classes/java/lang/Float16.java line 736:

> 734:      */
> 735:     // @IntrinsicCandidate
> 736:     public static Float16 add(Float16 addend, Float16 augend) {

Hi, thanks for implementing these operations for Float16. May I ask why do we have both `Float16 sum()` and `Float16 add()`? Also, both seem to be marked as `@IntrinsicsCandidate`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1639661924


From tobias.hartmann at oracle.com  Fri Jun 14 12:24:49 2024
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 14 Jun 2024 14:24:49 +0200
Subject: CFV: New Valhalla Committer: Christian Hagedorn
Message-ID: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>

I hereby nominate Christian Hagedorn [1] to Valhalla Committer.

Christian is a member of the HotSpot Compiler Team at Oracle and a JDK Reviewer. Since 2019, he
contributed over 218 changes to the JDK project [2] and 9 changes to the Valhalla project [3].

Votes are due by June 28, 2024, 13:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast
in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.java.net/census#chagedorn
[2]
https://github.com/search?q=committer-name%3A%22Christian+Hagedorn%22+repo%3Aopenjdk%2Fjdk&type=commits
[3]
https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20chagedorn%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] [2] https://openjdk.org/projects/#committer-vote


From jatin.bhateja at intel.com  Fri Jun 14 12:41:36 2024
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Fri, 14 Jun 2024 12:41:36 +0000
Subject: CFV: New Valhalla Committer: Christian Hagedorn
In-Reply-To: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
References: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
Message-ID: <PH8PR11MB796774DEB956D247CFC9BD21E8C22@PH8PR11MB7967.namprd11.prod.outlook.com>

Vote : yes

Best Regards,
Jatin.



________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Tobias Hartmann <tobias.hartmann at oracle.com>
Sent: Friday, June 14, 2024 5:55:39 PM
To: valhalla-dev at openjdk.java.net >> valhalla-dev <valhalla-dev at openjdk.java.net>
Cc: Christian Hagedorn <christian.hagedorn at oracle.com>
Subject: CFV: New Valhalla Committer: Christian Hagedorn

I hereby nominate Christian Hagedorn [1] to Valhalla Committer.

Christian is a member of the HotSpot Compiler Team at Oracle and a JDK Reviewer. Since 2019, he
contributed over 217 changes to the JDK project [2] and 9 changes to the Valhalla project [3].

Votes are due by June 28, 2024, 13:00 UTC.

Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast
in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Best regards,
Tobias

[1] https://openjdk.java.net/census#chagedorn
[2]
https://github.com/search?q=committer-name%3A%22Christian+Hagedorn%22+repo%3Aopenjdk%2Fjdk&type=commits
[3]
https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20chagedorn%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
[4] https://openjdk.java.net/census
[5] [2] https://openjdk.org/projects/#committer-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240614/dfd3538b/attachment.htm>

From vromero at openjdk.org  Fri Jun 14 13:14:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jun 2024 13:14:59 GMT
Subject: [lworld] Integrated: 8334294: [lworld] several javac tests are failing
 in valhalla
Message-ID: <RsYx-TAXHMt-ZiT0QvmHpQ3Q4HrHN_jMQMoe81XxvnE=.fb43b06d-c4f4-44c7-af0e-4a08039e9af7@github.com>

adding @enablePreview to several tests, they are not explicitly using any preview feature but the libs they depend on do use classes like `java.util.Optional` which is a value based class

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

Commit messages:
 - 8334294: [lworld] several javac tests are failing in valhalla

Changes: https://git.openjdk.org/valhalla/pull/1130/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1130&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334294
  Stats: 46 lines in 39 files changed: 39 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1130.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1130/head:pull/1130

PR: https://git.openjdk.org/valhalla/pull/1130


From vromero at openjdk.org  Fri Jun 14 13:14:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jun 2024 13:14:59 GMT
Subject: [lworld] Integrated: 8334294: [lworld] several javac tests are failing
 in valhalla
In-Reply-To: <RsYx-TAXHMt-ZiT0QvmHpQ3Q4HrHN_jMQMoe81XxvnE=.fb43b06d-c4f4-44c7-af0e-4a08039e9af7@github.com>
References: <RsYx-TAXHMt-ZiT0QvmHpQ3Q4HrHN_jMQMoe81XxvnE=.fb43b06d-c4f4-44c7-af0e-4a08039e9af7@github.com>
Message-ID: <U6qWvpTfm6W1xUgGgW72SaOeUmz6l-ejpAh2dAA_zYw=.e94fca85-29b6-494d-909e-7f0088b8bdad@github.com>

On Fri, 14 Jun 2024 13:08:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding @enablePreview to several tests, they are not explicitly using any preview feature but the libs they depend on do use classes like `java.util.Optional` which is a value based class

This pull request has now been integrated.

Changeset: 5536d7ab
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5536d7ab24ca3f6ba707a4ccda216149aa2e40f0
Stats:     46 lines in 39 files changed: 39 ins; 5 del; 2 mod

8334294: [lworld] several javac tests are failing in valhalla

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

PR: https://git.openjdk.org/valhalla/pull/1130


From brian.goetz at oracle.com  Fri Jun 14 13:26:01 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 14 Jun 2024 13:26:01 +0000
Subject: 128 bit Integer type
In-Reply-To: <CABKyW1sbV7RzZqGY=zVGfGswsa=rdew1uj3wWcOTn4_YLMmLDg@mail.gmail.com>
References: <CABKyW1sbV7RzZqGY=zVGfGswsa=rdew1uj3wWcOTn4_YLMmLDg@mail.gmail.com>
Message-ID: <D61B6B94-CEB6-4480-8FFF-B5C40609FE5A@oracle.com>

New numeric types are certainly one of the motivations for Valhalla.  Obvious examples include larger and smaller versions of existing primitives (Integer128, Float16), complex numbers, and fixed-point decimals.  

There are a number of open areas with respect to such classes.  There is a significant API design effort for how new numerics will fit into the JDK; there is a dependency on nullity control to get efficient and dense numerics; there is the question of how to incorporate conversions so that new numeric types can play with old ones (e.g., widening from int32 to Integer128), there is the question of operator overloading (no, we?re not going to talk about that now), and there may be intrinsics needed to get ideal performance.  These are all experiments that will play out in Valhalla soon, but for the most part, we are still nailing down the groundwork.  

> On Jun 13, 2024, at 6:42 PM, Red IO <redio.development at gmail.com> wrote:
> 
> Hi,
> I read somewhere that support for 128bit Integer was in the works and Valhalla was the place where it's worked on. I couldn't find a document confirming this or giving more information about the topic.
> Some of the follow up questions I had where:
> Do we get a new primitive? (probably not)
> How else is it implemented?
> Is it integrated into the language or just a library construct?
> What is the relation to Valhalla?
> 
> Thanks in advance
> 
> Great regards 
> RedIODev 


From tobias.hartmann at oracle.com  Fri Jun 14 13:52:51 2024
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 14 Jun 2024 15:52:51 +0200
Subject: CFV: New Valhalla Committer: Christian Hagedorn
In-Reply-To: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
References: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
Message-ID: <31e8c813-36b5-49dc-ba4c-7cdd3fe1957b@oracle.com>

Vote: yes

Best regards,
Tobias

On 14.06.24 14:24, Tobias Hartmann wrote:
> I hereby nominate Christian Hagedorn [1] to Valhalla Committer.
> 
> Christian is a member of the HotSpot Compiler Team at Oracle and a JDK Reviewer. Since 2019, he
> contributed over 218 changes to the JDK project [2] and 9 changes to the Valhalla project [3].
> 
> Votes are due by June 28, 2024, 13:00 UTC.
> 
> Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast
> in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> Best regards,
> Tobias
> 
> [1] https://openjdk.java.net/census#chagedorn
> [2]
> https://github.com/search?q=committer-name%3A%22Christian+Hagedorn%22+repo%3Aopenjdk%2Fjdk&type=commits
> [3]
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20chagedorn%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] [2] https://openjdk.org/projects/#committer-vote


From frederic.parain at oracle.com  Fri Jun 14 16:03:26 2024
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 14 Jun 2024 12:03:26 -0400
Subject: CFV: New Valhalla Committer: Christian Hagedorn
In-Reply-To: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
References: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
Message-ID: <0a733bad-6bbb-4569-a9df-a75e7d8d09a9@oracle.com>

Vote: yes

Fred

On 6/14/24 08:24, Tobias Hartmann wrote:
> I hereby nominate Christian Hagedorn [1] to Valhalla Committer.
>
> Christian is a member of the HotSpot Compiler Team at Oracle and a JDK Reviewer. Since 2019, he
> contributed over 218 changes to the JDK project [2] and 9 changes to the Valhalla project [3].
>
> Votes are due by June 28, 2024, 13:00 UTC.
>
> Only current Valhalla Committers [4] are eligible to vote on this nomination. Votes must be cast
> in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [5].
>
> Best regards,
> Tobias
>
> [1] https://openjdk.java.net/census#chagedorn
> [2]
> https://github.com/search?q=committer-name%3A%22Christian+Hagedorn%22+repo%3Aopenjdk%2Fjdk&type=commits
> [3]
> https://bugs.openjdk.org/issues/?jql=assignee%20%3D%20chagedorn%20AND%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%20repo-valhalla
> [4] https://openjdk.java.net/census
> [5] [2] https://openjdk.org/projects/#committer-vote

From darcy at openjdk.org  Fri Jun 14 16:46:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 14 Jun 2024 16:46:35 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v12]
In-Reply-To: <Z8dBv_xh29_sc5o6IrMReWmVYPNRqXgxGdtgQkBRwqk=.25c0ec81-b0cf-4d3f-b47c-0289acdeaa4b@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>
 <Z8dBv_xh29_sc5o6IrMReWmVYPNRqXgxGdtgQkBRwqk=.25c0ec81-b0cf-4d3f-b47c-0289acdeaa4b@github.com>
Message-ID: <DMhWumsiMoN3G8K2tHSjHEf_-Pn3uKAm_lmLRXBXTJs=.107b1da0-eafc-41fa-b1b0-0d9b5e8396a2@github.com>

On Fri, 14 Jun 2024 11:05:38 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Hi, thanks for implementing these operations for Float16. May I ask why do we have both `Float16 sum()` and `Float16 add()`? Also, both seem to be marked as `@IntrinsicsCandidate`.

Hello @Bhavana-Kilambi ,
The Float16 class already had a sum method before I started my work, so I left it in place. I assume "sum" was added in analogy to the the sum method added to Float and Double in the context of the stream work done in JDK 8.

For the purpose of including support for methods to perform the addition, subtraction, multiplication, and division operation, I think "add" is a better name than "sum".

I don't have any appreciable experience changing HotSpot, so I was going to leave that aspect of this work to others. The build fails if the `@IntrinsicCandidate` annotation is applied to methods without the possibility of a matching candidate in HotSpot. Therefore, I left a commented out form of the annotation on methods I assumed would be eligible for such support, but those were just my guesses and should be updated for what the actual intrinsic support could be.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1640103814

From fparain at openjdk.org  Fri Jun 14 17:48:36 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 14 Jun 2024 17:48:36 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
Message-ID: <rHhJx3bV_D8KLLJm3X9DfvMAALn78jEPMmtf1Gu3pmY=.77a0869f-bc27-4019-a87a-1e2eb45138bd@github.com>

On Fri, 24 May 2024 05:07:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
> 
> Changes:
> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
> - added the necessary checks for strict fields to the verifier and added some tests
> - added missing class modifier checks for value classes in the classfile parse
> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
> - updated existing tests to  support the above
> 
> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

Looks good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1109#pullrequestreview-2118947446

From fparain at openjdk.org  Fri Jun 14 18:10:36 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 14 Jun 2024 18:10:36 GMT
Subject: [lworld] RFR: 8332243: Value classes implementing Cloneable
Message-ID: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>

Allow value classes to implement the Cloneable interface.

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

Commit messages:
 - Allow value classes to implement Cloneable

Changes: https://git.openjdk.org/valhalla/pull/1131/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1131&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332243
  Stats: 127 lines in 4 files changed: 97 ins; 30 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1131.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1131/head:pull/1131

PR: https://git.openjdk.org/valhalla/pull/1131

From coleenp at openjdk.org  Fri Jun 14 18:48:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Jun 2024 18:48:45 GMT
Subject: [lworld] RFR: Use stringStream to keep field layout output together.
Message-ID: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>

Tested with -XX:+PrintFieldLayout comparing before and after.

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

Commit messages:
 - Use stringStream to keep field layout output together.

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

PR: https://git.openjdk.org/valhalla/pull/1132

From vromero at openjdk.org  Fri Jun 14 19:45:48 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jun 2024 19:45:48 GMT
Subject: [lworld] Integrated: 8334314: [lworld] javac valhalla tests need
 refactoring
Message-ID: <RFbjcyVcNjq-aGhmGJQITjqYH_heYxoB46WiEwaCDfo=.a60f2bd7-0761-4371-843b-62f94cc08fa3@github.com>

removing non-relevant test and adding some additional ones

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

Commit messages:
 - 8334314: [lworld] javac valhalla tests need refactoring

Changes: https://git.openjdk.org/valhalla/pull/1133/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1133&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334314
  Stats: 451 lines in 10 files changed: 49 ins; 400 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1133.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1133/head:pull/1133

PR: https://git.openjdk.org/valhalla/pull/1133

From vromero at openjdk.org  Fri Jun 14 19:45:48 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jun 2024 19:45:48 GMT
Subject: [lworld] Integrated: 8334314: [lworld] javac valhalla tests need
 refactoring
In-Reply-To: <RFbjcyVcNjq-aGhmGJQITjqYH_heYxoB46WiEwaCDfo=.a60f2bd7-0761-4371-843b-62f94cc08fa3@github.com>
References: <RFbjcyVcNjq-aGhmGJQITjqYH_heYxoB46WiEwaCDfo=.a60f2bd7-0761-4371-843b-62f94cc08fa3@github.com>
Message-ID: <IO_JTPE-ZdAd7ch-Ee_EpfvRJH8auoh4u1l-UtopLus=.d5d40e49-efc3-47f2-af06-63cb93b6a8a7@github.com>

On Fri, 14 Jun 2024 19:41:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> removing non-relevant test and adding some additional ones

This pull request has now been integrated.

Changeset: a3ee9764
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a3ee9764093895d419853cf16b135af827d72cfb
Stats:     451 lines in 10 files changed: 49 ins; 400 del; 2 mod

8334314: [lworld] javac valhalla tests need refactoring

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

PR: https://git.openjdk.org/valhalla/pull/1133

From fparain at openjdk.org  Fri Jun 14 19:51:19 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 14 Jun 2024 19:51:19 GMT
Subject: [lworld] RFR: Use stringStream to keep field layout output
 together.
In-Reply-To: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>
References: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>
Message-ID: <aPzI6PWAtunp_o3fD6Z0o-oVwBu_OCIv2PiJyAawQIs=.6d20333a-c611-4d64-b637-d2d8c60dca22@github.com>

On Fri, 14 Jun 2024 18:43:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Tested with -XX:+PrintFieldLayout comparing before and after, and field_layout tests.
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout
>                                                          6     6     0     0

LGTM.
Thank you Coleen for this nice cleanup of the ttyLock.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1132#pullrequestreview-2119140546

From coleenp at openjdk.org  Fri Jun 14 20:13:23 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Jun 2024 20:13:23 GMT
Subject: [lworld] RFR: Use stringStream to keep field layout output
 together.
In-Reply-To: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>
References: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>
Message-ID: <yuK7A8MTxHJvKY40YbHcijbZA9PodU1rQjtb-KDlbcw=.bf6e3f5a-451f-4f8b-adf9-6ad1e2969457@github.com>

On Fri, 14 Jun 2024 18:43:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Tested with -XX:+PrintFieldLayout comparing before and after, and field_layout tests.
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout
>                                                          6     6     0     0

Thanks Fred, hope it helps.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1132#issuecomment-2168691367

From coleenp at openjdk.org  Fri Jun 14 20:18:24 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Jun 2024 20:18:24 GMT
Subject: [lworld] Integrated: Use stringStream to keep field layout output
 together.
In-Reply-To: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>
References: <ubTiMFDjzFbZVWRoo3h-s0CjaEnaMV0deDptJ9HXEYw=.38f93b19-19ba-4026-bc86-6e0c468cdf54@github.com>
Message-ID: <h8vCOlgbcbS-wbx-MHPnrq0Zgtf2Jlo-C-rH-sbZXNE=.b099c5bc-b64a-4014-a75a-d84dc6b4a92a@github.com>

On Fri, 14 Jun 2024 18:43:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Tested with -XX:+PrintFieldLayout comparing before and after, and field_layout tests.
> 
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout
>                                                          6     6     0     0

This pull request has now been integrated.

Changeset: eb69365a
Author:    Coleen Phillimore <coleenp at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/eb69365a6207bc807ed79a04062332328f7b636a
Stats:     18 lines in 1 file changed: 2 ins; 0 del; 16 mod

Use stringStream to keep field layout output together.

Reviewed-by: fparain

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

PR: https://git.openjdk.org/valhalla/pull/1132

From serguei.spitsyn at oracle.com  Fri Jun 14 20:39:40 2024
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Fri, 14 Jun 2024 20:39:40 +0000
Subject: CFV: New Valhalla Committer: Christian Hagedorn
In-Reply-To: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
References: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
Message-ID: <BY5PR10MB4324A9795DE8EB33E91DF9318DC22@BY5PR10MB4324.namprd10.prod.outlook.com>

Vote: yes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240614/d913350b/attachment.htm>

From vromero at openjdk.org  Fri Jun 14 22:02:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jun 2024 22:02:05 GMT
Subject: [lworld] Integrated: 8334321: [lworld] add more javadoc and
 javax.lang.model tests for value classes
Message-ID: <4Q3UA4mTIqWXf7MSulxFUORtPcNy_dQKRTHJebkT2bo=.78478795-c6c9-4bc1-9ec8-4ded15f10405@github.com>

adding more tests for value classes javadoc and javax.lang.model

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

Commit messages:
 - 8334321: [lworld] add more javadoc and javax.lang.model tests for value classes

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

PR: https://git.openjdk.org/valhalla/pull/1134

From vromero at openjdk.org  Fri Jun 14 22:02:06 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 14 Jun 2024 22:02:06 GMT
Subject: [lworld] Integrated: 8334321: [lworld] add more javadoc and
 javax.lang.model tests for value classes
In-Reply-To: <4Q3UA4mTIqWXf7MSulxFUORtPcNy_dQKRTHJebkT2bo=.78478795-c6c9-4bc1-9ec8-4ded15f10405@github.com>
References: <4Q3UA4mTIqWXf7MSulxFUORtPcNy_dQKRTHJebkT2bo=.78478795-c6c9-4bc1-9ec8-4ded15f10405@github.com>
Message-ID: <7iQ86cIi7kumSdA41ucApfwMElRpx0Yd-6qwYT_a1K8=.b1b3d43c-4317-4469-bff2-9f046a04c201@github.com>

On Fri, 14 Jun 2024 21:57:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding more tests for value classes javadoc and javax.lang.model

This pull request has now been integrated.

Changeset: 98c1eaa5
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/98c1eaa5949e38894dfea4950cfea4d1a9ffeea4
Stats:     41 lines in 2 files changed: 40 ins; 0 del; 1 mod

8334321: [lworld] add more javadoc and javax.lang.model tests for value classes

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

PR: https://git.openjdk.org/valhalla/pull/1134

From vromero at openjdk.org  Sat Jun 15 20:24:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Jun 2024 20:24:37 GMT
Subject: [lworld] Integrated: 8334313: [lworld] only concrete value classes
 should be listed in the LoadableDescriptors attribute
Message-ID: <ruFWLDcfGCzG_8xCLWj-6bMOSUpWFJTXvHFb-C3zAtA=.b0b2f1cd-1b19-4112-b826-b1a8141af432@github.com>

do not add abstract value classes to the LoadableDescriptors attribute

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

Commit messages:
 - 8334313: [lworld] only concrete value classes should be listed in the LoadableDescriptors attribute

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

PR: https://git.openjdk.org/valhalla/pull/1135

From vromero at openjdk.org  Sat Jun 15 20:24:37 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Jun 2024 20:24:37 GMT
Subject: [lworld] Integrated: 8334313: [lworld] only concrete value classes
 should be listed in the LoadableDescriptors attribute
In-Reply-To: <ruFWLDcfGCzG_8xCLWj-6bMOSUpWFJTXvHFb-C3zAtA=.b0b2f1cd-1b19-4112-b826-b1a8141af432@github.com>
References: <ruFWLDcfGCzG_8xCLWj-6bMOSUpWFJTXvHFb-C3zAtA=.b0b2f1cd-1b19-4112-b826-b1a8141af432@github.com>
Message-ID: <HqPhGHllzCSn6gakgh4A3UJoN8EipqOclSSWxOibauc=.bc6015db-c7d9-4812-9204-a64cd48a779d@github.com>

On Sat, 15 Jun 2024 20:20:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> do not add abstract value classes to the LoadableDescriptors attribute

This pull request has now been integrated.

Changeset: 6935ee4b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6935ee4b01c1ec0b7ef869bd3c4e419c77d4c478
Stats:     26 lines in 4 files changed: 5 ins; 0 del; 21 mod

8334313: [lworld] only concrete value classes should be listed in the LoadableDescriptors attribute

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

PR: https://git.openjdk.org/valhalla/pull/1135

From vromero at openjdk.org  Sat Jun 15 21:54:40 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Jun 2024 21:54:40 GMT
Subject: [lworld] Integrated: 8334334: [lworld] more test coverage for value
 classes
Message-ID: <K7Y8GCsZWN6npFJ-bLD-FJzSjNLsg4Kp39l-Rj5Xol4=.bdb9ffcb-948c-4bb3-be43-ed98b687e5d2@github.com>

adding a reflection test for value classes

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

Commit messages:
 - 8334334: [lworld] more test coverage for value classes

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

PR: https://git.openjdk.org/valhalla/pull/1136

From vromero at openjdk.org  Sat Jun 15 21:54:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Jun 2024 21:54:41 GMT
Subject: [lworld] Integrated: 8334334: [lworld] more test coverage for value
 classes
In-Reply-To: <K7Y8GCsZWN6npFJ-bLD-FJzSjNLsg4Kp39l-Rj5Xol4=.bdb9ffcb-948c-4bb3-be43-ed98b687e5d2@github.com>
References: <K7Y8GCsZWN6npFJ-bLD-FJzSjNLsg4Kp39l-Rj5Xol4=.bdb9ffcb-948c-4bb3-be43-ed98b687e5d2@github.com>
Message-ID: <yBkXmmzrJh6YqG0lc24ysAbDxVvPamT7RsAC-1LYpEU=.7c74a51a-2de4-4dad-8e41-1e8c82668dce@github.com>

On Sat, 15 Jun 2024 21:49:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding a reflection test for value classes

This pull request has now been integrated.

Changeset: 66dd65a7
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/66dd65a7f6d237ef197f71023f2f5af508b72d6c
Stats:     117 lines in 2 files changed: 116 ins; 0 del; 1 mod

8334334: [lworld] more test coverage for value classes

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

PR: https://git.openjdk.org/valhalla/pull/1136

From vromero at openjdk.org  Sat Jun 15 23:58:46 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Jun 2024 23:58:46 GMT
Subject: [lworld] Integrated: 8334336: [lworld] map locationToFlags in
 j.l.r.AccessFlag is being added value classes related flags even if preview
 features are not enabled
Message-ID: <9okXFllMq5ba-fQTh_mMDivTCSYO4y1NLM-AhucdrNM=.ea3ebdbf-49b7-4969-b203-8a69abc57d3c@github.com>

some valhalla related access flags were being added to AccessFlags::locationToFlags without checking if preview features were enabled or not

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

Commit messages:
 - 8334336: [lworld] map locationToFlags in j.l.r.AccessFlag is being added value classes related flags even if preview features are not enabled

Changes: https://git.openjdk.org/valhalla/pull/1137/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334336
  Stats: 25 lines in 3 files changed: 16 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1137.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1137/head:pull/1137

PR: https://git.openjdk.org/valhalla/pull/1137

From vromero at openjdk.org  Sat Jun 15 23:58:46 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Jun 2024 23:58:46 GMT
Subject: [lworld] Integrated: 8334336: [lworld] map locationToFlags in
 j.l.r.AccessFlag is being added value classes related flags even if preview
 features are not enabled
In-Reply-To: <9okXFllMq5ba-fQTh_mMDivTCSYO4y1NLM-AhucdrNM=.ea3ebdbf-49b7-4969-b203-8a69abc57d3c@github.com>
References: <9okXFllMq5ba-fQTh_mMDivTCSYO4y1NLM-AhucdrNM=.ea3ebdbf-49b7-4969-b203-8a69abc57d3c@github.com>
Message-ID: <x1TUKapNS2X_o-oNJK1CF3tnxo8aEnoXzu9QiSKDg2U=.8d02aaa6-4ac4-4dd5-8fc2-35de45965912@github.com>

On Sat, 15 Jun 2024 23:52:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> some valhalla related access flags were being added to AccessFlags::locationToFlags without checking if preview features were enabled or not

This pull request has now been integrated.

Changeset: 47ba18aa
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/47ba18aae1a219abc1631776872414cf30ed5f38
Stats:     25 lines in 3 files changed: 16 ins; 3 del; 6 mod

8334336: [lworld] map locationToFlags in j.l.r.AccessFlag is being added value classes related flags even if preview features are not enabled

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

PR: https://git.openjdk.org/valhalla/pull/1137

From vromero at openjdk.org  Mon Jun 17 00:29:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Jun 2024 00:29:32 GMT
Subject: [lworld] Integrated: 8334345: [lworld] fix for JDK-8334336 introduced
 a regression
Message-ID: <NKYOmMXTWuVwgWoDfLQXJZBg79dIRKnMBKCDCJ4WIns=.e0e2b550-a917-4ca4-9385-2d4e359013cd@github.com>

fixing regression introduced by JDK-8334336

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

Commit messages:
 - 8334345: [lworld] fix for JDK-8334336 introduced a regression

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

PR: https://git.openjdk.org/valhalla/pull/1138

From vromero at openjdk.org  Mon Jun 17 00:29:32 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Jun 2024 00:29:32 GMT
Subject: [lworld] Integrated: 8334345: [lworld] fix for JDK-8334336 introduced
 a regression
In-Reply-To: <NKYOmMXTWuVwgWoDfLQXJZBg79dIRKnMBKCDCJ4WIns=.e0e2b550-a917-4ca4-9385-2d4e359013cd@github.com>
References: <NKYOmMXTWuVwgWoDfLQXJZBg79dIRKnMBKCDCJ4WIns=.e0e2b550-a917-4ca4-9385-2d4e359013cd@github.com>
Message-ID: <SfFchlT31_FQJu8GxurpHyfmJbaob1spudDckQpfGO4=.ce81dc7f-4067-4385-a9d6-f4b099bef3a5@github.com>

On Mon, 17 Jun 2024 00:25:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing regression introduced by JDK-8334336

This pull request has now been integrated.

Changeset: 25923048
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/259230489b05492456e26130e3e701c5bd7d91db
Stats:     9 lines in 2 files changed: 0 ins; 8 del; 1 mod

8334345: [lworld] fix for JDK-8334336 introduced a regression

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

PR: https://git.openjdk.org/valhalla/pull/1138

From dholmes at openjdk.org  Mon Jun 17 04:40:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Jun 2024 04:40:24 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <rHhJx3bV_D8KLLJm3X9DfvMAALn78jEPMmtf1Gu3pmY=.77a0869f-bc27-4019-a87a-1e2eb45138bd@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
 <rHhJx3bV_D8KLLJm3X9DfvMAALn78jEPMmtf1Gu3pmY=.77a0869f-bc27-4019-a87a-1e2eb45138bd@github.com>
Message-ID: <nd4mL4KmofpLn0zCPq3ezfOPIWoQaZHv2kM5mEC0nnw=.f9a989e9-046e-452d-ab40-77bce65f555e@github.com>

On Fri, 14 Jun 2024 17:45:18 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
>> 
>> Changes:
>> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
>> - added the necessary checks for strict fields to the verifier and added some tests
>> - added missing class modifier checks for value classes in the classfile parse
>> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
>> - updated existing tests to  support the above
>> 
>> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's
>
> Looks good to me.

Thanks for the review @fparain !

Do I need further reviews?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1109#issuecomment-2172222239

From chagedorn at openjdk.org  Mon Jun 17 07:19:55 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 17 Jun 2024 07:19:55 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check [v2]
In-Reply-To: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
Message-ID: <Arx7yC-6XCs9omIuQJtXlS_n5QYcXqRI2BKbxAlYmEg=.daf11e96-e8c4-4ee5-9b25-f2fcf5432494@github.com>

> #### Speculative Inline Type Checks for `aaload`
> 
> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
> 
> #### Known Problem when Load is Disconnected from Range Check
> 
> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
> 
> #### How this Problem Manifests in Valhalla
> 
> In the test case, the very same is happening:
> 
> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
> 
>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
> 
> I've additionally done some refactoring and added some comments which helped me to better understand the code.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:

 - Update comments
 - Apply suggestions from code review
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1127/files
  - new: https://git.openjdk.org/valhalla/pull/1127/files/324ba13f..3357f826

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1127&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1127&range=00-01

  Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1127.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1127/head:pull/1127

PR: https://git.openjdk.org/valhalla/pull/1127

From dsimms at openjdk.org  Mon Jun 17 07:55:30 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 17 Jun 2024 07:55:30 GMT
Subject: [lworld] RFR: 8332243: Value classes implementing Cloneable
In-Reply-To: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
References: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
Message-ID: <Lrd_XPybCCHIEX--knWx2Vy43W2RdcUnEsFDS7m-tuc=.c81378cc-efe3-4e65-8687-8d2c740ec62a@github.com>

On Fri, 14 Jun 2024 18:00:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Allow value classes to implement the Cloneable interface.

A tiny spelling thing, but LGTM

src/hotspot/share/prims/jvm.cpp line 731:

> 729:   if (klass->is_inline_klass()) {
> 730:     // Value instances have no identity, so return the current instance instead of allocating a new one
> 731:     // Value classes cannot have finalizers, so the method can return immediately

Nice

test/hotspot/jtreg/runtime/valhalla/inlinetypes/TestCloneableValue.java line 51:

> 49:       @Override
> 50:       public Object clone() throws CloneNotSupportedException {
> 51:         return super.clone(); // deleguate to Object's method performing a shallow copy

"delegate"

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1131#pullrequestreview-2122140407
PR Review Comment: https://git.openjdk.org/valhalla/pull/1131#discussion_r1642346392
PR Review Comment: https://git.openjdk.org/valhalla/pull/1131#discussion_r1642348640

From bkilambi at openjdk.org  Mon Jun 17 08:49:28 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 17 Jun 2024 08:49:28 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v12]
In-Reply-To: <DMhWumsiMoN3G8K2tHSjHEf_-Pn3uKAm_lmLRXBXTJs=.107b1da0-eafc-41fa-b1b0-0d9b5e8396a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>
 <Z8dBv_xh29_sc5o6IrMReWmVYPNRqXgxGdtgQkBRwqk=.25c0ec81-b0cf-4d3f-b47c-0289acdeaa4b@github.com>
 <DMhWumsiMoN3G8K2tHSjHEf_-Pn3uKAm_lmLRXBXTJs=.107b1da0-eafc-41fa-b1b0-0d9b5e8396a2@github.com>
Message-ID: <9mTvcnav6x46janFExBHlMy_cixmnq2vIOAAIUZsST8=.a420c943-5f5c-4670-b138-2fbaf373c374@github.com>

On Fri, 14 Jun 2024 16:44:04 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Float16.java line 736:
>> 
>>> 734:      */
>>> 735:     // @IntrinsicCandidate
>>> 736:     public static Float16 add(Float16 addend, Float16 augend) {
>> 
>> Hi, thanks for implementing these operations for Float16. May I ask why do we have both `Float16 sum()` and `Float16 add()`? Also, both seem to be marked as `@IntrinsicsCandidate`.
>
>> Hi, thanks for implementing these operations for Float16. May I ask why do we have both `Float16 sum()` and `Float16 add()`? Also, both seem to be marked as `@IntrinsicsCandidate`.
> 
> Hello @Bhavana-Kilambi ,
> The Float16 class already had a sum method before I started my work, so I left it in place. I assume "sum" was added in analogy to the the sum method added to Float and Double in the context of the stream work done in JDK 8.
> 
> For the purpose of including support for methods to perform the addition, subtraction, multiplication, and division operation, I think "add" is a better name than "sum".
> 
> I don't have any appreciable experience changing HotSpot, so I was going to leave that aspect of this work to others. The build fails if the `@IntrinsicCandidate` annotation is applied to methods without the possibility of a matching candidate in HotSpot. Therefore, I left a commented out form of the annotation on methods I assumed would be eligible for such support, but those were just my guesses and should be updated for what the actual intrinsic support could be.

Ok, got it. Thank you for the detailed response.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1642438023

From bkilambi at openjdk.org  Mon Jun 17 09:02:30 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 17 Jun 2024 09:02:30 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v12]
In-Reply-To: <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <X64YuyanSm5SCN91D-kWW-jAnNhrLADBofY-ZMaHDLg=.3cbba954-5e5a-417f-828b-5bee5cd61c6c@github.com>
Message-ID: <e0TmAKstZuxZSvXrVxWEHQlsH1Y41Z1ZMhNDF_lVqIc=.35d288fd-5547-4f5b-84fb-3c36c5da44fe@github.com>

On Fri, 14 Jun 2024 05:08:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor code, refine spec, add tests.

test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java line 33:

> 31: */
> 32: 
> 33: package compiler.vectorization;

I am not able to add comments to the lines above this line. I see "-XDenablePrimitiveClasses" flag on line #29 which I think is obsolete after the latest merge. If this test passes for you then you can leave this unchanged. I can change this line in my next PR. Thanks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1117#discussion_r1642457121

From thartmann at openjdk.org  Mon Jun 17 09:12:27 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 17 Jun 2024 09:12:27 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check [v2]
In-Reply-To: <Arx7yC-6XCs9omIuQJtXlS_n5QYcXqRI2BKbxAlYmEg=.daf11e96-e8c4-4ee5-9b25-f2fcf5432494@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
 <Arx7yC-6XCs9omIuQJtXlS_n5QYcXqRI2BKbxAlYmEg=.daf11e96-e8c4-4ee5-9b25-f2fcf5432494@github.com>
Message-ID: <TvEUtIbLtuBCfl3t5MoFN52u0azeBXsAwbgP6fhqn2E=.aa04c02c-7d54-440a-badd-1f0421de0115@github.com>

On Mon, 17 Jun 2024 07:19:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> #### Speculative Inline Type Checks for `aaload`
>> 
>> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
>> 
>> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
>> 
>> #### Known Problem when Load is Disconnected from Range Check
>> 
>> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
>> 
>> #### How this Problem Manifests in Valhalla
>> 
>> In the test case, the very same is happening:
>> 
>> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
>> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
>> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
>> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
>> 
>>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
>> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
>> 
>> I've additionally done some refactoring and added some comments which helped me to better understand the code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update comments
>  - Apply suggestions from code review
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Looks good, thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1127#pullrequestreview-2122343528

From fparain at openjdk.org  Mon Jun 17 12:26:40 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 17 Jun 2024 12:26:40 GMT
Subject: [lworld] RFR: 8332243: Value classes implementing Cloneable [v2]
In-Reply-To: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
References: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
Message-ID: <3kluDSrhy_B_AnNYi8LuJABh6TclYwbWnN_ceNEIWrE=.5f591b6f-a9bb-4460-b297-85ade98ffdd8@github.com>

> Allow value classes to implement the Cloneable interface.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1131/files
  - new: https://git.openjdk.org/valhalla/pull/1131/files/55798abe..f620623a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1131&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1131&range=00-01

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

PR: https://git.openjdk.org/valhalla/pull/1131

From fparain at openjdk.org  Mon Jun 17 12:26:40 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 17 Jun 2024 12:26:40 GMT
Subject: [lworld] RFR: 8332243: Value classes implementing Cloneable
In-Reply-To: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
References: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
Message-ID: <LjFQy45EordBa5Izk1roL65sdrQ5HZHY6ksjbLG_bLc=.a43e3033-7d45-42ae-90f5-ba5ca1ec37df@github.com>

On Fri, 14 Jun 2024 18:00:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Allow value classes to implement the Cloneable interface.

Thank you for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1131#issuecomment-2173255837

From fparain at openjdk.org  Mon Jun 17 12:26:40 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 17 Jun 2024 12:26:40 GMT
Subject: [lworld] RFR: 8332243: Value classes implementing Cloneable [v2]
In-Reply-To: <Lrd_XPybCCHIEX--knWx2Vy43W2RdcUnEsFDS7m-tuc=.c81378cc-efe3-4e65-8687-8d2c740ec62a@github.com>
References: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
 <Lrd_XPybCCHIEX--knWx2Vy43W2RdcUnEsFDS7m-tuc=.c81378cc-efe3-4e65-8687-8d2c740ec62a@github.com>
Message-ID: <B8mhr3GSOcBeKyax8_CKdlq0LN9FBPyzHbDZFjVd_hs=.b8592e29-dcb9-4c3b-86b4-97aab9f509ec@github.com>

On Mon, 17 Jun 2024 07:49:17 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/TestCloneableValue.java line 51:
> 
>> 49:       @Override
>> 50:       public Object clone() throws CloneNotSupportedException {
>> 51:         return super.clone(); // deleguate to Object's method performing a shallow copy
> 
> "delegate"

Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1131#discussion_r1642730524

From fparain at openjdk.org  Mon Jun 17 12:26:41 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 17 Jun 2024 12:26:41 GMT
Subject: [lworld] Integrated: 8332243: Value classes implementing Cloneable
In-Reply-To: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
References: <_dmnYBzCmE1nNRRM8D8h3DxkdDaOrPvow9kqOcfgPCA=.b9f473c8-a5ce-41a4-b2a8-fc602c6bb699@github.com>
Message-ID: <F_tnfd6LjC52mZCLXoa6-Imh7KI4kD01o8A2xKn_9Xc=.987466af-bfc3-4346-aef6-14d972d01011@github.com>

On Fri, 14 Jun 2024 18:00:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Allow value classes to implement the Cloneable interface.

This pull request has now been integrated.

Changeset: db494c6d
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/db494c6d0cd16d55bdf464d70e35dcac95abf593
Stats:     127 lines in 4 files changed: 97 ins; 30 del; 0 mod

8332243: Value classes implementing Cloneable

Reviewed-by: dsimms

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

PR: https://git.openjdk.org/valhalla/pull/1131

From heidinga at openjdk.org  Mon Jun 17 13:29:24 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 17 Jun 2024 13:29:24 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
Message-ID: <5g1LBbCUhXnZqRaKFCYfEUTpUI1FUf2liNg0udQ1uVE=.eedde6d5-aaea-49b2-a112-eda79ba92860@github.com>

On Fri, 24 May 2024 05:07:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
> 
> Changes:
> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
> - added the necessary checks for strict fields to the verifier and added some tests
> - added missing class modifier checks for value classes in the classfile parse
> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
> - updated existing tests to  support the above
> 
> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

All my concerns were addressed.  Looks good

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1109#pullrequestreview-2122911222

From vromero at openjdk.org  Mon Jun 17 17:06:55 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Jun 2024 17:06:55 GMT
Subject: [lworld] Integrated: 8334340: [lworld] javac code clean-up
Message-ID: <8VjiekqxsxwM43KLzyEGNqsk4oW4RQnUyrpQE2TfkSI=.2f8ee2a9-9363-4819-80a4-d0b5c86004fa@github.com>

remove old code and unnecessary differences with jdk/master

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

Commit messages:
 - removing more diffs
 - Merge branch 'lworld' into JDK-8334340
 - 8334340: [lworld] javac code clean-up

Changes: https://git.openjdk.org/valhalla/pull/1139/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1139&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334340
  Stats: 33 lines in 10 files changed: 8 ins; 15 del; 10 mod
  Patch: https://git.openjdk.org/valhalla/pull/1139.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1139/head:pull/1139

PR: https://git.openjdk.org/valhalla/pull/1139

From vromero at openjdk.org  Mon Jun 17 17:06:56 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Jun 2024 17:06:56 GMT
Subject: [lworld] Integrated: 8334340: [lworld] javac code clean-up
In-Reply-To: <8VjiekqxsxwM43KLzyEGNqsk4oW4RQnUyrpQE2TfkSI=.2f8ee2a9-9363-4819-80a4-d0b5c86004fa@github.com>
References: <8VjiekqxsxwM43KLzyEGNqsk4oW4RQnUyrpQE2TfkSI=.2f8ee2a9-9363-4819-80a4-d0b5c86004fa@github.com>
Message-ID: <YnVcg7IEPswv4P46DN4zP0pPnX8-kvrVx9z3luGnhYI=.0f2bff4e-9564-48e3-936b-5f12e3e61510@github.com>

On Mon, 17 Jun 2024 16:59:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> remove old code and unnecessary differences with jdk/master

This pull request has now been integrated.

Changeset: 25d0359f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/25d0359ff06d3753d32dde6f8604f17064d3c642
Stats:     33 lines in 10 files changed: 8 ins; 15 del; 10 mod

8334340: [lworld] javac code clean-up

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

PR: https://git.openjdk.org/valhalla/pull/1139

From darcy at openjdk.org  Mon Jun 17 17:13:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jun 2024 17:13:56 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v13]
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>

> Sketch of a more full-featured API for Float16.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Improve tests.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1117/files
  - new: https://git.openjdk.org/valhalla/pull/1117/files/553b9325..73f6d864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=12
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1117&range=11-12

  Stats: 196 lines in 2 files changed: 168 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/valhalla/pull/1117.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1117/head:pull/1117

PR: https://git.openjdk.org/valhalla/pull/1117

From brian.goetz at oracle.com  Mon Jun 17 18:00:50 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 17 Jun 2024 14:00:50 -0400
Subject: Null restriction on interface typed fields
In-Reply-To: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>

Yes, the eventual plan is that all references can be null-restricted.? 
We've been struggling with a specific problem, though, which is that for 
a reference type like `String!` or `Runnable!`, the VM is going to 
initialize such variables with .. null.? This is obviously a safety 
problem, because we've put a value in a variable that is not provably 
within the value set of the variable's type.? It was for this reason 
that earlier discussion focused on nullity control for (implicitly 
constructible) values first, and other types later.

Since then, we've figured out that we can solve this problem with better 
flow analysis.? Just like the DA analysis done by the compiler, the VM 
can do a similar analysis during verification time of fields that the 
compiler marks as "must be written before they are read" (where any 
this-escape might lead to reading those fields.)? This goes under the 
name of "strict fields", and we should be writing more about this soon.

Once we have this tool in our kit, the limitations on what types can be 
null-restricted -- and the safety with which we can enforce this -- will 
be greatly broadened.

On 6/9/2024 5:04 AM, Chen Liang wrote:
> Hello valhalla community,
> In our current iteration of valhalla, we only support null restriction 
> on value fields, as for references, null is a valid default value. 
> Meanwhile, interfaces are not restricted to be value or identity, yet 
> some value classes will only be represented via interfaces, most 
> notably Map.entry().
>
> In addition, consider this scenario in the ClassFile API: we have 
> ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>) and 
> withMethodBody(xxx,?Consumer<CodeBuilder>). A straightforward 
> implementation of withMethodBody would be withMethod(xxx, new 
> WithCode(cbConsumer)), where WithCode is (value) record 
> WithCode(Consumer<CodeBuilder> build) implements 
> Consumer<MethodBuilder>...
> In this WithCode record, we can see that we are interested in 
> declaring "build" null-restricted; if build is a value lambda that 
> simply captures context variables, then WithCode can be inlined to the 
> same captures should "build" be NR, without concerns about 
> representing a null build value in the inlined form.
>
> Another example is in Algebraic types:
> sealed interface Operation permits O1, O2, ...
> Record O1(Interface1 xxx)
> Record O2(Interface2 xxx)
> For value-based Interface1 and Interface2 values, we might seek to NR 
> the fields so the record representations can be simpler.
>
> Thus, I recommend considering support for NR on interface fields in 
> addition to on explicit value type fields. Though this might lead down 
> to the rabbit hole of "heap pollution of null on reference pointers", 
> I still believe its benefit outweighs its cost, especially in cases 
> where these values can be restricted on the stack in escape analysis, 
> as in most functional APIs (function only invoked conditionally, 
> function objects not stored when method exits).
>
> Chen Liang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240617/ef86bf0b/attachment.htm>

From chen.l.liang at oracle.com  Mon Jun 17 19:16:27 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 17 Jun 2024 19:16:27 +0000
Subject: Null restriction on interface typed fields
In-Reply-To: <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>
References: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>
Message-ID: <CH3PR10MB76770B2B79E432B522F29B91A2CD2@CH3PR10MB7677.namprd10.prod.outlook.com>

Indeed, another feature about the strict fields is their strong encapsulation against reflective setters; another safeguard against representable invalid values and their friendliness toward constant folding. John Rose's chart here seems up-to-date: objects-reloaded (openjdk.org)<https://cr.openjdk.org/~jrose/values/objects-reloaded.pdf> (This strictness can also benefit the upcoming Stable Values JEP)

Also for readers' convenience, I think this is the earliest and most comprehensive document about the strict field designs, seems still accurate for the most part: Cleanup on aisle zero: Constructive classes (openjdk.org)<https://cr.openjdk.org/~jrose/jls/constructive-classes.html>

- Chen
________________________________
From: Brian Goetz <brian.goetz at oracle.com>
Sent: Monday, June 17, 2024 1:00 PM
To: Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: Re: Null restriction on interface typed fields

Yes, the eventual plan is that all references can be null-restricted.  We've been struggling with a specific problem, though, which is that for a reference type like `String!` or `Runnable!`, the VM is going to initialize such variables with .. null.  This is obviously a safety problem, because we've put a value in a variable that is not provably within the value set of the variable's type.  It was for this reason that earlier discussion focused on nullity control for (implicitly constructible) values first, and other types later.

Since then, we've figured out that we can solve this problem with better flow analysis.  Just like the DA analysis done by the compiler, the VM can do a similar analysis during verification time of fields that the compiler marks as "must be written before they are read" (where any this-escape might lead to reading those fields.)  This goes under the name of "strict fields", and we should be writing more about this soon.

Once we have this tool in our kit, the limitations on what types can be null-restricted -- and the safety with which we can enforce this -- will be greatly broadened.

On 6/9/2024 5:04 AM, Chen Liang wrote:
Hello valhalla community,
In our current iteration of valhalla, we only support null restriction on value fields, as for references, null is a valid default value. Meanwhile, interfaces are not restricted to be value or identity, yet some value classes will only be represented via interfaces, most notably Map.entry().

In addition, consider this scenario in the ClassFile API: we have ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>) and withMethodBody(xxx, Consumer<CodeBuilder>). A straightforward implementation of withMethodBody would be withMethod(xxx, new WithCode(cbConsumer)), where WithCode is (value) record WithCode(Consumer<CodeBuilder> build) implements Consumer<MethodBuilder>...
In this WithCode record, we can see that we are interested in declaring "build" null-restricted; if build is a value lambda that simply captures context variables, then WithCode can be inlined to the same captures should "build" be NR, without concerns about representing a null build value in the inlined form.

Another example is in Algebraic types:
sealed interface Operation permits O1, O2, ...
Record O1(Interface1 xxx)
Record O2(Interface2 xxx)
For value-based Interface1 and Interface2 values, we might seek to NR the fields so the record representations can be simpler.

Thus, I recommend considering support for NR on interface fields in addition to on explicit value type fields. Though this might lead down to the rabbit hole of "heap pollution of null on reference pointers", I still believe its benefit outweighs its cost, especially in cases where these values can be restricted on the stack in escape analysis, as in most functional APIs (function only invoked conditionally, function objects not stored when method exits).

Chen Liang


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240617/e953184b/attachment-0001.htm>

From roger.riggs at oracle.com  Mon Jun 17 19:48:08 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 17 Jun 2024 15:48:08 -0400
Subject: CFV: New Valhalla Committer: Christian Hagedorn
In-Reply-To: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
References: <fadf4e98-642a-4147-9682-4a484bf1ed7c@oracle.com>
Message-ID: <578593d5-40cb-4490-a748-1af7acedb7ec@oracle.com>

Vote: yes

On 6/14/24 8:24 AM, Tobias Hartmann wrote:
> I hereby nominate Christian Hagedorn [1] to Valhalla Committer.


From darcy at openjdk.org  Mon Jun 17 20:17:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jun 2024 20:17:31 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]
In-Reply-To: <hz3rXEjl5unIscCZfTEhlqqaSRXxDF_9T6iajI4aMOc=.035d02a2-7b83-4267-bdcd-e0357db8c574@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <Ijin0tRdRm4ON4tMyZEeYwMCYEevbiP6gs8vywNAZeQ=.1c9a1b6e-cf61-4d1b-8bfb-e3f9e78701da@github.com>
 <86B-uyclFBrvwfP3mRCVSM6wk7tXZXZ5qc_4Vyzwt9U=.306329cb-81fe-4493-a07c-93ac900ecb4c@github.com>
 <_ozn7Js1eRDtdyLtvzCKu_cjtfleoCM0ld8p02oc_jw=.e3d33144-cfa9-44f9-8b2d-1d684ab608f7@github.com>
 <IejSEGh_XZxAjcQiH-o_YJClCFYiTAJT_cRpLrUzRb4=.3258692e-e6ca-4250-823e-d6d4e822988c@github.com>
 <QTqklzl8dmF_ldRa0ZWfGkJEIq05ZF9DRPayzliEcmw=.a71300c2-893b-4a8c-ac1e-9397e20e6c53@github.com>
 <hz3rXEjl5unIscCZfTEhlqqaSRXxDF_9T6iajI4aMOc=.035d02a2-7b83-4267-bdcd-e0357db8c574@github.com>
Message-ID: <E-nK8_ErI4bP-V_1PinPlKqvZ5MrZ2-kBydcNCMuMl0=.648e7392-f6a6-4b3a-8fdc-323fc0706b10@github.com>

On Fri, 14 Jun 2024 06:19:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
>>> 
>>> Kindly fix and integrate.
>> 
>> Thanks; let me take a pass at writing at least some basic regression tests before pushing.
>> 
>> @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)
>
>> > > Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
>> > > Kindly fix and integrate.
>> > 
>> > 
>> > Thanks; let me take a pass at writing at least some basic regression tests before pushing.
>> > @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)
>> 
>> Hi @jddarcy , As per specification of [Math.fma(float, float, float)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2494) internal computation of constituent operation (mul and add) should be done at infinite precision and only final result should be rounded, we are now upcasting float16 to double but it will not prevent rounding happening for mul and add.
> 
> Right; the fma needs to operate as-if it used infinite precision internally. This could be implemented (slowly) using JDK classes by implementing a BigDecimal -> Float16 conversion after doing a*b+c in BigDeicmal. I've been considering adding BigDecimal -> Float16 conversion anyway for completeness in the platform.
> 
> My understanding of how fma is implemented in hardware is that for a format with P bits of precision, there is a ~2P wide internal register to hold the exact product as an intermediate result. Then the value being adding in can be aligned at the right exponent location and the final rounding back to P bits of precision can occur, with logic of any sticky bit for rounding to nearest even, etc.
> 
> There are many cases where double (P = 53) will exactly hold the product and sum of three Float16 (P = 11) operands.  However, the product can be so large or so small that rounding  occurs when the third operand is added in.
> 
> I haven't worked through if the potential round-offs are all benign with the final rounding to Float16 or if some corrective action would need to be taken to get the effect of a sticky bit. For example, if a*b is so large that the highest exponent position set is more than 53 positions away from the lowest exponent position set on ...

> > > > Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> > > > Kindly fix and integrate.
> > > 
> > > 
> > > Thanks; let me take a pass at writing at least some basic regression tests before pushing.
> > > @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)
> > 
> > 
> > Hi @jddarcy , As per specification of [Math.fma(float, float, float)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2494) internal computation of constituent operation (mul and add) should be done at infinite precision and only final result should be rounded, we are now upcasting float16 to double but it will not prevent rounding happening for mul and add.
> 
> Right; the fma needs to operate as-if it used infinite precision internally. This could be implemented (slowly) using JDK classes by implementing a BigDecimal -> Float16 conversion after doing a*b+c in BigDeicmal. I've been considering adding BigDecimal -> Float16 conversion anyway for completeness in the platform.
> 
> My understanding of how fma is implemented in hardware is that for a format with P bits of precision, there is a ~2P wide internal register to hold the exact product as an intermediate result. Then the value being adding in can be aligned at the right exponent location and the final rounding back to P bits of precision can occur, with logic of any sticky bit for rounding to nearest even, etc.
> 
> There are many cases where double (P = 53) will exactly hold the product and sum of three Float16 (P = 11) operands. However, the product can be so large or so small that rounding occurs when the third operand is added in.
> 
> I haven't worked through if the potential round-offs are all benign with the final rounding to Float16 or if some corrective action would need to be taken to get the effect of a sticky bit. For example, if a_b is so large that the highest exponent position set is more than 53 positions away from the lowest exponent position set on c, if the final result is going to overflow anyway, the round-off in computing a_b+c in double doesn't matter. It might be problematic if a*b is much smaller than c, but that is another case I haven't fully thought through yet.
> 
> I'll give an updated on my analysis/research on this fma issue by next week.

An update: promoting the three float16 fma operands to double and then computing (a*b) + c in double and rounding once at the end to Float16 works for (at least) most possible operands to a Float16 fma. It may work for all operands; I'm still working through those details.

To summarize my findings. if the product-sum held in double is exact, the single rounding to Float16 will compute the correct result.

Each Float16 operand is exactly convertible to double and the a*b product is exact since double has more than twice the precision of Float16. That leaves analyzing whether or not the product-sum is exact.

For Float16 values, the possible exponent bit positions that could be set range from 2^15 (from MAX_VALUE) to 2^(-24) (from MIN_VALUE). This entire exponent range of 15 - (-24) + 1 = 40 is less than the _precision_ of double, 53 bits.

When multiplying two Float16 values together, the exponent bit positions set in the exact product range over 2^31 (MAX_VALUE squared) to 2^(-48) (MIN_VALUE) squared.

If the exact product is larger than about 2^16, the final rounded result must overflow Float16. If the exact product has a highest exponent bit of 2^16, the product-sum will be exact since a double could hold a value as small as 2^(16 - 52) = 2^(-36), which is smaller than Float16.MIN_VALUE. Therefore, when the product has an exponent of 2^16 or larger, the end result is correct after conversion to Float16.

A similar argument holds when the product has an exponent in the normal range of Float16; any additional sum will be exact given the precision of double.

However, if the product is sufficiently small, it is possible the double will not be able to hold the exact value since the exponent range of 2^(-48) to 2^(15) is larger than double precision. However, for many operands, even if the product has underflowed, adding in many operands may be exact in practice. This exactness can be tested for using the 2sum algorithm (https://en.wikipedia.org/wiki/2Sum) for a zero trailing "t" component.

Fortunately in terms of computing the final answer and rounding complications, if c is the subnormal range of Float16 (exponent range 2^(-14) to 2(-24)), the product-sum will be exactly representable in double.

That leaves possibly non-exact product-sum with a combination of product in the subnormal range of Float16 and the c term to be added in being not-small. However, if this product-sum is non-exact, the smaller term from the product, with at most 22 exponent bit positions set, and the the 11 bits from c being summed in, must be separated by at least 53 - (22 + 11) = 20 bit positions otherwise the product-sum would fit in a double. I believe this implies at least one of the double-rounding scenarios cannot occur, in particular a half-way result in the smaller precision, Float16 in this case, rounding differently because sticky bit information from the higher precision was rounded away.

I'll keep working through the non-exact cases. Assuming a `Float16 valueOf(BigDecimal)` method is added, an "obviously right" approach would be to use a*b + c in double for all exact cases and failover to computing the exact result in BigDecimal and then rounding to that to Float16 for all the inexact cases.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2174342914

From briangoetz at openjdk.org  Mon Jun 17 20:22:21 2024
From: briangoetz at openjdk.org (Brian Goetz)
Date: Mon, 17 Jun 2024 20:22:21 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v13]
In-Reply-To: <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>
Message-ID: <oF0dWlsDK2swage-j56ETQddHPro6AhybCCOVWvXs5E=.5583692a-1fb9-42e7-b917-db8f2468a647@github.com>

On Mon, 17 Jun 2024 17:13:56 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Sketch of a more full-featured API for Float16.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve tests.

Why separate entry points for `add` and `sum`?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2174352401

From rotanolexandr842 at gmail.com  Mon Jun 17 20:56:12 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Mon, 17 Jun 2024 23:56:12 +0300
Subject: Null restriction on interface typed fields
In-Reply-To: <CH3PR10MB76770B2B79E432B522F29B91A2CD2@CH3PR10MB7677.namprd10.prod.outlook.com>
References: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>
 <CH3PR10MB76770B2B79E432B522F29B91A2CD2@CH3PR10MB7677.namprd10.prod.outlook.com>
Message-ID: <CAL5bRt_C4N375m+3Tvn25oDmajL3MBikM1Xinans3TDmVjW6jw@mail.gmail.com>

Sorry if I am missing out something, but if null-restricted type contains
null value (as vm initializes it), isn't the null value itself is a marker
of the fact that value hasn't been set yet?

As I understand, if you assert non-nullity of null able type or type of
unknown nullability with some sort of syntax (like ! in many languages),
when in fact the value is null, exception should be thrown, so vm already
obligated to perform null-check on this assignments. Same goes for
reflective set, which should be treated as unknown nullity in any condition
I guess unless vm could specialize instructions for the same method call
but different nullity of args (either way vm must check nullity of value in
at least part of the situations). This leads to a fact that if person even
somehow manages to sneak through compiler analysis and try to set null to
non-nullable field, it will immediately fail. Therefore, if value is null -
it is unset.

That said, does it in fact matter that VM initializes this fields with
null, if null bit (I guess that is how it stored), in fact is a marker of
whether field has been initialized or not? VM could just check if value of
field is null, and if so, throw an exception. Moreover, one way or another,
as you said, checks on value access must be performed. So is this analysis
really converges to "check if field is null", or there is more to it and I
miss it?

On Mon, Jun 17, 2024, 22:16 Chen Liang <chen.l.liang at oracle.com> wrote:

> Indeed, another feature about the strict fields is their strong
> encapsulation against reflective setters; another safeguard against
> representable invalid values and their friendliness toward constant
> folding. John Rose's chart here seems up-to-date: objects-reloaded
> (openjdk.org) <https://cr.openjdk.org/~jrose/values/objects-reloaded.pdf> (This
> strictness can also benefit the upcoming Stable Values JEP)
>
> Also for readers' convenience, I think this is the earliest and most
> comprehensive document about the strict field designs, seems still accurate
> for the most part: Cleanup on aisle zero: Constructive classes
> (openjdk.org)
> <https://cr.openjdk.org/~jrose/jls/constructive-classes.html>
>
> - Chen
> ------------------------------
> *From:* Brian Goetz <brian.goetz at oracle.com>
> *Sent:* Monday, June 17, 2024 1:00 PM
> *To:* Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <
> valhalla-dev at openjdk.org>
> *Subject:* Re: Null restriction on interface typed fields
>
> Yes, the eventual plan is that all references can be null-restricted.
> We've been struggling with a specific problem, though, which is that for a
> reference type like `String!` or `Runnable!`, the VM is going to initialize
> such variables with .. null.  This is obviously a safety problem, because
> we've put a value in a variable that is not provably within the value set
> of the variable's type.  It was for this reason that earlier discussion
> focused on nullity control for (implicitly constructible) values first, and
> other types later.
>
> Since then, we've figured out that we can solve this problem with better
> flow analysis.  Just like the DA analysis done by the compiler, the VM can
> do a similar analysis during verification time of fields that the compiler
> marks as "must be written before they are read" (where any this-escape
> might lead to reading those fields.)  This goes under the name of "strict
> fields", and we should be writing more about this soon.
>
> Once we have this tool in our kit, the limitations on what types can be
> null-restricted -- and the safety with which we can enforce this -- will be
> greatly broadened.
>
> On 6/9/2024 5:04 AM, Chen Liang wrote:
>
> Hello valhalla community,
> In our current iteration of valhalla, we only support null restriction on
> value fields, as for references, null is a valid default value. Meanwhile,
> interfaces are not restricted to be value or identity, yet some value
> classes will only be represented via interfaces, most notably Map.entry().
>
> In addition, consider this scenario in the ClassFile API: we have
> ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>) and
> withMethodBody(xxx, Consumer<CodeBuilder>). A straightforward
> implementation of withMethodBody would be withMethod(xxx, new
> WithCode(cbConsumer)), where WithCode is (value) record
> WithCode(Consumer<CodeBuilder> build) implements Consumer<MethodBuilder>...
> In this WithCode record, we can see that we are interested in declaring
> "build" null-restricted; if build is a value lambda that simply captures
> context variables, then WithCode can be inlined to the same captures should
> "build" be NR, without concerns about representing a null build value in
> the inlined form.
>
> Another example is in Algebraic types:
> sealed interface Operation permits O1, O2, ...
> Record O1(Interface1 xxx)
> Record O2(Interface2 xxx)
> For value-based Interface1 and Interface2 values, we might seek to NR the
> fields so the record representations can be simpler.
>
> Thus, I recommend considering support for NR on interface fields in
> addition to on explicit value type fields. Though this might lead down to
> the rabbit hole of "heap pollution of null on reference pointers", I still
> believe its benefit outweighs its cost, especially in cases where these
> values can be restricted on the stack in escape analysis, as in most
> functional APIs (function only invoked conditionally, function objects not
> stored when method exits).
>
> Chen Liang
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240617/b06a5d91/attachment.htm>

From brian.goetz at oracle.com  Mon Jun 17 21:05:43 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 17 Jun 2024 17:05:43 -0400
Subject: Null restriction on interface typed fields
In-Reply-To: <CAL5bRt_C4N375m+3Tvn25oDmajL3MBikM1Xinans3TDmVjW6jw@mail.gmail.com>
References: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>
 <CH3PR10MB76770B2B79E432B522F29B91A2CD2@CH3PR10MB7677.namprd10.prod.outlook.com>
 <CAL5bRt_C4N375m+3Tvn25oDmajL3MBikM1Xinans3TDmVjW6jw@mail.gmail.com>
Message-ID: <005876ea-c96f-4ae5-a1bd-3433ffcb2c65@oracle.com>

What you are describing is a possible, though less desirable, way to 
implement nullity control, one which could be described as "erased 
nullity".? That is, the language does its type checking (as it does with 
generics) and then throws out the nullity information (as it does with 
generics), potentially inserting checks where it wouldn't be able to 
trust the contents of the variable (as it does with generics).? But in 
the face of interference or separate compilation anomalies, these checks 
can fail.? It would obviously be better if we could achieve "bang means 
provably never null, ever", and that is what I was describing through 
the flow analysis I was alluding to. (Again, all of this will be the 
subject of more extended writeups, in due time.)

A good way to think about why this is important is not with null 
references, but with the physical zero of a value type.? There are going 
to be some value types for which the all-zero representation is not only 
not a good default, but not even a member of the value set of the class, 
such as:

 ??? value class IsTrue {
 ??????? private boolean isTrue;
 ??????? private boolean isFalse;

 ??????? IsTrue(boolean b) {
 ??????????? isTrue = b;
 ??????????? isFalse = !b;
 ??????? }

 ??????? boolean isSane() {
 ??????????? return isTrue || isFalse;
 ??????? }
 ??? }

If we reviewed this class, we would reasonably conclude that `isSane` is 
always true.? However, if we can somehow observe an `IsTrue!` before it 
is written, both booleans would be seen to be false, and the sanity 
check would not hold.? In the case of a null reference, dereferencing 
and maybe getting an NPE is "not so unsafe" because we stop before we 
use the invalid (null) value, but in the case of an uninitialized 
`IsTrue!`, something far worse has happened -- a value has escaped that 
was never created by a constructor, which we might actually use.

This is why we are pursuing strengthening DA analysis in the VM, so that 
such instances will provably never be observed.

On 6/17/2024 4:56 PM, Olexandr Rotan wrote:
>
> Sorry if I am missing out something, but if null-restricted type 
> contains null value (as vm initializes it), isn't the null value 
> itself is a marker of the fact that value hasn't been set yet?
>
> As I understand, if you assert non-nullity of null able type or type 
> of unknown nullability with some sort of syntax (like ! in many 
> languages), when in fact the value is null, exception should be 
> thrown, so vm already obligated to perform null-check on this 
> assignments. Same goes for reflective set, which should be treated as 
> unknown nullity in any condition I guess unless vm could specialize 
> instructions for the same method call but different nullity of args 
> (either way vm must check nullity of value in at least part of the 
> situations). This leads to a fact that if person even somehow manages 
> to sneak through compiler analysis and try to set null to non-nullable 
> field, it will immediately fail. Therefore, if value is null - it is 
> unset.
>
> That said, does it in fact matter that VM initializes this fields with 
> null, if null bit (I guess that is how it stored), in fact is a marker 
> of whether field has been initialized or not? VM could just check if 
> value of field is null, and if so, throw an exception. Moreover, one 
> way or another, as you said, checks on value access must be performed. 
> So is this analysis really converges to "check if field is null", or 
> there is more to it and I miss it?
>
>
> On Mon, Jun 17, 2024, 22:16 Chen Liang <chen.l.liang at oracle.com> wrote:
>
>     Indeed, another feature about the strict fields is their strong
>     encapsulation against reflective setters; another safeguard
>     against representable invalid values and their friendliness toward
>     constant folding. John Rose's chart here seems up-to-date:
>     objects-reloaded (openjdk.org)
>     <https://cr.openjdk.org/~jrose/values/objects-reloaded.pdf>?(This
>     strictness can also benefit the upcoming Stable Values JEP)
>
>     Also for readers' convenience, I think this is the earliest and
>     most comprehensive document about the strict field designs, seems
>     still accurate for the most part: Cleanup on aisle zero:
>     Constructive classes (openjdk.org)
>     <https://cr.openjdk.org/~jrose/jls/constructive-classes.html>
>
>     - Chen
>     ------------------------------------------------------------------------
>     *From:* Brian Goetz <brian.goetz at oracle.com>
>     *Sent:* Monday, June 17, 2024 1:00 PM
>     *To:* Chen Liang <chen.l.liang at oracle.com>;
>     valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
>     *Subject:* Re: Null restriction on interface typed fields
>     Yes, the eventual plan is that all references can be
>     null-restricted.? We've been struggling with a specific problem,
>     though, which is that for a reference type like `String!` or
>     `Runnable!`, the VM is going to initialize such variables with ..
>     null.? This is obviously a safety problem, because we've put a
>     value in a variable that is not provably within the value set of
>     the variable's type.? It was for this reason that earlier
>     discussion focused on nullity control for (implicitly
>     constructible) values first, and other types later.
>
>     Since then, we've figured out that we can solve this problem with
>     better flow analysis.? Just like the DA analysis done by the
>     compiler, the VM can do a similar analysis during verification
>     time of fields that the compiler marks as "must be written before
>     they are read" (where any this-escape might lead to reading those
>     fields.)? This goes under the name of "strict fields", and we
>     should be writing more about this soon.
>
>     Once we have this tool in our kit, the limitations on what types
>     can be null-restricted -- and the safety with which we can enforce
>     this -- will be greatly broadened.
>
>     On 6/9/2024 5:04 AM, Chen Liang wrote:
>>     Hello valhalla community,
>>     In our current iteration of valhalla, we only support null
>>     restriction on value fields, as for references, null is a valid
>>     default value. Meanwhile, interfaces are not restricted to be
>>     value or identity, yet some value classes will only be
>>     represented via interfaces, most notably Map.entry().
>>
>>     In addition, consider this scenario in the ClassFile API: we have
>>     ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>) and
>>     withMethodBody(xxx,?Consumer<CodeBuilder>). A straightforward
>>     implementation of withMethodBody would be withMethod(xxx, new
>>     WithCode(cbConsumer)), where WithCode is (value) record
>>     WithCode(Consumer<CodeBuilder> build) implements
>>     Consumer<MethodBuilder>...
>>     In this WithCode record, we can see that we are interested in
>>     declaring "build" null-restricted; if build is a value lambda
>>     that simply captures context variables, then WithCode can be
>>     inlined to the same captures should "build" be NR, without
>>     concerns about representing a null build value in the inlined form.
>>
>>     Another example is in Algebraic types:
>>     sealed interface Operation permits O1, O2, ...
>>     Record O1(Interface1 xxx)
>>     Record O2(Interface2 xxx)
>>     For value-based Interface1 and Interface2 values, we might seek
>>     to NR the fields so the record representations can be simpler.
>>
>>     Thus, I recommend considering support for NR on interface fields
>>     in addition to on explicit value type fields. Though this might
>>     lead down to the rabbit hole of "heap pollution of null on
>>     reference pointers", I still believe its benefit outweighs its
>>     cost, especially in cases where these values can be restricted on
>>     the stack in escape analysis, as in most functional APIs
>>     (function only invoked conditionally, function objects not stored
>>     when method exits).
>>
>>     Chen Liang
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240617/69bc7395/attachment-0001.htm>

From darcy at openjdk.org  Mon Jun 17 21:16:20 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 17 Jun 2024 21:16:20 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v13]
In-Reply-To: <oF0dWlsDK2swage-j56ETQddHPro6AhybCCOVWvXs5E=.5583692a-1fb9-42e7-b917-db8f2468a647@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>
 <oF0dWlsDK2swage-j56ETQddHPro6AhybCCOVWvXs5E=.5583692a-1fb9-42e7-b917-db8f2468a647@github.com>
Message-ID: <Qq2ovy3U62PmD6Hgfe3TU7QFT7KEUAn9a1HD6CRFmsU=.249fec38-2822-44a7-903a-c0b927771a5d@github.com>

On Mon, 17 Jun 2024 20:20:10 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

> Why separate entry points for `add` and `sum`?

See previous comment https://github.com/openjdk/valhalla/pull/1117#discussion_r1640103814

tl;dr for this stage of the work, I didn't want to disable the existing `sum` intrinsic, but I think an `add` method works better in a larger context where methods for subtraction, multiplication, and division are being added.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2174435109

From rotanolexandr842 at gmail.com  Mon Jun 17 21:19:45 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Tue, 18 Jun 2024 00:19:45 +0300
Subject: Null restriction on interface typed fields
In-Reply-To: <005876ea-c96f-4ae5-a1bd-3433ffcb2c65@oracle.com>
References: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>
 <CH3PR10MB76770B2B79E432B522F29B91A2CD2@CH3PR10MB7677.namprd10.prod.outlook.com>
 <CAL5bRt_C4N375m+3Tvn25oDmajL3MBikM1Xinans3TDmVjW6jw@mail.gmail.com>
 <005876ea-c96f-4ae5-a1bd-3433ffcb2c65@oracle.com>
Message-ID: <CAL5bRt_VeK02WtG3tFMa+_2uMUGQu1_SLE2Equs+bA8xzwG9ww@mail.gmail.com>

This makes sense, I didn't even think about primitives. Although, I might
not fully understand what is meant by "somehow observed"? Is it refers to
bypassing VM-provided access to a value such as reading memory using Arenas
and other low-level APIs? And if yes, how is it possible to even restrict
this access?

And also, it's a discovery that even if object value is null, it's
primitive fields are still initialized. Is it really how this works? If
not, they I guess I just missed the point here, because how can you
"observe" unexciting object?

On Tue, Jun 18, 2024, 00:05 Brian Goetz <brian.goetz at oracle.com> wrote:

> What you are describing is a possible, though less desirable, way to
> implement nullity control, one which could be described as "erased
> nullity".  That is, the language does its type checking (as it does with
> generics) and then throws out the nullity information (as it does with
> generics), potentially inserting checks where it wouldn't be able to trust
> the contents of the variable (as it does with generics).  But in the face
> of interference or separate compilation anomalies, these checks can fail.
> It would obviously be better if we could achieve "bang means provably never
> null, ever", and that is what I was describing through the flow analysis I
> was alluding to.  (Again, all of this will be the subject of more extended
> writeups, in due time.)
>
> A good way to think about why this is important is not with null
> references, but with the physical zero of a value type.  There are going to
> be some value types for which the all-zero representation is not only not a
> good default, but not even a member of the value set of the class, such as:
>
>     value class IsTrue {
>         private boolean isTrue;
>         private boolean isFalse;
>
>         IsTrue(boolean b) {
>             isTrue = b;
>             isFalse = !b;
>         }
>
>         boolean isSane() {
>             return isTrue || isFalse;
>         }
>     }
>
> If we reviewed this class, we would reasonably conclude that `isSane` is
> always true.  However, if we can somehow observe an `IsTrue!` before it is
> written, both booleans would be seen to be false, and the sanity check
> would not hold.  In the case of a null reference, dereferencing and maybe
> getting an NPE is "not so unsafe" because we stop before we use the invalid
> (null) value, but in the case of an uninitialized `IsTrue!`, something far
> worse has happened -- a value has escaped that was never created by a
> constructor, which we might actually use.
>
> This is why we are pursuing strengthening DA analysis in the VM, so that
> such instances will provably never be observed.
>
> On 6/17/2024 4:56 PM, Olexandr Rotan wrote:
>
> Sorry if I am missing out something, but if null-restricted type contains
> null value (as vm initializes it), isn't the null value itself is a marker
> of the fact that value hasn't been set yet?
>
> As I understand, if you assert non-nullity of null able type or type of
> unknown nullability with some sort of syntax (like ! in many languages),
> when in fact the value is null, exception should be thrown, so vm already
> obligated to perform null-check on this assignments. Same goes for
> reflective set, which should be treated as unknown nullity in any condition
> I guess unless vm could specialize instructions for the same method call
> but different nullity of args (either way vm must check nullity of value in
> at least part of the situations). This leads to a fact that if person even
> somehow manages to sneak through compiler analysis and try to set null to
> non-nullable field, it will immediately fail. Therefore, if value is null -
> it is unset.
>
> That said, does it in fact matter that VM initializes this fields with
> null, if null bit (I guess that is how it stored), in fact is a marker of
> whether field has been initialized or not? VM could just check if value of
> field is null, and if so, throw an exception. Moreover, one way or another,
> as you said, checks on value access must be performed. So is this analysis
> really converges to "check if field is null", or there is more to it and I
> miss it?
>
> On Mon, Jun 17, 2024, 22:16 Chen Liang <chen.l.liang at oracle.com> wrote:
>
>> Indeed, another feature about the strict fields is their strong
>> encapsulation against reflective setters; another safeguard against
>> representable invalid values and their friendliness toward constant
>> folding. John Rose's chart here seems up-to-date: objects-reloaded
>> (openjdk.org) <https://cr.openjdk.org/~jrose/values/objects-reloaded.pdf> (This
>> strictness can also benefit the upcoming Stable Values JEP)
>>
>> Also for readers' convenience, I think this is the earliest and most
>> comprehensive document about the strict field designs, seems still accurate
>> for the most part: Cleanup on aisle zero: Constructive classes
>> (openjdk.org)
>> <https://cr.openjdk.org/~jrose/jls/constructive-classes.html>
>>
>> - Chen
>> ------------------------------
>> *From:* Brian Goetz <brian.goetz at oracle.com>
>> *Sent:* Monday, June 17, 2024 1:00 PM
>> *To:* Chen Liang <chen.l.liang at oracle.com>; valhalla-dev at openjdk.org <
>> valhalla-dev at openjdk.org>
>> *Subject:* Re: Null restriction on interface typed fields
>>
>> Yes, the eventual plan is that all references can be null-restricted.
>> We've been struggling with a specific problem, though, which is that for a
>> reference type like `String!` or `Runnable!`, the VM is going to initialize
>> such variables with .. null.  This is obviously a safety problem, because
>> we've put a value in a variable that is not provably within the value set
>> of the variable's type.  It was for this reason that earlier discussion
>> focused on nullity control for (implicitly constructible) values first, and
>> other types later.
>>
>> Since then, we've figured out that we can solve this problem with better
>> flow analysis.  Just like the DA analysis done by the compiler, the VM can
>> do a similar analysis during verification time of fields that the compiler
>> marks as "must be written before they are read" (where any this-escape
>> might lead to reading those fields.)  This goes under the name of "strict
>> fields", and we should be writing more about this soon.
>>
>> Once we have this tool in our kit, the limitations on what types can be
>> null-restricted -- and the safety with which we can enforce this -- will be
>> greatly broadened.
>>
>> On 6/9/2024 5:04 AM, Chen Liang wrote:
>>
>> Hello valhalla community,
>> In our current iteration of valhalla, we only support null restriction on
>> value fields, as for references, null is a valid default value. Meanwhile,
>> interfaces are not restricted to be value or identity, yet some value
>> classes will only be represented via interfaces, most notably Map.entry().
>>
>> In addition, consider this scenario in the ClassFile API: we have
>> ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>) and
>> withMethodBody(xxx, Consumer<CodeBuilder>). A straightforward
>> implementation of withMethodBody would be withMethod(xxx, new
>> WithCode(cbConsumer)), where WithCode is (value) record
>> WithCode(Consumer<CodeBuilder> build) implements Consumer<MethodBuilder>...
>> In this WithCode record, we can see that we are interested in declaring
>> "build" null-restricted; if build is a value lambda that simply captures
>> context variables, then WithCode can be inlined to the same captures should
>> "build" be NR, without concerns about representing a null build value in
>> the inlined form.
>>
>> Another example is in Algebraic types:
>> sealed interface Operation permits O1, O2, ...
>> Record O1(Interface1 xxx)
>> Record O2(Interface2 xxx)
>> For value-based Interface1 and Interface2 values, we might seek to NR the
>> fields so the record representations can be simpler.
>>
>> Thus, I recommend considering support for NR on interface fields in
>> addition to on explicit value type fields. Though this might lead down to
>> the rabbit hole of "heap pollution of null on reference pointers", I still
>> believe its benefit outweighs its cost, especially in cases where these
>> values can be restricted on the stack in escape analysis, as in most
>> functional APIs (function only invoked conditionally, function objects not
>> stored when method exits).
>>
>> Chen Liang
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240618/93a91c17/attachment-0001.htm>

From brian.goetz at oracle.com  Mon Jun 17 21:57:17 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 17 Jun 2024 17:57:17 -0400
Subject: Null restriction on interface typed fields
In-Reply-To: <CAL5bRt_VeK02WtG3tFMa+_2uMUGQu1_SLE2Equs+bA8xzwG9ww@mail.gmail.com>
References: <SJ2PR10MB766991127800C29951C85B2FA2C52@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <79ffe287-8abb-4b24-a6e5-35816fd03096@oracle.com>
 <CH3PR10MB76770B2B79E432B522F29B91A2CD2@CH3PR10MB7677.namprd10.prod.outlook.com>
 <CAL5bRt_C4N375m+3Tvn25oDmajL3MBikM1Xinans3TDmVjW6jw@mail.gmail.com>
 <005876ea-c96f-4ae5-a1bd-3433ffcb2c65@oracle.com>
 <CAL5bRt_VeK02WtG3tFMa+_2uMUGQu1_SLE2Equs+bA8xzwG9ww@mail.gmail.com>
Message-ID: <0037e3c3-bf9c-4e4d-a82f-72dbd59ace32@oracle.com>

There is a large category of hazards going under the collective name 
"escaping construction", by which an incompletely initialized object may 
be observed by alien code (such as a virtual method overridden by a 
subclass, or the super-constructor, or any code to which `this` has been 
explicitly or explicitly exposed during construction).? We've had this 
hazard forever, but the advent of non-nullable value types for which the 
physical zero is not in the value set makes this hazard considerably worse.



On 6/17/2024 5:19 PM, Olexandr Rotan wrote:
>
> This makes sense, I didn't even think about primitives. Although, I 
> might not fully understand what is meant by "somehow observed"? Is it 
> refers to bypassing VM-provided access to a value such as reading 
> memory using Arenas and other low-level APIs? And if yes, how is it 
> possible to even restrict this access?
>
> And also, it's a discovery that even if object value is null, it's 
> primitive fields are still initialized. Is it really how this works? 
> If not, they I guess I just missed the point here, because how can you 
> "observe" unexciting object?
>
>
> On Tue, Jun 18, 2024, 00:05 Brian Goetz <brian.goetz at oracle.com> wrote:
>
>     What you are describing is a possible, though less desirable, way
>     to implement nullity control, one which could be described as
>     "erased nullity".? That is, the language does its type checking
>     (as it does with generics) and then throws out the nullity
>     information (as it does with generics), potentially inserting
>     checks where it wouldn't be able to trust the contents of the
>     variable (as it does with generics).? But in the face of
>     interference or separate compilation anomalies, these checks can
>     fail.? It would obviously be better if we could achieve "bang
>     means provably never null, ever", and that is what I was
>     describing through the flow analysis I was alluding to.? (Again,
>     all of this will be the subject of more extended writeups, in due
>     time.)
>
>     A good way to think about why this is important is not with null
>     references, but with the physical zero of a value type.? There are
>     going to be some value types for which the all-zero representation
>     is not only not a good default, but not even a member of the value
>     set of the class, such as:
>
>     ??? value class IsTrue {
>     ??????? private boolean isTrue;
>     ??????? private boolean isFalse;
>
>     ??????? IsTrue(boolean b) {
>     ??????????? isTrue = b;
>     ??????????? isFalse = !b;
>     ??????? }
>
>     ??????? boolean isSane() {
>     ??????????? return isTrue || isFalse;
>     ??????? }
>     ??? }
>
>     If we reviewed this class, we would reasonably conclude that
>     `isSane` is always true.? However, if we can somehow observe an
>     `IsTrue!` before it is written, both booleans would be seen to be
>     false, and the sanity check would not hold.? In the case of a null
>     reference, dereferencing and maybe getting an NPE is "not so
>     unsafe" because we stop before we use the invalid (null) value,
>     but in the case of an uninitialized `IsTrue!`, something far worse
>     has happened -- a value has escaped that was never created by a
>     constructor, which we might actually use.
>
>     This is why we are pursuing strengthening DA analysis in the VM,
>     so that such instances will provably never be observed.
>
>     On 6/17/2024 4:56 PM, Olexandr Rotan wrote:
>>
>>     Sorry if I am missing out something, but if null-restricted type
>>     contains null value (as vm initializes it), isn't the null value
>>     itself is a marker of the fact that value hasn't been set yet?
>>
>>     As I understand, if you assert non-nullity of null able type or
>>     type of unknown nullability with some sort of syntax (like ! in
>>     many languages), when in fact the value is null, exception should
>>     be thrown, so vm already obligated to perform null-check on this
>>     assignments. Same goes for reflective set, which should be
>>     treated as unknown nullity in any condition I guess unless vm
>>     could specialize instructions for the same method call but
>>     different nullity of args (either way vm must check nullity of
>>     value in at least part of the situations). This leads to a fact
>>     that if person even somehow manages to sneak through compiler
>>     analysis and try to set null to non-nullable field, it will
>>     immediately fail. Therefore, if value is null - it is unset.
>>
>>     That said, does it in fact matter that VM initializes this fields
>>     with null, if null bit (I guess that is how it stored), in fact
>>     is a marker of whether field has been initialized or not? VM
>>     could just check if value of field is null, and if so, throw an
>>     exception. Moreover, one way or another, as you said, checks on
>>     value access must be performed. So is this analysis really
>>     converges to "check if field is null", or there is more to it and
>>     I miss it?
>>
>>
>>     On Mon, Jun 17, 2024, 22:16 Chen Liang <chen.l.liang at oracle.com>
>>     wrote:
>>
>>         Indeed, another feature about the strict fields is their
>>         strong encapsulation against reflective setters; another
>>         safeguard against representable invalid values and their
>>         friendliness toward constant folding. John Rose's chart here
>>         seems up-to-date: objects-reloaded (openjdk.org)
>>         <https://cr.openjdk.org/~jrose/values/objects-reloaded.pdf>?(This
>>         strictness can also benefit the upcoming Stable Values JEP)
>>
>>         Also for readers' convenience, I think this is the earliest
>>         and most comprehensive document about the strict field
>>         designs, seems still accurate for the most part: Cleanup on
>>         aisle zero: Constructive classes (openjdk.org)
>>         <https://cr.openjdk.org/~jrose/jls/constructive-classes.html>
>>
>>         - Chen
>>         ------------------------------------------------------------------------
>>         *From:* Brian Goetz <brian.goetz at oracle.com>
>>         *Sent:* Monday, June 17, 2024 1:00 PM
>>         *To:* Chen Liang <chen.l.liang at oracle.com>;
>>         valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
>>         *Subject:* Re: Null restriction on interface typed fields
>>         Yes, the eventual plan is that all references can be
>>         null-restricted.? We've been struggling with a specific
>>         problem, though, which is that for a reference type like
>>         `String!` or `Runnable!`, the VM is going to initialize such
>>         variables with .. null.? This is obviously a safety problem,
>>         because we've put a value in a variable that is not provably
>>         within the value set of the variable's type.? It was for this
>>         reason that earlier discussion focused on nullity control for
>>         (implicitly constructible) values first, and other types later.
>>
>>         Since then, we've figured out that we can solve this problem
>>         with better flow analysis.? Just like the DA analysis done by
>>         the compiler, the VM can do a similar analysis during
>>         verification time of fields that the compiler marks as "must
>>         be written before they are read" (where any this-escape might
>>         lead to reading those fields.)? This goes under the name of
>>         "strict fields", and we should be writing more about this soon.
>>
>>         Once we have this tool in our kit, the limitations on what
>>         types can be null-restricted -- and the safety with which we
>>         can enforce this -- will be greatly broadened.
>>
>>         On 6/9/2024 5:04 AM, Chen Liang wrote:
>>>         Hello valhalla community,
>>>         In our current iteration of valhalla, we only support null
>>>         restriction on value fields, as for references, null is a
>>>         valid default value. Meanwhile, interfaces are not
>>>         restricted to be value or identity, yet some value classes
>>>         will only be represented via interfaces, most notably
>>>         Map.entry().
>>>
>>>         In addition, consider this scenario in the ClassFile API: we
>>>         have ClassBuilder.withMethod(xxx, Consumer<MethodBuilder>)
>>>         and withMethodBody(xxx,?Consumer<CodeBuilder>). A
>>>         straightforward implementation of withMethodBody would be
>>>         withMethod(xxx, new WithCode(cbConsumer)), where WithCode is
>>>         (value) record WithCode(Consumer<CodeBuilder> build)
>>>         implements Consumer<MethodBuilder>...
>>>         In this WithCode record, we can see that we are interested
>>>         in declaring "build" null-restricted; if build is a value
>>>         lambda that simply captures context variables, then WithCode
>>>         can be inlined to the same captures should "build" be NR,
>>>         without concerns about representing a null build value in
>>>         the inlined form.
>>>
>>>         Another example is in Algebraic types:
>>>         sealed interface Operation permits O1, O2, ...
>>>         Record O1(Interface1 xxx)
>>>         Record O2(Interface2 xxx)
>>>         For value-based Interface1 and Interface2 values, we might
>>>         seek to NR the fields so the record representations can be
>>>         simpler.
>>>
>>>         Thus, I recommend considering support for NR on interface
>>>         fields in addition to on explicit value type fields. Though
>>>         this might lead down to the rabbit hole of "heap pollution
>>>         of null on reference pointers", I still believe its benefit
>>>         outweighs its cost, especially in cases where these values
>>>         can be restricted on the stack in escape analysis, as in
>>>         most functional APIs (function only invoked conditionally,
>>>         function objects not stored when method exits).
>>>
>>>         Chen Liang
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240617/f50b7252/attachment-0001.htm>

From darcy at openjdk.org  Tue Jun 18 01:14:25 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jun 2024 01:14:25 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v13]
In-Reply-To: <Qq2ovy3U62PmD6Hgfe3TU7QFT7KEUAn9a1HD6CRFmsU=.249fec38-2822-44a7-903a-c0b927771a5d@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>
 <oF0dWlsDK2swage-j56ETQddHPro6AhybCCOVWvXs5E=.5583692a-1fb9-42e7-b917-db8f2468a647@github.com>
 <Qq2ovy3U62PmD6Hgfe3TU7QFT7KEUAn9a1HD6CRFmsU=.249fec38-2822-44a7-903a-c0b927771a5d@github.com>
Message-ID: <FzIr9skNq0FFTWEqkXg92LOr_JJRHGzAKQk9TVyiPu8=.0c4b3068-57c8-4769-b586-0e0ddd006ffd@github.com>

On Mon, 17 Jun 2024 21:13:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Why separate entry points for `add` and `sum`?
>
>> Why separate entry points for `add` and `sum`?
> 
> See previous comment https://github.com/openjdk/valhalla/pull/1117#discussion_r1640103814
> 
> tl;dr for this stage of the work, I didn't want to disable the existing `sum` intrinsic, but I think an `add` method works better in a larger context where methods for subtraction, multiplication, and division are being added.

> > > > > Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> > > > > Kindly fix and integrate.
> > > > 
> > > > 
> > > > Thanks; let me take a pass at writing at least some basic regression tests before pushing.
> > > > @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)
> > > 
> > > 
> > > Hi @jddarcy , As per specification of [Math.fma(float, float, float)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2494) internal computation of constituent operation (mul and add) should be done at infinite precision and only final result should be rounded, we are now upcasting float16 to double but it will not prevent rounding happening for mul and add.
> > 
> > 
> > Right; the fma needs to operate as-if it used infinite precision internally. This could be implemented (slowly) using JDK classes by implementing a BigDecimal -> Float16 conversion after doing a*b+c in BigDeicmal. I've been considering adding BigDecimal -> Float16 conversion anyway for completeness in the platform.
> > My understanding of how fma is implemented in hardware is that for a format with P bits of precision, there is a ~2P wide internal register to hold the exact product as an intermediate result. Then the value being adding in can be aligned at the right exponent location and the final rounding back to P bits of precision can occur, with logic of any sticky bit for rounding to nearest even, etc.
> > There are many cases where double (P = 53) will exactly hold the product and sum of three Float16 (P = 11) operands. However, the product can be so large or so small that rounding occurs when the third operand is added in.
> > I haven't worked through if the potential round-offs are all benign with the final rounding to Float16 or if some corrective action would need to be taken to get the effect of a sticky bit. For example, if a_b is so large that the highest exponent position set is more than 53 positions away from the lowest exponent position set on c, if the final result is going to overflow anyway, the round-off in computing a_b+c in double doesn't matter. It might be problematic if a*b is much smaller than c, but that is another case I haven't fully thought through yet.
> > I'll give an updated on my analysis/research on this fma issue by next week.
> 
> An update: promoting the three float16 fma operands to double and then computing (a*b) + c in double and rounding once at the end to Float16 works for (at least) most possible operands to a Float16 fma. It may work for all operands; I'm still working through those details.
> 
> To summarize my findings. if the product-sum held in double is exact, the single rounding to Float16 will compute the correct result.
> 
> Each Float16 operand is exactly convertible to double and the a*b product is exact since double has more than twice the precision of Float16. That leaves analyzing whether or not the product-sum is exact.
> 
> For Float16 values, the possible exponent bit positions that could be set range from 2^15 (from MAX_VALUE) to 2^(-24) (from MIN_VALUE). This entire exponent range of 15 - (-24) + 1 = 40 is less than the _precision_ of double, 53 bits.
> 
> When multiplying two Float16 values together, the exponent bit positions set in the exact product range over 2^31 (MAX_VALUE squared) to 2^(-48) (MIN_VALUE) squared.
> 
> If the exact product is larger than about 2^16, the final rounded result must overflow Float16. If the exact product has a highest exponent bit of 2^16, the product-sum will be exact since a double could hold a value as small as 2^(16 - 52) = 2^(-36), which is smaller than Float16.MIN_VALUE. Therefore, when the product has an exponent of 2^16 or larger, the end result is correct after conversion to Float16.
> 
> A similar argument holds when the product has an exponent in the normal range of Float16; any additional sum will be exact given the precision of double.
> 
> However, if the product is sufficiently small, it is possible the double will not be able to hold the exact value since the exponent range of 2^(-48) to 2^(15) is larger than double precision. However, for many operands, even if the product has underflowed, adding in many operands may be exact in practice. This exactness can be tested for using the 2sum algorithm (https://en.wikipedia.org/wiki/2Sum) for a zero trailing "t" component.
> 
> Fortunately in terms of computing the final answer and rounding complications, if c is the subnormal range of Float16 (exponent range 2^(-14) to 2(-24)), the product-sum will be exactly representable in double.
> 
> That leaves possibly non-exact product-sum with a combination of product in the subnormal range of Float16 and the c term to be added in being not-small. However, if this product-sum is non-exact, the smaller term from the product, with at most 22 exponent bit positions set, and the the 11 bits from c being summed in, must be separated by at least 53 - (22 + 11) = 20 bit positions otherwise the product-sum would fit in a double. I believe this implies at least one of the double-rounding scenarios cannot occur, in particular a half-way result in the smaller precision, Float16 in this case, rounding differently because sticky bit information from the higher precision was rounded away.
> 
> I'll keep working through the non-exact cases. Assuming a `Float16 valueOf(BigDecimal)` method is added, an "obviously right" approach would be to use a*b + c in double for all exact cases and failover to computing the exact result in BigDecimal and then rounding to that to Float16 for all the inexact cases.

PS I issued an integrate command to checkpoint the current state of the work and allow collaboration on other aspects of it, like adding intrinsics for more methods. I filed https://bugs.openjdk.org/browse/JDK-8334432 to track refinements to to Float16.fma. If nothing else, even if the current implementation is correct, the analysis of that should be included as a code comment.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2174719414

From dholmes at openjdk.org  Tue Jun 18 06:03:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Jun 2024 06:03:24 GMT
Subject: [lworld] RFR: 8326597: [lworld] Verifier must enforce new JEP 401
 rules related to strict fields
In-Reply-To: <5g1LBbCUhXnZqRaKFCYfEUTpUI1FUf2liNg0udQ1uVE=.eedde6d5-aaea-49b2-a112-eda79ba92860@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
 <5g1LBbCUhXnZqRaKFCYfEUTpUI1FUf2liNg0udQ1uVE=.eedde6d5-aaea-49b2-a112-eda79ba92860@github.com>
Message-ID: <U9mV64UAgZwSayTc0DznYSpvlHkJUWGpjenHFzFwhwA=.cf76495e-af16-40f8-9b74-2ea039b8d129@github.com>

On Mon, 17 Jun 2024 13:26:48 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
>> 
>> Changes:
>> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
>> - added the necessary checks for strict fields to the verifier and added some tests
>> - added missing class modifier checks for value classes in the classfile parse
>> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
>> - updated existing tests to  support the above
>> 
>> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's
>
> All my concerns were addressed.  Looks good

Thanks @DanHeidinga !

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

PR Comment: https://git.openjdk.org/valhalla/pull/1109#issuecomment-2175076736

From dholmes at openjdk.org  Tue Jun 18 06:03:26 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Jun 2024 06:03:26 GMT
Subject: [lworld] Integrated: 8326597: [lworld] Verifier must enforce new JEP
 401 rules related to strict fields
In-Reply-To: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
References: <5dl9VlUV0QVixF9JhZGuVOdPocmvZhKTKvSiNXljwfU=.22d99dfa-ed23-4576-a378-723a9b74e42b@github.com>
Message-ID: <_S8gzdjpJEpCdI3I9Lo-B8jlAi4uvbNyePj0mwvB22A=.79a8dc0e-2e9a-4b50-b288-89427cc246cc@github.com>

On Fri, 24 May 2024 05:07:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

> There are a number of commits here relating to different changes. To keep things more simple you can look at them individually.
> 
> Changes:
> - removed the old Q-type support from the verifier (verifierType.hpp/cpp)
> - added the necessary checks for strict fields to the verifier and added some tests
> - added missing class modifier checks for value classes in the classfile parse
> - brought the field modifier checks in classfile parser into line with JEP 401, simplified logic and provided more informative exception messages.
> - updated existing tests to  support the above
> 
> There is still a lot of inline-type terminology remaining, at least some of which should be cleaned up in future RFE's

This pull request has now been integrated.

Changeset: 4c31fe8e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4c31fe8e0fa851fe8be0f1fafe66aa3e6e1d2fd8
Stats:     355 lines in 9 files changed: 202 ins; 126 del; 27 mod

8326597: [lworld] Verifier must enforce new JEP 401 rules related to strict fields

Reviewed-by: fparain, heidinga

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

PR: https://git.openjdk.org/valhalla/pull/1109

From jbhateja at openjdk.org  Tue Jun 18 06:59:30 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 18 Jun 2024 06:59:30 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v13]
In-Reply-To: <FzIr9skNq0FFTWEqkXg92LOr_JJRHGzAKQk9TVyiPu8=.0c4b3068-57c8-4769-b586-0e0ddd006ffd@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>
 <oF0dWlsDK2swage-j56ETQddHPro6AhybCCOVWvXs5E=.5583692a-1fb9-42e7-b917-db8f2468a647@github.com>
 <Qq2ovy3U62PmD6Hgfe3TU7QFT7KEUAn9a1HD6CRFmsU=.249fec38-2822-44a7-903a-c0b927771a5d@github.com>
 <FzIr9skNq0FFTWEqkXg92LOr_JJRHGzAKQk9TVyiPu8=.0c4b3068-57c8-4769-b586-0e0ddd006ffd@github.com>
Message-ID: <bbfJLVPUSVHYiFUxmZr0EDiQ0h1IuxXhrPGvBTIacFo=.5259543c-4081-4310-bfc9-21e288aaeed2@github.com>

On Tue, 18 Jun 2024 01:11:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> Why separate entry points for `add` and `sum`?
>> 
>> See previous comment https://github.com/openjdk/valhalla/pull/1117#discussion_r1640103814
>> 
>> tl;dr for this stage of the work, I didn't want to disable the existing `sum` intrinsic, but I think an `add` method works better in a larger context where methods for subtraction, multiplication, and division are being added.
>
>> > > > > Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
>> > > > > Kindly fix and integrate.
>> > > > 
>> > > > 
>> > > > Thanks; let me take a pass at writing at least some basic regression tests before pushing.
>> > > > @jatin-bhateja , do you know if promoting the three operands of a Float16 fma to double, doing the operation in double, and rounding to Float16 is sufficient to correctly implement a Float16 fma? I haven't worked through all the cases yet and I'm not certain they're cannot be double-rounding issues. (If double rounding turns out to be a problem, I was thinking it would be possible to see if (a*b + c) was exact in double, and if, not add in a sticky bit to make sure the rounding occurs properly, but I haven't developed the details yet.)
>> > > 
>> > > 
>> > > Hi @jddarcy , As per specification of [Math.fma(float, float, float)](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2494) internal computation of constituent operation (mul and add) should be done at infinite precision and only final result should be rounded, we are now upcasting float16 to double but it will not prevent rounding happening for mul and add.
>> > 
>> > 
>> > Right; the fma needs to operate as-if it used infinite precision internally. This could be implemented (slowly) using JDK classes by implementing a BigDecimal -> Float16 conversion after doing a*b+c in BigDeicmal. I've been considering adding BigDecimal -> Float16 conversion anyway for completeness in the platform.
>> > My understanding of how fma is implemented in hardware is that for a format with P bits of precision, there is a ~2P wide internal register to hold the exact product as an intermediate result. Then the value being adding in can be aligned at the right exponent location and the final rounding back to P bits of precision can occur, with logic of any sticky bit for rounding to nearest even, etc.
>> > There are many cases where double (P = 53) will exactly hold the product and sum of three Float16 (P = 11) operands. However, the product can be so large or so small that rounding occurs when the third operand is added in.
>> > I haven't worked through if the potential round-offs are all benign with the final rounding to Float16 or if some corrective action would need to be taken to get the effect of a sticky bit. For example, if a_b is so large that the highest exponent position set is more than ...

Thanks @jddarcy , for detailed explanations. 
Sponsoring the patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2175285649

From darcy at openjdk.org  Tue Jun 18 06:59:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 18 Jun 2024 06:59:31 GMT
Subject: [lworld+fp16] Integrated: 8329817: Augment prototype Float16 class
In-Reply-To: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
Message-ID: <xPYNtV91i647KGc63L8R_cmltUWOL5PYbWo4h_arvR4=.47beed41-1f1f-4f0a-8f21-cc0b0ed645f1@github.com>

On Fri, 7 Jun 2024 04:17:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Sketch of a more full-featured API for Float16.

This pull request has now been integrated.

Changeset: 1b319ffe
Author:    Joe Darcy <darcy at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1b319ffe2150795304bab6b8ad34b1c4fdee0380
Stats:     1500 lines in 7 files changed: 1389 ins; 15 del; 96 mod

8329817: Augment prototype Float16 class

Reviewed-by: jbhateja

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

PR: https://git.openjdk.org/valhalla/pull/1117

From chagedorn at openjdk.org  Tue Jun 18 09:00:59 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 18 Jun 2024 09:00:59 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check [v3]
In-Reply-To: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
Message-ID: <fa8Jgcr-_cK0w6jvRwCA2KvjUlXMVpZeIGjlJPde7Xc=.5e722e7f-7c95-483b-ba7c-4d28534aae9f@github.com>

> #### Speculative Inline Type Checks for `aaload`
> 
> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
> 
> #### Known Problem when Load is Disconnected from Range Check
> 
> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
> 
> #### How this Problem Manifests in Valhalla
> 
> In the test case, the very same is happening:
> 
> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
> 
>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
> 
> I've additionally done some refactoring and added some comments which helped me to better understand the code.
> 
> Thanks,
> Christian

Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:

  Fix additional case where a load still floats above the range check

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1127/files
  - new: https://git.openjdk.org/valhalla/pull/1127/files/3357f826..a956c768

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1127&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1127&range=01-02

  Stats: 30 lines in 2 files changed: 16 ins; 11 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1127.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1127/head:pull/1127

PR: https://git.openjdk.org/valhalla/pull/1127

From chagedorn at openjdk.org  Tue Jun 18 09:03:48 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 18 Jun 2024 09:03:48 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check [v2]
In-Reply-To: <Arx7yC-6XCs9omIuQJtXlS_n5QYcXqRI2BKbxAlYmEg=.daf11e96-e8c4-4ee5-9b25-f2fcf5432494@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
 <Arx7yC-6XCs9omIuQJtXlS_n5QYcXqRI2BKbxAlYmEg=.daf11e96-e8c4-4ee5-9b25-f2fcf5432494@github.com>
Message-ID: <BFizs9dKVgQjni5ZyXu-9xDPUUqD6YtuOgMWv0pO7l4=.5e3ed0fa-c7cf-42b5-bd26-94960b1fb3f7@github.com>

On Mon, 17 Jun 2024 07:19:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> #### Speculative Inline Type Checks for `aaload`
>> 
>> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
>> 
>> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
>> 
>> #### Known Problem when Load is Disconnected from Range Check
>> 
>> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
>> 
>> #### How this Problem Manifests in Valhalla
>> 
>> In the test case, the very same is happening:
>> 
>> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
>> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
>> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
>> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
>> 
>>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
>> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
>> 
>> I've additionally done some refactoring and added some comments which helped me to better understand the code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update comments
>  - Apply suggestions from code review
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Thanks Tobias for your review! As we've discussed offline, I've pushed an additional fix for a case that was missing: The load can still float above a range check when it's pinned at the If with a `FlatArrayCheck` which directly follows the range check. To avoid that, we pin it with `C2_UNKNOWN_CONTROL_LOAD` because we cannot set two nodes as control dependency.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1127#issuecomment-2175578075

From briangoetz at openjdk.org  Tue Jun 18 13:52:31 2024
From: briangoetz at openjdk.org (Brian Goetz)
Date: Tue, 18 Jun 2024 13:52:31 GMT
Subject: [lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v13]
In-Reply-To: <Qq2ovy3U62PmD6Hgfe3TU7QFT7KEUAn9a1HD6CRFmsU=.249fec38-2822-44a7-903a-c0b927771a5d@github.com>
References: <I5YlmcA4num2iD_Vo-IOwmhcBP_9JnHwQyOtr1c_hTQ=.cc467c98-3b36-4fe4-863b-82063ffd70a2@github.com>
 <wqYUtXb-zJ1ZcPq_orLDfI-QpkX2XdWlULRfWO2EBS4=.9ffbab6d-723b-402c-b214-1ecc9b982648@github.com>
 <oF0dWlsDK2swage-j56ETQddHPro6AhybCCOVWvXs5E=.5583692a-1fb9-42e7-b917-db8f2468a647@github.com>
 <Qq2ovy3U62PmD6Hgfe3TU7QFT7KEUAn9a1HD6CRFmsU=.249fec38-2822-44a7-903a-c0b927771a5d@github.com>
Message-ID: <2svD-XohYqEzzYo7ChlpKQ7ZhBDNc2t04D7EbNk-V2c=.acd62a65-4c00-45cf-b906-b868f169614a@github.com>

On Mon, 17 Jun 2024 21:13:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> tl;dr for this stage of the work, I didn't want to disable the existing `sum` intrinsic, but I think an `add` method works better in a larger context where methods for subtraction, multiplication, and division are being added.

Good, that's what I was looking for.  One of the things we hope to gain consensus on in this experiment is conventions for naming and organizing operations on numerics.  There may be some inevitable duplication (because Number asks for a particular method name) but we need to establish the right conventions for going forward.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2176156611

From fparain at openjdk.org  Tue Jun 18 20:39:50 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 18 Jun 2024 20:39:50 GMT
Subject: [lworld] RFR: [lworld] Various fixes
Message-ID: <ra0pAd453oxcTYRpntxGFLWYSxFelTT0RI5FFSw8L-E=.2a1ba4fd-99cf-4eac-b1eb-1780092261dc@github.com>

Bag of various fixes:
  - removal of dead code
  - cleanup of existing code (simplification, removal of repeated actions)
  - refactoring some code to make it more readable
  - some adjustments because of abstract value classes
  - some minor fixes


Fred

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

Commit messages:
 - Fix typos
 - Code cleanup and adjustments to abstract value classes

Changes: https://git.openjdk.org/valhalla/pull/1140/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1140&range=00
  Stats: 120 lines in 11 files changed: 65 ins; 31 del; 24 mod
  Patch: https://git.openjdk.org/valhalla/pull/1140.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1140/head:pull/1140

PR: https://git.openjdk.org/valhalla/pull/1140

From fparain at openjdk.org  Tue Jun 18 21:03:49 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 18 Jun 2024 21:03:49 GMT
Subject: [lworld] RFR: [lworld] Various fixes [v2]
In-Reply-To: <ra0pAd453oxcTYRpntxGFLWYSxFelTT0RI5FFSw8L-E=.2a1ba4fd-99cf-4eac-b1eb-1780092261dc@github.com>
References: <ra0pAd453oxcTYRpntxGFLWYSxFelTT0RI5FFSw8L-E=.2a1ba4fd-99cf-4eac-b1eb-1780092261dc@github.com>
Message-ID: <duhDNWAZ15O-v2JTD7Pw4i-2UUtCrANL8HO_vx7_D6U=.f4458602-32c4-46b4-aac0-1e954028e05f@github.com>

> Bag of various fixes:
>   - removal of dead code
>   - cleanup of existing code (simplification, removal of repeated actions)
>   - refactoring some code to make it more readable
>   - some adjustments because of abstract value classes
>   - some minor fixes
> 
> 
> Fred

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

 - Merge remote-tracking branch 'upstream/lworld' into code_cleanup
 - Fix typos
 - Code cleanup and adjustments to abstract value classes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1140/files
  - new: https://git.openjdk.org/valhalla/pull/1140/files/d7f0e1f6..8fabaaee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1140&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1140&range=00-01

  Stats: 2745 lines in 93 files changed: 594 ins; 2060 del; 91 mod
  Patch: https://git.openjdk.org/valhalla/pull/1140.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1140/head:pull/1140

PR: https://git.openjdk.org/valhalla/pull/1140

From thartmann at openjdk.org  Wed Jun 19 06:33:24 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Jun 2024 06:33:24 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check [v3]
In-Reply-To: <fa8Jgcr-_cK0w6jvRwCA2KvjUlXMVpZeIGjlJPde7Xc=.5e722e7f-7c95-483b-ba7c-4d28534aae9f@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
 <fa8Jgcr-_cK0w6jvRwCA2KvjUlXMVpZeIGjlJPde7Xc=.5e722e7f-7c95-483b-ba7c-4d28534aae9f@github.com>
Message-ID: <6voX9PvK59V9uU1axfhj8ogTm3VxVkCOfNqsqo4xjmM=.47350ecc-8646-49d3-9038-d18d826b8d27@github.com>

On Tue, 18 Jun 2024 09:00:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> #### Speculative Inline Type Checks for `aaload`
>> 
>> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
>> 
>> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
>> 
>> #### Known Problem when Load is Disconnected from Range Check
>> 
>> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
>> 
>> #### How this Problem Manifests in Valhalla
>> 
>> In the test case, the very same is happening:
>> 
>> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
>> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
>> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
>> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
>> 
>>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
>> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
>> 
>> I've additionally done some refactoring and added some comments which helped me to better understand the code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix additional case where a load still floats above the range check

Looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1127#pullrequestreview-2127165186

From chagedorn at openjdk.org  Wed Jun 19 06:36:31 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Jun 2024 06:36:31 GMT
Subject: [lworld] RFR: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check [v3]
In-Reply-To: <fa8Jgcr-_cK0w6jvRwCA2KvjUlXMVpZeIGjlJPde7Xc=.5e722e7f-7c95-483b-ba7c-4d28534aae9f@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
 <fa8Jgcr-_cK0w6jvRwCA2KvjUlXMVpZeIGjlJPde7Xc=.5e722e7f-7c95-483b-ba7c-4d28534aae9f@github.com>
Message-ID: <UuS49Xb_fd_ADbCbNylL3m2WRz-qh17G4T8wUJl4AKY=.8e2029fc-0842-4613-ad86-294eb4eedf3c@github.com>

On Tue, 18 Jun 2024 09:00:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> #### Speculative Inline Type Checks for `aaload`
>> 
>> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
>> 
>> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
>> 
>> #### Known Problem when Load is Disconnected from Range Check
>> 
>> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
>> 
>> #### How this Problem Manifests in Valhalla
>> 
>> In the test case, the very same is happening:
>> 
>> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
>> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
>> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
>> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
>> 
>>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
>> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
>> 
>> I've additionally done some refactoring and added some comments which helped me to better understand the code.
>> 
>> Thanks,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix additional case where a load still floats above the range check

Thanks Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1127#issuecomment-2177856967

From chagedorn at openjdk.org  Wed Jun 19 09:11:27 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Jun 2024 09:11:27 GMT
Subject: [lworld] Integrated: 8333889: [lworld] C2: Hoisting speculative array
 access type check wrongly moves array access before its range check
In-Reply-To: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
References: <pxwjersDI-xcBbsXpcUakHjyAjF6p0z9_6iPTd_pF3c=.08e6eb74-2d7e-4490-affe-f04b5950fa16@github.com>
Message-ID: <Pboh_7utVMsj0c_q5LiHtfbW7EQhXxd71eXaKBALxEM=.0860b0a7-28d5-4e7e-a7bf-d54659748282@github.com>

On Fri, 14 Jun 2024 07:09:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> #### Speculative Inline Type Checks for `aaload`
> 
> In `Parse::array_addressing()`, we emit speculative inline type checks (about non-flatness and non-null-freeness) with traps based on profiling information. These checks are emitted directly after the `RangeCheck`. This will lead to the situation that the `CastII` and actual `LoadN` nodes are disconnected from the `RangeCheck` true projection:
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/b82e4b5c-20b5-4c0f-8099-57883aae19d1)
> 
> #### Known Problem when Load is Disconnected from Range Check
> 
> This disconnection of the load from its range check is a known general problem and could lead to the situation where the actual load ends up before the range check due to some optimizations. As a result, we could crash due to an unprotected out-of-bounds access when the load is actually scheduled before the range check with an invalid index. This was observed before on several occasions in mainline and was being fixed there (e.g. [JDK-8323274](https://bugs.openjdk.org/browse/JDK-8323274)). 
> 
> #### How this Problem Manifests in Valhalla
> 
> In the test case, the very same is happening:
> 
> 1. Loop Predication hoists `237 If` out of the loop since it's invariant.
> 2. `108 RangeCheck` cannot be hoisted since it's not invariant and we have a non-counted loop with a `float` iv phi.
> 3. By hoisting `237 If` out of the loop, we also rewire the data dependencies (i.e. `140 CastII` and `146 LoadN`) out of the loop. These now end up before the range check which is still inside the loop.
> 4. When running with `-XX:+StressGCM`, the `LoadN` could be scheduled before the actual `RangeCheck` inside the loop and we crash when using an invalid out-of-bounds array index.
> 
>  #### Solution: Swap `RangeCheck` and Speculative Inline Type Traps
> The fix is straight forward to first emit the speculative inline type checks with its traps and only then emit the `RangeCheck` such that it does not lose the connection to the actual load. 
> 
> I've additionally done some refactoring and added some comments which helped me to better understand the code.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 404a4fae
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/404a4fae6fc099cd93cc73d57e29b08b5418adb9
Stats:     373 lines in 3 files changed: 210 ins; 85 del; 78 mod

8333889: [lworld] C2: Hoisting speculative array access type check wrongly moves array access before its range check

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1127

From bkilambi at openjdk.org  Thu Jun 20 10:42:57 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 20 Jun 2024 10:42:57 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation [v3]
In-Reply-To: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
Message-ID: <4k-ObapFtD75jAXColXX1lu-LTtkPPZPAdbgkMZqv40=.b3673ca3-1755-4be6-9c68-1786768f670e@github.com>

> This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.
> 
> [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Remove couple of IR testcases + add --enable-preview flag to tests
 - Merge branch 'lworld+fp16'
 - Add a missing return statement in the ad file
 - 8330021: AArch64: Add backend support for FP16 add operation
   
   This commit [1] adds initial support for FP16 operations and adds
   backend support for FP16 add operation for X86. This task adds backend
   support for scalar and vector FP16 add operation on aarch64.
   
   [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

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

Changes: https://git.openjdk.org/valhalla/pull/1096/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1096&range=02
  Stats: 874 lines in 19 files changed: 176 ins; 6 del; 692 mod
  Patch: https://git.openjdk.org/valhalla/pull/1096.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1096/head:pull/1096

PR: https://git.openjdk.org/valhalla/pull/1096

From fparain at openjdk.org  Thu Jun 20 13:02:23 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 20 Jun 2024 13:02:23 GMT
Subject: [lworld] Integrated: [lworld] Various fixes
In-Reply-To: <ra0pAd453oxcTYRpntxGFLWYSxFelTT0RI5FFSw8L-E=.2a1ba4fd-99cf-4eac-b1eb-1780092261dc@github.com>
References: <ra0pAd453oxcTYRpntxGFLWYSxFelTT0RI5FFSw8L-E=.2a1ba4fd-99cf-4eac-b1eb-1780092261dc@github.com>
Message-ID: <1_Hr9t-_nanSySSF8CrIWOmhRE921a8HSMHU5RENh04=.d2d85302-71a6-4bb3-8778-9c4bf52897cb@github.com>

On Tue, 18 Jun 2024 20:35:43 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Bag of various fixes:
>   - removal of dead code
>   - cleanup of existing code (simplification, removal of repeated actions)
>   - refactoring some code to make it more readable
>   - some adjustments because of abstract value classes
>   - some minor fixes
> 
> 
> Fred

This pull request has now been integrated.

Changeset: e3da5c61
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e3da5c619b55cf29547c868d5824c146be33c876
Stats:     120 lines in 11 files changed: 65 ins; 31 del; 24 mod

[lworld] Various fixes

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

PR: https://git.openjdk.org/valhalla/pull/1140

From bkilambi at openjdk.org  Thu Jun 20 13:13:30 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 20 Jun 2024 13:13:30 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation [v3]
In-Reply-To: <4k-ObapFtD75jAXColXX1lu-LTtkPPZPAdbgkMZqv40=.b3673ca3-1755-4be6-9c68-1786768f670e@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
 <4k-ObapFtD75jAXColXX1lu-LTtkPPZPAdbgkMZqv40=.b3673ca3-1755-4be6-9c68-1786768f670e@github.com>
Message-ID: <ce8XjDR04Kpf7jcKZS08ZfS2ShIpo7yV9o36h5iTWXc=.a8a54472-b62a-492f-b728-b187899d3b55@github.com>

On Thu, 20 Jun 2024 10:42:57 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This commit [1] adds initial support for FP16 operations and adds backend support for FP16 add operation for X86. This task adds backend support for scalar and vector FP16 add operation on aarch64.
>> 
>> [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad
>
> Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Remove couple of IR testcases + add --enable-preview flag to tests
>  - Merge branch 'lworld+fp16'
>  - Add a missing return statement in the ad file
>  - 8330021: AArch64: Add backend support for FP16 add operation
>    
>    This commit [1] adds initial support for FP16 operations and adds
>    backend support for FP16 add operation for X86. This task adds backend
>    support for scalar and vector FP16 add operation on aarch64.
>    
>    [1] https://github.com/openjdk/valhalla/commit/f03fb4e4ee4d59ed692d0c26ddce260511f544e7#diff-a799ce8da7f3062bb3699beb65aae504840c649942032e325c2a50f88a2869ad

Hello @jatin-bhateja , I noticed that the vector test - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java` fails on aarch64/x86 machines that support the Float16 feature. Have you noticed this on any of your `avx512_fp16` supporting machines too? I suspect this failure does not show up on github actions for this PR or others because they might be running the tests on non-fp16 supporting hardware.

I digged a bit deeper and found out that the Float16 `add` operation was not getting unrolled in the first place because of which it doesn't get vectorized eventually. I have an internal implementation for other binary FP16 operations (like subtract, multiply, divide, min and max) and none of these operations get vectorized either. After some debugging, I noticed that the inner loop body -> `_body` at this point of code execution - `https://github.com/openjdk/valhalla/blob/404a4fae6fc099cd93cc73d57e29b08b5418adb9/src/hotspot/share/opto/loopTransform.cpp#L1069` contains 188 nodes for Half float add compared to 29 nodes for Float32 add and 31 nodes for FP16 add before the merge on June 9th. I think due to so many nodes in the loop, the unrolling policy decides not to unroll it. 
I printed the extra nodes that the loop (for FP16 add operation) contains and I can see nodes like - `DecodeNKlass`, `DecodeN`, `LoadNKlass`, `LoadN`, `CmpP`, `StoreP`, `StoreCM`, `MergeMem`, `EncodeP`, `CastPP` and other pointer related IR nodes and maybe some nodes related to decoding compressed class pointers. Although none of these exist in the FP32 code or the FP16 code before the merge. Do you have any idea about this failure or the extra nodes in the loop?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1096#issuecomment-2180646670

From rriggs at openjdk.org  Thu Jun 20 14:42:35 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Jun 2024 14:42:35 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identiy bits
Message-ID: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>

Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
The access flag bits for arrays come from the VM, hence the changes to HotSpot.

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

Commit messages:
 - Correct bugid references
 - 8294866: [lworld] Array classes modifier mask should include identity bits

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

PR: https://git.openjdk.org/valhalla/pull/1141

From liach at openjdk.org  Thu Jun 20 15:10:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jun 2024 15:10:26 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identiy bits
In-Reply-To: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
Message-ID: <O01LpLshE1R-FOsrsq_BpBZRATt1pZWtQxSA7Y0S7Wo=.d05b7858-aa30-4335-88e4-8d7b66b14e6d@github.com>

On Thu, 20 Jun 2024 14:38:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
> The access flag bits for arrays come from the VM, hence the changes to HotSpot.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 218:

> 216:                 @Override
> 217:                 public Set<Location> apply(ClassFileFormatVersion cffv) {
> 218:                     return (cffv.compareTo(ClassFileFormatVersion.RELEASE_23) >= 0

Should we just use `cffv == ClassFileFormatVersion.latest()`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1141#discussion_r1647739592

From rriggs at openjdk.org  Thu Jun 20 16:45:35 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Jun 2024 16:45:35 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identiy bits [v2]
In-Reply-To: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
Message-ID: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>

> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
> The access flag bits for arrays come from the VM, hence the changes to HotSpot.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of the `latest()` class file version number.
  They should float forward with releases until the first release in which Valhalla is integrated.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1141/files
  - new: https://git.openjdk.org/valhalla/pull/1141/files/92fb3896..9e0368fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1141&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1141&range=00-01

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

PR: https://git.openjdk.org/valhalla/pull/1141

From dgomezg at gmail.com  Thu Jun 20 16:49:51 2024
From: dgomezg at gmail.com (David Gomez Garcia)
Date: Thu, 20 Jun 2024 18:49:51 +0200
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identiy bits [v2]
In-Reply-To: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
 <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
Message-ID: <CA+nwK89AyiOtfSNKH7_azgtm1xpObteX+xAfSjVAy_jJSRye7g@mail.gmail.com>

On Thu, 20 Jun 2024 at 18:46, Roger Riggs <rriggs at openjdk.org> wrote:

> > Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
> > The access flag bits for arrays come from the VM, hence the changes to
> HotSpot.
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
>   Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of
> the `latest()` class file version number.
>   They should float forward with releases until the first release in which
> Valhalla is integrated.
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.org/valhalla/pull/1141/files
>   - new:
> https://git.openjdk.org/valhalla/pull/1141/files/92fb3896..9e0368fc
>
> Webrevs:
>  - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1141&range=01
>  - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1141&range=00-01
>
>   Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
>   Patch: https://git.openjdk.org/valhalla/pull/1141.diff
>   Fetch: git fetch https://git.openjdk.org/valhalla.git
> pull/1141/head:pull/1141
>
> PR: https://git.openjdk.org/valhalla/pull/1141
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240620/49ab66ab/attachment.htm>

From liach at openjdk.org  Thu Jun 20 16:51:36 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 20 Jun 2024 16:51:36 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identity bits [v2]
In-Reply-To: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
 <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
Message-ID: <zGJxsqf3O8U2ZvyNdHIIbPGf9selHPKO2OKauplBNOk=.6a1ccae3-34a9-430d-b165-90cf8aa4530b@github.com>

On Thu, 20 Jun 2024 16:45:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
>> The access flag bits for arrays come from the VM, hence the changes to HotSpot.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of the `latest()` class file version number.
>   They should float forward with releases until the first release in which Valhalla is integrated.

Thanks for the latest preview tagging.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1141#pullrequestreview-2130919741

From heidinga at openjdk.org  Thu Jun 20 17:09:24 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Thu, 20 Jun 2024 17:09:24 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identity bits [v2]
In-Reply-To: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
 <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
Message-ID: <LdqtujE2Zuf4PQ-8We_tj5IXSi0OHwQJOFuOdsLQwzw=.274e12f7-9497-4058-a3f6-1b8b4e417261@github.com>

On Thu, 20 Jun 2024 16:45:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
>> The access flag bits for arrays come from the VM, hence the changes to HotSpot.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of the `latest()` class file version number.
>   They should float forward with releases until the first release in which Valhalla is integrated.

Looks right to me.  @fparain any concerns?

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1141#pullrequestreview-2130952840

From vromero at openjdk.org  Thu Jun 20 17:43:25 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jun 2024 17:43:25 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identity bits [v2]
In-Reply-To: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
 <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
Message-ID: <3ejwB7eo_LC_UWrzXRDEE5lK7R44hyr7_qtrviB8FWk=.25686628-742b-485e-b470-ad99a07cc6e1@github.com>

On Thu, 20 Jun 2024 16:45:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
>> The access flag bits for arrays come from the VM, hence the changes to HotSpot.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of the `latest()` class file version number.
>   They should float forward with releases until the first release in which Valhalla is integrated.

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1141#pullrequestreview-2131018242

From vromero at openjdk.org  Thu Jun 20 17:55:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jun 2024 17:55:23 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identity bits [v2]
In-Reply-To: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
 <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
Message-ID: <T1jbi57KWr2_LGp6ituTRsVlogW7IEhFVd7wQTEDm4s=.cff94cd6-3f34-4d35-ac56-7b4288c31f83@github.com>

On Thu, 20 Jun 2024 16:45:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
>> The access flag bits for arrays come from the VM, hence the changes to HotSpot.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of the `latest()` class file version number.
>   They should float forward with releases until the first release in which Valhalla is integrated.

just wondering now that you are modifying AccessFlag, should we change SUPER:

SUPER(0x0000_0020, false,
            PreviewFeatures.isEnabled() ? Location.EMPTY_SET : Location.SET_CLASS,
            new Function<ClassFileFormatVersion, Set<Location>>() {
            @Override
            public Set<Location> apply(ClassFileFormatVersion cffv) {
-               return (cffv.compareTo(ClassFileFormatVersion.RELEASE_22) >= 0) &&
+               return (cffv.compareTo(ClassFileFormatVersion.RELEASE_23) >= 0) &&
                        PreviewFeatures.isEnabled() ? Location.EMPTY_SET : Location.SET_CLASS;
            }
        }),

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

PR Comment: https://git.openjdk.org/valhalla/pull/1141#issuecomment-2181231226

From rriggs at openjdk.org  Thu Jun 20 18:20:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Jun 2024 18:20:27 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identity bits [v3]
In-Reply-To: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
Message-ID: <HeDwxmp9A-B8aRvBY67aIFYxL0SI4EriiwK2w2r6PMo=.0481f6c9-1195-4fcc-8c98-5d9a7d39b9d5@github.com>

> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
> The access flag bits for arrays come from the VM, hence the changes to HotSpot.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Included SUPER in the set of AccessFlags that are valid for the latest release until integrated

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1141/files
  - new: https://git.openjdk.org/valhalla/pull/1141/files/9e0368fc..4d4da60a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1141&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1141&range=01-02

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

PR: https://git.openjdk.org/valhalla/pull/1141

From fparain at openjdk.org  Thu Jun 20 18:20:28 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 20 Jun 2024 18:20:28 GMT
Subject: [lworld] RFR: 8294866: [lworld] Array classes access flags should
 include identity bits [v2]
In-Reply-To: <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
 <6DTePvGtXptOa9Nz-fB7RigXIf4EOWm9lewou2MB-bA=.2a0b08de-6ccd-4764-a68f-1512d1da388a@github.com>
Message-ID: <3wtBB8wtjeMlnxV35UKdgM_1V-G_VLC4Gtsb5ORctoY=.75594d07-bb3d-4821-b9b3-58f4122b2e73@github.com>

On Thu, 20 Jun 2024 16:45:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
>> The access flag bits for arrays come from the VM, hence the changes to HotSpot.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tagged the new IDENTITY and STRICT_FIELD AccessFlags to be valid as of the `latest()` class file version number.
>   They should float forward with releases until the first release in which Valhalla is integrated.

VM changes look good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1141#pullrequestreview-2131079613

From vromero at openjdk.org  Thu Jun 20 21:26:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jun 2024 21:26:41 GMT
Subject: [lworld] Integrated: 8334678: [lworld] some javac tests are failing
 intermittently due to a VM warning
Message-ID: <5RF4SoQir9qkMLLAPeWG9tEVXPVvUu98kjfsQRlPRiU=.d8df4b25-4f59-47e5-80fd-4d0caf804945@github.com>

Several tests using library class JavacTestingAbstractProcessor are failing intermittently as JavacTestingAbstractProcessor uses Optional. Optional has two versions: one is a value class and the other one is not. The VM issues a warning if the loaded class is not the value version. The tests failing have a golden file and the presence or not of the warning can make them fail. The proposed fix, temporary, is to remove the dependency on Optional.

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

Commit messages:
 - 8334678: [lworld] some javac tests are failing intermittently due to a VM warning

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

PR: https://git.openjdk.org/valhalla/pull/1142

From vromero at openjdk.org  Thu Jun 20 21:26:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 20 Jun 2024 21:26:41 GMT
Subject: [lworld] Integrated: 8334678: [lworld] some javac tests are failing
 intermittently due to a VM warning
In-Reply-To: <5RF4SoQir9qkMLLAPeWG9tEVXPVvUu98kjfsQRlPRiU=.d8df4b25-4f59-47e5-80fd-4d0caf804945@github.com>
References: <5RF4SoQir9qkMLLAPeWG9tEVXPVvUu98kjfsQRlPRiU=.d8df4b25-4f59-47e5-80fd-4d0caf804945@github.com>
Message-ID: <wXCtgbDYxRTjdVmxM-wzOtVUDeOYF2leWIUja0la-I8=.fc2a7ee8-0a72-44df-865a-3007e5407568@github.com>

On Thu, 20 Jun 2024 21:21:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests using library class JavacTestingAbstractProcessor are failing intermittently as JavacTestingAbstractProcessor uses Optional. Optional has two versions: one is a value class and the other one is not. The VM issues a warning if the loaded class is not the value version. The tests failing have a golden file and the presence or not of the warning can make them fail. The proposed fix, temporary, is to remove the dependency on Optional.

This pull request has now been integrated.

Changeset: e1830399
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e1830399fae8dc52f3ff8a4dc6e745b08e05c790
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8334678: [lworld] some javac tests are failing intermittently due to a VM warning

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

PR: https://git.openjdk.org/valhalla/pull/1142

From darcy at openjdk.org  Fri Jun 21 04:41:39 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 21 Jun 2024 04:41:39 GMT
Subject: [lworld+fp16] RFR: 8334432: Refine Float16.fma
Message-ID: <N4FgYFfNy05Hi4FKmTYogez0-XpmlUTFAr5Mvcpu_wo=.9dae7548-f67f-42cd-80cd-f25eec2161ff@github.com>

Adding comments and test cases for Float16.fma.

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

Commit messages:
 - JDK-8334432: Refine Float16.fma

Changes: https://git.openjdk.org/valhalla/pull/1143/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334432
  Stats: 189 lines in 2 files changed: 157 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/valhalla/pull/1143.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1143/head:pull/1143

PR: https://git.openjdk.org/valhalla/pull/1143

From darcy at openjdk.org  Fri Jun 21 04:41:39 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 21 Jun 2024 04:41:39 GMT
Subject: [lworld+fp16] RFR: 8334432: Refine Float16.fma
In-Reply-To: <N4FgYFfNy05Hi4FKmTYogez0-XpmlUTFAr5Mvcpu_wo=.9dae7548-f67f-42cd-80cd-f25eec2161ff@github.com>
References: <N4FgYFfNy05Hi4FKmTYogez0-XpmlUTFAr5Mvcpu_wo=.9dae7548-f67f-42cd-80cd-f25eec2161ff@github.com>
Message-ID: <Se352sOgLCNUJAuCgnJQ5J932J06rF-G_cCsLNPLq1Y=.baedbbed-1c47-470d-9941-c070fc604c98@github.com>

On Fri, 21 Jun 2024 04:36:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Adding comments and test cases for Float16.fma.

I've asked my colleague @rgiulietti to help with the error analysis of the current implementation.

The commented-out code in the fma for an inexact product-sum does get executed for the expected test cases. If special-case code for an inexact product-sum  turns out need to be needed, this extra code will be deleted before a push.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1143#issuecomment-2181985826

From jbhateja at openjdk.org  Fri Jun 21 06:12:16 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 21 Jun 2024 06:12:16 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation [v3]
In-Reply-To: <ce8XjDR04Kpf7jcKZS08ZfS2ShIpo7yV9o36h5iTWXc=.a8a54472-b62a-492f-b728-b187899d3b55@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
 <4k-ObapFtD75jAXColXX1lu-LTtkPPZPAdbgkMZqv40=.b3673ca3-1755-4be6-9c68-1786768f670e@github.com>
 <ce8XjDR04Kpf7jcKZS08ZfS2ShIpo7yV9o36h5iTWXc=.a8a54472-b62a-492f-b728-b187899d3b55@github.com>
Message-ID: <dJvTuXE58lzqrjSdYe9MjCzKUyBx_0U5Ic9HQOJVTHE=.e8971e4d-dc33-453e-bbf6-49bde906e9b8@github.com>

On Thu, 20 Jun 2024 13:10:16 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Hello @jatin-bhateja , I noticed that the vector test - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java` fails on aarch64/x86 machines that support the Float16 feature. Have you noticed this on any of your `avx512_fp16` supporting machines too? I suspect this failure does not show up on github actions for this PR or others because they might be running the tests on non-fp16 supporting hardware.
> 
> I digged a bit deeper and found out that the Float16 `add` operation was not getting unrolled in the first place because of which it doesn't get vectorized eventually. I have an internal implementation for other binary FP16 operations (like subtract, multiply, divide, min and max) and none of these operations get vectorized either. After some debugging, I noticed that the inner loop body -> `_body` at this point of code execution - `https://github.com/openjdk/valhalla/blob/404a4fae6fc099cd93cc73d57e29b08b5418adb9/src/hotspot/share/opto/loopTransform.cpp#L1069` contains 188 nodes for Half float add compared to 29 nodes for Float32 add and 31 nodes for FP16 add before the merge on June 9th. I think due to so many nodes in the loop, the unrolling policy decides not to unroll it. I printed the extra nodes that the loop (for FP16 add operation) contains and I can see nodes like - `DecodeNKlass`, `DecodeN`, `LoadNKlass`, `LoadN`, `CmpP`, `StoreP`, `StoreCM`, `MergeMem`, `EncodeP`, `CastP
 P` and other pointer related IR nodes and maybe some nodes related to decoding compressed class pointers. Although none of these exist in the FP32 code or the FP16 code before the merge. Do you have any idea about this failure or the extra nodes in the loop?

Hi @Bhavana-Kilambi , 

Flat array layout is currently broken, it used to work when Float16 was a primitive value class, please refer following link for more details.
https://github.com/openjdk/valhalla/pull/1117#issuecomment-2161269886

I have already created a RFE for it https://bugs.openjdk.org/browse/JDK-8333852 and working on the same.

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/1096#issuecomment-2182070087

From bkilambi at openjdk.org  Fri Jun 21 08:40:26 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 21 Jun 2024 08:40:26 GMT
Subject: [lworld+fp16] RFR: 8330021: AArch64: Add backend support for FP16
 add operation [v3]
In-Reply-To: <dJvTuXE58lzqrjSdYe9MjCzKUyBx_0U5Ic9HQOJVTHE=.e8971e4d-dc33-453e-bbf6-49bde906e9b8@github.com>
References: <-sLrODPBVflosNEfVE5yzNdbC2l2AhJ3E-tfyLc3OTc=.606995b7-bdef-4d04-bf84-75ecdc3668fb@github.com>
 <4k-ObapFtD75jAXColXX1lu-LTtkPPZPAdbgkMZqv40=.b3673ca3-1755-4be6-9c68-1786768f670e@github.com>
 <ce8XjDR04Kpf7jcKZS08ZfS2ShIpo7yV9o36h5iTWXc=.a8a54472-b62a-492f-b728-b187899d3b55@github.com>
 <dJvTuXE58lzqrjSdYe9MjCzKUyBx_0U5Ic9HQOJVTHE=.e8971e4d-dc33-453e-bbf6-49bde906e9b8@github.com>
Message-ID: <uuyXTXDbHl7WAJ0zUTXjjKRNEUol8TMOxVH3dkRFdAU=.63c7aed8-6630-465b-9921-04fbcce9c1d3@github.com>

On Fri, 21 Jun 2024 06:09:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hello @jatin-bhateja , I noticed that the vector test - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java` fails on aarch64/x86 machines that support the Float16 feature. Have you noticed this on any of your `avx512_fp16` supporting machines too? I suspect this failure does not show up on github actions for this PR or others because they might be running the tests on non-fp16 supporting hardware.
>> 
>> I digged a bit deeper and found out that the Float16 `add` operation was not getting unrolled in the first place because of which it doesn't get vectorized eventually. I have an internal implementation for other binary FP16 operations (like subtract, multiply, divide, min and max) and none of these operations get vectorized either. After some debugging, I noticed that the inner loop body -> `_body` at this point of code execution - `https://github.com/openjdk/valhalla/blob/404a4fae6fc099cd93cc73d57e29b08b5418adb9/src/hotspot/share/opto/loopTransform.cpp#L1069` contains 188 nodes for Half float add compared to 29 nodes for Float32 add and 31 nodes for FP16 add before the merge on June 9th. I think due to so many nodes in the loop, the unrolling policy decides not to unroll it. 
>> I printed the extra nodes that the loop (for FP16 add operation) contains and I can see nodes like - `DecodeNKlass`, `DecodeN`, `LoadNKlass`, `LoadN`, `CmpP`, `StoreP`, `StoreCM`, `MergeMem`, `EncodeP`, `CastPP` and other pointer related IR nodes and maybe some nodes related to decoding compressed class pointers. Although none of these exist in the FP32 code or the FP16 code before the merge. Do you have any idea about this failure or the extra nodes in the loop?
>
>> Hello @jatin-bhateja , I noticed that the vector test - `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorSum.java` fails on aarch64/x86 machines that support the Float16 feature. Have you noticed this on any of your `avx512_fp16` supporting machines too? I suspect this failure does not show up on github actions for this PR or others because they might be running the tests on non-fp16 supporting hardware.
>> 
>> I digged a bit deeper and found out that the Float16 `add` operation was not getting unrolled in the first place because of which it doesn't get vectorized eventually. I have an internal implementation for other binary FP16 operations (like subtract, multiply, divide, min and max) and none of these operations get vectorized either. After some debugging, I noticed that the inner loop body -> `_body` at this point of code execution - `https://github.com/openjdk/valhalla/blob/404a4fae6fc099cd93cc73d57e29b08b5418adb9/src/hotspot/share/opto/loopTransform.cpp#L1069` contains 188 nodes for Half float add compared to 29 nodes for Float32 add and 31 nodes for FP16 add before the merge on June 9th. I think due to so many nodes in the loop, the unrolling policy decides not to unroll it. I printed the extra nodes that the loop (for FP16 add operation) contains and I can see nodes like - `DecodeNKlass`, `DecodeN`, `LoadNKlass`, `LoadN`, `CmpP`, `StoreP`, `StoreCM`, `MergeMem`, `EncodeP`, `Cast
 PP` and other pointer related IR nodes and maybe some nodes related to decoding compressed class pointers. Although none of these exist in the FP32 code or the FP16 code before the merge. Do you have any idea about this failure or the extra nodes in the loop?
> 
> Hi @Bhavana-Kilambi , 
> 
> Flat array layout is currently broken, it used to work when Float16 was a primitive value class, please refer following link for more details.
> https://github.com/openjdk/valhalla/pull/1117#issuecomment-2161269886
> 
> I have already created a RFE for it https://bugs.openjdk.org/browse/JDK-8333852 and working on the same.
> 
> Best Regards,
> Jatin

Thanks @jatin-bhateja. I seem to have missed this RFE. I get it now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1096#issuecomment-2182283500

From rgiulietti at openjdk.org  Fri Jun 21 14:19:23 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 21 Jun 2024 14:19:23 GMT
Subject: [lworld+fp16] RFR: 8334432: Refine Float16.fma
In-Reply-To: <N4FgYFfNy05Hi4FKmTYogez0-XpmlUTFAr5Mvcpu_wo=.9dae7548-f67f-42cd-80cd-f25eec2161ff@github.com>
References: <N4FgYFfNy05Hi4FKmTYogez0-XpmlUTFAr5Mvcpu_wo=.9dae7548-f67f-42cd-80cd-f25eec2161ff@github.com>
Message-ID: <SgqubywxdhB9vYhVFUEbIJntDMSpBaBLoCbWn6zrbZM=.ee66257a-61f0-4c5b-8341-4046d522be40@github.com>

On Fri, 21 Jun 2024 04:36:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Adding comments and test cases for Float16.fma.

The analysis done [here](https://github.com/openjdk/valhalla/pull/1117#issuecomment-2174342914) seems correct, but there is an implicit suspension moment in the last case.

> That leaves possibly non-exact product-sum with a combination of product in the subnormal range of Float16 and the c term to be added in being not-small. However, if this product-sum is non-exact, the smaller term from the product, with at most 22 exponent bit positions set, and the the 11 bits from c being summed in, must be separated by at least 53 - (22 + 11) = 20 bit positions otherwise the product-sum would fit in a double. I believe this implies at least one of the double-rounding scenarios cannot occur, in particular a half-way result in the smaller precision, Float16 in this case, rounding differently because sticky bit information from the higher precision was rounded away.

Here's a further analysis of this case.

Double rounding is usually harmless. It is harmful only in two situations:

- The first rounding from the exact value to the extended precision (here `double`) happens to be directed _toward_ 0 to a value exactly midway between two adjacent working precision (here `float16`) values, followed by a second rounding from there which again happens to be directed _toward_ 0 to one of these values (the one with lesser magnitude).
  A single rounding from the exact value to the working precision, in contrast, rounds to the value with larger magnitude.
- Symmetrically, the first rounding to the extended precision happens to be directed _away_ from 0 to a value exactly midway between two adjacent working precision values, followed by a second rounding from there which again happens to be directed _away_ from 0 to one of these values (the one with larger magnitude).
  However, a single rounding from the exact value to the working precision rounds to the value with lesser magnitude.

In any other case double rounding is innocuous, returning the same value as a single rounding to the working precision.
We only need to ensure that the first rounding to `double` does not produce the midpoint of two adjacent `float16` values.

- If a?b and c have the same sign, the sum a?b + c has a significand with a large gap of 20 or more 0s between the bits of the signifcand of c to the left (at most 11 bits) and those of the product a?b to the right (at most 22 bits).
The rounding bit for the final working precision of `float16` is the leftmost 0 in the gap.
  - If rounding to `double` is directed toward 0, all the 0s in the gap are preserved, thus the `float16` rounding bit is unaffected and remains 0. This means that the `double` value is _not_ the midpoint  of two adjacent `float16` values, so double rounding is harmless.
  - If rounding to `double` is directed away form 0, the rightmost 0 in the gap might be replaced by a 1, but the others are unaffected, including the `float16` rounding bit. Again, this shows that the `double` value is _not_ the midpoint  of two adjacent `float16` values, and double rounding is innocuous.

- If a?b and c have opposite signs, the sum a?b + c the long gap of 0s above is replaced by a long gap of 1s. The `float16` rounding bit is the leftmost 1 in the gap, or the second leftmost 1 iff c is a power of 2. In both cases, the rounding bit is followed by at least another 1.
  - If rounding to `double` is directed toward 0, the `float16` rounding bit and its follower are preserved and both 1, so the `double` value is _not_ the midpoint  of two adjacent `float16` values, and double rounding is harmless.
  - If rounding to `double` is directed away from 0, the `float16` rounding bit and its follower are either preserved (both 1), or both switch to 0. Either way, the `double` value is again _not_ the midpoint  of two adjacent `float16` values, and double rounding is harmless.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1143#issuecomment-2182843647

From fparain at openjdk.org  Fri Jun 21 14:42:42 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 21 Jun 2024 14:42:42 GMT
Subject: [lworld] RFR: 8334729: [lworld] CDS should no force the computation of
 identity hash code for value instances
Message-ID: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>

Simple fix to prevent the VM thread from calling back to Java code when archiving value instances.

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

Commit messages:
 - Prevent CDS code from calling Java code from VM thread

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

PR: https://git.openjdk.org/valhalla/pull/1144

From rriggs at openjdk.org  Fri Jun 21 15:25:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Jun 2024 15:25:22 GMT
Subject: [lworld] Integrated: 8294866: [lworld] Array classes access flags
 should include identity bits
In-Reply-To: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
References: <923nKdYv28-1GHTw4bOMu7DykD3K_XTkzILY650uccI=.2953099c-4f28-4ff3-8831-de94c772b3af@github.com>
Message-ID: <0WaMwohArX4CNNQAwJRlNmtr56krIMbGUBXDkiDudrA=.f2e36eeb-1484-4ef9-a510-aa8b2c7ff25b@github.com>

On Thu, 20 Jun 2024 14:38:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update java.lang.reflect.AccessFlag to return IDENTITY for array classes.
> The access flag bits for arrays come from the VM, hence the changes to HotSpot.

This pull request has now been integrated.

Changeset: 83b94744
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/83b947445789187ae0e0dc5be1ba48c5350e6c9e
Stats:     25 lines in 7 files changed: 14 ins; 0 del; 11 mod

8294866: [lworld] Array classes access flags should include identity bits

Reviewed-by: liach, heidinga, vromero, fparain

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

PR: https://git.openjdk.org/valhalla/pull/1141

From fparain at openjdk.org  Fri Jun 21 19:13:31 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 21 Jun 2024 19:13:31 GMT
Subject: [lworld] Integrated: 8334746: [lworld] GTestWrapper.java fails because
 of LogSelectionList
Message-ID: <gBcDRuRLBrC5Qud9DQf3TUqp5OF1jbAQSlxGAEfoIGY=.baa3e53a-80e3-4bae-a8b3-1584fc0ffa8d@github.com>

Simple fix copied from JDK-8327098.

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

Commit messages:
 - Increase hard coded limit

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

PR: https://git.openjdk.org/valhalla/pull/1145

From fparain at openjdk.org  Fri Jun 21 19:13:31 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 21 Jun 2024 19:13:31 GMT
Subject: [lworld] Integrated: 8334746: [lworld] GTestWrapper.java fails because
 of LogSelectionList
In-Reply-To: <gBcDRuRLBrC5Qud9DQf3TUqp5OF1jbAQSlxGAEfoIGY=.baa3e53a-80e3-4bae-a8b3-1584fc0ffa8d@github.com>
References: <gBcDRuRLBrC5Qud9DQf3TUqp5OF1jbAQSlxGAEfoIGY=.baa3e53a-80e3-4bae-a8b3-1584fc0ffa8d@github.com>
Message-ID: <c6xu-QGBjOT_dwCOehqBdQ8EogMAaVXYinBiGLU0DKQ=.53ae98e2-63d9-4a15-9b07-4b64d91494b5@github.com>

On Fri, 21 Jun 2024 19:08:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple fix copied from JDK-8327098.

This pull request has now been integrated.

Changeset: 77bc8d35
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/77bc8d35bfcb827d3998b95ab0ba71c254e19f3c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8334746: [lworld] GTestWrapper.java fails because of LogSelectionList

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

PR: https://git.openjdk.org/valhalla/pull/1145

From darcy at openjdk.org  Fri Jun 21 20:13:20 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 21 Jun 2024 20:13:20 GMT
Subject: [lworld+fp16] RFR: 8334432: Refine Float16.fma
In-Reply-To: <SgqubywxdhB9vYhVFUEbIJntDMSpBaBLoCbWn6zrbZM=.ee66257a-61f0-4c5b-8341-4046d522be40@github.com>
References: <N4FgYFfNy05Hi4FKmTYogez0-XpmlUTFAr5Mvcpu_wo=.9dae7548-f67f-42cd-80cd-f25eec2161ff@github.com>
 <SgqubywxdhB9vYhVFUEbIJntDMSpBaBLoCbWn6zrbZM=.ee66257a-61f0-4c5b-8341-4046d522be40@github.com>
Message-ID: <EUfqo8RLY-J6vCudFNaIDu_nrPbSCnAfpBTMkG2Qz3k=.9977a900-815e-4ce6-b098-1aa1ea536ed1@github.com>

On Fri, 21 Jun 2024 14:17:02 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> The analysis done [here](https://github.com/openjdk/valhalla/pull/1117#issuecomment-2174342914) seems correct, but there is an implicit suspension moment in the last case.
> 
> > That leaves possibly non-exact product-sum with a combination of product in the subnormal range of Float16 and the c term to be added in being not-small. However, if this product-sum is non-exact, the smaller term from the product, with at most 22 exponent bit positions set, and the the 11 bits from c being summed in, must be separated by at least 53 - (22 + 11) = 20 bit positions otherwise the product-sum would fit in a double. I believe this implies at least one of the double-rounding scenarios cannot occur, in particular a half-way result in the smaller precision, Float16 in this case, rounding differently because sticky bit information from the higher precision was rounded away.
> 
> Here's a further analysis of this case.
> 
> Double rounding is usually harmless. It is harmful only in two situations:
> 
>     * The first rounding from the exact value to the extended precision (here `double`) happens to be directed _toward_ 0 to a value exactly midway between two adjacent working precision (here `float16`) values, followed by a second rounding from there which again happens to be directed _toward_ 0 to one of these values (the one with lesser magnitude).
>       A single rounding from the exact value to the working precision, in contrast, rounds to the value with larger magnitude.
> 
>     * Symmetrically, the first rounding to the extended precision happens to be directed _away_ from 0 to a value exactly midway between two adjacent working precision values, followed by a second rounding from there which again happens to be directed _away_ from 0 to one of these values (the one with larger magnitude).
>       However, a single rounding from the exact value to the working precision rounds to the value with lesser magnitude.
> 
> 
> In any other case double rounding is innocuous, returning the same value as a single rounding to the working precision. We only need to ensure that the first rounding to `double` does not produce the midpoint of two adjacent `float16` values.
> 
>     * If a?b and c have the same sign, the sum a?b + c has a significand with a large gap of 20 or more 0s between the bits of the signifcand of c to the left (at most 11 bits) and those of the product a?b to the right (at most 22 bits).
>       The rounding bit for the final working precision of `float16` is the leftmost 0 in the gap.
>       
>       * If rounding to `double` is directed toward 0, all the 0s in the gap are preserved, thus the `float16` rounding bit is unaffected and remains 0. This means that the `double` value is _not_ the midpoint  of two adjacent `float16` values, so double rounding is harmless.
>       * If rounding to `double` is directed away form 0, the rightmost 0 in the gap might be replaced by a 1, but the others are unaffected, including the `float16` rounding bit. Again, this shows that the `double` value is _not_ the midpoint  of two adjacent `float16` values, and double rounding is innocuous.
> 
>     * If a?b and c have opposite signs, the sum a?b + c the long gap of 0s above is replaced by a long gap of 1s. The `float16` rounding bit is the leftmost 1 in the gap, or the second leftmost 1 iff c is a power of 2. In both cases, the rounding bit is followed by at least another 1.
>       
>       * If rounding to `double` is directed toward 0, the `float16` rounding bit and its follower are preserved and both 1, so the `double` value is _not_ the midpoint  of two adjacent `float16` values, and double rounding is harmless.
>       * If rounding to `double` is directed away from 0, the `float16` rounding bit and its follower are either preserved (both 1), or both switch to 0. Either way, the `double` value is again _not_ the midpoint  of two adjacent `float16` values, and double rounding is harmless.

Thanks; that agrees with the sketch of those cases I was working on. I'll update the explanatory comment and cleanup the implementation accordingly.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1143#issuecomment-2183387134

From duke at openjdk.org  Mon Jun 24 02:01:18 2024
From: duke at openjdk.org (duke)
Date: Mon, 24 Jun 2024 02:01:18 GMT
Subject: [valhalla-docs] Withdrawn: 01-background.md: fix link
 in-defense-of-erasure md
In-Reply-To: <ze8d-67Y1Avx0xJ_2Zs0_qXdbbvBBv-LwrRfIpgVTJI=.8f90b28b-48ea-4574-b62d-7b567c0cf43d@github.com>
References: <ze8d-67Y1Avx0xJ_2Zs0_qXdbbvBBv-LwrRfIpgVTJI=.8f90b28b-48ea-4574-b62d-7b567c0cf43d@github.com>
Message-ID: <mse9KFSYPW3BQpGA2gmpz8hZ0e1iFD_Wv1WdYlsJSxY=.fb7c7149-65b5-46a8-a5e4-cd8c9023b8af@github.com>

On Wed, 3 Apr 2024 14:14:58 GMT, Federico Medina <duke at openjdk.org> wrote:

> Udate link `in-defense-of-erasure.html` -> `in-defense-of-erasure`

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla-docs/pull/12

From heidinga at openjdk.org  Mon Jun 24 12:33:23 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 24 Jun 2024 12:33:23 GMT
Subject: [lworld] RFR: 8334729: [lworld] CDS should not force the
 computation of identity hash code for value instances
In-Reply-To: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>
References: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>
Message-ID: <LKZFrgtTwcZcCJcscnrKxACiywUGhhkdlC85zub9wDY=.e48b13bd-3fb6-4e07-be4f-7f240a759d49@github.com>

On Fri, 21 Jun 2024 14:38:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple fix to prevent the VM thread from calling back to Java code when archiving value instances.

Lgtm

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1144#pullrequestreview-2135668822

From fparain at openjdk.org  Mon Jun 24 13:02:22 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 24 Jun 2024 13:02:22 GMT
Subject: [lworld] Integrated: 8334729: [lworld] CDS should not force the
 computation of identity hash code for value instances
In-Reply-To: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>
References: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>
Message-ID: <0C_q4UuR0OnxyATIrn1nr2p8QInW91_CA5sbQgZdPQ8=.8bd729d1-3f6a-496f-abaa-6adaa4c5e49b@github.com>

On Fri, 21 Jun 2024 14:38:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple fix to prevent the VM thread from calling back to Java code when archiving value instances.

This pull request has now been integrated.

Changeset: 157a0a10
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/157a0a1023a68d6f585de018a69d9e54bce00e7b
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8334729: [lworld] CDS should not force the computation of identity hash code for value instances

Reviewed-by: heidinga

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

PR: https://git.openjdk.org/valhalla/pull/1144

From fparain at openjdk.org  Mon Jun 24 13:02:22 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 24 Jun 2024 13:02:22 GMT
Subject: [lworld] RFR: 8334729: [lworld] CDS should not force the
 computation of identity hash code for value instances
In-Reply-To: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>
References: <uyAZ6oJXT8hPogc0dEO-YXkCYGpdaZQBb3MH4LDANCM=.d9b540a9-73a1-4ce2-9c43-b2d341224013@github.com>
Message-ID: <uXmNOeLLcEergfDgyQgCdYdgIwQMX5CDOqm7hRjORSo=.101258ca-c1ae-429c-9419-f2578ae7e5ae@github.com>

On Fri, 21 Jun 2024 14:38:22 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple fix to prevent the VM thread from calling back to Java code when archiving value instances.

Thank you for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1144#issuecomment-2186525564

From fparain at openjdk.org  Tue Jun 25 20:11:39 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 25 Jun 2024 20:11:39 GMT
Subject: [lworld] RFR: 8334747: [lworld] C1 needs adjustments after JDK-8294866
Message-ID: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>

Adjustments in C1 after the addition of ACC_IDENTITY to arrays' modifiers.

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

Commit messages:
 - Re-implement without branches
 - Fix getModifiers in C1 code

Changes: https://git.openjdk.org/valhalla/pull/1146/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1146&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334747
  Stats: 48 lines in 3 files changed: 25 ins; 2 del; 21 mod
  Patch: https://git.openjdk.org/valhalla/pull/1146.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1146/head:pull/1146

PR: https://git.openjdk.org/valhalla/pull/1146

From thartmann at openjdk.org  Wed Jun 26 08:29:33 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 26 Jun 2024 08:29:33 GMT
Subject: [lworld] RFR: 8334747: [lworld] C1 needs adjustments after
 JDK-8294866
In-Reply-To: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>
References: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>
Message-ID: <dfZL2hzVu3Sf0OsgxM5b58tUKN0JHlHxqIb85qUblPw=.7d618609-2640-4396-8ac9-0177ce314b37@github.com>

On Mon, 24 Jun 2024 22:17:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Adjustments in C1 after the addition of ACC_IDENTITY to arrays' modifiers.

Looks good to me. Thanks for fixing!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1146#pullrequestreview-2141094491

From fparain at openjdk.org  Wed Jun 26 10:59:27 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 26 Jun 2024 10:59:27 GMT
Subject: [lworld] RFR: 8334747: [lworld] C1 needs adjustments after
 JDK-8294866
In-Reply-To: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>
References: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>
Message-ID: <v-aoKqA-cvdQ9j8fP9yMYUipUOpDIXxGIW5o-0KvTnU=.67796cd2-4ce9-4773-9eeb-0516e1b94957@github.com>

On Mon, 24 Jun 2024 22:17:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Adjustments in C1 after the addition of ACC_IDENTITY to arrays' modifiers.

Thank you for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1146#issuecomment-2191408183

From fparain at openjdk.org  Wed Jun 26 10:59:28 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 26 Jun 2024 10:59:28 GMT
Subject: [lworld] Integrated: 8334747: [lworld] C1 needs adjustments after
 JDK-8294866
In-Reply-To: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>
References: <Vm5-Xo80eYCv07cY_7KFjw61CDXp0B5J1RslAiao60E=.49f9f413-40a3-4029-badb-21aa1431c6cb@github.com>
Message-ID: <2KRjyFwSQOT6URS5epyaM-8hKcVChBNxBTCvF9LDbO8=.018a5656-8a05-40ce-a95e-faf94e981cfc@github.com>

On Mon, 24 Jun 2024 22:17:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Adjustments in C1 after the addition of ACC_IDENTITY to arrays' modifiers.

This pull request has now been integrated.

Changeset: 38f1e93e
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/38f1e93eb4778ec804028e6266715077a08ecfd2
Stats:     48 lines in 3 files changed: 25 ins; 2 del; 21 mod

8334747: [lworld] C1 needs adjustments after JDK-8294866

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1146

From vromero at openjdk.org  Wed Jun 26 11:18:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 26 Jun 2024 11:18:42 GMT
Subject: [lworld] Integrated: 8334692: [lworld] add missing compiler warnings
Message-ID: <Ntg1an0AGDIAzH-ZU65nszXFLzFQMVE2gABCtvsdbCQ=.a1fdd06a-44af-4c72-b4f0-4e0e7c29a31d@github.com>

adding warning for value classes declaring a `finalize` method and warnings related to the new serialization

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

Commit messages:
 - white space
 - fixing comment
 - fixing comment
 - minor change
 - 8334692: [lworld] add missing compiler warnings

Changes: https://git.openjdk.org/valhalla/pull/1147/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1147&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334692
  Stats: 376 lines in 9 files changed: 324 ins; 9 del; 43 mod
  Patch: https://git.openjdk.org/valhalla/pull/1147.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1147/head:pull/1147

PR: https://git.openjdk.org/valhalla/pull/1147

From vromero at openjdk.org  Wed Jun 26 11:18:44 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 26 Jun 2024 11:18:44 GMT
Subject: [lworld] Integrated: 8334692: [lworld] add missing compiler warnings
In-Reply-To: <Ntg1an0AGDIAzH-ZU65nszXFLzFQMVE2gABCtvsdbCQ=.a1fdd06a-44af-4c72-b4f0-4e0e7c29a31d@github.com>
References: <Ntg1an0AGDIAzH-ZU65nszXFLzFQMVE2gABCtvsdbCQ=.a1fdd06a-44af-4c72-b4f0-4e0e7c29a31d@github.com>
Message-ID: <kUWYyIrj3bg5Dw_OtsuvyDQ-PrvaHhxkX6zi35b7fcs=.a126fe14-cb41-49dc-9d42-2bb91969c158@github.com>

On Wed, 26 Jun 2024 02:20:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding warning for value classes declaring a `finalize` method and warnings related to the new serialization

This pull request has now been integrated.

Changeset: 76306cb0
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/76306cb0b5f887e77778db496d7a9ad35c2bcac3
Stats:     376 lines in 9 files changed: 324 ins; 9 del; 43 mod

8334692: [lworld] add missing compiler warnings

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

PR: https://git.openjdk.org/valhalla/pull/1147

From rriggs at openjdk.org  Wed Jun 26 13:25:28 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 26 Jun 2024 13:25:28 GMT
Subject: [lworld] Integrated: 8334692: [lworld] add missing compiler
 warnings
In-Reply-To: <Ntg1an0AGDIAzH-ZU65nszXFLzFQMVE2gABCtvsdbCQ=.a1fdd06a-44af-4c72-b4f0-4e0e7c29a31d@github.com>
References: <Ntg1an0AGDIAzH-ZU65nszXFLzFQMVE2gABCtvsdbCQ=.a1fdd06a-44af-4c72-b4f0-4e0e7c29a31d@github.com>
Message-ID: <34rCuCbLcpciLxFNpjDYvWK-dnPC2a0uHMqwVPsbeWU=.3c10caa9-b489-4d1c-8692-3b319dcda463@github.com>

On Wed, 26 Jun 2024 02:20:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding warning for value classes declaring a `finalize` method and warnings related to the new serialization

The bug closed as a duplicate intended to add a javadoc note on the non-applicability of finalize to value objects.
I had added a comment to 8334692, to make sure it didn't get missed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1147#issuecomment-2191689864

From vromero at openjdk.org  Wed Jun 26 14:49:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 26 Jun 2024 14:49:30 GMT
Subject: [lworld] Integrated: 8334692: [lworld] add missing compiler
 warnings
In-Reply-To: <34rCuCbLcpciLxFNpjDYvWK-dnPC2a0uHMqwVPsbeWU=.3c10caa9-b489-4d1c-8692-3b319dcda463@github.com>
References: <Ntg1an0AGDIAzH-ZU65nszXFLzFQMVE2gABCtvsdbCQ=.a1fdd06a-44af-4c72-b4f0-4e0e7c29a31d@github.com>
 <34rCuCbLcpciLxFNpjDYvWK-dnPC2a0uHMqwVPsbeWU=.3c10caa9-b489-4d1c-8692-3b319dcda463@github.com>
Message-ID: <GdYCZPYZuMpTORj9gRCZ0DKQXGhJCru5WPxtgFeAREA=.cbc8ab51-f12c-412a-a2ab-fc954234c981@github.com>

On Wed, 26 Jun 2024 13:22:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The bug closed as a duplicate intended to add a javadoc note on the non-applicability of finalize to value objects. I had added a comment to 8334692, to make sure it didn't get missed.

true, I had a note for that, I forgot sorry

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

PR Comment: https://git.openjdk.org/valhalla/pull/1147#issuecomment-2191897746

From fparain at openjdk.org  Thu Jun 27 12:43:31 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 27 Jun 2024 12:43:31 GMT
Subject: [lworld] RFR: 8335254: [lworld] Test ObjectMethods.java doesn't test
 Object's default clone() method on values
Message-ID: <YkB7-m_Pkl_rq-l90jrtF09QnXWPGnDKCjU-yobCRT4=.3ca5d174-a3ef-447c-888a-236646f1878b@github.com>

Increase test coverage of cloneable values.

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

Commit messages:
 - Extend test to cloneable values

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

PR: https://git.openjdk.org/valhalla/pull/1148

From chagedorn at openjdk.org  Thu Jun 27 13:35:39 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 27 Jun 2024 13:35:39 GMT
Subject: [lworld] RFR: 8334546: [lworld] C2: Calling clone() on non-allocated
 inline types fails with "Should have been buffered"
Message-ID: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>

We are currently not handling inline types in the `clone()` instrinsic because it was not possible for a value class to implement `Cloneable`. This changed with [JDK-8332243](https://bugs.openjdk.org/browse/JDK-8332243). A value class now trivially returns the inline type because it has no identity. We need to do the same in the C2 intrinsic for `clone()` when we have an inline type (currently, we are hitting an assert later).

Thanks,
Christian

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

Commit messages:
 - 8334546: [lworld] C2: Calling clone() on non-allocated inline types fails with "Should have been buffered"

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

PR: https://git.openjdk.org/valhalla/pull/1149

From thartmann at openjdk.org  Thu Jun 27 14:16:20 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 27 Jun 2024 14:16:20 GMT
Subject: [lworld] RFR: 8334546: [lworld] C2: Calling clone() on
 non-allocated inline types fails with "Should have been buffered"
In-Reply-To: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
References: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
Message-ID: <kKksO2XKhZSI3aiq3Q2dA_wzAhC-hhrBczdXy-CuILA=.76ce39ef-1464-4b1a-86df-adf5dd238b60@github.com>

On Thu, 27 Jun 2024 13:30:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> We are currently not handling inline types in the `clone()` instrinsic because it was not possible for a value class to implement `Cloneable`. This changed with [JDK-8332243](https://bugs.openjdk.org/browse/JDK-8332243). A value class now trivially returns the inline type because it has no identity. We need to do the same in the C2 intrinsic for `clone()` when we have an inline type (currently, we are hitting an assert later).
> 
> Thanks,
> Christian

Looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1149#pullrequestreview-2145519212

From fparain at openjdk.org  Thu Jun 27 21:02:52 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 27 Jun 2024 21:02:52 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify the
 value class
Message-ID: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>

Improve the message of IdentityException by including the class of the instance that triggered the exception.

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

Commit messages:
 - Improve IdentityException message

Changes: https://git.openjdk.org/valhalla/pull/1150/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282106
  Stats: 118 lines in 10 files changed: 109 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/1150.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1150/head:pull/1150

PR: https://git.openjdk.org/valhalla/pull/1150

From thartmann at openjdk.org  Fri Jun 28 06:09:32 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 28 Jun 2024 06:09:32 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class
In-Reply-To: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
Message-ID: <PHCg6WtQEgL1bQmwSNvpIuMgUEYbyTDOTot0tLD6Bw0=.84c8e165-7c09-457f-bb22-8b91d83080df@github.com>

On Thu, 27 Jun 2024 20:58:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Improve the message of IdentityException by including the class of the instance that triggered the exception.

What about AArch64? Wouldn't the test now fail on that platform?

test/hotspot/jtreg/runtime/valhalla/inlinetypes/MonitorEnterTest.java line 55:

> 53: 
> 54:   static void monitorEnter(Object o, boolean expectSuccess, String message) {
> 55:     try {

Should be 4-whitespace indentation for Java code.

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

PR Review: https://git.openjdk.org/valhalla/pull/1150#pullrequestreview-2147127579
PR Review Comment: https://git.openjdk.org/valhalla/pull/1150#discussion_r1658198952

From chagedorn at openjdk.org  Fri Jun 28 09:09:34 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 28 Jun 2024 09:09:34 GMT
Subject: [lworld] RFR: 8334546: [lworld] C2: Calling clone() on
 non-allocated inline types fails with "Should have been buffered"
In-Reply-To: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
References: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
Message-ID: <34qA2sd0XHClJdDdEVXyIVCQkke62l71IyMLLkWmd-4=.254ba769-b0f0-4abf-8ee9-97996dc349ff@github.com>

On Thu, 27 Jun 2024 13:30:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> We are currently not handling inline types in the `clone()` instrinsic because it was not possible for a value class to implement `Cloneable`. This changed with [JDK-8332243](https://bugs.openjdk.org/browse/JDK-8332243). A value class now trivially returns the inline type because it has no identity. We need to do the same in the C2 intrinsic for `clone()` when we have an inline type (currently, we are hitting an assert later).
> 
> Thanks,
> Christian

Thanks Tobias for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1149#issuecomment-2196459134

From duke at openjdk.org  Fri Jun 28 09:09:34 2024
From: duke at openjdk.org (duke)
Date: Fri, 28 Jun 2024 09:09:34 GMT
Subject: [lworld] RFR: 8334546: [lworld] C2: Calling clone() on
 non-allocated inline types fails with "Should have been buffered"
In-Reply-To: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
References: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
Message-ID: <WY_TDDXOKfN56LiN6VOkHK0lJYF7PR0Rq4iPcAj9GXo=.5ce6e172-03c9-43cc-bab8-c4beab4fa71a@github.com>

On Thu, 27 Jun 2024 13:30:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> We are currently not handling inline types in the `clone()` instrinsic because it was not possible for a value class to implement `Cloneable`. This changed with [JDK-8332243](https://bugs.openjdk.org/browse/JDK-8332243). A value class now trivially returns the inline type because it has no identity. We need to do the same in the C2 intrinsic for `clone()` when we have an inline type (currently, we are hitting an assert later).
> 
> Thanks,
> Christian

@chhagedorn 
Your change (at version bd1d725da26c4f78ae4950a1ffc03c1f1f5fa784) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1149#issuecomment-2196462433

From chagedorn at openjdk.org  Fri Jun 28 12:14:41 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 28 Jun 2024 12:14:41 GMT
Subject: [lworld] Integrated: 8334546: [lworld] C2: Calling clone() on
 non-allocated inline types fails with "Should have been buffered"
In-Reply-To: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
References: <ffwt0TgiJ4HHb39qFvIMefZzfiRbGZAp2WZu2g24Ijg=.f14aec62-9a3f-497e-aef2-21a697d924aa@github.com>
Message-ID: <n-p6ukvlSpufVi2lenaJv-ckRpmR1LiiRqQQYu9c8no=.baba83ec-1947-48d5-809e-3295c954ced8@github.com>

On Thu, 27 Jun 2024 13:30:55 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> We are currently not handling inline types in the `clone()` instrinsic because it was not possible for a value class to implement `Cloneable`. This changed with [JDK-8332243](https://bugs.openjdk.org/browse/JDK-8332243). A value class now trivially returns the inline type because it has no identity. We need to do the same in the C2 intrinsic for `clone()` when we have an inline type (currently, we are hitting an assert later).
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 09014c77
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/09014c776169fe92ebbf0f69b8cbd696fb41b217
Stats:     35 lines in 2 files changed: 35 ins; 0 del; 0 mod

8334546: [lworld] C2: Calling clone() on non-allocated inline types fails with "Should have been buffered"

Reviewed-by: thartmann

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

PR: https://git.openjdk.org/valhalla/pull/1149

From fparain at openjdk.org  Fri Jun 28 12:56:56 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Jun 2024 12:56:56 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v2]
In-Reply-To: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
Message-ID: <t3u6V4iJ9UZZnAlfqeIEgE_zvBgY6_3EHxGLMz9UpT0=.45247065-f0c8-4882-aaa0-09b825d90748@github.com>

> Improve the message of IdentityException by including the class of the instance that triggered the exception.

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

 - Fix indentation
 - Add aarch64 support

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1150/files
  - new: https://git.openjdk.org/valhalla/pull/1150/files/c5c859a0..866b2b0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1150&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1150&range=00-01

  Stats: 28 lines in 4 files changed: 7 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1150.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1150/head:pull/1150

PR: https://git.openjdk.org/valhalla/pull/1150

From tobias.hartmann at oracle.com  Fri Jun 28 13:11:14 2024
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 28 Jun 2024 15:11:14 +0200
Subject: Result: New Valhalla Committer: Christian Hagedorn
Message-ID: <ab6e36c2-8e07-4100-97ac-571d379ec227@oracle.com>

Voting for Christian Hagedorn [1] is now closed.

Yes: 5
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination.

Thanks,
Tobias

[1] https://mail.openjdk.org/pipermail/valhalla-dev/2024-June/012567.html

From fparain at openjdk.org  Fri Jun 28 13:19:34 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Jun 2024 13:19:34 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v2]
In-Reply-To: <PHCg6WtQEgL1bQmwSNvpIuMgUEYbyTDOTot0tLD6Bw0=.84c8e165-7c09-457f-bb22-8b91d83080df@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
 <PHCg6WtQEgL1bQmwSNvpIuMgUEYbyTDOTot0tLD6Bw0=.84c8e165-7c09-457f-bb22-8b91d83080df@github.com>
Message-ID: <TBkN4xfQ_DcvieR7BHtPaRjycVp2mRH1Yl777DwThhI=.2eb0f4a9-22e8-407b-b987-8487086ce6cb@github.com>

On Fri, 28 Jun 2024 06:05:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix indentation
>>  - Add aarch64 support
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/MonitorEnterTest.java line 55:
> 
>> 53: 
>> 54:   static void monitorEnter(Object o, boolean expectSuccess, String message) {
>> 55:     try {
> 
> Should be 4-whitespace indentation for Java code.

Fixed

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1150#discussion_r1658731216

From fparain at openjdk.org  Fri Jun 28 13:22:26 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Jun 2024 13:22:26 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v2]
In-Reply-To: <t3u6V4iJ9UZZnAlfqeIEgE_zvBgY6_3EHxGLMz9UpT0=.45247065-f0c8-4882-aaa0-09b825d90748@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
 <t3u6V4iJ9UZZnAlfqeIEgE_zvBgY6_3EHxGLMz9UpT0=.45247065-f0c8-4882-aaa0-09b825d90748@github.com>
Message-ID: <3-d91a3DJ8O39as-2YosYvzixQ15yViI0d5j_pLqZ6Y=.54979342-9366-410e-9311-d2bbfb8d47ea@github.com>

On Fri, 28 Jun 2024 12:56:56 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Improve the message of IdentityException by including the class of the instance that triggered the exception.
>
> Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix indentation
>  - Add aarch64 support

Thank your for the reminder for aarch64 (the Mach5 job I ran last night reminded it to me as well).
Now aarch64 changes are included (they are similar to the x64 changes).
Failed tests on Mach5 have been tested locally, and there's a new Mach5 job testing the updated patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1150#issuecomment-2196889782

From rriggs at openjdk.org  Fri Jun 28 14:45:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 28 Jun 2024 14:45:27 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v2]
In-Reply-To: <t3u6V4iJ9UZZnAlfqeIEgE_zvBgY6_3EHxGLMz9UpT0=.45247065-f0c8-4882-aaa0-09b825d90748@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
 <t3u6V4iJ9UZZnAlfqeIEgE_zvBgY6_3EHxGLMz9UpT0=.45247065-f0c8-4882-aaa0-09b825d90748@github.com>
Message-ID: <_APRYXJbbRfFVCvYBnDrrXO_dHrUUQcplcmzcYLE49c=.3221b628-7095-4d80-8569-681af92be183@github.com>

On Fri, 28 Jun 2024 12:56:56 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Improve the message of IdentityException by including the class of the instance that triggered the exception.
>
> Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix indentation
>  - Add aarch64 support

test/hotspot/jtreg/runtime/valhalla/inlinetypes/MonitorEnterTest.java line 29:

> 27: * @enablePreview
> 28: * @compile TestCloneableValue.java
> 29: * @run main/othervm -XX:LockingMode=0 runtime.valhalla.inlinetypes.TestCloneableValue

I'm missing the connection between TestCloneableValue and MonitorEnterTest?
Should the @run line refer to MonitorEnterTest.MyValue?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1150#discussion_r1658864680

From fparain at openjdk.org  Fri Jun 28 15:06:29 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Jun 2024 15:06:29 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v3]
In-Reply-To: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
Message-ID: <gVwG2C7qQ-4fwbFT5prSOZH3HNmIUzG1kFXjOZsSpl4=.0292d50c-b96b-4835-8f2a-a8e87be18978@github.com>

> Improve the message of IdentityException by including the class of the instance that triggered the exception.

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

  Fix test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1150/files
  - new: https://git.openjdk.org/valhalla/pull/1150/files/866b2b0d..6d96f353

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1150&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1150&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1150.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1150/head:pull/1150

PR: https://git.openjdk.org/valhalla/pull/1150

From fparain at openjdk.org  Fri Jun 28 15:54:27 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Jun 2024 15:54:27 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v2]
In-Reply-To: <_APRYXJbbRfFVCvYBnDrrXO_dHrUUQcplcmzcYLE49c=.3221b628-7095-4d80-8569-681af92be183@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
 <t3u6V4iJ9UZZnAlfqeIEgE_zvBgY6_3EHxGLMz9UpT0=.45247065-f0c8-4882-aaa0-09b825d90748@github.com>
 <_APRYXJbbRfFVCvYBnDrrXO_dHrUUQcplcmzcYLE49c=.3221b628-7095-4d80-8569-681af92be183@github.com>
Message-ID: <W1EenHGbhR11Y-FBTLKbkVBldmI6cbs-FGza4KyCiSI=.f56438f6-ca0f-4cf0-b939-2280d4c1f4e9@github.com>

On Fri, 28 Jun 2024 14:43:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix indentation
>>  - Add aarch64 support
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/MonitorEnterTest.java line 29:
> 
>> 27: * @enablePreview
>> 28: * @compile TestCloneableValue.java
>> 29: * @run main/othervm -XX:LockingMode=0 runtime.valhalla.inlinetypes.TestCloneableValue
> 
> I'm missing the connection between TestCloneableValue and MonitorEnterTest?
> Should the @run line refer to MonitorEnterTest.MyValue?

Good catch! This is not the test I used during development, but one that I wrote after, and I clearly did it too quickly.
I've pushed a fix for the test that should address this issue (and a few others in the test itself).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1150#discussion_r1658948546

From fparain at openjdk.org  Fri Jun 28 17:36:35 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Jun 2024 17:36:35 GMT
Subject: [lworld] Integrated: 8335254: [lworld] Test ObjectMethods.java doesn't
 test Object's default clone() method on values
In-Reply-To: <YkB7-m_Pkl_rq-l90jrtF09QnXWPGnDKCjU-yobCRT4=.3ca5d174-a3ef-447c-888a-236646f1878b@github.com>
References: <YkB7-m_Pkl_rq-l90jrtF09QnXWPGnDKCjU-yobCRT4=.3ca5d174-a3ef-447c-888a-236646f1878b@github.com>
Message-ID: <iNO-pX4NPG4vHCcsPd1dF4QsPPW6b9HSgU2AvRLwogQ=.9dfee63e-db92-4e0b-ac05-a9b23a357c3e@github.com>

On Thu, 27 Jun 2024 12:39:19 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Increase test coverage of cloneable values.

This pull request has now been integrated.

Changeset: 5c2df3a4
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5c2df3a43d44efb4b427b87016d28848adb36b84
Stats:     37 lines in 1 file changed: 35 ins; 0 del; 2 mod

8335254: [lworld] Test ObjectMethods.java doesn't test Object's default clone() method on values

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

PR: https://git.openjdk.org/valhalla/pull/1148

From rriggs at openjdk.org  Fri Jun 28 19:46:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 28 Jun 2024 19:46:38 GMT
Subject: [lworld] RFR: 8282106: [lworld] IdentityException should identify
 the value class [v3]
In-Reply-To: <gVwG2C7qQ-4fwbFT5prSOZH3HNmIUzG1kFXjOZsSpl4=.0292d50c-b96b-4835-8f2a-a8e87be18978@github.com>
References: <lSMDQ9fPcXttWhsaD2pbbuQXtK2ULimmOESDxKR3MJ8=.b9ebdadf-83e0-4f5e-b981-361659ba240b@github.com>
 <gVwG2C7qQ-4fwbFT5prSOZH3HNmIUzG1kFXjOZsSpl4=.0292d50c-b96b-4835-8f2a-a8e87be18978@github.com>
Message-ID: <yhcVZxmE-nKVJXwKwD_Sn6mkgROyUNQtO1ekfpaSAVE=.cbed53d0-aaff-4ea9-ab2f-25d0ffe9afae@github.com>

On Fri, 28 Jun 2024 15:06:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Improve the message of IdentityException by including the class of the instance that triggered the exception.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test

The test looks ok to me.

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

PR Review: https://git.openjdk.org/valhalla/pull/1150#pullrequestreview-2148843204

From vromero at openjdk.org  Sat Jun 29 20:59:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 29 Jun 2024 20:59:31 GMT
Subject: [lworld] RFR: 8335279: [lworld] javac should attribute instance
 initializers according to their final location relative to the super ctor
 invocation
Message-ID: <z1QdsAWnHCsnZwxKWQf-UNVnqW0Oqm-X8IMQOrzjckQ=.1aed6151-a6b8-4986-911f-51075aaa17c0@github.com>

this code:


value class Test {
    Test t = null;
    Runnable r = () -> { System.err.println(t); };
}

was being accepted by javac but then failed with a verifier error at run time. When attributing instance initializers javac should take into account the position they will have in the constructor relative to the super constructor invocation

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

Commit messages:
 - 8335279: [lworld] javac should attribute instance initializers according to their final location relative to the super ctor invocation

Changes: https://git.openjdk.org/valhalla/pull/1151/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1151&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335279
  Stats: 21 lines in 2 files changed: 17 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1151.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1151/head:pull/1151

PR: https://git.openjdk.org/valhalla/pull/1151

From vromero at openjdk.org  Sat Jun 29 21:04:25 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 29 Jun 2024 21:04:25 GMT
Subject: [lworld] Integrated: 8335279: [lworld] javac should attribute instance
 initializers according to their final location relative to the super ctor
 invocation
In-Reply-To: <z1QdsAWnHCsnZwxKWQf-UNVnqW0Oqm-X8IMQOrzjckQ=.1aed6151-a6b8-4986-911f-51075aaa17c0@github.com>
References: <z1QdsAWnHCsnZwxKWQf-UNVnqW0Oqm-X8IMQOrzjckQ=.1aed6151-a6b8-4986-911f-51075aaa17c0@github.com>
Message-ID: <AGdM50eD5NfPgsurckjXRttLBf4L1CcqTV_b1Goxb7w=.91fe316d-ca22-49d5-ab4d-c4f1729f4cff@github.com>

On Sat, 29 Jun 2024 20:55:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this code:
> 
> 
> value class Test {
>     Test t = null;
>     Runnable r = () -> { System.err.println(t); };
> }
> 
> was being accepted by javac but then failed with a verifier error at run time. When attributing instance initializers javac should take into account the position they will have in the constructor relative to the super constructor invocation

This pull request has now been integrated.

Changeset: 62091c0b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/62091c0b6791381e8906e5b2a3b943cb2092a439
Stats:     21 lines in 2 files changed: 17 ins; 0 del; 4 mod

8335279: [lworld] javac should attribute instance initializers according to their final location relative to the super ctor invocation

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

PR: https://git.openjdk.org/valhalla/pull/1151