From jbhateja at openjdk.org  Tue Sep  3 01:48:30 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 3 Sep 2024 01:48:30 GMT
Subject: [lworld+fp16] RFR: 8339098: Add class
 jdk.internal.math.Float16Consts
In-Reply-To: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
References: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
Message-ID: <hq_IvWmPKKjgbjb-skxFwyFjdqddrwx5MPGcrTpJB54=.d8db3b63-90bb-45f9-b187-86421c847775@github.com>

On Tue, 27 Aug 2024 16:11:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding class Float16Consts to parallel DoubleConsts and FloatConsts.

Marked as reviewed by jbhateja (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1226#pullrequestreview-2276275424

From dsimms at openjdk.org  Tue Sep  3 07:58:48 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 3 Sep 2024 07:58:48 GMT
Subject: [lworld] RFR: 8327729: [lworld] Adjust UnsafeTest.java for JDK-8327729
Message-ID: <tRBYw8hxywllzb0h4o_ILD81hN-QB6ql--h4lTDNtQ0=.a5c747ce-dfea-4129-b99b-3fea37ed3246@github.com>

putObject -> putReference

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

Commit messages:
 - 8327729: [lworld] Adjust UnsafeTest.java for JDK-8327729

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

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

From dsimms at openjdk.org  Tue Sep  3 08:35:26 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 3 Sep 2024 08:35:26 GMT
Subject: [lworld] Integrated: 8339456: [lworld] Adjust UnsafeTest.java for
 JDK-8327729
In-Reply-To: <tRBYw8hxywllzb0h4o_ILD81hN-QB6ql--h4lTDNtQ0=.a5c747ce-dfea-4129-b99b-3fea37ed3246@github.com>
References: <tRBYw8hxywllzb0h4o_ILD81hN-QB6ql--h4lTDNtQ0=.a5c747ce-dfea-4129-b99b-3fea37ed3246@github.com>
Message-ID: <AIKpGD5lurApPe8iSljNPfy8sxteU6gbHB18MgutryU=.7d440797-962a-43b2-8525-fa4b97f6757c@github.com>

On Tue, 3 Sep 2024 07:54:20 GMT, David Simms <dsimms at openjdk.org> wrote:

> putObject -> putReference

This pull request has now been integrated.

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

8339456: [lworld] Adjust UnsafeTest.java for JDK-8327729

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

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

From chagedorn at openjdk.org  Tue Sep  3 09:28:09 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 3 Sep 2024 09:28:09 GMT
Subject: [lworld] RFR: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types
In-Reply-To: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
References: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
Message-ID: <reMbr26D3_gtbbP5E8aqQWIT8ATTaLvy49PqQ6SjuMk=.bc5b0850-fed1-4abc-8d21-5dc3964e5287@github.com>

On Tue, 3 Sep 2024 09:19:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.
> 
> I propose to relax the assert by excluding circular inline types.
> 
> #### Additional Required Fix
> 
> I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.
> 
> Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287
> 
> For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:
> 
> https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321
> 
> ![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)
> 
> The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 
> 
> But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:
> 
> ![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)
> 
> The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.
> 
> Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/output.cpp#L809-L816
> 
> The first input is `21 ConP #...

src/hotspot/share/opto/macro.cpp line 711:

> 709:           } else {
> 710:             // Add other uses to the worklist to process individually
> 711:             // TODO will be fixed by 8328470

Just noticed that 8328470 was already fixed and thus the comment is outdated.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1231#discussion_r1741725996

From chagedorn at openjdk.org  Tue Sep  3 09:28:08 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 3 Sep 2024 09:28:08 GMT
Subject: [lworld] RFR: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types
Message-ID: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>

The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.

I propose to relax the assert by excluding circular inline types.

#### Additional Required Fix

I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.

Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:

https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287

For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:

https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321

![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)

The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 

But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:

![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)

The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.

Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:

https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/output.cpp#L809-L816

The first input is `21 ConP #null` which is neither `top` nor an `int` and we crash at L816 when trying to convert the type to a `TypeInt`. 

The fix I propose for that is to add a fake top input for circular inline type nodes when scalarizing them after EA such that we can skip over the `IsInit` which does not exist for the inline type oop.

Thanks,
Christian

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

Commit messages:
 - 8339302: [lworld] C2: "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed: Inline type allocations should not have safepoint uses" with circular inline types

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

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

From bkilambi at openjdk.org  Tue Sep  3 11:22:38 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 3 Sep 2024 11:22:38 GMT
Subject: [lworld+fp16] RFR: 8338061: Add support for FP16 unary and ternary
 operations [v2]
In-Reply-To: <GhPE4joe9YOLmxaUrdY3zOL8Lssow7aDj9ZQuD3xXqs=.2b3c46cd-6217-4ce2-aac8-e4356ba2e0aa@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
 <GhPE4joe9YOLmxaUrdY3zOL8Lssow7aDj9ZQuD3xXqs=.2b3c46cd-6217-4ce2-aac8-e4356ba2e0aa@github.com>
Message-ID: <2niyIvFIQN1QDNo34l4BhUzdXppQJM4Gewl8mYWtO_w=.ab68c974-d4e7-49e8-b0e3-fa0e01bb2692@github.com>

On Tue, 20 Aug 2024 08:59:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Bhavana Kilambi 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:
>> 
>>  - Address review comments
>>  - Merge branch 'lworld+fp16'
>>  - 8338061: Add support for FP16 unary and ternary operations
>>    
>>    This patch adds support for three unary operators - abs, neg and sqrt
>>    and a ternary operator - fma for FP16.
>>    Both scalar and vector mid-end support along with aarch64 backend
>>    support are added.
>>    Tested all FP16 tests successfully on aarch64.
>
> Looks good to me, apart from one test comment.

Hi @jatin-bhateja , did you get a chance to go through my patch? Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1211#issuecomment-2326267136

From rgiulietti at openjdk.org  Tue Sep  3 11:33:32 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 11:33:32 GMT
Subject: [lworld+fp16] RFR: 8339098: Add class
 jdk.internal.math.Float16Consts
In-Reply-To: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
References: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
Message-ID: <7ogVPVVr1F5bETWUTd60oX-y2WDms_Rdx0Kduxzs18U=.56252bdf-4f6a-42b5-a16c-f2299969bd29@github.com>

On Tue, 27 Aug 2024 16:11:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding class Float16Consts to parallel DoubleConsts and FloatConsts.

@jddarcy any comment on this before integration?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1226#issuecomment-2326287293

From chagedorn at openjdk.org  Tue Sep  3 11:55:05 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 3 Sep 2024 11:55:05 GMT
Subject: [lworld] RFR: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types [v2]
In-Reply-To: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
References: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
Message-ID: <NoeSIHx0Cx4ynfY7raw7No2Wxg8zUBdg8I-lhPDhXzg=.2e23362b-278b-44c4-80eb-53f6a1fa79ff@github.com>

> The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.
> 
> I propose to relax the assert by excluding circular inline types.
> 
> #### Additional Required Fix
> 
> I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.
> 
> Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287
> 
> For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:
> 
> https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321
> 
> ![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)
> 
> The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 
> 
> But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:
> 
> ![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)
> 
> The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.
> 
> Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/output.cpp#L809-L816
> 
> The first input is `21 ConP #...

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

  use int=1 constant instead and update assert message

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1231/files
  - new: https://git.openjdk.org/valhalla/pull/1231/files/d719d86c..d0a62f64

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

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

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

From jbhateja at openjdk.org  Tue Sep  3 12:15:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 3 Sep 2024 12:15:44 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v2]
In-Reply-To: <TN-K62jNUdfqOVzLjsgfzQ2Iu9XoHWgand8dghP4WaM=.1e99b77d-9db9-4615-a9d7-25027d76da3f@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <TN-K62jNUdfqOVzLjsgfzQ2Iu9XoHWgand8dghP4WaM=.1e99b77d-9db9-4615-a9d7-25027d76da3f@github.com>
Message-ID: <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>

On Fri, 30 Aug 2024 13:01:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti 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.

src/java.base/share/classes/java/math/BigDecimal.java line 3857:

> 3855:          *      2^12 = 2^{P+1} <= i < 2^{P+5} = 2^16
> 3856:          * Contrary to the double and float cases, here we cannot simply
> 3857:          * declare i as short, because P + 5 < Short.SIZE fails to hold.

Comment is not very clear here, can you please elaborate on the significance of augend '5' here.

test/jdk/java/math/BigInteger/PrimitiveConversionTests.java line 117:

> 115:         }
> 116: 
> 117:         BigInteger large = ONE.shiftLeft(1_000);

Nit: we can be strict here, and pass a value slightly greater than MAX_VALUE  + 0.5 * ULP(MAX_VALUE) i.e. 0x1.ffeP+15
`BigInteger large = BigInteger.valueOf(0x1.ffeP+15)`

Thereby avoiding shift left.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1741949169
PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1741805989

From chagedorn at openjdk.org  Tue Sep  3 12:45:44 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 3 Sep 2024 12:45:44 GMT
Subject: [lworld] RFR: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types [v3]
In-Reply-To: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
References: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
Message-ID: <AfPBU09MWov5zaTA1BfTWbco8PCBlB6_hjwKN_YRUl4=.9efd9fc1-8bc3-4111-ae1e-0a1dc570c352@github.com>

> The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.
> 
> I propose to relax the assert by excluding circular inline types.
> 
> #### Additional Required Fix
> 
> I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.
> 
> Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287
> 
> For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:
> 
> https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321
> 
> ![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)
> 
> The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 
> 
> But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:
> 
> ![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)
> 
> The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.
> 
> Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/output.cpp#L809-L816
> 
> The first input is `21 ConP #...

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

  update comment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1231/files
  - new: https://git.openjdk.org/valhalla/pull/1231/files/d0a62f64..a103dc25

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

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

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

From thartmann at openjdk.org  Tue Sep  3 12:45:44 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 3 Sep 2024 12:45:44 GMT
Subject: [lworld] RFR: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types [v3]
In-Reply-To: <AfPBU09MWov5zaTA1BfTWbco8PCBlB6_hjwKN_YRUl4=.9efd9fc1-8bc3-4111-ae1e-0a1dc570c352@github.com>
References: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
 <AfPBU09MWov5zaTA1BfTWbco8PCBlB6_hjwKN_YRUl4=.9efd9fc1-8bc3-4111-ae1e-0a1dc570c352@github.com>
Message-ID: <aomSpUYE-wW6sONs5HUQHzZjOggj8WfQ7bepFGeuoFc=.9ef4d1d0-5924-4f18-adf8-f115eeec0118@github.com>

On Tue, 3 Sep 2024 12:43:01 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.
>> 
>> I propose to relax the assert by excluding circular inline types.
>> 
>> #### Additional Required Fix
>> 
>> I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.
>> 
>> Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:
>> 
>> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287
>> 
>> For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:
>> 
>> https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321
>> 
>> ![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)
>> 
>> The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 
>> 
>> But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:
>> 
>> ![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)
>> 
>> The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.
>> 
>> Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:
>> 
>> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/shar...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment

Great analysis, Christian! The fix looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1231#pullrequestreview-2277325169

From rgiulietti at openjdk.org  Tue Sep  3 13:06:43 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 13:06:43 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v2]
In-Reply-To: <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <TN-K62jNUdfqOVzLjsgfzQ2Iu9XoHWgand8dghP4WaM=.1e99b77d-9db9-4615-a9d7-25027d76da3f@github.com>
 <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>
Message-ID: <-_o0SGlv0qdezFCj2fEzSeQzHg1ezB9YV5BntkV1dgU=.3f80404c-ee42-43b1-a61d-571f8ede44e6@github.com>

On Tue, 3 Sep 2024 10:17:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Raffaello Giulietti 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.
>
> test/jdk/java/math/BigInteger/PrimitiveConversionTests.java line 117:
> 
>> 115:         }
>> 116: 
>> 117:         BigInteger large = ONE.shiftLeft(1_000);
> 
> Nit: we can be strict here, and pass a value slightly greater than MAX_VALUE  + 0.5 * ULP(MAX_VALUE) i.e. 0x1.ffeP+15
> `BigInteger large = BigInteger.valueOf(0x1.ffeP+15)`
> 
> Thereby avoiding shift left.

All integers between `-(MAX_VALUE + ULP(MAX_VALUE))` and `(MAX_VALUE + ULP(MAX_VALUE))` are tested in the loop, including `MAX_VALUE + 0.5 * ULP(MAX_VALUE)`.

But we also need a test for really big integers.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1742028512

From rgiulietti at openjdk.org  Tue Sep  3 13:10:33 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 13:10:33 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v2]
In-Reply-To: <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <TN-K62jNUdfqOVzLjsgfzQ2Iu9XoHWgand8dghP4WaM=.1e99b77d-9db9-4615-a9d7-25027d76da3f@github.com>
 <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>
Message-ID: <VwLiohDaSnn54RtqrY9F9aP6BJGld9wAJQ4N1TxJFuo=.36cb13ed-3fa1-4a3b-b71a-cbea0752ae6a@github.com>

On Tue, 3 Sep 2024 12:12:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Raffaello Giulietti 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.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 3857:
> 
>> 3855:          *      2^12 = 2^{P+1} <= i < 2^{P+5} = 2^16
>> 3856:          * Contrary to the double and float cases, here we cannot simply
>> 3857:          * declare i as short, because P + 5 < Short.SIZE fails to hold.
> 
> Comment is not very clear here, can you please elaborate on the significance of augend '5' here.

The full documentation of the algorithm is in extensive comments in the `doubleValue()` and `fullDoubleValue()` methods. Here, we only apply that logic as much as possible, adapting it for the `Float16` case.

In particular, see the discussion starting on L.4158

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1742034582

From dsimms at openjdk.org  Tue Sep  3 13:25:22 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 3 Sep 2024 13:25:22 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <pm4sg2tRIrslUaKoj6jeYqS-R33bt5XgD8soH_j4KNM=.77027ae0-2cff-4d19-9889-0dd7fa729fad@github.com>

Merge tag 'jdk-23+17' into lworld_merge_jdk_23_17
Added tag jdk-23+17 for changeset 8efd7aa6

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

Commit messages:
 - Merge tag 'jdk-23+17' into lworld_merge_jdk_23_17
 - 8328786: [AIX] move some important warnings/errors from trcVerbose to UL
 - 8327110: Refactor create_bool_from_template_assertion_predicate() to separate class and fix identical cloning cases used for Loop Unswitching and Split If
 - 8328702: C2: Crash during parsing because sub type check is not folded
 - 8326962: C2 SuperWord: cache VPointer
 - 8328938: C2 SuperWord: disable vectorization for large stride and scale
 - 8329494: Serial: Merge GenMarkSweep into MarkSweep
 - 8329470: Remove obsolete CDS SharedStrings tests
 - 8329564: [JVMCI] TranslatedException::debugPrintStackTrace does not work in the libjvmci compiler.
 - 8328957: Update PKCS11Test.java to not use hardcoded path
 - ... and 66 more: https://git.openjdk.org/valhalla/compare/29a24d28...ed42755e

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

Changes: https://git.openjdk.org/valhalla/pull/1232/files
  Stats: 12377 lines in 258 files changed: 4733 ins; 5665 del; 1979 mod
  Patch: https://git.openjdk.org/valhalla/pull/1232.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1232/head:pull/1232

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

From rgiulietti at openjdk.org  Tue Sep  3 16:32:47 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 16:32:47 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v3]
In-Reply-To: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
Message-ID: <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>

> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  More clarification in a comment.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1228/files
  - new: https://git.openjdk.org/valhalla/pull/1228/files/01418c65..0d76e859

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

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

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

From rgiulietti at openjdk.org  Tue Sep  3 16:35:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 3 Sep 2024 16:35:31 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v2]
In-Reply-To: <VwLiohDaSnn54RtqrY9F9aP6BJGld9wAJQ4N1TxJFuo=.36cb13ed-3fa1-4a3b-b71a-cbea0752ae6a@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <TN-K62jNUdfqOVzLjsgfzQ2Iu9XoHWgand8dghP4WaM=.1e99b77d-9db9-4615-a9d7-25027d76da3f@github.com>
 <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>
 <VwLiohDaSnn54RtqrY9F9aP6BJGld9wAJQ4N1TxJFuo=.36cb13ed-3fa1-4a3b-b71a-cbea0752ae6a@github.com>
Message-ID: <2o0vG7wcZTr_YP6VueasULmktbJZ5hs2Oo2XmZUl8bY=.b9290eb6-7b63-4ae0-9bd6-4abda5a07d61@github.com>

On Tue, 3 Sep 2024 13:07:46 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 3857:
>> 
>>> 3855:          *      2^12 = 2^{P+1} <= i < 2^{P+5} = 2^16
>>> 3856:          * Contrary to the double and float cases, here we cannot simply
>>> 3857:          * declare i as short, because P + 5 < Short.SIZE fails to hold.
>> 
>> Comment is not very clear here, can you please elaborate on the significance of augend '5' here.
>
> The full documentation of the algorithm is in extensive comments in the `doubleValue()` and `fullDoubleValue()` methods. Here, we only apply that logic as much as possible, adapting it for the `Float16` case.
> 
> In particular, see the discussion starting on L.4158

I hope I made the comment a bit clearer.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1742361608

From jbhateja at openjdk.org  Tue Sep  3 17:33:55 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 3 Sep 2024 17:33:55 GMT
Subject: [lworld+fp16] RFR: 8339494: Porting HalfFloatVector classes.
Message-ID: <8wlNcjc8SbwzEq7Sluk9Bcg2Hw6FPdQx-T0mckR6wYc=.834597fd-30f2-45b8-9f6f-a1e66640f2eb@github.com>

- Port existing HalfFloatVector and its concrete vector classes from vectorIntrinsics+fp16 to lworld+fp16.
- These new vector classes uses Float16 array as their backing storage.
- Idea is to enable intrinsificaiton of new HalfFloatVector operations and leverage existing Float16 auto-vectorization and backend support.

All existing VectorAPI tests are passing with the patch.

Best Regards,
Jatin

Follow up work:-
a) Jtreg suite extensions to cover HalfFloatVector operations.
b) Handle Float16 lane type in vector API inline expansion layer.

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

Commit messages:
 - 8339494: Porting HalfFloatVector classes.

Changes: https://git.openjdk.org/valhalla/pull/1233/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1233&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339494
  Stats: 9455 lines in 58 files changed: 8786 ins; 17 del; 652 mod
  Patch: https://git.openjdk.org/valhalla/pull/1233.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1233/head:pull/1233

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

From darcy at openjdk.org  Tue Sep  3 21:09:27 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Sep 2024 21:09:27 GMT
Subject: [lworld+fp16] RFR: 8339098: Add class
 jdk.internal.math.Float16Consts
In-Reply-To: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
References: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
Message-ID: <-qhWgBgQNBVWKCBP3BXuDifBLKDwNRPtaQeHJb_vmHE=.f5e329b4-d939-4358-adf1-de3ca53bbd3e@github.com>

On Tue, 27 Aug 2024 16:11:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding class Float16Consts to parallel DoubleConsts and FloatConsts.

Marked as reviewed by darcy (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1226#pullrequestreview-2278502319

From darcy at openjdk.org  Tue Sep  3 21:09:28 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Sep 2024 21:09:28 GMT
Subject: [lworld+fp16] RFR: 8339098: Add class
 jdk.internal.math.Float16Consts
In-Reply-To: <7ogVPVVr1F5bETWUTd60oX-y2WDms_Rdx0Kduxzs18U=.56252bdf-4f6a-42b5-a16c-f2299969bd29@github.com>
References: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
 <7ogVPVVr1F5bETWUTd60oX-y2WDms_Rdx0Kduxzs18U=.56252bdf-4f6a-42b5-a16c-f2299969bd29@github.com>
Message-ID: <0ZFTqQPeE01M_MQu6pmz_HkuAYwxt_ekmZdC6RVYFlM=.7f9344e1-65f4-4675-ba2d-a330574bb377@github.com>

On Tue, 3 Sep 2024 11:30:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> @jddarcy any comment on this before integration?

I wanted to look over the remaining usage of the fields defined in FloatConsts and DoubleConsts before approving this PR. For those classes, there is usage in FloatingDecimal for base conversion purposes. Since that is a area where we want to provide functionality for Float16, I think Float16Consts is a reasonable addition.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1226#issuecomment-2327438786

From darcy at openjdk.org  Tue Sep  3 22:15:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Sep 2024 22:15:46 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v3]
In-Reply-To: <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>
Message-ID: <rwVVy5mlWkl_-EvdoA1mgUlgjj4KzPqRkAsi5MCSGTk=.5e2dc150-97ee-4972-9246-9abef89c2401@github.com>

On Tue, 3 Sep 2024 16:32:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More clarification in a comment.

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

> 284:     */
> 285:     public static Float16 valueOf(long value) {
> 286:         if (value <= -65_520L) {  // -(Float16.MAX_VALUE + Float16.ulp(Float16.MAX_VALUE) / 2)

I assume you'll sync in / merge this change from the branch.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1742764559

From darcy at openjdk.org  Tue Sep  3 22:32:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 3 Sep 2024 22:32:30 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v3]
In-Reply-To: <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>
Message-ID: <3GgPQfqPfDWmbTqhNhy16uJu6ZFGT3kPBTPRJWrt2Ow=.db907628-4644-4442-a8a9-81e97a0b0cae@github.com>

On Tue, 3 Sep 2024 16:32:47 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More clarification in a comment.

src/java.base/share/classes/java/math/BigDecimal.java line 3837:

> 3835:         }
> 3836:         if (scale < 0) {
> 3837:             return Float16.valueOf(signum() * w.multiply(bigTenToThe(-scale)).floatValue());

Are the calls to `floatValue()` for the `scale < 0` and `scale == 0` cases meant to be calls to `float16Value()`?

If not, the different coding pattern from the analagous float and double methods should be documented in a comment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1742775635

From jbhateja at openjdk.org  Wed Sep  4 04:18:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Sep 2024 04:18:35 GMT
Subject: [lworld+fp16] RFR: 8338061: Add support for FP16 unary and ternary
 operations [v2]
In-Reply-To: <GhPE4joe9YOLmxaUrdY3zOL8Lssow7aDj9ZQuD3xXqs=.2b3c46cd-6217-4ce2-aac8-e4356ba2e0aa@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
 <GhPE4joe9YOLmxaUrdY3zOL8Lssow7aDj9ZQuD3xXqs=.2b3c46cd-6217-4ce2-aac8-e4356ba2e0aa@github.com>
Message-ID: <jGQizHsQF5NmyzZ8zNf3FLqaJILhku27KRZgNjfQktY=.0c701262-5680-43e0-aff1-c4b90eb54e46@github.com>

On Tue, 20 Aug 2024 08:59:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Bhavana Kilambi 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:
>> 
>>  - Address review comments
>>  - Merge branch 'lworld+fp16'
>>  - 8338061: Add support for FP16 unary and ternary operations
>>    
>>    This patch adds support for three unary operators - abs, neg and sqrt
>>    and a ternary operator - fma for FP16.
>>    Both scalar and vector mid-end support along with aarch64 backend
>>    support are added.
>>    Tested all FP16 tests successfully on aarch64.
>
> Looks good to me, apart from one test comment.

> Hi @jatin-bhateja , I have addressed review comments. Please take a look. Also, I have noticed that after the recent merge with `lworld` , the vector tests - `compiler/vectorization/TestFloat16VectorOps.java` and `compiler/vectorization/TestFloat16VectorReinterpretConv.java` failed. Looks like none of the FP16 operations are getting vectorized either. Any idea why? Initially I suspected if any of the code from this patch - [#1154 (comment)](https://github.com/openjdk/valhalla/pull/1154#issuecomment-2208350696) got botched up during the merge but it looks like all of that code is fine and the test to test flat array vectorization - `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatArrayVectorization.java` also passes.

Hi @Bhavana-Kilambi, I am working on fixing this at priority, @rgiulietti also faced problems in running the automated tests and pointed out the issue with multiple occurrence of libLinkerInvokerUnnamed.cpp.

Will address both these issues.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1211#issuecomment-2327878606

From chagedorn at openjdk.org  Wed Sep  4 06:32:36 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 4 Sep 2024 06:32:36 GMT
Subject: [lworld] RFR: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types [v3]
In-Reply-To: <AfPBU09MWov5zaTA1BfTWbco8PCBlB6_hjwKN_YRUl4=.9efd9fc1-8bc3-4111-ae1e-0a1dc570c352@github.com>
References: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
 <AfPBU09MWov5zaTA1BfTWbco8PCBlB6_hjwKN_YRUl4=.9efd9fc1-8bc3-4111-ae1e-0a1dc570c352@github.com>
Message-ID: <5WI_fzcTkAwDLhJievkIIzWEwclqVbsQwLXgR20PW-Y=.30ded771-4a9d-4dd9-82d5-5e6657fe5e62@github.com>

On Tue, 3 Sep 2024 12:45:44 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.
>> 
>> I propose to relax the assert by excluding circular inline types.
>> 
>> #### Additional Required Fix
>> 
>> I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.
>> 
>> Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:
>> 
>> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287
>> 
>> For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:
>> 
>> https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321
>> 
>> ![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)
>> 
>> The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 
>> 
>> But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:
>> 
>> ![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)
>> 
>> The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.
>> 
>> Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:
>> 
>> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/shar...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment

Thanks Tobias for the review and the offline suggestions!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1231#issuecomment-2328020338

From chagedorn at openjdk.org  Wed Sep  4 06:32:36 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 4 Sep 2024 06:32:36 GMT
Subject: [lworld] Integrated: 8339302: [lworld] C2:
 "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed:
 Inline type allocations should not have safepoint uses" with circular inline
 types
In-Reply-To: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
References: <sF0q1L04eHPWzmdFe_BWGf4X-3Bez5i6hwE72C5xYPc=.ace1544e-b24b-4f56-8ce2-53aeef0ba777@github.com>
Message-ID: <LLY4esa1rIcsAfmmkGGzz3OAlPFLFQqXgdbQ41_GmfQ=.a2dacc1c-2651-417c-9369-72267b401e2e@github.com>

On Tue, 3 Sep 2024 09:19:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> The circular inline type test cases show that two asserts are too strong: They assume that we can always replace inline types with `SafePointScalarObject` nodes before doing EA with its scalar replacement phase. If we fail to do so, then there must be a missed optimization opportunity. However, this only holds for non-circular inline types. When having circular inline types, we stop the (eager) scalarization at depth 1 because we could possibly do it endlessly in a recursion. Therefore, we could have a non-scalarized `CheckCastPP` inline type oop in a safepoint which triggers the asserts.
> 
> I propose to relax the assert by excluding circular inline types.
> 
> #### Additional Required Fix
> 
> I also had to adjust the code which creates a `SafePointScalarObject` in the scalar replacement after EA for such a circular inline type represented by a non-`InlineTypeNode` as follows.
> 
> Normally, we would call `InlineTypeNode::make_scalar_in_safepoint()` to scalarize an inline type. This adds an additional input to the safepoint for the `IsInit` input to check:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/inlinetypenode.cpp#L280-L287
> 
> For example, in `testCircularSafepointUse()`, `IsInit` is false for the inline type created for `v` at L3318 and we add a top input when creating `260 SafePointScalarObject`:
> 
> https://github.com/openjdk/valhalla/blob/d719d86c33f87bbdb37c5a4055fbbb5f81d7937f/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableInlineTypes.java#L3315-L3321
> 
> ![image](https://github.com/user-attachments/assets/6defb530-9a37-4701-a704-591ab391a3da)
> 
> The first field `v` is the `166 CheckCastPP` oop and the second field `i` has the value `188 ConI #23`. 
> 
> But when scalarizing the inline type field `v` later (i.e. `166 CheckCastPP`) after EA, without an `InlineTypeNode`, we miss to account for `IsInit`. We create a new `264 SafePointScalarObject` and directly append the fields after the last input (i.e. `188 ConI`) without `IsInit`:
> 
> ![image](https://github.com/user-attachments/assets/d5c26975-5847-4bb3-b53e-102af1471acd)
> 
> The first field `v` is a `21 ConP #null` and the second field `i` is the value `74 ConI #34`.
> 
> Later, when processing the `264 SafePointScalarObject` at code generation, we try to read the `IsInit` input which was never added:
> 
> https://github.com/openjdk/valhalla/blob/884078f06a2bf15e4be768dd09d0790b63d8e015/src/hotspot/share/opto/output.cpp#L809-L816
> 
> The first input is `21 ConP #...

This pull request has now been integrated.

Changeset: 3084f84b
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3084f84b0e77c9c7693842b3044939a5f535018b
Stats:     74 lines in 2 files changed: 71 ins; 1 del; 2 mod

8339302: [lworld] C2: "assert(safepoints.length() == 0 || !res_type->is_inlinetypeptr()) failed: Inline type allocations should not have safepoint uses" with circular inline types

Reviewed-by: thartmann

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

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

From dsimms at openjdk.org  Wed Sep  4 07:41:45 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 4 Sep 2024 07:41:45 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <pm4sg2tRIrslUaKoj6jeYqS-R33bt5XgD8soH_j4KNM=.77027ae0-2cff-4d19-9889-0dd7fa729fad@github.com>
References: <pm4sg2tRIrslUaKoj6jeYqS-R33bt5XgD8soH_j4KNM=.77027ae0-2cff-4d19-9889-0dd7fa729fad@github.com>
Message-ID: <mwrKXuFVp--ItU2VkSgwcXOgnB6IPIuVPpO1HgX0dDo=.49b6c162-a78d-484e-a6f8-83592d95ee07@github.com>

On Tue, 3 Sep 2024 13:19:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-23+17' into lworld_merge_jdk_23_17
> Added tag jdk-23+17 for changeset 8efd7aa6

This pull request has now been integrated.

Changeset: e9ce5a94
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e9ce5a9466968b3cb00e1002ac4e36bbf5673399
Stats:     12377 lines in 258 files changed: 4733 ins; 5665 del; 1979 mod

Merge jdk

Merge jdk-23+17

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

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

From jbhateja at openjdk.org  Wed Sep  4 08:45:50 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Sep 2024 08:45:50 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
Message-ID: <fF_bR817DK-t5n1ryM6GPrdm2nbM3GZUnOfEyqBDBRM=.78a6a938-da7d-42c1-91b7-0de77b7f9621@github.com>

Merge latest lworld into lworld+fp16.

- Removed duplicate occurrences of libLinkerInvokerUnnamed.cpp, artifact of last merge.
- All Float16 specific vectorization tests are passing with this merge.

Best Regards,
Jatin

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

Commit messages:
 - Regressions fixes
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_lworld_into_lworldfp16
 - 8339076: Float16.valueOf(long) incorrectly returns infinities in some cases
 - Merge lworld
 - 8334432: Refine Float16.fma
 - 8337605: Update description of constants in Float16
 - 8338102: x86 backend support for newly added Float16 intrinsics.
 - 8336406: Add support for FP16 binary operations
 - 8330021: AArch64: Add backend support for FP16 add operation
 - 8333852: Allow flat array layout for value based classes.
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/e9ce5a94...407b1608

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

Changes: https://git.openjdk.org/valhalla/pull/1235/files
  Stats: 5468 lines in 73 files changed: 4665 ins; 4 del; 799 mod
  Patch: https://git.openjdk.org/valhalla/pull/1235.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1235/head:pull/1235

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

From jbhateja at openjdk.org  Wed Sep  4 08:45:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Sep 2024 08:45:54 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
In-Reply-To: <fF_bR817DK-t5n1ryM6GPrdm2nbM3GZUnOfEyqBDBRM=.78a6a938-da7d-42c1-91b7-0de77b7f9621@github.com>
References: <fF_bR817DK-t5n1ryM6GPrdm2nbM3GZUnOfEyqBDBRM=.78a6a938-da7d-42c1-91b7-0de77b7f9621@github.com>
Message-ID: <JJehZrMfcS_bIkjvHZobTUBMNQyJRR4u0RPd3F-7DdA=.edeea11e-b9b9-49e8-ae70-7a354833c38a@github.com>

On Wed, 4 Sep 2024 08:39:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge latest lworld into lworld+fp16.
> 
> - Removed duplicate occurrences of libLinkerInvokerUnnamed.cpp, artifact of last merge.
> - All Float16 specific vectorization tests are passing with this merge.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 83dfd37d
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/83dfd37d4eb23ad1a62f30d67d613227e0fe9cb7
Stats:     12516 lines in 270 files changed: 4818 ins; 5711 del; 1987 mod

Merge lworld

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

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

From duke at openjdk.org  Wed Sep  4 09:13:31 2024
From: duke at openjdk.org (duke)
Date: Wed, 4 Sep 2024 09:13:31 GMT
Subject: [lworld+fp16] RFR: 8339098: Add class
 jdk.internal.math.Float16Consts
In-Reply-To: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
References: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
Message-ID: <KM91_Megl6EX52Ojfswx1wn2FwkCOaN6MrlHAlXwAws=.c43435d1-5108-4843-852b-8af58b3ae669@github.com>

On Tue, 27 Aug 2024 16:11:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding class Float16Consts to parallel DoubleConsts and FloatConsts.

@rgiulietti 
Your change (at version 51fbc1f22e2ccd7572bde82855fc9af6bbb970bd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1226#issuecomment-2328327116

From rgiulietti at openjdk.org  Wed Sep  4 09:34:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Sep 2024 09:34:27 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v3]
In-Reply-To: <rwVVy5mlWkl_-EvdoA1mgUlgjj4KzPqRkAsi5MCSGTk=.5e2dc150-97ee-4972-9246-9abef89c2401@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>
 <rwVVy5mlWkl_-EvdoA1mgUlgjj4KzPqRkAsi5MCSGTk=.5e2dc150-97ee-4972-9246-9abef89c2401@github.com>
Message-ID: <JBUd0wZqogMf-OZSoSyUU6pMeMi4ejzg86R8BKuA7rw=.7d4cf64f-c486-4733-ab0d-53706dc2802f@github.com>

On Tue, 3 Sep 2024 22:13:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More clarification in a comment.
>
> src/java.base/share/classes/java/lang/Float16.java line 286:
> 
>> 284:     */
>> 285:     public static Float16 valueOf(long value) {
>> 286:         if (value <= -65_520L) {  // -(Float16.MAX_VALUE + Float16.ulp(Float16.MAX_VALUE) / 2)
> 
> I assume you'll sync in / merge this change from the branch.

I think this is a remnant due to my previous error to associate the PR to branch `lworld` before moving it to `lworld+fp16`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1743394319

From rgiulietti at openjdk.org  Wed Sep  4 09:39:38 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Sep 2024 09:39:38 GMT
Subject: [lworld+fp16] Integrated: 8339098: Add class
 jdk.internal.math.Float16Consts
In-Reply-To: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
References: <-8N3XIpgiSTtz853R15L9JOEAxR0Tepgd9oVzg-mob4=.6cd93c60-fd83-463e-8b97-68185c057672@github.com>
Message-ID: <52HZmvZizzL33lRecTifQf0RdEJrTGGVsMY5F0H0Kqo=.f20a63c9-4ecd-44db-b7d6-caf8d7c34e87@github.com>

On Tue, 27 Aug 2024 16:11:09 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding class Float16Consts to parallel DoubleConsts and FloatConsts.

This pull request has now been integrated.

Changeset: d3d914aa
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d3d914aa110774e92a5cfa49d15eb341afef2014
Stats:     93 lines in 1 file changed: 93 ins; 0 del; 0 mod

8339098: Add class jdk.internal.math.Float16Consts

Reviewed-by: jbhateja, darcy

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

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

From rgiulietti at openjdk.org  Wed Sep  4 09:54:53 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Sep 2024 09:54:53 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v4]
In-Reply-To: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
Message-ID: <BnPCCyp_I6EKLA6p_KPGehwy9rDubwogFC5tmPEH63M=.716969c7-7665-4593-95c7-fbeb96019bb9@github.com>

> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'lworld+fp16' into 8339252
 - Clearer code for fullFloat16Value().
 - More clarification in a comment.
 - 8339252: Add method float16Value() to BigInteger and BigDecimal
 - Added valueOf(BigDecimal).

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

Changes: https://git.openjdk.org/valhalla/pull/1228/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1228&range=03
  Stats: 310 lines in 5 files changed: 301 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/1228.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1228/head:pull/1228

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

From rgiulietti at openjdk.org  Wed Sep  4 10:00:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Sep 2024 10:00:31 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v3]
In-Reply-To: <3GgPQfqPfDWmbTqhNhy16uJu6ZFGT3kPBTPRJWrt2Ow=.db907628-4644-4442-a8a9-81e97a0b0cae@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <38Gx0KCpLVP4VoO0-4R1vhx_oNWrc7poPi9qcGqnlYM=.8a6775d7-537e-4252-b131-b5a30ce22b4e@github.com>
 <3GgPQfqPfDWmbTqhNhy16uJu6ZFGT3kPBTPRJWrt2Ow=.db907628-4644-4442-a8a9-81e97a0b0cae@github.com>
Message-ID: <MdIxMiF7yiecF25k0hpv8MUrj1LiR25aubx-3fQrHF0=.49b59d3e-c3dd-47c9-a145-1ce520c18d5f@github.com>

On Tue, 3 Sep 2024 22:30:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More clarification in a comment.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 3837:
> 
>> 3835:         }
>> 3836:         if (scale < 0) {
>> 3837:             return Float16.valueOf(signum() * w.multiply(bigTenToThe(-scale)).floatValue());
> 
> Are the calls to `floatValue()` for the `scale < 0` and `scale == 0` cases meant to be calls to `float16Value()`?
> 
> If not, the different coding pattern from the analagous float and double methods should be documented in a comment.

Improved code to mirror analogous code in `fullDoubleValue()`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1743432936

From chagedorn at openjdk.org  Wed Sep  4 10:55:36 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 4 Sep 2024 10:55:36 GMT
Subject: [lworld] RFR: [lworld] C2: Support abstract value class fields
Message-ID: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>

This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.

## Updated Larval Handling
### Previous Larval Initialization
Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:

new MyValue -> MyValue.<init> (initialization here) -> Object.<init>

or by first delegating to another value type constructor inside the same value class which does the initiliazation:

new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>

It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).

Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.

This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.

### New Larval Initialization with Fields in Abstract Classes
#### Problems
- A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
- The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to all the callers.

#### Solution
We therefore decided to only process larvals after the constructor call by looking at the just called method (regardless of whether is was inlined or not). If it was another concrete value class constructor, an abstract constructor or `Object.<init>` with the same receiver, then we know that after the call, the inline type is fully initialized. We only now mark it as non-larval and update the maps to propagate the update.

#### Other Fixes
I also needed to update other places where we update the receiver and the maps which often just checked if the holder class is a value type. This does not work anymore and needs to be updated (abstract value classes are not marked as inline type klasses).

#### Details
For more details, I refer to the code comments added in the patch for the various cases.

## Testing
I've copied the existing `TestValueConstructor` tests and created versions with abstract classes and added some new tests. The patch passed tier1-4 + stress except for one test failure in the stress testing: `TestNullableInlineTypes::test80()` failed with the very same assert and the same flags as `TestNullableInlineTypes::test81()` which was already disabled and tracked by [JDK-8325632](https://bugs.openjdk.org/browse/JDK-8325632). This suggests that it is most likely the same issue but triggered differently. To move forward with this patch, I also disabled `test80()`. We can get back to this later.

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

Commit messages:
 - disable helper method
 - [lworld] C2: Support abstract value class fields

Changes: https://git.openjdk.org/valhalla/pull/1236/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1236&range=00
  Stats: 1370 lines in 13 files changed: 1247 ins; 24 del; 99 mod
  Patch: https://git.openjdk.org/valhalla/pull/1236.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1236/head:pull/1236

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

From chagedorn at openjdk.org  Wed Sep  4 10:55:37 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 4 Sep 2024 10:55:37 GMT
Subject: [lworld] RFR: [lworld] C2: Support abstract value class fields
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <m5kmWNdy_rCRMXqznw9TSOLCQk1V7xa2xUT6MNZ77lM=.dcb7a4cc-c80c-4a59-b80e-7e6e4ec4f6f6@github.com>

On Wed, 4 Sep 2024 10:32:49 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

src/hotspot/share/ci/ciInstanceKlass.hpp line 72:

> 70:   ciConstantPoolCache*   _field_cache;  // cached map index->field
> 71:  public:
> 72:   GrowableArray<ciField*>* _nonstatic_fields;

Could probably be improved in the future to avoid this direct public access.

src/hotspot/share/compiler/methodLiveness.cpp line 627:

> 625:           (method->is_object_constructor() &&
> 626:            ((!holder->is_abstract() && holder->is_inlinetype()) ||
> 627:             holder->is_abstract()))) {

We now keep more receivers live that might not be needed (non-value abstract classes). But I think this is the simplest/most straight forward solution since we do not have access to the actual receiver node here to check its bottom type as done in the code during parsing.

src/hotspot/share/oops/inlineKlass.cpp line 249:

> 247:   int count = 0;
> 248:   SigEntry::add_entry(sig, T_METADATA, name(), base_off);
> 249:   for (JavaFieldStream fs(this); !fs.done(); fs.next()) {

`JavaFieldStream` failed to get the fields in the abstract class. Using `HierarchicalFieldStream` fixes this.

src/hotspot/share/opto/doCall.cpp line 581:

> 579:   bool      call_does_dispatch = false;
> 580: 
> 581:   // Detect the call to the object or abstract class constructor at the end of a value constructor to know when we are done initializing the larval

Removed pre-call processing. Everything done post-call now.

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

> 1895:     } else if (arg->is_InlineType()) {
> 1896:       // Pass inline type argument via oop to callee
> 1897:       InlineTypeNode* inline_type = arg->as_InlineType();

Before this patch, we already marked an inline type as non-larval before the non-inlined super constructor call. So, we would always initialize the buffer when calling the super constructor. But now, we could still have marked larvals on which we call the super constructors. We therefore need to force an initialization in this case.

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

> 1971: 
> 1972:   // We just called the constructor on a value type receiver. Reload it from the buffer
> 1973:   if (call->method()->is_object_constructor() && call->method()->holder()->is_inlinetype()) {

`call->method()->holder()->is_inlinetype()` false for abstract value classes -> use bottom type of receiver instead.

src/hotspot/share/opto/inlinetypenode.cpp line 1348:

> 1346:     st->print(" #larval");
> 1347:   }
> 1348: }

Added for easier debugging.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743498014
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743504878
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743499724
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743505840
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743520647
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743507515
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743527757

From thartmann at openjdk.org  Wed Sep  4 12:27:34 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Sep 2024 12:27:34 GMT
Subject: [lworld] RFR: [lworld] C2: Support abstract value class fields
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <2_1l9OMu98C5-OXBMhpmiu2AoSaIC-I4VO5yClLgOyg=.31dc52d7-e8b1-4fe4-beee-3a5fd8d1cbcf@github.com>

On Wed, 4 Sep 2024 10:32:49 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

Excellent work, Christian! Great analysis and proper fix. I know how tedious it was to find all these tests to trigger all construction variants and investigate the correct fix.

I just left a few code style comments.

src/hotspot/share/ci/ciInlineKlass.cpp line 38:

> 36:   GrowableArray<ciField*>* super_klass_fields = nullptr;
> 37:   if (super_klass != nullptr && super_klass->has_nonstatic_fields()) {
> 38:     int super_flen   = super_klass->nof_nonstatic_fields();

Suggestion:

    int super_flen = super_klass->nof_nonstatic_fields();

src/hotspot/share/compiler/methodLiveness.cpp line 627:

> 625:           (method->is_object_constructor() &&
> 626:            ((!holder->is_abstract() && holder->is_inlinetype()) ||
> 627:             holder->is_abstract()))) {

Suggestion:

      if (method->intrinsic_id() == vmIntrinsics::_Object_init ||
          (method->is_object_constructor() && ((!holder->is_abstract() && holder->is_inlinetype()) || holder->is_abstract()))) {


It's personal taste but I find this version more readable.

src/hotspot/share/compiler/methodLiveness.cpp line 628:

> 626:            ((!holder->is_abstract() && holder->is_inlinetype()) ||
> 627:             holder->is_abstract()))) {
> 628:         // Returning from Object.<init> implicitly registers a finalizer for the receiver if needed, so keep it alive.

Suggestion:

        // Returning from Object.<init> implicitly registers a finalizer for the receiver if needed, to keep it alive.

src/hotspot/share/compiler/methodLiveness.cpp line 631:

> 629:         // Value class constructors update the scalarized receiver. We need to keep it live so that we can find it after
> 630:         // (chained) constructor calls and propagate updates to the caller. If the holder of the constructor is abstract,
> 631:         // we do not know if the constructor was called from a value class or not. We therefore keep the receiver of all

Should this be

Suggestion:

        // we do not know if the constructor was called on a value class or not. We therefore keep the receiver of all


?

src/hotspot/share/oops/fieldStreams.hpp line 296:

> 294:   const FieldStreamType& current() const {
> 295:     return _current_stream;
> 296:   }

I would suggest to rather add `is_flat` and `index` wrapper methods instead of exposing `_current_stream`.

src/hotspot/share/oops/inlineKlass.cpp line 247:

> 245: // types is an argument: drop all T_METADATA/T_VOID from the list).
> 246: //
> 247: // Inline types could also have fields in abstract super value classes.

Suggestion:

// Value classes could also have fields in abstract super value classes.

src/hotspot/share/opto/doCall.cpp line 807:

> 805:         _caller->map()->argument(_caller, 0)->bottom_type()->is_inlinetypeptr();
> 806:     assert(!is_current_method_inline_type_constructor || !cg->method()->is_object_constructor() || receiver != nullptr,
> 807:            "must have valid receiver after calling another inline type constructor");

It's not guaranteed here (yet) that `cg()->method()` is an inline type constructor.

src/hotspot/share/opto/doCall.cpp line 807:

> 805:         _caller->map()->argument(_caller, 0)->bottom_type()->is_inlinetypeptr();
> 806:     assert(!is_current_method_inline_type_constructor || !cg->method()->is_object_constructor() || receiver != nullptr,
> 807:            "must have valid receiver after calling another inline type constructor");

Suggestion:

           "must have valid receiver after calling another constructor");

src/hotspot/share/opto/doCall.cpp line 812:

> 810:         cg->method()->is_object_constructor() && receiver->bottom_type()->is_inlinetypeptr() &&
> 811:         // AND:
> 812:         // 1) ...has the same receiver? Then it's another constructor of the same class doing the initialization.

Suggestion:

         // AND:
         // 1) ... invoked on the same receiver? Then it's another constructor on the same object doing the initialization.

src/hotspot/share/opto/doCall.cpp line 814:

> 812:         // 1) ...has the same receiver? Then it's another constructor of the same class doing the initialization.
> 813:         (receiver == _caller->map()->argument(_caller, 0) ||
> 814:          // 2) ...is abstract? Then it's the call to the super constructor which eventually calls Object.<init> to

Suggestion:

         // 2) ... abstract? Then it's the call to the super constructor which eventually calls Object.<init> to

src/hotspot/share/opto/doCall.cpp line 818:

> 816:          cg->method()->holder()->is_abstract() ||
> 817:          // 3) ...Object.<init>? Then we know it's the final call to finish the larval initialization. Other
> 818:          //       Object.<init> calls would have a non-inline-type receiver which we already excluded in the check above.

Suggestion:

         // 3) ... Object.<init>? Then we know it's the final call to finish the larval initialization. Other
         //        Object.<init> calls would have a non-inline-type receiver which we already excluded in the check above.

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

> 1896:       // Pass inline type argument via oop to callee
> 1897:       InlineTypeNode* inline_type = arg->as_InlineType();
> 1898:       const ciMethod* caller_method = _method;

Unused?

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

> 1899:       const ciMethod* method = call->method();
> 1900:       ciInstanceKlass* holder = method->holder();
> 1901:       const bool is_receiver = i == TypeFunc::Parms;

Suggestion:

      const bool is_receiver = (i == TypeFunc::Parms);

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

> 1913:         must_init_buffer = true;
> 1914:       }
> 1915:       arg = inline_type->buffer(this, true, must_init_buffer);

I think `must_init_buffer` should be true by default and set to false here for larvals, see comments below.

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

> 1995:     Node* receiver = call->in(TypeFunc::Parms);
> 1996:     if (receiver->bottom_type()->is_inlinetypeptr()) {
> 1997:       InlineTypeNode* inline_type_receiver = receiver->as_InlineType();

Suggestion:

    InlineTypeNode* inline_type_receiver = call->in(TypeFunc::Parms)->isa_InlineType();
    if (receiver != nullptr) {

src/hotspot/share/opto/inlinetypenode.cpp line 264:

> 262:   // updated. If we scalarize now and update the fields, we cannot propagate the update out of the constructor call
> 263:   // because the scalarized fields are local to this method. We need to use the buffer to make the update visible to
> 264:   // the outside (see also CompiledEntrySignature::compute_calling_conventions()).

Suggestion:

  // We should not scalarize larvals in debug info of their constructor calls because their fields could still be
  // updated. If we scalarize and update the fields in the constructor, the updates won't be visible in the caller after deoptimization
  // because the scalarized field values are local to the caller. We need to use a buffer to make the updates visible to
  // the outside.

src/hotspot/share/opto/inlinetypenode.cpp line 269:

> 267:       sfpt->in(TypeFunc::Parms) == this) {
> 268:     // Receiver of larval is always buffered in its constructor call because it was initially created outside the
> 269:     // constructor.

Suggestion:

    // Receiver is always buffered because it's passed as oop, see special case in CompiledEntrySignature::compute_calling_conventions().

src/hotspot/share/opto/inlinetypenode.cpp line 601:

> 599:       //                  create a new buffer. Once the larval escapes, we will initialize the buffer (must_init set).
> 600:       assert(!must_init || is_larval(), "must_init should only be set for larval");
> 601:       if (!is_larval() || must_init) {

This is confusing: Shouldn't the default of `must_init` be true because that's the common case? And then we can assert here that it can only ever be false if `is_larval()` is true.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1236#pullrequestreview-2279823394
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743578078
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743584985
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743586545
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743588472
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743593742
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743594412
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743601667
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743606921
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743609549
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743616161
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743616516
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743622995
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743621506
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743681859
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743628383
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743639902
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743646004
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743677905

From thartmann at openjdk.org  Wed Sep  4 12:27:34 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 4 Sep 2024 12:27:34 GMT
Subject: [lworld] RFR: [lworld] C2: Support abstract value class fields
In-Reply-To: <2_1l9OMu98C5-OXBMhpmiu2AoSaIC-I4VO5yClLgOyg=.31dc52d7-e8b1-4fe4-beee-3a5fd8d1cbcf@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <2_1l9OMu98C5-OXBMhpmiu2AoSaIC-I4VO5yClLgOyg=.31dc52d7-e8b1-4fe4-beee-3a5fd8d1cbcf@github.com>
Message-ID: <AZG4vGJ78WAhbr9myECW9x1Xn6UMIgpxebC-YCMOMoc=.8ae19202-61e0-4a5c-956a-e929db4399c9@github.com>

On Wed, 4 Sep 2024 11:49:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> src/hotspot/share/opto/graphKit.cpp line 1997:
> 
>> 1995:     Node* receiver = call->in(TypeFunc::Parms);
>> 1996:     if (receiver->bottom_type()->is_inlinetypeptr()) {
>> 1997:       InlineTypeNode* inline_type_receiver = receiver->as_InlineType();
> 
> Suggestion:
> 
>     InlineTypeNode* inline_type_receiver = call->in(TypeFunc::Parms)->isa_InlineType();
>     if (receiver != nullptr) {

(Not tested)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1743629453

From jbhateja at openjdk.org  Wed Sep  4 15:31:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 4 Sep 2024 15:31:38 GMT
Subject: [lworld+fp16] RFR: 8338061: Add support for FP16 unary and ternary
 operations [v2]
In-Reply-To: <c_z0-ljVyuDlkTAfScZ7tG_ny2NZhTmuVCwjLyN5vJI=.f4722a57-7bfe-448c-817a-c11115f5cb16@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
 <c_z0-ljVyuDlkTAfScZ7tG_ny2NZhTmuVCwjLyN5vJI=.f4722a57-7bfe-448c-817a-c11115f5cb16@github.com>
Message-ID: <Eg6_kmkTdMc2QnqObbS5BsN1cqv3LX3A6ITuSFUIGNQ=.86f7f5af-c2ca-425f-8180-f4cae35fdd6a@github.com>

On Tue, 27 Aug 2024 15:44:03 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds support for three unary operators - abs, neg and sqrt and a ternary operator - fma for FP16.
>> Both scalar and vector mid-end support along with aarch64 backend support are added.
>> Tested all FP16 tests successfully on aarch64.
>
> Bhavana Kilambi 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:
> 
>  - Address review comments
>  - Merge branch 'lworld+fp16'
>  - 8338061: Add support for FP16 unary and ternary operations
>    
>    This patch adds support for three unary operators - abs, neg and sqrt
>    and a ternary operator - fma for FP16.
>    Both scalar and vector mid-end support along with aarch64 backend
>    support are added.
>    Tested all FP16 tests successfully on aarch64.

Hi @Bhavana-Kilambi , Patch looks good to me, I did a merge and fixed the failing regressions. Kindly rebase and submit the patch, I will add x86 backed support for these new operations.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1211#pullrequestreview-2280575060

From darcy at openjdk.org  Wed Sep  4 19:42:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Sep 2024 19:42:35 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v4]
In-Reply-To: <BnPCCyp_I6EKLA6p_KPGehwy9rDubwogFC5tmPEH63M=.716969c7-7665-4593-95c7-fbeb96019bb9@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <BnPCCyp_I6EKLA6p_KPGehwy9rDubwogFC5tmPEH63M=.716969c7-7665-4593-95c7-fbeb96019bb9@github.com>
Message-ID: <-EkO3OlRNkpfo9BfpUmdTmTkSR0BorAz1ZTo3Qknjds=.78a199f4-7c93-42cf-b375-3738c54bb738@github.com>

On Wed, 4 Sep 2024 09:54:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'lworld+fp16' into 8339252
>  - Clearer code for fullFloat16Value().
>  - More clarification in a comment.
>  - 8339252: Add method float16Value() to BigInteger and BigDecimal
>  - Added valueOf(BigDecimal).

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

> 435:     }
> 436: 
> 437:     //    /**

Please remove this comment block before pushing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1744323071

From darcy at openjdk.org  Wed Sep  4 19:46:33 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Sep 2024 19:46:33 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v4]
In-Reply-To: <-EkO3OlRNkpfo9BfpUmdTmTkSR0BorAz1ZTo3Qknjds=.78a199f4-7c93-42cf-b375-3738c54bb738@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <BnPCCyp_I6EKLA6p_KPGehwy9rDubwogFC5tmPEH63M=.716969c7-7665-4593-95c7-fbeb96019bb9@github.com>
 <-EkO3OlRNkpfo9BfpUmdTmTkSR0BorAz1ZTo3Qknjds=.78a199f4-7c93-42cf-b375-3738c54bb738@github.com>
Message-ID: <U3-Ot0MWDi85VpCcVfnn9zRiRjxGNyYm7H5xHjqFRMA=.6aabbbdf-8774-4c1d-8278-7de52dad1d78@github.com>

On Wed, 4 Sep 2024 19:39:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'lworld+fp16' into 8339252
>>  - Clearer code for fullFloat16Value().
>>  - More clarification in a comment.
>>  - 8339252: Add method float16Value() to BigInteger and BigDecimal
>>  - Added valueOf(BigDecimal).
>
> src/java.base/share/classes/java/lang/Float16.java line 437:
> 
>> 435:     }
>> 436: 
>> 437:     //    /**
> 
> Please remove this comment block before pushing.

And the similar comment around line 90.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1744328126

From rgiulietti at openjdk.org  Wed Sep  4 21:15:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Sep 2024 21:15:06 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v5]
In-Reply-To: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
Message-ID: <EqBBK7mNxlblipZfdWYT-QDjimFb6pJsnfoVLPAeIRs=.0cc1e907-0963-44b8-9202-b6ad1d29a488@github.com>

> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Removed stale comment lines.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1228/files
  - new: https://git.openjdk.org/valhalla/pull/1228/files/d81b71a1..d11b9223

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

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

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

From rgiulietti at openjdk.org  Wed Sep  4 21:54:05 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 4 Sep 2024 21:54:05 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v6]
In-Reply-To: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
Message-ID: <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>

> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added @see to valueOf(BigDecimal).

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1228/files
  - new: https://git.openjdk.org/valhalla/pull/1228/files/d11b9223..4070f4f7

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

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

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

From darcy at openjdk.org  Wed Sep  4 22:36:07 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Sep 2024 22:36:07 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v6]
In-Reply-To: <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>
Message-ID: <-wPRhTRHPjekYbS1PhiMG6YKPTNcyDVsta9Pcl774Es=.1fed6a25-f571-4a3a-82a3-525d23d4e01f@github.com>

On Wed, 4 Sep 2024 21:54:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @see to valueOf(BigDecimal).

Marked as reviewed by darcy (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1228#pullrequestreview-2281525502

From chagedorn at openjdk.org  Thu Sep  5 08:10:06 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 08:10:06 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v2]
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <O0CqqLTsg7CjlT9dsaDITc1MHkiKZWgkOna7pFVADtE=.26fdc345-462a-4179-aec2-f0dc0136eba9@github.com>

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

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

  Apply suggestions from code review
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1236/files
  - new: https://git.openjdk.org/valhalla/pull/1236/files/95253c72..b291cb83

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

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

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

From chagedorn at openjdk.org  Thu Sep  5 09:05:36 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 09:05:36 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v3]
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <IhVBSMptcSBtNzsyHBfCP45B1rIb9GYkTf_7BPjW2S0=.c8348956-124d-40ad-9a97-3a4b840f1d76@github.com>

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:

 - Addressing remaining review comments
 - Fix comment format

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1236/files
  - new: https://git.openjdk.org/valhalla/pull/1236/files/b291cb83..db6e6729

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

  Stats: 45 lines in 6 files changed: 13 ins; 7 del; 25 mod
  Patch: https://git.openjdk.org/valhalla/pull/1236.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1236/head:pull/1236

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

From chagedorn at openjdk.org  Thu Sep  5 09:05:37 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 09:05:37 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v2]
In-Reply-To: <O0CqqLTsg7CjlT9dsaDITc1MHkiKZWgkOna7pFVADtE=.26fdc345-462a-4179-aec2-f0dc0136eba9@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <O0CqqLTsg7CjlT9dsaDITc1MHkiKZWgkOna7pFVADtE=.26fdc345-462a-4179-aec2-f0dc0136eba9@github.com>
Message-ID: <YzXX4eLZoJZT_tjCnMgGW1C82wDeX0YZYzlLg-0F2BA=.e5adaabd-d5fb-4a49-ace3-957204a834f7@github.com>

On Thu, 5 Sep 2024 08:10:06 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Thanks a lot Tobias for your careful review, the suggestions, and all the offline discussions! I addressed your review comments.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1236#issuecomment-2330988923

From chagedorn at openjdk.org  Thu Sep  5 09:05:37 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 09:05:37 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v3]
In-Reply-To: <2_1l9OMu98C5-OXBMhpmiu2AoSaIC-I4VO5yClLgOyg=.31dc52d7-e8b1-4fe4-beee-3a5fd8d1cbcf@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <2_1l9OMu98C5-OXBMhpmiu2AoSaIC-I4VO5yClLgOyg=.31dc52d7-e8b1-4fe4-beee-3a5fd8d1cbcf@github.com>
Message-ID: <XnJOTenVrQDInC_MNZjrAT_G4iDZsWEQSCCd75gJBEg=.b5241048-9e6c-4350-8dd5-d79435f59a49@github.com>

On Wed, 4 Sep 2024 11:25:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Addressing remaining review comments
>>  - Fix comment format
>
> src/hotspot/share/compiler/methodLiveness.cpp line 627:
> 
>> 625:           (method->is_object_constructor() &&
>> 626:            ((!holder->is_abstract() && holder->is_inlinetype()) ||
>> 627:             holder->is_abstract()))) {
> 
> Suggestion:
> 
>       if (method->intrinsic_id() == vmIntrinsics::_Object_init ||
>           (method->is_object_constructor() && ((!holder->is_abstract() && holder->is_inlinetype()) || holder->is_abstract()))) {
> 
> 
> It's personal taste but I find this version more readable.

Extracted variables to make this more readable

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1744977287

From duke at openjdk.org  Thu Sep  5 09:26:11 2024
From: duke at openjdk.org (duke)
Date: Thu, 5 Sep 2024 09:26:11 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v6]
In-Reply-To: <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>
Message-ID: <BNfmCqxftR8cFskJZAMP92TV40oVq_ubI5-RIBZrSvs=.7b7f5e4b-8ea2-4d10-b95e-93acf69fb491@github.com>

On Wed, 4 Sep 2024 21:54:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @see to valueOf(BigDecimal).

@rgiulietti 
Your change (at version 4070f4f7f7cd1bcc64d12f7535f77c71e53687bb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1228#issuecomment-2331031615

From chagedorn at openjdk.org  Thu Sep  5 10:52:19 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 10:52:19 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v4]
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <l7775KtDW0ZV6gfluN8FkzIC2IjuquM7jMyG4f19Fzs=.618f4ae9-f3a4-41d2-811b-f8a8c66c41a9@github.com>

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

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

  fix build

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1236/files
  - new: https://git.openjdk.org/valhalla/pull/1236/files/db6e6729..25a1aa70

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

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

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

From thartmann at openjdk.org  Thu Sep  5 11:00:05 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Sep 2024 11:00:05 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v4]
In-Reply-To: <l7775KtDW0ZV6gfluN8FkzIC2IjuquM7jMyG4f19Fzs=.618f4ae9-f3a4-41d2-811b-f8a8c66c41a9@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <l7775KtDW0ZV6gfluN8FkzIC2IjuquM7jMyG4f19Fzs=.618f4ae9-f3a4-41d2-811b-f8a8c66c41a9@github.com>
Message-ID: <7ySrSAlOri6j84o-I0xE8haTNDQOPf06NlMLYqG-O1Y=.e74f86ad-5daa-4461-81ef-e011e0f17549@github.com>

On Thu, 5 Sep 2024 10:52:19 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build

That looks good, thanks for the updates!

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

> 1905:       // We always need to buffer inline types when they are escaping. However, we can skip the actual initialization
> 1906:       // of the buffer if the inline type is a larval because we are going to update the buffer anyway which requires
> 1907:       // us to create a one. But there is one special case where we are still required to initialize the buffer: When

Suggestion:

      // us to create a new one. But there is one special case where we are still required to initialize the buffer: When

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1236#pullrequestreview-2282574172
PR Review Comment: https://git.openjdk.org/valhalla/pull/1236#discussion_r1745248057

From chagedorn at openjdk.org  Thu Sep  5 11:11:45 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 11:11:45 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v5]
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <220leAJmeIC4mH95dVCyl3VKC1qq4RWOkgFV19mphFU=.61950bb4-abe0-49a3-9088-2e7c96af7f6d@github.com>

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

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

  fix build and typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1236/files
  - new: https://git.openjdk.org/valhalla/pull/1236/files/25a1aa70..92dab832

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

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

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

From thartmann at openjdk.org  Thu Sep  5 11:27:10 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 5 Sep 2024 11:27:10 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v5]
In-Reply-To: <220leAJmeIC4mH95dVCyl3VKC1qq4RWOkgFV19mphFU=.61950bb4-abe0-49a3-9088-2e7c96af7f6d@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <220leAJmeIC4mH95dVCyl3VKC1qq4RWOkgFV19mphFU=.61950bb4-abe0-49a3-9088-2e7c96af7f6d@github.com>
Message-ID: <PLE1RFh3yAre-Zy3AXIBJJSNEfZo4WgN7dbofybaw9o=.332f38b4-c1f4-4c0d-9a71-588422a29abf@github.com>

On Thu, 5 Sep 2024 11:11:45 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build and typo

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1236#pullrequestreview-2282635259

From bkilambi at openjdk.org  Thu Sep  5 12:01:34 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 5 Sep 2024 12:01:34 GMT
Subject: [lworld+fp16] RFR: 8338061: Add support for FP16 unary and ternary
 operations [v3]
In-Reply-To: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
Message-ID: <Yzw8Oa48X3Yo75QFLZJX1r8BpEBKa6N-k-fa3w6vWHQ=.000b7b36-88cf-4186-9361-1ad2b9b6db9f@github.com>

> This patch adds support for three unary operators - abs, neg and sqrt and a ternary operator - fma for FP16.
> Both scalar and vector mid-end support along with aarch64 backend support are added.
> Tested all FP16 tests successfully on aarch64.

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:

 - Merge branch 'lworld+fp16'
 - Address review comments
 - Merge branch 'lworld+fp16'
 - 8338061: Add support for FP16 unary and ternary operations
   
   This patch adds support for three unary operators - abs, neg and sqrt
   and a ternary operator - fma for FP16.
   Both scalar and vector mid-end support along with aarch64 backend
   support are added.
   Tested all FP16 tests successfully on aarch64.

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

Changes: https://git.openjdk.org/valhalla/pull/1211/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1211&range=02
  Stats: 1413 lines in 29 files changed: 645 ins; 5 del; 763 mod
  Patch: https://git.openjdk.org/valhalla/pull/1211.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1211/head:pull/1211

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

From jbhateja at openjdk.org  Thu Sep  5 12:03:15 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Sep 2024 12:03:15 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v6]
In-Reply-To: <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <Ird4Wog1uD0FmJNgTObydvMLDXza9GlkQ1mqx24goME=.d8a49dd2-16d7-4109-b3f8-e3673399fa4a@github.com>
Message-ID: <rpwuPgb1exblBfwLr3IDJIbqtNh9VpKSEIkYTMq8PZM=.adcd52ad-7932-41ef-8fbf-56f4b699d874@github.com>

On Wed, 4 Sep 2024 21:54:05 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @see to valueOf(BigDecimal).

Marked as reviewed by jbhateja (Committer).

src/java.base/share/classes/java/math/BigDecimal.java line 3864:

> 3862:          * Further, as Math.scalb(Float16) does not exists, we fall back to
> 3863:          * Math.scalb(double).
> 3864:          */

FTR @rgiulietti , Thanks for the pointers, comments looks out of context unless read in light of https://github.com/openjdk/valhalla/blob/lworld/src/java.base/share/classes/java/math/BigDecimal.java#L4066

We should add a reference to fullDoubleValue just before your explanation.

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

PR Review: https://git.openjdk.org/valhalla/pull/1228#pullrequestreview-2277749861
PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1745325776

From jbhateja at openjdk.org  Thu Sep  5 12:03:17 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 5 Sep 2024 12:03:17 GMT
Subject: [lworld+fp16] RFR: 8339252: Add method float16Value() to
 BigInteger and BigDecimal [v2]
In-Reply-To: <-_o0SGlv0qdezFCj2fEzSeQzHg1ezB9YV5BntkV1dgU=.3f80404c-ee42-43b1-a61d-571f8ede44e6@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
 <TN-K62jNUdfqOVzLjsgfzQ2Iu9XoHWgand8dghP4WaM=.1e99b77d-9db9-4615-a9d7-25027d76da3f@github.com>
 <l9rB19KRbZNZPYcE4CbpRK6tdMUKm9QaTdFvXip22ws=.4fc02a2a-488d-4b72-bd5d-d300a2a83c7e@github.com>
 <-_o0SGlv0qdezFCj2fEzSeQzHg1ezB9YV5BntkV1dgU=.3f80404c-ee42-43b1-a61d-571f8ede44e6@github.com>
Message-ID: <LUlcxO1-fukFoKqOOE55x8Q0454lP4KsC9eRqUKCwik=.1952d1e6-91da-4e91-9057-fd39db50fc0d@github.com>

On Tue, 3 Sep 2024 13:03:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Raffaello Giulietti 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.
>
> test/jdk/java/math/BigInteger/PrimitiveConversionTests.java line 117:
> 
>> 115:         }
>> 116: 
>> 117:         BigInteger large = ONE.shiftLeft(1_000);
> 
> All integers between `-(MAX_VALUE + ULP(MAX_VALUE))` and `(MAX_VALUE + ULP(MAX_VALUE))` are tested in the loop, including `MAX_VALUE + 0.5 * ULP(MAX_VALUE)`.
> 
> But we also need a test for really big integers.

Thanks

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1228#discussion_r1742247288

From rgiulietti at openjdk.org  Thu Sep  5 12:03:17 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 5 Sep 2024 12:03:17 GMT
Subject: [lworld+fp16] Integrated: 8339252: Add method float16Value() to
 BigInteger and BigDecimal
In-Reply-To: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
References: <_wd00b-OPYrY0ZvETxGXJKg_bGsb0KWX6iUpk5k1NmI=.b2c31b21-ac67-4da9-95d5-38ebaae4d4ff@github.com>
Message-ID: <ajd8iqh6Fd0qGHm8BFN-lzsrSYVKBbVtqJ0b03icvNo=.41e20a53-3a24-44a0-8c8b-daa241117289@github.com>

On Fri, 30 Aug 2024 12:48:46 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This patch adds `float16Value()` to `BigInteger` and `BigDecimal`, as well as `Float16.valueOf(BigDecimal)`.

This pull request has now been integrated.

Changeset: ab40af27
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ab40af27361c8f2d80799173d78fd5d8967c5ba2
Stats:     311 lines in 5 files changed: 294 ins; 1 del; 16 mod

8339252: Add method float16Value() to BigInteger and BigDecimal
8337761: Add BigDecimal to Float16 conversion

Reviewed-by: darcy, jbhateja

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

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

From bkilambi at openjdk.org  Thu Sep  5 12:15:00 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 5 Sep 2024 12:15:00 GMT
Subject: [lworld+fp16] RFR: 8338061: Add support for FP16 unary and ternary
 operations [v3]
In-Reply-To: <jGQizHsQF5NmyzZ8zNf3FLqaJILhku27KRZgNjfQktY=.0c701262-5680-43e0-aff1-c4b90eb54e46@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
 <GhPE4joe9YOLmxaUrdY3zOL8Lssow7aDj9ZQuD3xXqs=.2b3c46cd-6217-4ce2-aac8-e4356ba2e0aa@github.com>
 <jGQizHsQF5NmyzZ8zNf3FLqaJILhku27KRZgNjfQktY=.0c701262-5680-43e0-aff1-c4b90eb54e46@github.com>
Message-ID: <j2GZU5YLXga67FcfaSq5x6PicyZ5gqvOS-bX019yjNU=.d0c90439-6af3-4b2e-ad49-7d322f4c63fa@github.com>

On Wed, 4 Sep 2024 04:15:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Looks good to me, apart from one test comment.
>
>> Hi @jatin-bhateja , I have addressed review comments. Please take a look. Also, I have noticed that after the recent merge with `lworld` , the vector tests - `compiler/vectorization/TestFloat16VectorOps.java` and `compiler/vectorization/TestFloat16VectorReinterpretConv.java` failed. Looks like none of the FP16 operations are getting vectorized either. Any idea why? Initially I suspected if any of the code from this patch - [#1154 (comment)](https://github.com/openjdk/valhalla/pull/1154#issuecomment-2208350696) got botched up during the merge but it looks like all of that code is fine and the test to test flat array vectorization - `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestFlatArrayVectorization.java` also passes.
> 
> Hi @Bhavana-Kilambi, I am working on fixing this at priority, @rgiulietti also faced problems in running the automated tests and pointed out the issue with multiple occurrence of libLinkerInvokerUnnamed.cpp.
> 
> Will address both these issues.

Hi @jatin-bhateja , I have rebased my patch. Thanks for the approval. Could you please sponsor?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1211#issuecomment-2331358666

From duke at openjdk.org  Thu Sep  5 12:15:03 2024
From: duke at openjdk.org (duke)
Date: Thu, 5 Sep 2024 12:15:03 GMT
Subject: [lworld+fp16] RFR: 8338061: Add support for FP16 unary and ternary
 operations [v3]
In-Reply-To: <Yzw8Oa48X3Yo75QFLZJX1r8BpEBKa6N-k-fa3w6vWHQ=.000b7b36-88cf-4186-9361-1ad2b9b6db9f@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
 <Yzw8Oa48X3Yo75QFLZJX1r8BpEBKa6N-k-fa3w6vWHQ=.000b7b36-88cf-4186-9361-1ad2b9b6db9f@github.com>
Message-ID: <1iAmqSN8bCfncFoFm7uFqdB34gCTMygdrRKnX0rG42Q=.878799c1-8e23-48ed-a880-21bd94f06516@github.com>

On Thu, 5 Sep 2024 12:01:34 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds support for three unary operators - abs, neg and sqrt and a ternary operator - fma for FP16.
>> Both scalar and vector mid-end support along with aarch64 backend support are added.
>> Tested all FP16 tests successfully on aarch64.
>
> 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:
> 
>  - Merge branch 'lworld+fp16'
>  - Address review comments
>  - Merge branch 'lworld+fp16'
>  - 8338061: Add support for FP16 unary and ternary operations
>    
>    This patch adds support for three unary operators - abs, neg and sqrt
>    and a ternary operator - fma for FP16.
>    Both scalar and vector mid-end support along with aarch64 backend
>    support are added.
>    Tested all FP16 tests successfully on aarch64.

@Bhavana-Kilambi 
Your change (at version f0c919b2d976076cfe10a493a287b4cadf95a358) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1211#issuecomment-2331361739

From chagedorn at openjdk.org  Thu Sep  5 13:38:35 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 5 Sep 2024 13:38:35 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v6]
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <W5RGKMFAVqoQhZruq5BenUz1vuXWIKidGGAWBaH2kB8=.1600e62c-c6d1-495b-b76f-e1a849611ecb@github.com>

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

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

  fix bool -> int

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1236/files
  - new: https://git.openjdk.org/valhalla/pull/1236/files/92dab832..f71384ab

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

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

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

From bkilambi at openjdk.org  Fri Sep  6 03:56:08 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 6 Sep 2024 03:56:08 GMT
Subject: [lworld+fp16] Integrated: 8338061: Add support for FP16 unary and
 ternary operations
In-Reply-To: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
References: <0ApfBYsaUEghUv60I8CXYNUiV6m4xJPiNF6YGefM0tw=.b66e3bc5-a60f-46ea-9b88-612f12da3d6f@github.com>
Message-ID: <hCMTP0n6AoYP8tkACUPVed3cgErAb_IckC6eHcUAcqU=.4a385b91-9dd9-4614-802b-b6e3d596bae4@github.com>

On Mon, 19 Aug 2024 13:08:06 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds support for three unary operators - abs, neg and sqrt and a ternary operator - fma for FP16.
> Both scalar and vector mid-end support along with aarch64 backend support are added.
> Tested all FP16 tests successfully on aarch64.

This pull request has now been integrated.

Changeset: 2e21e366
Author:    Bhavana Kilambi <bkilambi at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2e21e366969e1f02db46a684046812d00fa3eb52
Stats:     1413 lines in 29 files changed: 645 ins; 5 del; 763 mod

8338061: Add support for FP16 unary and ternary operations

Reviewed-by: jbhateja

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

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

From chagedorn at openjdk.org  Fri Sep  6 13:40:37 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 6 Sep 2024 13:40:37 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v7]
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <k7oYbOZwRd8nRjUHPjErTosTRbHb1wLeQ7o23vhD770=.716c7f52-0180-4b55-95b9-5d22a576d129@github.com>

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

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

  fix replace in map for updated receiver instead of original one

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1236/files
  - new: https://git.openjdk.org/valhalla/pull/1236/files/f71384ab..7d6468f6

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

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

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

From chagedorn at openjdk.org  Fri Sep  6 13:40:37 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 6 Sep 2024 13:40:37 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v6]
In-Reply-To: <W5RGKMFAVqoQhZruq5BenUz1vuXWIKidGGAWBaH2kB8=.1600e62c-c6d1-495b-b76f-e1a849611ecb@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <W5RGKMFAVqoQhZruq5BenUz1vuXWIKidGGAWBaH2kB8=.1600e62c-c6d1-495b-b76f-e1a849611ecb@github.com>
Message-ID: <hRUtFHqBmrcMKlc_KlAT0yh9rG07y9znk-gyxNTAWG0=.d0b8aa72-626e-49b6-9c53-571cf3455604@github.com>

On Thu, 5 Sep 2024 13:38:35 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix bool -> int

As discussed offline, I've pushed another fix to correctly update the receiver after the `super()` call when an inline type is no longer a larval. We wrongly updated the original receiver in the map instead of the updated one which led to a wrong result when calling another method after `super()` which queries the receiver.

I also added a new test flag variation which found the bug immediately (before that it was only triggered intermediately with `DeoptimizeALot` and some other flags which caused a different inlining decision).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1236#issuecomment-2334076083

From dsimms at openjdk.org  Mon Sep  9 09:41:53 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 9 Sep 2024 09:41:53 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <fVjg-fqx0gKQK_HGZoF49Owg2GDm4ZQT0jheOhX8Ho0=.f8af3461-62be-4869-8418-9eea2d7b10e1@github.com>

Merge tag 'jdk-23+18' into lworld_merge_jdk_23_18
Added tag jdk-23+18 for changeset b04b3047

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

Commit messages:
 - Merge tag 'jdk-23+18' into lworld_merge_jdk_23_18
 - 8329254: optimize integral reverse operations on x86 GFNI target.
 - 8329656: assertion failed in MAP_ARCHIVE_MMAP_FAILURE path: Invalid immediate -5 0
 - 8329491: GetThreadListStackTraces function should use JvmtiHandshake
 - 8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake
 - 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in AssertionError after JDK-8326568
 - 8329961: Buffer overflow in os::Linux::kernel_version
 - 8327137: Add test for ConcurrentModificationException in BasicDirectoryModel
 - 8309751: Duplicate constant pool entries added during default method processing
 - 8326568: jdk/test/com/sun/net/httpserver/bugs/B6431193.java should use try-with-resource and try-finally
 - ... and 99 more: https://git.openjdk.org/valhalla/compare/e9ce5a94...30d3edef

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

Changes: https://git.openjdk.org/valhalla/pull/1237/files
  Stats: 20583 lines in 570 files changed: 10034 ins; 7287 del; 3262 mod
  Patch: https://git.openjdk.org/valhalla/pull/1237.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1237/head:pull/1237

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

From dsimms at openjdk.org  Mon Sep  9 14:28:25 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 9 Sep 2024 14:28:25 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <fVjg-fqx0gKQK_HGZoF49Owg2GDm4ZQT0jheOhX8Ho0=.f8af3461-62be-4869-8418-9eea2d7b10e1@github.com>
References: <fVjg-fqx0gKQK_HGZoF49Owg2GDm4ZQT0jheOhX8Ho0=.f8af3461-62be-4869-8418-9eea2d7b10e1@github.com>
Message-ID: <a9XP41BLXKiE5DPRxAhjJGZ_JXAr-t7K9kR-upf9gEI=.a1fac1ff-d3ee-427f-b840-a063e2bada38@github.com>

On Mon, 9 Sep 2024 09:36:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-23+18' into lworld_merge_jdk_23_18
> Added tag jdk-23+18 for changeset b04b3047

This pull request has now been integrated.

Changeset: f4f1ec68
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f4f1ec680654d97a4717f2212c2ca4729c2a77a5
Stats:     20583 lines in 570 files changed: 10034 ins; 7287 del; 3262 mod

Merge jdk

Merge jdk-23+18

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

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

From thartmann at openjdk.org  Tue Sep 10 16:44:21 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 10 Sep 2024 16:44:21 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v7]
In-Reply-To: <k7oYbOZwRd8nRjUHPjErTosTRbHb1wLeQ7o23vhD770=.716c7f52-0180-4b55-95b9-5d22a576d129@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <k7oYbOZwRd8nRjUHPjErTosTRbHb1wLeQ7o23vhD770=.716c7f52-0180-4b55-95b9-5d22a576d129@github.com>
Message-ID: <ZsZelTTyh0TB6k9gAMDM5Z7ALU6MPgWffM4g7CaNPu0=.fda62e1e-9074-4e5a-8df3-7c0b9d9f0162@github.com>

On Fri, 6 Sep 2024 13:40:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix replace in map for updated receiver instead of original one

Good catch!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1236#pullrequestreview-2293058374

From brian.goetz at oracle.com  Tue Sep 10 17:05:09 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 10 Sep 2024 17:05:09 +0000
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
Message-ID: <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>

The following was received on valhalla-spec-comments.  

Point #1 rests on an assumption that the goal of this feature is to eliminate, or at least strongly discourage, nulls.  This is a common assumption ? many people are so-called ?null haters? ? but encouraging or rewarding such biases is not the role of the langauge.  Nulls are not intrinsically bad; the problem with nulls is that they are so often unexpected, and so people code as if they would never happen.  Reflecting nullity in the type system allows you to reason about when they are expected, and make reasoned choices about where nulls are appropriate or not.  

You state your position pretty explicitly here:

>> The syntax to use null must be "disgusting enough" in order to
>> discourage people from using it.

I?m not going to criticize your opinions about nulls, but it is also OK to have different opinions about nulls, and it?s not the role of the language to insist that one or the other is the only valid set of feelings about it.  

Your second point is what we call ?inventing a new null?; it is a tempting answer, but is overwhelmingly likely to just make the problem worse, because now there are two ill-behaved states.  


> On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com> wrote:
> 
> REF: https://openjdk.org/jeps/8303099
> 
> Feedback 1:
> 
> Using the syntax "Foo?" for nullables values does not discourage the
> use of nulls in code.
> 
> In my experience working with Kotlin, novice (and not so novice)
> developers just find themselves comfortable enough adding an extra
> character and continue to infest code with nulls.
> 
> The syntax to use null must be "disgusting enough" in order to
> discourage people from using it.
> 
> For example something like Foo!!!NullBackwardCompliant!!!. This syntax
> is ugly enough to scare people about using it.
> 
> 
> Feedback 2:
> Most people naively tends to use null in next scenarios:
> 
> * A class/record must be initialized, but due to the data flow, some
> of its members are not yet known in "present time". They depend on
> future input data/processing.
> * Some member must not take any value in a given context.
> 
> Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
> Apply) values in parallel to null. Any read must throw a
> FuturePointerException or NAPointerException.
> While the behaviour looks similar to the current null and
> NullPointerException, it makes error debugging much easier to
> understand:
> * A FuturePointerException promptly warns about some race condition:
> Some code tried to read a value before some process (maybe another
> thread) initialized it.
> * A NAPointerException promptly warns about some error in the business
> logic. Some code didn't contemplate the NA scenario.
> 
> "catch" blocks will also be able to make much more sensible decisions
> (when compared to the pervert NullPointerException).
> 
> Without any JVM extension, a compiler most probably can automate a
> similar behavior with a syntax similar to:
> 
> var Foo1 = Future
> var Foo2 = NA
> 
> Foo1 and Foo2 are **NOT** nullables.
> 
>  Foo2 becomes a constant (It will never change once defined and the
> compiler can make many verifications out of the box).
> 
>  Foo1 must never be read until a given value is provided (after which
> it will probably become constant).
> 
> 
> My two cents!
> 
> Enrique Ariz?n Benito
> Software Gardener


From rgiulietti at openjdk.org  Tue Sep 10 19:23:58 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 10 Sep 2024 19:23:58 GMT
Subject: [lworld+fp16] RFR: 8339599: Add nextUp(), nextDown(),
 scalb() to Float16
Message-ID: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>

Adding these to Float16 rather than Math|StrictMath.

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

Commit messages:
 - 8339599: Add nextUp(), nextDown(), scalb() to Float16

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

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

From rotanolexandr842 at gmail.com  Tue Sep 10 21:43:17 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Wed, 11 Sep 2024 00:43:17 +0300
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
Message-ID: <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>

I would argue that not the syntax around nulls should be hideous, but
rather non-null should somehow be the default option, so people will not
bother adding anything on top of that unless explicitly needed. I'm
not really sure if it's achievable with preserving source backward
compatibility though, given that currently, default is unspecified
nullability. I think that many people will bother adding ! as much as ?,
honestly. Most of the production code I have worked with didnt even care
about returning an unmodifiable view of collection instead of the real one
or wrapping nullable value in optional in getters and hiding no-args
constructors in POJO using protected keyword. Honestly, the sad truth (in
my experience) is the fact that if something is not done by default, it
will not be done manually in the vast majority of cases, no matter how
potentially beneficial it is. I would say that best option would be to
introduce compiler flag that enables non-null by default, and eventually,
after most users are migrated, make it true by default.

Regarding new null in language. I (unfortunately) spend at least half of my
working with typescript. To say that this null-undefined fuss is terrible
is to keep silent. That's just a complete mess. Question mark in type
stands only for type | undefined, want to accept null - go and do var?:
type | null - just terrible. Question mark notation in field access chains
is also so strange: it, contrary to ? in type, accepts both null and
undefined, and it often leads to confusing situations when you expect one
of those two, but get another, logic in ?? still executes, and your
erroneous state passes down through long chain of invocation until it
finally fails somewhere and good luck debugging it/ Two different nulls is
just a horrible idea in so many ways.

PS: Nothing bad with nulls by themself. Absence of value is also a value in
many scenarios

On Tue, Sep 10, 2024 at 8:46?PM Brian Goetz <brian.goetz at oracle.com> wrote:

> The following was received on valhalla-spec-comments.
>
> Point #1 rests on an assumption that the goal of this feature is to
> eliminate, or at least strongly discourage, nulls.  This is a common
> assumption ? many people are so-called ?null haters? ? but encouraging or
> rewarding such biases is not the role of the langauge.  Nulls are not
> intrinsically bad; the problem with nulls is that they are so often
> unexpected, and so people code as if they would never happen.  Reflecting
> nullity in the type system allows you to reason about when they are
> expected, and make reasoned choices about where nulls are appropriate or
> not.
>
> You state your position pretty explicitly here:
>
> >> The syntax to use null must be "disgusting enough" in order to
> >> discourage people from using it.
>
> I?m not going to criticize your opinions about nulls, but it is also OK to
> have different opinions about nulls, and it?s not the role of the language
> to insist that one or the other is the only valid set of feelings about
> it.
>
> Your second point is what we call ?inventing a new null?; it is a tempting
> answer, but is overwhelmingly likely to just make the problem worse,
> because now there are two ill-behaved states.
>
>
> > On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com>
> wrote:
> >
> > REF: https://openjdk.org/jeps/8303099
> >
> > Feedback 1:
> >
> > Using the syntax "Foo?" for nullables values does not discourage the
> > use of nulls in code.
> >
> > In my experience working with Kotlin, novice (and not so novice)
> > developers just find themselves comfortable enough adding an extra
> > character and continue to infest code with nulls.
> >
> > The syntax to use null must be "disgusting enough" in order to
> > discourage people from using it.
> >
> > For example something like Foo!!!NullBackwardCompliant!!!. This syntax
> > is ugly enough to scare people about using it.
> >
> >
> > Feedback 2:
> > Most people naively tends to use null in next scenarios:
> >
> > * A class/record must be initialized, but due to the data flow, some
> > of its members are not yet known in "present time". They depend on
> > future input data/processing.
> > * Some member must not take any value in a given context.
> >
> > Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
> > Apply) values in parallel to null. Any read must throw a
> > FuturePointerException or NAPointerException.
> > While the behaviour looks similar to the current null and
> > NullPointerException, it makes error debugging much easier to
> > understand:
> > * A FuturePointerException promptly warns about some race condition:
> > Some code tried to read a value before some process (maybe another
> > thread) initialized it.
> > * A NAPointerException promptly warns about some error in the business
> > logic. Some code didn't contemplate the NA scenario.
> >
> > "catch" blocks will also be able to make much more sensible decisions
> > (when compared to the pervert NullPointerException).
> >
> > Without any JVM extension, a compiler most probably can automate a
> > similar behavior with a syntax similar to:
> >
> > var Foo1 = Future
> > var Foo2 = NA
> >
> > Foo1 and Foo2 are **NOT** nullables.
> >
> >  Foo2 becomes a constant (It will never change once defined and the
> > compiler can make many verifications out of the box).
> >
> >  Foo1 must never be read until a given value is provided (after which
> > it will probably become constant).
> >
> >
> > My two cents!
> >
> > Enrique Ariz?n Benito
> > Software Gardener
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240911/d931a0f4/attachment.htm>

From bronee at gmail.com  Tue Sep 10 22:45:48 2024
From: bronee at gmail.com (Brian S O'Neill)
Date: Tue, 10 Sep 2024 15:45:48 -0700
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
Message-ID: <a54b4091-622c-4b2e-8f5d-04923db43336@gmail.com>

On 2024-09-10 02:43 PM, Olexandr Rotan wrote:

> I would say that best option 
> would be to introduce compiler flag that enables non-null by default, 
> and eventually, after most users are migrated, make it true by default.

Such a flag would effectively make javac target multiple different 
languages, and there'd be nothing in the source file (or extension) 
which indicates what language you intend to use.

The only sensible flag would be a new lint warning, which can be 
combined with -Werror to fail compilation. Making the warning (and 
failure) a default behavior would be very annoying, and it would break 
compatibility.


From brian.goetz at oracle.com  Wed Sep 11 00:27:53 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 11 Sep 2024 00:27:53 +0000
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
Message-ID: <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>



On Sep 10, 2024, at 5:43 PM, Olexandr Rotan <rotanolexandr842 at gmail.com<mailto:rotanolexandr842 at gmail.com>> wrote:

I would argue that not the syntax around nulls should be hideous, but rather non-null should somehow be the default option

We?re going to get this suggestion a lot.  It is pretty clear that ?non-null? is a better default interpretation of an otherwise unannotated type name than ?nullable? is; this results in a lower annotation burden for annotating old code, less visual noise for reading fully annotated code, a safer default, etc.  And if we were designing a language from scratch, it would be pretty hard to argue against this.

But as you acknowledge, there are billions of lines of Java code out there, and retroactively changing their meaning is a non-starter.  People will surely suggest things like ?what about a compiler flag? (please don?t), but that?s just forking the language and pretending we aren?t.  And all the ?obvious? suggestions have one or both of these characteristics.

So, we truly understand how this would be yet another ?Java got the defaults wrong?.  And maybe there is a path ? in the not-so-immediate-future ? to opting into stricter null checking in a way that does not feel like a fork. And we?re going to think about that, and if we find something that seems acceptable, we?ll consider it.  But as James says, if you don?t know the right thing to do, then the right thing to do right now is to do nothing.  So we will not be tackling the ?wrong default? problem at the same time as we are addressing null restriction.  (Besides, there?s enough impossible problems in Valhalla that we don?t need to add another one onto our plate.)

, so people will not bother adding anything on top of that unless explicitly needed. I'm not really sure if it's achievable with preserving source backward compatibility though, given that currently, default is unspecified nullability. I think that many people will bother adding ! as much as ?, honestly. Most of the production code I have worked with didnt even care about returning an unmodifiable view of collection instead of the real one or wrapping nullable value in optional in getters and hiding no-args constructors in POJO using protected keyword. Honestly, the sad truth (in my experience) is the fact that if something is not done by default, it will not be done manually in the vast majority of cases, no matter how potentially beneficial it is. I would say that best option would be to introduce compiler flag that enables non-null by default, and eventually, after most users are migrated, make it true by default.

Regarding new null in language. I (unfortunately) spend at least half of my working with typescript. To say that this null-undefined fuss is terrible is to keep silent. That's just a complete mess. Question mark in type stands only for type | undefined, want to accept null - go and do var?: type | null - just terrible. Question mark notation in field access chains is also so strange: it, contrary to ? in type, accepts both null and undefined, and it often leads to confusing situations when you expect one of those two, but get another, logic in ?? still executes, and your erroneous state passes down through long chain of invocation until it finally fails somewhere and good luck debugging it/ Two different nulls is just a horrible idea in so many ways.

PS: Nothing bad with nulls by themself. Absence of value is also a value in many scenarios

On Tue, Sep 10, 2024 at 8:46?PM Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>> wrote:
The following was received on valhalla-spec-comments.

Point #1 rests on an assumption that the goal of this feature is to eliminate, or at least strongly discourage, nulls.  This is a common assumption ? many people are so-called ?null haters? ? but encouraging or rewarding such biases is not the role of the langauge.  Nulls are not intrinsically bad; the problem with nulls is that they are so often unexpected, and so people code as if they would never happen.  Reflecting nullity in the type system allows you to reason about when they are expected, and make reasoned choices about where nulls are appropriate or not.

You state your position pretty explicitly here:

>> The syntax to use null must be "disgusting enough" in order to
>> discourage people from using it.

I?m not going to criticize your opinions about nulls, but it is also OK to have different opinions about nulls, and it?s not the role of the language to insist that one or the other is the only valid set of feelings about it.

Your second point is what we call ?inventing a new null?; it is a tempting answer, but is overwhelmingly likely to just make the problem worse, because now there are two ill-behaved states.


> On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com<mailto:enrique.arizonbenito at gmail.com>> wrote:
>
> REF: https://openjdk.org/jeps/8303099
>
> Feedback 1:
>
> Using the syntax "Foo?" for nullables values does not discourage the
> use of nulls in code.
>
> In my experience working with Kotlin, novice (and not so novice)
> developers just find themselves comfortable enough adding an extra
> character and continue to infest code with nulls.
>
> The syntax to use null must be "disgusting enough" in order to
> discourage people from using it.
>
> For example something like Foo!!!NullBackwardCompliant!!!. This syntax
> is ugly enough to scare people about using it.
>
>
> Feedback 2:
> Most people naively tends to use null in next scenarios:
>
> * A class/record must be initialized, but due to the data flow, some
> of its members are not yet known in "present time". They depend on
> future input data/processing.
> * Some member must not take any value in a given context.
>
> Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
> Apply) values in parallel to null. Any read must throw a
> FuturePointerException or NAPointerException.
> While the behaviour looks similar to the current null and
> NullPointerException, it makes error debugging much easier to
> understand:
> * A FuturePointerException promptly warns about some race condition:
> Some code tried to read a value before some process (maybe another
> thread) initialized it.
> * A NAPointerException promptly warns about some error in the business
> logic. Some code didn't contemplate the NA scenario.
>
> "catch" blocks will also be able to make much more sensible decisions
> (when compared to the pervert NullPointerException).
>
> Without any JVM extension, a compiler most probably can automate a
> similar behavior with a syntax similar to:
>
> var Foo1 = Future
> var Foo2 = NA
>
> Foo1 and Foo2 are **NOT** nullables.
>
>  Foo2 becomes a constant (It will never change once defined and the
> compiler can make many verifications out of the box).
>
>  Foo1 must never be read until a given value is provided (after which
> it will probably become constant).
>
>
> My two cents!
>
> Enrique Ariz?n Benito
> Software Gardener


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240911/8f4b9166/attachment-0001.htm>

From vromero at openjdk.org  Wed Sep 11 02:24:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Sep 2024 02:24:57 GMT
Subject: Integrated: 8339357: [lw5] make non-nullable instance fields strict
Message-ID: <hXcoqG6T3-DU9S5WZMsaKlsLz2dGWCUoSWP5fsSXZUs=.a5e33370-9657-4169-86bc-3ce7df47fad7@github.com>

syncing javac with [[1](https://bugs.openjdk.org/browse/JDK-8303099)], in particular section: `Field and array initialization`:

- A null-restricted instance field without an initializer must be definitely assigned before the (explicit or implicit) super(...) call in each of the class's constructors. The [Flexible Constructor Bodies JEP](https://openjdk.org/jeps/8325803) allows the necessary initialization code to be written at the start of a constructor. In this early construction context, the initialization logic is not allowed to refer to this or risk any attempts to read the uninitialized field.
- If a null-restricted instance field has an initializer, the initializer is executed at the start of each constructor, before the super(...) call. (Constructors that call this(...) are a special case and, as usual, do not execute initializers at all.) Again, this means that the initialization logic of the field occurs in an early construction context and may not refer to this or risk any reads of the uninitialized field.

TIA

[1] https://bugs.openjdk.org/browse/JDK-8303099

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

Commit messages:
 - adding tests
 - 8339357: [lw5] make non-nullable fields strict

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

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

From vromero at openjdk.org  Wed Sep 11 02:24:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Sep 2024 02:24:57 GMT
Subject: Integrated: 8339357: [lw5] make non-nullable instance fields strict
In-Reply-To: <hXcoqG6T3-DU9S5WZMsaKlsLz2dGWCUoSWP5fsSXZUs=.a5e33370-9657-4169-86bc-3ce7df47fad7@github.com>
References: <hXcoqG6T3-DU9S5WZMsaKlsLz2dGWCUoSWP5fsSXZUs=.a5e33370-9657-4169-86bc-3ce7df47fad7@github.com>
Message-ID: <eSMROmKDsVKgL2wkADJHGIpdO_lJ7_-Hl_oIRA0uAA0=.daf54449-c475-45b8-b96c-b15c4ac0e03a@github.com>

On Tue, 3 Sep 2024 17:27:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> syncing javac with [[1](https://bugs.openjdk.org/browse/JDK-8303099)], in particular section: `Field and array initialization`:
> 
> - A null-restricted instance field without an initializer must be definitely assigned before the (explicit or implicit) super(...) call in each of the class's constructors. The [Flexible Constructor Bodies JEP](https://openjdk.org/jeps/8325803) allows the necessary initialization code to be written at the start of a constructor. In this early construction context, the initialization logic is not allowed to refer to this or risk any attempts to read the uninitialized field.
> - If a null-restricted instance field has an initializer, the initializer is executed at the start of each constructor, before the super(...) call. (Constructors that call this(...) are a special case and, as usual, do not execute initializers at all.) Again, this means that the initialization logic of the field occurs in an early construction context and may not refer to this or risk any reads of the uninitialized field.
> 
> TIA
> 
> [1] https://bugs.openjdk.org/browse/JDK-8303099

This pull request has now been integrated.

Changeset: 9daec2e6
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9daec2e662cca0d8fcb583481726e0a762aff5ff
Stats:     103 lines in 4 files changed: 91 ins; 0 del; 12 mod

8339357: [lw5] make non-nullable instance fields strict

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

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

From darcy at openjdk.org  Wed Sep 11 03:07:16 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 11 Sep 2024 03:07:16 GMT
Subject: [lworld+fp16] RFR: 8339599: Add nextUp(), nextDown(),
 scalb() to Float16
In-Reply-To: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>
References: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>
Message-ID: <UXQ0x8Pmzsyg0F_ewOo3L5PcRtXxTRU-MXNqu0LUWKs=.362b406d-d087-4ba3-9ad9-d6d6be67a1e7@github.com>

On Tue, 10 Sep 2024 19:17:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding these to Float16 rather than Math|StrictMath.

Looks fine.

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

Marked as reviewed by darcy (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1238#pullrequestreview-2295139453

From duke at openjdk.org  Wed Sep 11 07:55:27 2024
From: duke at openjdk.org (duke)
Date: Wed, 11 Sep 2024 07:55:27 GMT
Subject: [lworld+fp16] RFR: 8339599: Add nextUp(), nextDown(),
 scalb() to Float16
In-Reply-To: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>
References: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>
Message-ID: <Nm2GqdM7_K1XG9UzYzcLvcbXLuwI54ZxFD-k9n7jqI8=.ddf9764f-d533-4e61-a48d-ffc4262cc52b@github.com>

On Tue, 10 Sep 2024 19:17:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding these to Float16 rather than Math|StrictMath.

@rgiulietti 
Your change (at version a28cdc0297d35321792acfe8d1f3ec48780728cf) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1238#issuecomment-2342916097

From forax at univ-mlv.fr  Wed Sep 11 08:03:26 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 11 Sep 2024 10:03:26 +0200 (CEST)
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
 <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>
Message-ID: <80016337.1516245.1726041806985.JavaMail.zimbra@univ-eiffel.fr>

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Olexandr Rotan" <rotanolexandr842 at gmail.com>
> Cc: "Enrique" <enrique.arizonbenito at gmail.com>, "valhalla-dev"
> <valhalla-dev at openjdk.org>
> Sent: Wednesday, September 11, 2024 2:27:53 AM
> Subject: Re: Feedback on Null-Restricted and Nullable Types

>> On Sep 10, 2024, at 5:43 PM, Olexandr Rotan < [
>> mailto:rotanolexandr842 at gmail.com | rotanolexandr842 at gmail.com ] > wrote:

>> I would argue that not the syntax around nulls should be hideous, but rather
>> non-null should somehow be the default option

> We?re going to get this suggestion a lot. It is pretty clear that ?non-null? is
> a better default interpretation of an otherwise unannotated type name than
> ?nullable? is; this results in a lower annotation burden for annotating old
> code, less visual noise for reading fully annotated code, a safer default, etc.
> And if we were designing a language from scratch, it would be pretty hard to
> argue against this.

> But as you acknowledge, there are billions of lines of Java code out there, and
> retroactively changing their meaning is a non-starter. People will surely
> suggest things like ?what about a compiler flag? (please don?t), but that?s
> just forking the language and pretending we aren?t. And all the ?obvious?
> suggestions have one or both of these characteristics.

> So, we truly understand how this would be yet another ?Java got the defaults
> wrong?. And maybe there is a path ? in the not-so-immediate-future ? to opting
> into stricter null checking in a way that does not feel like a fork. And we?re
> going to think about that, and if we find something that seems acceptable,
> we?ll consider it. But as James says, if you don?t know the right thing to do,
> then the right thing to do right now is to do nothing. So we will not be
> tackling the ?wrong default? problem at the same time as we are addressing null
> restriction. (Besides, there?s enough impossible problems in Valhalla that we
> don?t need to add another one onto our plate.)

I see non-null by default as a side effect and not as a goal. 
The goal is to simplify the model we expose to users. 
It's clear that the underlying model is a 3 states model (let's pretend there is no type variable for a moment), so String, String? and String!. 
The main advantage of saying it's non-null by default is that it simplify the user model to a 2 states model, either String or String? so the user model is easier to understand. 
Obviously, once the code interacts with methods from the old world, the raw Strings are still there lurking but having a local 2 states model is i believe still a win. 

So the feature is providing a local 2 states user model and the nice side effect of that is having non-null by default. 

There are drawbacks to the local 2 states user model, on top of my head, how to opt-in ? Is making type variables a special case a good idea ?, should the bounds of a type variable be non-null too ? Is having no way to represent raw nullability not a problem when trying to guide inference ? And i'm sure many more. 

R?mi 

>> , so people will not bother adding anything on top of that unless explicitly
>> needed. I'm not really sure if it's achievable with preserving source backward
>> compatibility though, given that currently, default is unspecified nullability.
>> I think that many people will bother adding ! as much as ?, honestly. Most of
>> the production code I have worked with didnt even care about returning an
>> unmodifiable view of collection instead of the real one or wrapping nullable
>> value in optional in getters and hiding no-args constructors in POJO using
>> protected keyword. Honestly, the sad truth (in my experience) is the fact that
>> if something is not done by default, it will not be done manually in the vast
>> majority of cases, no matter how potentially beneficial it is. I would say that
>> best option would be to introduce compiler flag that enables non-null by
>> default, and eventually, after most users are migrated, make it true by
>> default.

>> Regarding new null in language. I (unfortunately) spend at least half of my
>> working with typescript. To say that this null-undefined fuss is terrible is to
>> keep silent. That's just a complete mess. Question mark in type stands only for
>> type | undefined, want to accept null - go and do var?: type | null - just
>> terrible. Question mark notation in field access chains is also so strange: it,
>> contrary to ? in type, accepts both null and undefined, and it often leads to
>> confusing situations when you expect one of those two, but get another, logic
>> in ?? still executes, and your erroneous state passes down through long chain
>> of invocation until it finally fails somewhere and good luck debugging it/ Two
>> different nulls is just a horrible idea in so many ways.

>> PS: Nothing bad with nulls by themself. Absence of value is also a value in many
>> scenarios

>> On Tue, Sep 10, 2024 at 8:46 PM Brian Goetz < [ mailto:brian.goetz at oracle.com |
>> brian.goetz at oracle.com ] > wrote:

>>> The following was received on valhalla-spec-comments.

>>> Point #1 rests on an assumption that the goal of this feature is to eliminate,
>>> or at least strongly discourage, nulls. This is a common assumption ? many
>>> people are so-called ?null haters? ? but encouraging or rewarding such biases
>>> is not the role of the langauge. Nulls are not intrinsically bad; the problem
>>> with nulls is that they are so often unexpected, and so people code as if they
>>> would never happen. Reflecting nullity in the type system allows you to reason
>>> about when they are expected, and make reasoned choices about where nulls are
>>> appropriate or not.

>>> You state your position pretty explicitly here:

>>> >> The syntax to use null must be "disgusting enough" in order to
>>> >> discourage people from using it.

>>> I?m not going to criticize your opinions about nulls, but it is also OK to have
>>> different opinions about nulls, and it?s not the role of the language to insist
>>> that one or the other is the only valid set of feelings about it.

>>> Your second point is what we call ?inventing a new null?; it is a tempting
>>> answer, but is overwhelmingly likely to just make the problem worse, because
>>> now there are two ill-behaved states.

>>>> On Sep 10, 2024, at 10:46 AM, Enrique < [ mailto:enrique.arizonbenito at gmail.com
>>> > | enrique.arizonbenito at gmail.com ] > wrote:

>>> > REF: [ https://openjdk.org/jeps/8303099 |
>>> https://openjdk.org/jeps/8303099 ]

>>> > Feedback 1:

>>> > Using the syntax "Foo?" for nullables values does not discourage the
>>> > use of nulls in code.

>>> > In my experience working with Kotlin, novice (and not so novice)
>>> > developers just find themselves comfortable enough adding an extra
>>> > character and continue to infest code with nulls.

>>> > The syntax to use null must be "disgusting enough" in order to
>>> > discourage people from using it.

>>> > For example something like Foo!!!NullBackwardCompliant!!!. This syntax
>>> > is ugly enough to scare people about using it.


>>> > Feedback 2:
>>> > Most people naively tends to use null in next scenarios:

>>> > * A class/record must be initialized, but due to the data flow, some
>>> > of its members are not yet known in "present time". They depend on
>>> > future input data/processing.
>>> > * Some member must not take any value in a given context.

>>> > Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
>>> > Apply) values in parallel to null. Any read must throw a
>>> > FuturePointerException or NAPointerException.
>>> > While the behaviour looks similar to the current null and
>>> > NullPointerException, it makes error debugging much easier to
>>> > understand:
>>> > * A FuturePointerException promptly warns about some race condition:
>>> > Some code tried to read a value before some process (maybe another
>>> > thread) initialized it.
>>> > * A NAPointerException promptly warns about some error in the business
>>> > logic. Some code didn't contemplate the NA scenario.

>>> > "catch" blocks will also be able to make much more sensible decisions
>>> > (when compared to the pervert NullPointerException).

>>> > Without any JVM extension, a compiler most probably can automate a
>>> > similar behavior with a syntax similar to:

>>> > var Foo1 = Future
>>> > var Foo2 = NA

>>> > Foo1 and Foo2 are **NOT** nullables.

>>> > Foo2 becomes a constant (It will never change once defined and the
>>> > compiler can make many verifications out of the box).

>>> > Foo1 must never be read until a given value is provided (after which
>>> > it will probably become constant).


>>> > My two cents!

>>> > Enrique Ariz?n Benito
>>> > Software Gardener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240911/e4b538bd/attachment.htm>

From bkilambi at openjdk.org  Wed Sep 11 08:42:34 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 11 Sep 2024 08:42:34 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
Message-ID: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>

This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.

Tested all FP16 related tests successfully on aarch64.

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

Commit messages:
 - 8339473: Add support for FP16 isFinite, isInfinite and isNaN

Changes: https://git.openjdk.org/valhalla/pull/1239/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1239&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339473
  Stats: 832 lines in 15 files changed: 198 ins; 0 del; 634 mod
  Patch: https://git.openjdk.org/valhalla/pull/1239.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1239/head:pull/1239

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

From rgiulietti at openjdk.org  Wed Sep 11 16:58:24 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 11 Sep 2024 16:58:24 GMT
Subject: [lworld+fp16] Integrated: 8339599: Add nextUp(), nextDown(),
 scalb() to Float16
In-Reply-To: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>
References: <eYdN_exVy7t7dB9wSj4a8Gpnn1iuJ7uKpzEzqJE5NPg=.7aa36f0d-a4ff-40d2-a1e8-ffe1a821a8f6@github.com>
Message-ID: <8tv6BTJzRpliZFJzIVQLl6Jns5y4vbHtOu2EL1h3OQY=.a5adc620-ce57-4640-84c5-4cfbc7745007@github.com>

On Tue, 10 Sep 2024 19:17:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Adding these to Float16 rather than Math|StrictMath.

This pull request has now been integrated.

Changeset: 45041639
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4504163905925648f3c411754ff186b55e6067ee
Stats:     496 lines in 4 files changed: 481 ins; 8 del; 7 mod

8339599: Add nextUp(), nextDown(), scalb() to Float16

Reviewed-by: darcy

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

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

From vromero at openjdk.org  Wed Sep 11 17:36:55 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Sep 2024 17:36:55 GMT
Subject: RFR: Merge lworld
Message-ID: <CCpU0P3OiliV8Q0aleLmPVQzgKfjuG-XAjbaU57AC9w=.a4f8e501-46cd-40e9-8707-4f347ee0d11a@github.com>

Merge lworld into lw5

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - Merge jdk
 - 8329254: optimize integral reverse operations on x86 GFNI target.
 - 8329656: assertion failed in MAP_ARCHIVE_MMAP_FAILURE path: Invalid immediate -5 0
 - 8329491: GetThreadListStackTraces function should use JvmtiHandshake
 - 8329432: PopFrame and ForceEarlyReturn functions should use JvmtiHandshake
 - 8330033: com/sun/net/httpserver/bugs/B6431193.java fails in AssertionError after JDK-8326568
 - 8329961: Buffer overflow in os::Linux::kernel_version
 - 8327137: Add test for ConcurrentModificationException in BasicDirectoryModel
 - 8309751: Duplicate constant pool entries added during default method processing
 - ... and 174 more: https://git.openjdk.org/valhalla/compare/9daec2e6...c0af961a

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

Changes: https://git.openjdk.org/valhalla/pull/1240/files
  Stats: 32338 lines in 788 files changed: 14503 ins; 12605 del; 5230 mod
  Patch: https://git.openjdk.org/valhalla/pull/1240.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1240/head:pull/1240

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

From vromero at openjdk.org  Wed Sep 11 17:41:22 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Sep 2024 17:41:22 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <CCpU0P3OiliV8Q0aleLmPVQzgKfjuG-XAjbaU57AC9w=.a4f8e501-46cd-40e9-8707-4f347ee0d11a@github.com>
References: <CCpU0P3OiliV8Q0aleLmPVQzgKfjuG-XAjbaU57AC9w=.a4f8e501-46cd-40e9-8707-4f347ee0d11a@github.com>
Message-ID: <aEZVqqdFxz--w5ZIwD6I2zvgNyU0sxgGrT8Ra5M-y6I=.a594004d-3caf-4128-8a46-b2631bf85d17@github.com>

On Wed, 11 Sep 2024 17:26:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge lworld into lw5

This pull request has now been integrated.

Changeset: c9a06d36
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c9a06d3669690e34da4d965683614c2a536c6cb5
Stats:     32338 lines in 788 files changed: 14503 ins; 12605 del; 5230 mod

Merge lworld

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

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

From amenkov at openjdk.org  Wed Sep 11 23:46:27 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 11 Sep 2024 23:46:27 GMT
Subject: [lworld] RFR: 8328461: [lworld] Reimplement FieldAccessModify test for
 JEP401
Message-ID: <sIGGlgBpuAPFTQo7EcZN5cI3aSRSF2iYcWu5FqGPLzY=.dcda1904-051d-4b63-a3eb-bc66532ea7f6@github.com>

- updated the test for field access/modify (use value classes);
- enabled testing of FieldModify events (the functionality was fixed);
- renamed "Valhalla" to "valhalla" for consistency with other tests.

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

Commit messages:
 - Merge branch 'FieldAccessModify' of github.com:alexmenkov/valhalla into FieldAccessModify
 - update problemlist
 - rename Valhalla dir to valhalla
 - update FieldAccessModify test
 - update problemlist
 - rename Valhalla dir to valhalla
 - update FieldAccessModify test

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

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

From snownf at outlook.com  Thu Sep 12 07:52:42 2024
From: snownf at outlook.com (=?UTF-8?B?c25vd25mQG91dGxvb2suY29t?=)
Date: Thu, 12 Sep 2024 15:52:42 +0800 (GMT+08:00)
Subject: Question: value class in switch?
Message-ID: <OS3P286MB255485F14A8811669F769F2AD1642@OS3P286MB2554.JPNP286.PROD.OUTLOOK.COM>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240912/7783afe2/attachment.htm>

From bkilambi at openjdk.org  Thu Sep 12 08:15:18 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 12 Sep 2024 08:15:18 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>

On Wed, 11 Sep 2024 08:37:38 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

Hi @jatin-bhateja , I have implemented these intrinsics in floating point in this patch. I also have another version where I tried implementing isInfinite in integer arithmetic for aarch64. I have created a draft PR here - https://github.com/openjdk/valhalla/pull/1242/commits/e095b2d47a4c28bece8fc0fcbc656da713feb132

I avoided generating the ReinterpretS2HF nodes in the mid-end which will make the "src" to be in a GPR and made the implementation in integer arithmetic easier and resulted in significant gains which can be seen in the commit message of the draft PR.

I have also tried implementing similar integer logic on x86 (in the draft PR) and I could see ~2.6x better performance than the case without the intrinsic (I have however not tried to implement the vpclass instruction for FP16 and compare performance).

Keeping the RenterpretS2HF nodes would mean that we need to move the `src` from an FPR to a GPR in the backend, before executing the integer operations which proved to be costly and not very beneficial.

What do you think of not using ReinterpretS2HF node for these intrinsics and keeping the `src` in a GPR instead? I know that technically FP16 is floating point (even if storage is `short`) and we have always implemented the `src` in an FPR so as to generate FP instructions but I was wondering if this tweak is ok if we see good performance gains? Looking forward to hearing your feedback. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2345562624

From chagedorn at openjdk.org  Thu Sep 12 08:23:15 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 12 Sep 2024 08:23:15 GMT
Subject: [lworld] RFR: 8331964: [lworld] C2: Support abstract value class
 fields [v7]
In-Reply-To: <k7oYbOZwRd8nRjUHPjErTosTRbHb1wLeQ7o23vhD770=.716c7f52-0180-4b55-95b9-5d22a576d129@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
 <k7oYbOZwRd8nRjUHPjErTosTRbHb1wLeQ7o23vhD770=.716c7f52-0180-4b55-95b9-5d22a576d129@github.com>
Message-ID: <6Wx6HGc6bQRSubdHzOuXadwwB6Ff10Br5bHcUeQhhow=.dcf6d763-e50c-4df4-a87a-6dc479636463@github.com>

On Fri, 6 Sep 2024 13:40:37 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
>> 
>> ## Updated Larval Handling
>> ### Previous Larval Initialization
>> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
>> 
>> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
>> 
>> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
>> 
>> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
>> 
>> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
>> 
>> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
>> 
>> ### New Larval Initialization with Fields in Abstract Classes
>> #### Problems
>> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
>> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class construct...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix replace in map for updated receiver instead of original one

Thanks for the review, testing looked good!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1236#issuecomment-2345577501

From chagedorn at openjdk.org  Thu Sep 12 08:23:16 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 12 Sep 2024 08:23:16 GMT
Subject: [lworld] Integrated: 8331964: [lworld] C2: Support abstract value
 class fields
In-Reply-To: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
References: <cobeYtDqVZ6pyLmyeSGFslygJXTl9bNWalf2YF5rY88=.86d0b864-5fc0-43c7-b747-419e52a1d282@github.com>
Message-ID: <CIJ9JiCFzKcdtxRcsCwDY5elhuHm1opDF182851UP00=.001aa22a-8aa0-4178-a6d9-9ff4eacdaac6@github.com>

On Wed, 4 Sep 2024 10:32:49 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch adds support for abstract value class fields. To make it work, it required fixes in various places. The two main things to change was to account for fields in abstract value classes when collecting/accessing all fields which was not expected before and updating the way we handle larvals.
> 
> ## Updated Larval Handling
> ### Previous Larval Initialization
> Before this change, larvals were always updated inside a single concrete value class constructor. It could have been done directly:
> 
> new MyValue -> MyValue.<init> (initialization here) -> Object.<init>
> 
> or by first delegating to another value type constructor inside the same value class which does the initiliazation:
> 
> new MyValue -> MyValue.<init> -> MyValue.<init> (initialization here) -> Object.<init>
> 
> It was not possible to distribute the initialization of an inline type to multiple constructors (i.e. at value class constructor cannot do a partial initialization).
> 
> Therefore, we could just detect any call from a value class constructor to an abstract constructor or the `Object` constructor with the same receiver and then mark the inline type as non-larval since it's completely initialized before calling the super constructor (abstract classes and `Object.<init>` cannot modify the inline type anymore). The only thing required after the call was to detect if we actually inlined another constructor with the same receiver within the same concrete value class. If that's the case, we need to update the exit map to propagate the initialized receiver to the caller.
> 
> This now changes: With fields in abstract value classes, a larval is not completely initialized after the concrete value class constructor is complete. We therefore needed to find a new way to ensure the correct initialization of larvals.
> 
> ### New Larval Initialization with Fields in Abstract Classes
> #### Problems
> - A larval _could_ be fully initialized after calling the concrete value class constructor. But we could also have a situation where we still need to initialize a field in an abstract value class. Therefore, we cannot eagerly mark an inline type as non-larval once the concrete value class constructor is completed nor when an abstract value class constructor is completed (there could be multiple).
> - The currently parsed method only has the map/JVM state from the direct caller. We therefore cannot simply detect the call to the `Object.<init>()` call at the end of chained value class constructor calls and then propagate the update to al...

This pull request has now been integrated.

Changeset: f63f1940
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f63f19400ba72f5fd1d34a0169617661c945bf43
Stats:     1388 lines in 13 files changed: 1267 ins; 24 del; 97 mod

8331964: [lworld] C2: Support abstract value class fields

Reviewed-by: thartmann

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

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

From rotanolexandr842 at gmail.com  Thu Sep 12 10:31:42 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 12 Sep 2024 13:31:42 +0300
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <80016337.1516245.1726041806985.JavaMail.zimbra@univ-eiffel.fr>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
 <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>
 <80016337.1516245.1726041806985.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAL5bRt9RJRf6N7RuTjE=O2CsKOzpnSM6Xd3y=B6rZa1Mm2A=OQ@mail.gmail.com>

I have given a lot of thought to this topic since my last mail here.
Ultimately, what I have concluded on is that even if we try to somehow
infer nullability, the limits of this inference are drawn on the bounds of
the system and non-final fields. Nullability, though, can be inferred for
local variables, and IDEs already are doing a pretty good job in this area,
so I am not sure if this is a job of jdk to reinvent this analysis once
again.

So, the best idea that crossed my mind so far is to, instead of
forbidding compilation by making non-null default, just be as annoying as
possible *for unspecified nullability* (I emphasize that, as I see, problem
is unspecified nullability rather then specified with '?'), by introducing
some warning for any unspecified nullability type, at least at the bounds
of type (i.e. public and arguably package-private members and their
declaration members), but, if i were to decide, for all members of type.
Local variables could have a bit more loose requirements imo, however,
including them into inspection could encourage people to use var keywords
if that was the point for any reason.

I think that this annoyance is acceptable, because, as I see it, ? notation
is essentially union of type and null, while ! is an explicit statement
that this type does not contain null. Hence, warnings about unspecified
nullability is just a warning that you don't give compiler enough
information to validate your code, in some way like unchecked cast and raw
types warnings currently. This kind of soft but steady power could
potentially end us up in a situation when, eventually, there is little to
none code without nullability notation.

Also, as an option, a tool for nullability inference could be included in
jdk as a separate tool instead of part of the compiler. This could smoothen
the steep path developers would have to take o migrate to new java
versions, by sparing them from work to manually add nullability info to
each local variable

On Wed, Sep 11, 2024 at 11:03?AM Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ------------------------------
>
> *From: *"Brian Goetz" <brian.goetz at oracle.com>
> *To: *"Olexandr Rotan" <rotanolexandr842 at gmail.com>
> *Cc: *"Enrique" <enrique.arizonbenito at gmail.com>, "valhalla-dev" <
> valhalla-dev at openjdk.org>
> *Sent: *Wednesday, September 11, 2024 2:27:53 AM
> *Subject: *Re: Feedback on Null-Restricted and Nullable Types
>
>
>
> On Sep 10, 2024, at 5:43 PM, Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
>
> I would argue that not the syntax around nulls should be hideous, but
> rather non-null should somehow be the default option
>
>
> We?re going to get this suggestion a lot.  It is pretty clear that
> ?non-null? is a better default interpretation of an otherwise unannotated
> type name than ?nullable? is; this results in a lower annotation burden for
> annotating old code, less visual noise for reading fully annotated code, a
> safer default, etc.  And if we were designing a language from scratch, it
> would be pretty hard to argue against this.
>
> But as you acknowledge, there are billions of lines of Java code out
> there, and retroactively changing their meaning is a non-starter.  People
> will surely suggest things like ?what about a compiler flag? (please
> don?t), but that?s just forking the language and pretending we aren?t.  And
> all the ?obvious? suggestions have one or both of these characteristics.
>
> So, we truly understand how this would be yet another ?Java got the
> defaults wrong?.  And maybe there is a path ? in the
> not-so-immediate-future ? to opting into stricter null checking in a way
> that does not feel like a fork. And we?re going to think about that, and if
> we find something that seems acceptable, we?ll consider it.  But as James
> says, if you don?t know the right thing to do, then the right thing to do
> right now is to do nothing.  So we will not be tackling the ?wrong default?
> problem at the same time as we are addressing null restriction.  (Besides,
> there?s enough impossible problems in Valhalla that we don?t need to add
> another one onto our plate.)
>
>
> I see non-null by default as a side effect and not as a goal.
> The goal is to simplify the model we expose to users.
> It's clear that the underlying model is a 3 states model (let's pretend
> there is no type variable for a moment), so String, String? and String!.
> The main advantage of saying it's non-null by default is that it simplify
> the user model to a 2 states model, either String or String? so the user
> model is easier to understand.
> Obviously, once the code interacts with methods from the old world, the
> raw Strings are still there lurking but having a local 2 states model is i
> believe still a win.
>
> So the feature is providing a local 2 states user model and the nice side
> effect of that is having non-null by default.
>
> There are drawbacks to the local 2 states user model, on top of my head,
> how to opt-in ? Is making type variables a special case a good idea ?,
> should the bounds of a type variable be non-null too ? Is having no way to
> represent raw nullability not a problem when trying to guide inference ?
> And i'm sure many more.
>
> R?mi
>
>
> , so people will not bother adding anything on top of that unless
> explicitly needed. I'm not really sure if it's achievable with preserving
> source backward compatibility though, given that currently, default is
> unspecified nullability. I think that many people will bother adding ! as
> much as ?, honestly. Most of the production code I have worked with
> didnt even care about returning an unmodifiable view of collection instead
> of the real one or wrapping nullable value in optional in getters and
> hiding no-args constructors in POJO using protected keyword. Honestly, the
> sad truth (in my experience) is the fact that if something is not done by
> default, it will not be done manually in the vast majority of cases, no
> matter how potentially beneficial it is. I would say that best option would
> be to introduce compiler flag that enables non-null by default, and
> eventually, after most users are migrated, make it true by default.
>
> Regarding new null in language. I (unfortunately) spend at least half of
> my working with typescript. To say that this null-undefined fuss is
> terrible is to keep silent. That's just a complete mess. Question mark in
> type stands only for type | undefined, want to accept null - go and do
> var?: type | null - just terrible. Question mark notation in field access
> chains is also so strange: it, contrary to ? in type, accepts both null and
> undefined, and it often leads to confusing situations when you expect one
> of those two, but get another, logic in ?? still executes, and your
> erroneous state passes down through long chain of invocation until it
> finally fails somewhere and good luck debugging it/ Two different nulls is
> just a horrible idea in so many ways.
>
> PS: Nothing bad with nulls by themself. Absence of value is also a value
> in many scenarios
>
> On Tue, Sep 10, 2024 at 8:46?PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> The following was received on valhalla-spec-comments.
>>
>> Point #1 rests on an assumption that the goal of this feature is to
>> eliminate, or at least strongly discourage, nulls.  This is a common
>> assumption ? many people are so-called ?null haters? ? but encouraging or
>> rewarding such biases is not the role of the langauge.  Nulls are not
>> intrinsically bad; the problem with nulls is that they are so often
>> unexpected, and so people code as if they would never happen.  Reflecting
>> nullity in the type system allows you to reason about when they are
>> expected, and make reasoned choices about where nulls are appropriate or
>> not.
>>
>> You state your position pretty explicitly here:
>>
>> >> The syntax to use null must be "disgusting enough" in order to
>> >> discourage people from using it.
>>
>> I?m not going to criticize your opinions about nulls, but it is also OK
>> to have different opinions about nulls, and it?s not the role of the
>> language to insist that one or the other is the only valid set of feelings
>> about it.
>>
>> Your second point is what we call ?inventing a new null?; it is a
>> tempting answer, but is overwhelmingly likely to just make the problem
>> worse, because now there are two ill-behaved states.
>>
>>
>> > On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com>
>> wrote:
>> >
>> > REF: https://openjdk.org/jeps/8303099
>> >
>> > Feedback 1:
>> >
>> > Using the syntax "Foo?" for nullables values does not discourage the
>> > use of nulls in code.
>> >
>> > In my experience working with Kotlin, novice (and not so novice)
>> > developers just find themselves comfortable enough adding an extra
>> > character and continue to infest code with nulls.
>> >
>> > The syntax to use null must be "disgusting enough" in order to
>> > discourage people from using it.
>> >
>> > For example something like Foo!!!NullBackwardCompliant!!!. This syntax
>> > is ugly enough to scare people about using it.
>> >
>> >
>> > Feedback 2:
>> > Most people naively tends to use null in next scenarios:
>> >
>> > * A class/record must be initialized, but due to the data flow, some
>> > of its members are not yet known in "present time". They depend on
>> > future input data/processing.
>> > * Some member must not take any value in a given context.
>> >
>> > Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
>> > Apply) values in parallel to null. Any read must throw a
>> > FuturePointerException or NAPointerException.
>> > While the behaviour looks similar to the current null and
>> > NullPointerException, it makes error debugging much easier to
>> > understand:
>> > * A FuturePointerException promptly warns about some race condition:
>> > Some code tried to read a value before some process (maybe another
>> > thread) initialized it.
>> > * A NAPointerException promptly warns about some error in the business
>> > logic. Some code didn't contemplate the NA scenario.
>> >
>> > "catch" blocks will also be able to make much more sensible decisions
>> > (when compared to the pervert NullPointerException).
>> >
>> > Without any JVM extension, a compiler most probably can automate a
>> > similar behavior with a syntax similar to:
>> >
>> > var Foo1 = Future
>> > var Foo2 = NA
>> >
>> > Foo1 and Foo2 are **NOT** nullables.
>> >
>> >  Foo2 becomes a constant (It will never change once defined and the
>> > compiler can make many verifications out of the box).
>> >
>> >  Foo1 must never be read until a given value is provided (after which
>> > it will probably become constant).
>> >
>> >
>> > My two cents!
>> >
>> > Enrique Ariz?n Benito
>> > Software Gardener
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240912/c32ee4ca/attachment-0001.htm>

From jbhateja at openjdk.org  Thu Sep 12 14:26:48 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 12 Sep 2024 14:26:48 GMT
Subject: [lworld+fp16] RFR: 8340013: x86 backend support for Float16 unary and
 ternary operations
Message-ID: <xu_bshOjYpgMNuNHP3N6vdcgbRLWh-vkIEBpJJ-4c3M=.0b48a909-681d-4426-83c3-1515bc1303cb@github.com>

Summary of changes:-
- Add optimized x86 backend implementation for scalar and vector flavors of following Float16 APIs.
  - FMA, SQRT, NEG, ABS
- Add memory operand patterns for all existing Float16 vector operations.

All existing Float16 functional and IR based tests are passing with the patch.

Best Regards,
Jatin

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

Commit messages:
 - 8340013: x86 backend support for Float16 unary and ternary operations

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

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

From enrique.arizonbenito at gmail.com  Thu Sep 12 16:20:26 2024
From: enrique.arizonbenito at gmail.com (Enrique)
Date: Thu, 12 Sep 2024 18:20:26 +0200
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <CAL5bRt9RJRf6N7RuTjE=O2CsKOzpnSM6Xd3y=B6rZa1Mm2A=OQ@mail.gmail.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
 <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>
 <80016337.1516245.1726041806985.JavaMail.zimbra@univ-eiffel.fr>
 <CAL5bRt9RJRf6N7RuTjE=O2CsKOzpnSM6Xd3y=B6rZa1Mm2A=OQ@mail.gmail.com>
Message-ID: <CAD-msxEvOqEG2DW3KaCc40ioyqkZCRdXP2BegPEJL5yHU1+Z=Q@mail.gmail.com>

Hi again,

just some extra thoughts based on previous comments.

Starting from the scratch, the simplest way to get rid of nulls would
be to remove it. This is completely possible as Vlang has proved.
https://vlang.io/
(As a curiosity I also proposed that same solution time ago in the LUA
list https://lua-users.org/lists/lua-l/2015-01/msg00222.html,
unfortunately I lack the time to implement it.)

Then the real problem is to keep compatibility with "the billion
dollar mistake". A "simple" way to do so would be:

Duplicate the syntax for declaration of variables.

We can use the current syntax with no change:

var maybeNullVar = getFromOldFunctionReturningNullsAtWill();
String maybeNull  = getFromAnotherOldFunctionReturningNullsAtWill();

then the new syntax is added:

mutable safeval neverNullVar =
getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes(); // ?
safeString doesntApplyInContext = NA; // throw NAPointerException when
trying to read or update it. safeString is final by default.
safeString email = FUTURE; // throw FUTUREPointerException when trying
to read it, we can still update it "just once", then becomes
immutable.
mutable safeString stringState = FUTURE; throw FUTUREPointerException
when trying to read it, we can still update as many times as we want.

? Since we want to make things safe, let's just default to immutable
variables, and mark mutable explicitly.

To convert from unsafe to safe, a function will be needed:

final safeLong safeLong =
safetyFunctionTakingNonSafeAsInputAndReturningSafeAsOutput();

The "safe" prefix is a "30 seconds of thought", just to let it clear
to novices that the opposite is not safe and discouraged.

QA managers will have no trouble detecting code using unsafe vars. No
need for special tooling, just "grepping" the code.

Some future JDK "N" version can start warning about unsafe variables,
then N+20 version will force the use of a flag (or environment
variable) to compile unsafe code, finally N+100 will remove unsafe
vars from the language and JVM (I guess this will also boost the JIT
performance).

PS: I didn't know about the "null haters" term. I find it funny, and
definitely and considering that the null makes all of us waste time
and money, I invite everybody to join the "null haters" religion.
We can organize illegal parties and destroy null pointers to
celebrate, then escape before the police arrive.

Regards,

Enrique Ariz?n Benito
Software Gardener


On Thu, Sep 12, 2024 at 12:32?PM Olexandr Rotan
<rotanolexandr842 at gmail.com> wrote:
>
> I have given a lot of thought to this topic since my last mail here. Ultimately, what I have concluded on is that even if we try to somehow infer nullability, the limits of this inference are drawn on the bounds of the system and non-final fields. Nullability, though, can be inferred for local variables, and IDEs already are doing a pretty good job in this area, so I am not sure if this is a job of jdk to reinvent this analysis once again.
>
> So, the best idea that crossed my mind so far is to, instead of forbidding compilation by making non-null default, just be as annoying as possible *for unspecified nullability* (I emphasize that, as I see, problem is unspecified nullability rather then specified with '?'), by introducing some warning for any unspecified nullability type, at least at the bounds of type (i.e. public and arguably package-private members and their declaration members), but, if i were to decide, for all members of type. Local variables could have a bit more loose requirements imo, however, including them into inspection could encourage people to use var keywords if that was the point for any reason.
>
> I think that this annoyance is acceptable, because, as I see it, ? notation is essentially union of type and null, while ! is an explicit statement that this type does not contain null. Hence, warnings about unspecified nullability is just a warning that you don't give compiler enough information to validate your code, in some way like unchecked cast and raw types warnings currently. This kind of soft but steady power could potentially end us up in a situation when, eventually, there is little to none code without nullability notation.
>
> Also, as an option, a tool for nullability inference could be included in jdk as a separate tool instead of part of the compiler. This could smoothen the steep path developers would have to take o migrate to new java versions, by sparing them from work to manually add nullability info to each local variable
>
> On Wed, Sep 11, 2024 at 11:03?AM Remi Forax <forax at univ-mlv.fr> wrote:
>>
>>
>>
>> ________________________________
>>
>> From: "Brian Goetz" <brian.goetz at oracle.com>
>> To: "Olexandr Rotan" <rotanolexandr842 at gmail.com>
>> Cc: "Enrique" <enrique.arizonbenito at gmail.com>, "valhalla-dev" <valhalla-dev at openjdk.org>
>> Sent: Wednesday, September 11, 2024 2:27:53 AM
>> Subject: Re: Feedback on Null-Restricted and Nullable Types
>>
>>
>>
>> On Sep 10, 2024, at 5:43 PM, Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:
>>
>> I would argue that not the syntax around nulls should be hideous, but rather non-null should somehow be the default option
>>
>>
>> We?re going to get this suggestion a lot.  It is pretty clear that ?non-null? is a better default interpretation of an otherwise unannotated type name than ?nullable? is; this results in a lower annotation burden for annotating old code, less visual noise for reading fully annotated code, a safer default, etc.  And if we were designing a language from scratch, it would be pretty hard to argue against this.
>>
>> But as you acknowledge, there are billions of lines of Java code out there, and retroactively changing their meaning is a non-starter.  People will surely suggest things like ?what about a compiler flag? (please don?t), but that?s just forking the language and pretending we aren?t.  And all the ?obvious? suggestions have one or both of these characteristics.
>>
>> So, we truly understand how this would be yet another ?Java got the defaults wrong?.  And maybe there is a path ? in the not-so-immediate-future ? to opting into stricter null checking in a way that does not feel like a fork. And we?re going to think about that, and if we find something that seems acceptable, we?ll consider it.  But as James says, if you don?t know the right thing to do, then the right thing to do right now is to do nothing.  So we will not be tackling the ?wrong default? problem at the same time as we are addressing null restriction.  (Besides, there?s enough impossible problems in Valhalla that we don?t need to add another one onto our plate.)
>>
>>
>> I see non-null by default as a side effect and not as a goal.
>> The goal is to simplify the model we expose to users.
>> It's clear that the underlying model is a 3 states model (let's pretend there is no type variable for a moment), so String, String? and String!.
>> The main advantage of saying it's non-null by default is that it simplify the user model to a 2 states model, either String or String? so the user model is easier to understand.
>> Obviously, once the code interacts with methods from the old world, the raw Strings are still there lurking but having a local 2 states model is i believe still a win.
>>
>> So the feature is providing a local 2 states user model and the nice side effect of that is having non-null by default.
>>
>> There are drawbacks to the local 2 states user model, on top of my head, how to opt-in ? Is making type variables a special case a good idea ?, should the bounds of a type variable be non-null too ? Is having no way to represent raw nullability not a problem when trying to guide inference ? And i'm sure many more.
>>
>> R?mi
>>
>>
>> , so people will not bother adding anything on top of that unless explicitly needed. I'm not really sure if it's achievable with preserving source backward compatibility though, given that currently, default is unspecified nullability. I think that many people will bother adding ! as much as ?, honestly. Most of the production code I have worked with didnt even care about returning an unmodifiable view of collection instead of the real one or wrapping nullable value in optional in getters and hiding no-args constructors in POJO using protected keyword. Honestly, the sad truth (in my experience) is the fact that if something is not done by default, it will not be done manually in the vast majority of cases, no matter how potentially beneficial it is. I would say that best option would be to introduce compiler flag that enables non-null by default, and eventually, after most users are migrated, make it true by default.
>>
>> Regarding new null in language. I (unfortunately) spend at least half of my working with typescript. To say that this null-undefined fuss is terrible is to keep silent. That's just a complete mess. Question mark in type stands only for type | undefined, want to accept null - go and do var?: type | null - just terrible. Question mark notation in field access chains is also so strange: it, contrary to ? in type, accepts both null and undefined, and it often leads to confusing situations when you expect one of those two, but get another, logic in ?? still executes, and your erroneous state passes down through long chain of invocation until it finally fails somewhere and good luck debugging it/ Two different nulls is just a horrible idea in so many ways.
>>
>> PS: Nothing bad with nulls by themself. Absence of value is also a value in many scenarios
>>
>> On Tue, Sep 10, 2024 at 8:46?PM Brian Goetz <brian.goetz at oracle.com> wrote:
>>>
>>> The following was received on valhalla-spec-comments.
>>>
>>> Point #1 rests on an assumption that the goal of this feature is to eliminate, or at least strongly discourage, nulls.  This is a common assumption ? many people are so-called ?null haters? ? but encouraging or rewarding such biases is not the role of the langauge.  Nulls are not intrinsically bad; the problem with nulls is that they are so often unexpected, and so people code as if they would never happen.  Reflecting nullity in the type system allows you to reason about when they are expected, and make reasoned choices about where nulls are appropriate or not.
>>>
>>> You state your position pretty explicitly here:
>>>
>>> >> The syntax to use null must be "disgusting enough" in order to
>>> >> discourage people from using it.
>>>
>>> I?m not going to criticize your opinions about nulls, but it is also OK to have different opinions about nulls, and it?s not the role of the language to insist that one or the other is the only valid set of feelings about it.
>>>
>>> Your second point is what we call ?inventing a new null?; it is a tempting answer, but is overwhelmingly likely to just make the problem worse, because now there are two ill-behaved states.
>>>
>>>
>>> > On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com> wrote:
>>> >
>>> > REF: https://openjdk.org/jeps/8303099
>>> >
>>> > Feedback 1:
>>> >
>>> > Using the syntax "Foo?" for nullables values does not discourage the
>>> > use of nulls in code.
>>> >
>>> > In my experience working with Kotlin, novice (and not so novice)
>>> > developers just find themselves comfortable enough adding an extra
>>> > character and continue to infest code with nulls.
>>> >
>>> > The syntax to use null must be "disgusting enough" in order to
>>> > discourage people from using it.
>>> >
>>> > For example something like Foo!!!NullBackwardCompliant!!!. This syntax
>>> > is ugly enough to scare people about using it.
>>> >
>>> >
>>> > Feedback 2:
>>> > Most people naively tends to use null in next scenarios:
>>> >
>>> > * A class/record must be initialized, but due to the data flow, some
>>> > of its members are not yet known in "present time". They depend on
>>> > future input data/processing.
>>> > * Some member must not take any value in a given context.
>>> >
>>> > Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
>>> > Apply) values in parallel to null. Any read must throw a
>>> > FuturePointerException or NAPointerException.
>>> > While the behaviour looks similar to the current null and
>>> > NullPointerException, it makes error debugging much easier to
>>> > understand:
>>> > * A FuturePointerException promptly warns about some race condition:
>>> > Some code tried to read a value before some process (maybe another
>>> > thread) initialized it.
>>> > * A NAPointerException promptly warns about some error in the business
>>> > logic. Some code didn't contemplate the NA scenario.
>>> >
>>> > "catch" blocks will also be able to make much more sensible decisions
>>> > (when compared to the pervert NullPointerException).
>>> >
>>> > Without any JVM extension, a compiler most probably can automate a
>>> > similar behavior with a syntax similar to:
>>> >
>>> > var Foo1 = Future
>>> > var Foo2 = NA
>>> >
>>> > Foo1 and Foo2 are **NOT** nullables.
>>> >
>>> >  Foo2 becomes a constant (It will never change once defined and the
>>> > compiler can make many verifications out of the box).
>>> >
>>> >  Foo1 must never be read until a given value is provided (after which
>>> > it will probably become constant).
>>> >
>>> >
>>> > My two cents!
>>> >
>>> > Enrique Ariz?n Benito
>>> > Software Gardener
>>>
>>
>>

From rotanolexandr842 at gmail.com  Thu Sep 12 16:39:58 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 12 Sep 2024 19:39:58 +0300
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <CAD-msxEvOqEG2DW3KaCc40ioyqkZCRdXP2BegPEJL5yHU1+Z=Q@mail.gmail.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
 <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>
 <80016337.1516245.1726041806985.JavaMail.zimbra@univ-eiffel.fr>
 <CAL5bRt9RJRf6N7RuTjE=O2CsKOzpnSM6Xd3y=B6rZa1Mm2A=OQ@mail.gmail.com>
 <CAD-msxEvOqEG2DW3KaCc40ioyqkZCRdXP2BegPEJL5yHU1+Z=Q@mail.gmail.com>
Message-ID: <CAL5bRt_r3gPzgAxbOBeeHy7TFO2WkENfdhxgQBHavQOo4ONg+A@mail.gmail.com>

Just an immediate thought about reading your mail. What is the difference
between the mutable safeval neverNullVar =
getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes() syntax and var
neverNullVar = getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes()!
(exclam on the end), which is really common in null-safe languages. I would
argue that if exclam syntax would be fail-fast, later is even more
plausible, especially considering the cost of adding new keywords to
language, even weak ones. Undefined nullability decorated with ! would just
become non-nullable.

The Future syntax somehow for me seems like a readonly (final in java) for
local variables. That would be nice to have, but If we go down to the level
of local variables, I would say that just a simple val keyword from kotlin
would be a much greater contribution to local variables immutability.

On Thu, Sep 12, 2024 at 7:20?PM Enrique <enrique.arizonbenito at gmail.com>
wrote:

> Hi again,
>
> just some extra thoughts based on previous comments.
>
> Starting from the scratch, the simplest way to get rid of nulls would
> be to remove it. This is completely possible as Vlang has proved.
> https://vlang.io/
> (As a curiosity I also proposed that same solution time ago in the LUA
> list https://lua-users.org/lists/lua-l/2015-01/msg00222.html,
> unfortunately I lack the time to implement it.)
>
> Then the real problem is to keep compatibility with "the billion
> dollar mistake". A "simple" way to do so would be:
>
> Duplicate the syntax for declaration of variables.
>
> We can use the current syntax with no change:
>
> var maybeNullVar = getFromOldFunctionReturningNullsAtWill();
> String maybeNull  = getFromAnotherOldFunctionReturningNullsAtWill();
>
> then the new syntax is added:
>
> mutable safeval neverNullVar =
> getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes(); // ?
> safeString doesntApplyInContext = NA; // throw NAPointerException when
> trying to read or update it. safeString is final by default.
> safeString email = FUTURE; // throw FUTUREPointerException when trying
> to read it, we can still update it "just once", then becomes
> immutable.
> mutable safeString stringState = FUTURE; throw FUTUREPointerException
> when trying to read it, we can still update as many times as we want.
>
> ? Since we want to make things safe, let's just default to immutable
> variables, and mark mutable explicitly.
>
> To convert from unsafe to safe, a function will be needed:
>
> final safeLong safeLong =
> safetyFunctionTakingNonSafeAsInputAndReturningSafeAsOutput();
>
> The "safe" prefix is a "30 seconds of thought", just to let it clear
> to novices that the opposite is not safe and discouraged.
>
> QA managers will have no trouble detecting code using unsafe vars. No
> need for special tooling, just "grepping" the code.
>
> Some future JDK "N" version can start warning about unsafe variables,
> then N+20 version will force the use of a flag (or environment
> variable) to compile unsafe code, finally N+100 will remove unsafe
> vars from the language and JVM (I guess this will also boost the JIT
> performance).
>
> PS: I didn't know about the "null haters" term. I find it funny, and
> definitely and considering that the null makes all of us waste time
> and money, I invite everybody to join the "null haters" religion.
> We can organize illegal parties and destroy null pointers to
> celebrate, then escape before the police arrive.
>
> Regards,
>
> Enrique Ariz?n Benito
> Software Gardener
>
>
> On Thu, Sep 12, 2024 at 12:32?PM Olexandr Rotan
> <rotanolexandr842 at gmail.com> wrote:
> >
> > I have given a lot of thought to this topic since my last mail here.
> Ultimately, what I have concluded on is that even if we try to somehow
> infer nullability, the limits of this inference are drawn on the bounds of
> the system and non-final fields. Nullability, though, can be inferred for
> local variables, and IDEs already are doing a pretty good job in this area,
> so I am not sure if this is a job of jdk to reinvent this analysis once
> again.
> >
> > So, the best idea that crossed my mind so far is to, instead of
> forbidding compilation by making non-null default, just be as annoying as
> possible *for unspecified nullability* (I emphasize that, as I see, problem
> is unspecified nullability rather then specified with '?'), by introducing
> some warning for any unspecified nullability type, at least at the bounds
> of type (i.e. public and arguably package-private members and their
> declaration members), but, if i were to decide, for all members of type.
> Local variables could have a bit more loose requirements imo, however,
> including them into inspection could encourage people to use var keywords
> if that was the point for any reason.
> >
> > I think that this annoyance is acceptable, because, as I see it, ?
> notation is essentially union of type and null, while ! is an explicit
> statement that this type does not contain null. Hence, warnings about
> unspecified nullability is just a warning that you don't give compiler
> enough information to validate your code, in some way like unchecked cast
> and raw types warnings currently. This kind of soft but steady power could
> potentially end us up in a situation when, eventually, there is little to
> none code without nullability notation.
> >
> > Also, as an option, a tool for nullability inference could be included
> in jdk as a separate tool instead of part of the compiler. This could
> smoothen the steep path developers would have to take o migrate to new java
> versions, by sparing them from work to manually add nullability info to
> each local variable
> >
> > On Wed, Sep 11, 2024 at 11:03?AM Remi Forax <forax at univ-mlv.fr> wrote:
> >>
> >>
> >>
> >> ________________________________
> >>
> >> From: "Brian Goetz" <brian.goetz at oracle.com>
> >> To: "Olexandr Rotan" <rotanolexandr842 at gmail.com>
> >> Cc: "Enrique" <enrique.arizonbenito at gmail.com>, "valhalla-dev" <
> valhalla-dev at openjdk.org>
> >> Sent: Wednesday, September 11, 2024 2:27:53 AM
> >> Subject: Re: Feedback on Null-Restricted and Nullable Types
> >>
> >>
> >>
> >> On Sep 10, 2024, at 5:43 PM, Olexandr Rotan <rotanolexandr842 at gmail.com>
> wrote:
> >>
> >> I would argue that not the syntax around nulls should be hideous, but
> rather non-null should somehow be the default option
> >>
> >>
> >> We?re going to get this suggestion a lot.  It is pretty clear that
> ?non-null? is a better default interpretation of an otherwise unannotated
> type name than ?nullable? is; this results in a lower annotation burden for
> annotating old code, less visual noise for reading fully annotated code, a
> safer default, etc.  And if we were designing a language from scratch, it
> would be pretty hard to argue against this.
> >>
> >> But as you acknowledge, there are billions of lines of Java code out
> there, and retroactively changing their meaning is a non-starter.  People
> will surely suggest things like ?what about a compiler flag? (please
> don?t), but that?s just forking the language and pretending we aren?t.  And
> all the ?obvious? suggestions have one or both of these characteristics.
> >>
> >> So, we truly understand how this would be yet another ?Java got the
> defaults wrong?.  And maybe there is a path ? in the
> not-so-immediate-future ? to opting into stricter null checking in a way
> that does not feel like a fork. And we?re going to think about that, and if
> we find something that seems acceptable, we?ll consider it.  But as James
> says, if you don?t know the right thing to do, then the right thing to do
> right now is to do nothing.  So we will not be tackling the ?wrong default?
> problem at the same time as we are addressing null restriction.  (Besides,
> there?s enough impossible problems in Valhalla that we don?t need to add
> another one onto our plate.)
> >>
> >>
> >> I see non-null by default as a side effect and not as a goal.
> >> The goal is to simplify the model we expose to users.
> >> It's clear that the underlying model is a 3 states model (let's pretend
> there is no type variable for a moment), so String, String? and String!.
> >> The main advantage of saying it's non-null by default is that it
> simplify the user model to a 2 states model, either String or String? so
> the user model is easier to understand.
> >> Obviously, once the code interacts with methods from the old world, the
> raw Strings are still there lurking but having a local 2 states model is i
> believe still a win.
> >>
> >> So the feature is providing a local 2 states user model and the nice
> side effect of that is having non-null by default.
> >>
> >> There are drawbacks to the local 2 states user model, on top of my
> head, how to opt-in ? Is making type variables a special case a good idea
> ?, should the bounds of a type variable be non-null too ? Is having no way
> to represent raw nullability not a problem when trying to guide inference ?
> And i'm sure many more.
> >>
> >> R?mi
> >>
> >>
> >> , so people will not bother adding anything on top of that unless
> explicitly needed. I'm not really sure if it's achievable with preserving
> source backward compatibility though, given that currently, default is
> unspecified nullability. I think that many people will bother adding ! as
> much as ?, honestly. Most of the production code I have worked with didnt
> even care about returning an unmodifiable view of collection instead of the
> real one or wrapping nullable value in optional in getters and hiding
> no-args constructors in POJO using protected keyword. Honestly, the sad
> truth (in my experience) is the fact that if something is not done by
> default, it will not be done manually in the vast majority of cases, no
> matter how potentially beneficial it is. I would say that best option would
> be to introduce compiler flag that enables non-null by default, and
> eventually, after most users are migrated, make it true by default.
> >>
> >> Regarding new null in language. I (unfortunately) spend at least half
> of my working with typescript. To say that this null-undefined fuss is
> terrible is to keep silent. That's just a complete mess. Question mark in
> type stands only for type | undefined, want to accept null - go and do
> var?: type | null - just terrible. Question mark notation in field access
> chains is also so strange: it, contrary to ? in type, accepts both null and
> undefined, and it often leads to confusing situations when you expect one
> of those two, but get another, logic in ?? still executes, and your
> erroneous state passes down through long chain of invocation until it
> finally fails somewhere and good luck debugging it/ Two different nulls is
> just a horrible idea in so many ways.
> >>
> >> PS: Nothing bad with nulls by themself. Absence of value is also a
> value in many scenarios
> >>
> >> On Tue, Sep 10, 2024 at 8:46?PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
> >>>
> >>> The following was received on valhalla-spec-comments.
> >>>
> >>> Point #1 rests on an assumption that the goal of this feature is to
> eliminate, or at least strongly discourage, nulls.  This is a common
> assumption ? many people are so-called ?null haters? ? but encouraging or
> rewarding such biases is not the role of the langauge.  Nulls are not
> intrinsically bad; the problem with nulls is that they are so often
> unexpected, and so people code as if they would never happen.  Reflecting
> nullity in the type system allows you to reason about when they are
> expected, and make reasoned choices about where nulls are appropriate or
> not.
> >>>
> >>> You state your position pretty explicitly here:
> >>>
> >>> >> The syntax to use null must be "disgusting enough" in order to
> >>> >> discourage people from using it.
> >>>
> >>> I?m not going to criticize your opinions about nulls, but it is also
> OK to have different opinions about nulls, and it?s not the role of the
> language to insist that one or the other is the only valid set of feelings
> about it.
> >>>
> >>> Your second point is what we call ?inventing a new null?; it is a
> tempting answer, but is overwhelmingly likely to just make the problem
> worse, because now there are two ill-behaved states.
> >>>
> >>>
> >>> > On Sep 10, 2024, at 10:46 AM, Enrique <
> enrique.arizonbenito at gmail.com> wrote:
> >>> >
> >>> > REF: https://openjdk.org/jeps/8303099
> >>> >
> >>> > Feedback 1:
> >>> >
> >>> > Using the syntax "Foo?" for nullables values does not discourage the
> >>> > use of nulls in code.
> >>> >
> >>> > In my experience working with Kotlin, novice (and not so novice)
> >>> > developers just find themselves comfortable enough adding an extra
> >>> > character and continue to infest code with nulls.
> >>> >
> >>> > The syntax to use null must be "disgusting enough" in order to
> >>> > discourage people from using it.
> >>> >
> >>> > For example something like Foo!!!NullBackwardCompliant!!!. This
> syntax
> >>> > is ugly enough to scare people about using it.
> >>> >
> >>> >
> >>> > Feedback 2:
> >>> > Most people naively tends to use null in next scenarios:
> >>> >
> >>> > * A class/record must be initialized, but due to the data flow, some
> >>> > of its members are not yet known in "present time". They depend on
> >>> > future input data/processing.
> >>> > * Some member must not take any value in a given context.
> >>> >
> >>> > Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
> >>> > Apply) values in parallel to null. Any read must throw a
> >>> > FuturePointerException or NAPointerException.
> >>> > While the behaviour looks similar to the current null and
> >>> > NullPointerException, it makes error debugging much easier to
> >>> > understand:
> >>> > * A FuturePointerException promptly warns about some race condition:
> >>> > Some code tried to read a value before some process (maybe another
> >>> > thread) initialized it.
> >>> > * A NAPointerException promptly warns about some error in the
> business
> >>> > logic. Some code didn't contemplate the NA scenario.
> >>> >
> >>> > "catch" blocks will also be able to make much more sensible decisions
> >>> > (when compared to the pervert NullPointerException).
> >>> >
> >>> > Without any JVM extension, a compiler most probably can automate a
> >>> > similar behavior with a syntax similar to:
> >>> >
> >>> > var Foo1 = Future
> >>> > var Foo2 = NA
> >>> >
> >>> > Foo1 and Foo2 are **NOT** nullables.
> >>> >
> >>> >  Foo2 becomes a constant (It will never change once defined and the
> >>> > compiler can make many verifications out of the box).
> >>> >
> >>> >  Foo1 must never be read until a given value is provided (after which
> >>> > it will probably become constant).
> >>> >
> >>> >
> >>> > My two cents!
> >>> >
> >>> > Enrique Ariz?n Benito
> >>> > Software Gardener
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240912/df0d10e4/attachment-0001.htm>

From vromero at openjdk.org  Thu Sep 12 19:14:52 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Sep 2024 19:14:52 GMT
Subject: Integrated: 8340027: [lw5] the ACC_STRICT flag is not being set for
 non-nullable static fields
Message-ID: <ASNee3x5VaEzqnTW5FsKev5dUKz09qMPf-FkqdVlyM8=.28a55615-3984-4f1c-9dca-7b2df879f287@github.com>

the ACC_STRICT flag is not being added to static fields

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

Commit messages:
 - 8340027: [lw5] the ACC_STRICT flag is not being set for non-nullable static fields

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

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

From vromero at openjdk.org  Thu Sep 12 19:14:52 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Sep 2024 19:14:52 GMT
Subject: Integrated: 8340027: [lw5] the ACC_STRICT flag is not being set for
 non-nullable static fields
In-Reply-To: <ASNee3x5VaEzqnTW5FsKev5dUKz09qMPf-FkqdVlyM8=.28a55615-3984-4f1c-9dca-7b2df879f287@github.com>
References: <ASNee3x5VaEzqnTW5FsKev5dUKz09qMPf-FkqdVlyM8=.28a55615-3984-4f1c-9dca-7b2df879f287@github.com>
Message-ID: <IDc0MrqdDz7U-gwJvzZas8hF5ueoMPvU-W9TDjaFUKs=.643dacc9-6534-4e2b-8aa6-ffc87168cd77@github.com>

On Thu, 12 Sep 2024 19:08:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> the ACC_STRICT flag is not being added to static fields

This pull request has now been integrated.

Changeset: 9ec94191
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9ec94191269e0528132eb00ccc35e033a2458925
Stats:     49 lines in 2 files changed: 45 ins; 1 del; 3 mod

8340027: [lw5] the ACC_STRICT flag is not being set for non-nullable static fields

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

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

From amenkov at openjdk.org  Thu Sep 12 21:00:22 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 12 Sep 2024 21:00:22 GMT
Subject: [lworld] Integrated: 8328461: [lworld] Reimplement FieldAccessModify
 test for JEP401
In-Reply-To: <sIGGlgBpuAPFTQo7EcZN5cI3aSRSF2iYcWu5FqGPLzY=.dcda1904-051d-4b63-a3eb-bc66532ea7f6@github.com>
References: <sIGGlgBpuAPFTQo7EcZN5cI3aSRSF2iYcWu5FqGPLzY=.dcda1904-051d-4b63-a3eb-bc66532ea7f6@github.com>
Message-ID: <fymicdfcAYOLFO58ttYlLFRJIwPHZaH-4U0R8-QxT-o=.186cae6b-109c-4f30-b828-a24320109796@github.com>

On Wed, 11 Sep 2024 23:40:59 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> - updated the test for field access/modify (use value classes);
> - enabled testing of FieldModify events (the functionality was fixed);
> - renamed "Valhalla" to "valhalla" for consistency with other tests.

This pull request has now been integrated.

Changeset: 3d33e0dc
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3d33e0dcbc933827272afd2d41baa1ec9e81b109
Stats:     445 lines in 5 files changed: 219 ins; 225 del; 1 mod

8328461: [lworld] Reimplement FieldAccessModify test for JEP401

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

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

From jbhateja at openjdk.org  Fri Sep 13 05:59:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 05:59:20 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <Qdtv0p_SW0Eapc14-tEX-g0sfwRuvLKfCmv89nv4QIk=.937c55b0-e24a-478e-96e7-83b77efce203@github.com>

On Wed, 11 Sep 2024 08:37:38 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

> Hi @jatin-bhateja , I have implemented these intrinsics in floating point in this patch. I also have another version where I tried implementing isInfinite in integer arithmetic for aarch64. I have created a draft PR here - [e095b2d](https://github.com/openjdk/valhalla/commit/e095b2d47a4c28bece8fc0fcbc656da713feb132)
> 
> I avoided generating the ReinterpretS2HF nodes in the mid-end which will make the "src" to be in a GPR and made the implementation in integer arithmetic easier and resulted in significant gains which can be seen in the commit message of the draft PR.
> 
> I have also tried implementing similar integer logic on x86 (in the draft PR) and I could see ~2.6x better performance than the case without the intrinsic (I have however not tried to implement the vpclass instruction for FP16 and compare performance).
> 
> Keeping the RenterpretS2HF nodes would mean that we need to move the `src` from an FPR to a GPR in the backend, before executing the integer operations which proved to be costly and not very beneficial.
> 
> What do you think of not using ReinterpretS2HF node for these intrinsics and keeping the `src` in a GPR instead? I know that technically FP16 is floating point (even if storage is `short`) and we have always implemented the `src` in an FPR so as to generate FP instructions but I was wondering if this tweak is ok if we see good performance gains? Looking forward to hearing your feedback. Thanks!

Hi @Bhavana-Kilambi , Thanks for the patch, I will add the corresponding x86 backend implimentation.

On your prototype, c2 instruction selector is very flexible in folding bigger graph pallets,  we can skip over creating a specialized IR for graph fragment and directly create a matcher rule covering a bigger pattern and emit optimized instruction sequence for it. 

So what you have in this patch looks good to me.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2348088194

From jbhateja at openjdk.org  Fri Sep 13 07:13:18 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 07:13:18 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
Message-ID: <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>

On Thu, 12 Sep 2024 08:12:18 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Hi @jatin-bhateja , I have implemented these intrinsics in floating point in this patch. I also have another version where I tried implementing isInfinite in integer arithmetic for aarch64. I have created a draft PR here - https://github.com/openjdk/valhalla/pull/1242/commits/e095b2d47a4c28bece8fc0fcbc656da713feb132
> 
> I avoided generating the ReinterpretS2HF nodes in the mid-end which will make the "src" to be in a GPR and made the implementation in integer arithmetic easier and resulted in significant gains which can be seen in the commit message of the draft PR.
> 
> I have also tried implementing similar integer logic on x86 (in the draft PR) and I could see ~2.6x better performance than the case without the intrinsic (I have however not tried to implement the vpclass instruction for FP16 and compare performance).
> 
> Keeping the RenterpretS2HF nodes would mean that we need to move the `src` from an FPR to a GPR in the backend, before executing the integer operations which proved to be costly and not very beneficial.
> 
> What do you think of not using ReinterpretS2HF node for these intrinsics and keeping the `src` in a GPR instead? I know that technically FP16 is floating point (even if storage is `short`) and we have always implemented the `src` in an FPR so as to generate FP instructions but I was wondering if this tweak is ok if we see good performance gains? Looking forward to hearing your feedback. Thanks!

Hi @Bhavana-Kilambi , 
Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? 
e.g.  isNaNTest :=  (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2348195361

From jbhateja at openjdk.org  Fri Sep 13 07:13:18 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 07:13:18 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <88PcBsjjKMT79nHCIoSi9Ww3sTOetKwgLifmeITVHbw=.7f083ee9-f493-4e9a-b89b-6bdef4c29d27@github.com>

On Wed, 11 Sep 2024 08:37:38 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

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

> 450:      * @see Double#isNaN(double)
> 451:      */
> 452:     @IntrinsicCandidate

Please remove existing comments.
https://github.com/openjdk/valhalla/blob/4504163905925648f3c411754ff186b55e6067ee/src/java.base/share/classes/java/lang/Float16.java#L489

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1239#discussion_r1758258473

From jbhateja at openjdk.org  Fri Sep 13 17:25:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 13 Sep 2024 17:25:20 GMT
Subject: [lworld+fp16] Integrated: 8340013: x86 backend support for Float16
 unary and ternary operations
In-Reply-To: <xu_bshOjYpgMNuNHP3N6vdcgbRLWh-vkIEBpJJ-4c3M=.0b48a909-681d-4426-83c3-1515bc1303cb@github.com>
References: <xu_bshOjYpgMNuNHP3N6vdcgbRLWh-vkIEBpJJ-4c3M=.0b48a909-681d-4426-83c3-1515bc1303cb@github.com>
Message-ID: <JflH3_vHrki-_Lw5GPT7qxyGf9WorXfljHqwS9t-UlA=.06a395bc-e9e3-437e-b915-f05540958385@github.com>

On Thu, 12 Sep 2024 14:22:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary of changes:-
> - Add optimized x86 backend implementation for scalar and vector flavors of following Float16 APIs.
>   - FMA, SQRT, NEG, ABS
> - Add memory operand patterns for all existing Float16 vector operations.
> 
> All existing Float16 functional and IR based tests are passing with the patch.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: baea588d
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/baea588d190960a6386f51492c93d12e874b615e
Stats:     374 lines in 7 files changed: 355 ins; 9 del; 10 mod

8340013: x86 backend support for Float16 unary and ternary operations

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

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

From enrique.arizonbenito at gmail.com  Fri Sep 13 17:59:02 2024
From: enrique.arizonbenito at gmail.com (Enrique)
Date: Fri, 13 Sep 2024 19:59:02 +0200
Subject: Feedback on Null-Restricted and Nullable Types
In-Reply-To: <CAL5bRt_r3gPzgAxbOBeeHy7TFO2WkENfdhxgQBHavQOo4ONg+A@mail.gmail.com>
References: <CAD-msxHe0b1EHtSqwa+cXg4KAfS9QDnz5qs9UHkevf67QZEzHw@mail.gmail.com>
 <13A3A654-BC7A-4470-8D41-DD3D1980E42E@oracle.com>
 <CAL5bRt_xn2QvLnmcU=goaC747KiM44TAE3CxdyxykodsFr0q-A@mail.gmail.com>
 <A1FE8C11-06CD-475F-AE9E-EB318B6E74B2@oracle.com>
 <80016337.1516245.1726041806985.JavaMail.zimbra@univ-eiffel.fr>
 <CAL5bRt9RJRf6N7RuTjE=O2CsKOzpnSM6Xd3y=B6rZa1Mm2A=OQ@mail.gmail.com>
 <CAD-msxEvOqEG2DW3KaCc40ioyqkZCRdXP2BegPEJL5yHU1+Z=Q@mail.gmail.com>
 <CAL5bRt_r3gPzgAxbOBeeHy7TFO2WkENfdhxgQBHavQOo4ONg+A@mail.gmail.com>
Message-ID: <CAD-msxGLWdggD2sY+XUEj58cJGJjbTcr8y6gosLjWgfJ9b3PZA@mail.gmail.com>

I was thinking about a function with a signature similar to:

safeString getFromNewFunctionWhoJustDoesntKnowThatNullNeverExisted(... )

There is no need to add the final exclamation when using it since it
just returns safe data or throws ("surrenders") if it can not.

My experience with the "val/var" syntax in Kotlin is that it works for
people that are curious/meticulous and invest some time about thinking
on immutable code, but many people in the programming world are not
curious/meticulous or just do not invest time in important things
because they ignore such important thing (The risk of the "unknown
unknowns" is always present, specially for newcomers).  They will end
up typing val/var and initializing to null at random.

 But, without investing any time or being curious/meticulous, if a
developer observes the "safe" word around, he/she will try to follow
the pattern because nobody wants to be "unsafe". If working in teams,
everybody will be very uncomfortable working with other people not
using "safe" code, putting "pressure" on the whole team (a false
"pressure" because they will be much more productive even in the
short/long term). From my point of view, this has more to do with
psychology or pedagogy than programming theory (humans fail much more
often than compilers).

Enrique


On Thu, Sep 12, 2024 at 6:40?PM Olexandr Rotan
<rotanolexandr842 at gmail.com> wrote:
>
> Just an immediate thought about reading your mail. What is the difference between the mutable safeval neverNullVar = getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes() syntax and var  neverNullVar = getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes()! (exclam on the end), which is really common in null-safe languages. I would argue that if exclam syntax would be fail-fast, later is even more plausible, especially considering the cost of adding new keywords to language, even weak ones. Undefined nullability decorated with ! would just become non-nullable.
>
> The Future syntax somehow for me seems like a readonly (final in java) for local variables. That would be nice to have, but If we go down to the level of local variables, I would say that just a simple val keyword from kotlin would be a much greater contribution to local variables immutability.
>
> On Thu, Sep 12, 2024 at 7:20?PM Enrique <enrique.arizonbenito at gmail.com> wrote:
>>
>> Hi again,
>>
>> just some extra thoughts based on previous comments.
>>
>> Starting from the scratch, the simplest way to get rid of nulls would
>> be to remove it. This is completely possible as Vlang has proved.
>> https://vlang.io/
>> (As a curiosity I also proposed that same solution time ago in the LUA
>> list https://lua-users.org/lists/lua-l/2015-01/msg00222.html,
>> unfortunately I lack the time to implement it.)
>>
>> Then the real problem is to keep compatibility with "the billion
>> dollar mistake". A "simple" way to do so would be:
>>
>> Duplicate the syntax for declaration of variables.
>>
>> We can use the current syntax with no change:
>>
>> var maybeNullVar = getFromOldFunctionReturningNullsAtWill();
>> String maybeNull  = getFromAnotherOldFunctionReturningNullsAtWill();
>>
>> then the new syntax is added:
>>
>> mutable safeval neverNullVar =
>> getFromNewFunctionWhoJustDoesntKnowThatNullNeverExistes(); // ?
>> safeString doesntApplyInContext = NA; // throw NAPointerException when
>> trying to read or update it. safeString is final by default.
>> safeString email = FUTURE; // throw FUTUREPointerException when trying
>> to read it, we can still update it "just once", then becomes
>> immutable.
>> mutable safeString stringState = FUTURE; throw FUTUREPointerException
>> when trying to read it, we can still update as many times as we want.
>>
>> ? Since we want to make things safe, let's just default to immutable
>> variables, and mark mutable explicitly.
>>
>> To convert from unsafe to safe, a function will be needed:
>>
>> final safeLong safeLong =
>> safetyFunctionTakingNonSafeAsInputAndReturningSafeAsOutput();
>>
>> The "safe" prefix is a "30 seconds of thought", just to let it clear
>> to novices that the opposite is not safe and discouraged.
>>
>> QA managers will have no trouble detecting code using unsafe vars. No
>> need for special tooling, just "grepping" the code.
>>
>> Some future JDK "N" version can start warning about unsafe variables,
>> then N+20 version will force the use of a flag (or environment
>> variable) to compile unsafe code, finally N+100 will remove unsafe
>> vars from the language and JVM (I guess this will also boost the JIT
>> performance).
>>
>> PS: I didn't know about the "null haters" term. I find it funny, and
>> definitely and considering that the null makes all of us waste time
>> and money, I invite everybody to join the "null haters" religion.
>> We can organize illegal parties and destroy null pointers to
>> celebrate, then escape before the police arrive.
>>
>> Regards,
>>
>> Enrique Ariz?n Benito
>> Software Gardener
>>
>>
>> On Thu, Sep 12, 2024 at 12:32?PM Olexandr Rotan
>> <rotanolexandr842 at gmail.com> wrote:
>> >
>> > I have given a lot of thought to this topic since my last mail here. Ultimately, what I have concluded on is that even if we try to somehow infer nullability, the limits of this inference are drawn on the bounds of the system and non-final fields. Nullability, though, can be inferred for local variables, and IDEs already are doing a pretty good job in this area, so I am not sure if this is a job of jdk to reinvent this analysis once again.
>> >
>> > So, the best idea that crossed my mind so far is to, instead of forbidding compilation by making non-null default, just be as annoying as possible *for unspecified nullability* (I emphasize that, as I see, problem is unspecified nullability rather then specified with '?'), by introducing some warning for any unspecified nullability type, at least at the bounds of type (i.e. public and arguably package-private members and their declaration members), but, if i were to decide, for all members of type. Local variables could have a bit more loose requirements imo, however, including them into inspection could encourage people to use var keywords if that was the point for any reason.
>> >
>> > I think that this annoyance is acceptable, because, as I see it, ? notation is essentially union of type and null, while ! is an explicit statement that this type does not contain null. Hence, warnings about unspecified nullability is just a warning that you don't give compiler enough information to validate your code, in some way like unchecked cast and raw types warnings currently. This kind of soft but steady power could potentially end us up in a situation when, eventually, there is little to none code without nullability notation.
>> >
>> > Also, as an option, a tool for nullability inference could be included in jdk as a separate tool instead of part of the compiler. This could smoothen the steep path developers would have to take o migrate to new java versions, by sparing them from work to manually add nullability info to each local variable
>> >
>> > On Wed, Sep 11, 2024 at 11:03?AM Remi Forax <forax at univ-mlv.fr> wrote:
>> >>
>> >>
>> >>
>> >> ________________________________
>> >>
>> >> From: "Brian Goetz" <brian.goetz at oracle.com>
>> >> To: "Olexandr Rotan" <rotanolexandr842 at gmail.com>
>> >> Cc: "Enrique" <enrique.arizonbenito at gmail.com>, "valhalla-dev" <valhalla-dev at openjdk.org>
>> >> Sent: Wednesday, September 11, 2024 2:27:53 AM
>> >> Subject: Re: Feedback on Null-Restricted and Nullable Types
>> >>
>> >>
>> >>
>> >> On Sep 10, 2024, at 5:43 PM, Olexandr Rotan <rotanolexandr842 at gmail.com> wrote:
>> >>
>> >> I would argue that not the syntax around nulls should be hideous, but rather non-null should somehow be the default option
>> >>
>> >>
>> >> We?re going to get this suggestion a lot.  It is pretty clear that ?non-null? is a better default interpretation of an otherwise unannotated type name than ?nullable? is; this results in a lower annotation burden for annotating old code, less visual noise for reading fully annotated code, a safer default, etc.  And if we were designing a language from scratch, it would be pretty hard to argue against this.
>> >>
>> >> But as you acknowledge, there are billions of lines of Java code out there, and retroactively changing their meaning is a non-starter.  People will surely suggest things like ?what about a compiler flag? (please don?t), but that?s just forking the language and pretending we aren?t.  And all the ?obvious? suggestions have one or both of these characteristics.
>> >>
>> >> So, we truly understand how this would be yet another ?Java got the defaults wrong?.  And maybe there is a path ? in the not-so-immediate-future ? to opting into stricter null checking in a way that does not feel like a fork. And we?re going to think about that, and if we find something that seems acceptable, we?ll consider it.  But as James says, if you don?t know the right thing to do, then the right thing to do right now is to do nothing.  So we will not be tackling the ?wrong default? problem at the same time as we are addressing null restriction.  (Besides, there?s enough impossible problems in Valhalla that we don?t need to add another one onto our plate.)
>> >>
>> >>
>> >> I see non-null by default as a side effect and not as a goal.
>> >> The goal is to simplify the model we expose to users.
>> >> It's clear that the underlying model is a 3 states model (let's pretend there is no type variable for a moment), so String, String? and String!.
>> >> The main advantage of saying it's non-null by default is that it simplify the user model to a 2 states model, either String or String? so the user model is easier to understand.
>> >> Obviously, once the code interacts with methods from the old world, the raw Strings are still there lurking but having a local 2 states model is i believe still a win.
>> >>
>> >> So the feature is providing a local 2 states user model and the nice side effect of that is having non-null by default.
>> >>
>> >> There are drawbacks to the local 2 states user model, on top of my head, how to opt-in ? Is making type variables a special case a good idea ?, should the bounds of a type variable be non-null too ? Is having no way to represent raw nullability not a problem when trying to guide inference ? And i'm sure many more.
>> >>
>> >> R?mi
>> >>
>> >>
>> >> , so people will not bother adding anything on top of that unless explicitly needed. I'm not really sure if it's achievable with preserving source backward compatibility though, given that currently, default is unspecified nullability. I think that many people will bother adding ! as much as ?, honestly. Most of the production code I have worked with didnt even care about returning an unmodifiable view of collection instead of the real one or wrapping nullable value in optional in getters and hiding no-args constructors in POJO using protected keyword. Honestly, the sad truth (in my experience) is the fact that if something is not done by default, it will not be done manually in the vast majority of cases, no matter how potentially beneficial it is. I would say that best option would be to introduce compiler flag that enables non-null by default, and eventually, after most users are migrated, make it true by default.
>> >>
>> >> Regarding new null in language. I (unfortunately) spend at least half of my working with typescript. To say that this null-undefined fuss is terrible is to keep silent. That's just a complete mess. Question mark in type stands only for type | undefined, want to accept null - go and do var?: type | null - just terrible. Question mark notation in field access chains is also so strange: it, contrary to ? in type, accepts both null and undefined, and it often leads to confusing situations when you expect one of those two, but get another, logic in ?? still executes, and your erroneous state passes down through long chain of invocation until it finally fails somewhere and good luck debugging it/ Two different nulls is just a horrible idea in so many ways.
>> >>
>> >> PS: Nothing bad with nulls by themself. Absence of value is also a value in many scenarios
>> >>
>> >> On Tue, Sep 10, 2024 at 8:46?PM Brian Goetz <brian.goetz at oracle.com> wrote:
>> >>>
>> >>> The following was received on valhalla-spec-comments.
>> >>>
>> >>> Point #1 rests on an assumption that the goal of this feature is to eliminate, or at least strongly discourage, nulls.  This is a common assumption ? many people are so-called ?null haters? ? but encouraging or rewarding such biases is not the role of the langauge.  Nulls are not intrinsically bad; the problem with nulls is that they are so often unexpected, and so people code as if they would never happen.  Reflecting nullity in the type system allows you to reason about when they are expected, and make reasoned choices about where nulls are appropriate or not.
>> >>>
>> >>> You state your position pretty explicitly here:
>> >>>
>> >>> >> The syntax to use null must be "disgusting enough" in order to
>> >>> >> discourage people from using it.
>> >>>
>> >>> I?m not going to criticize your opinions about nulls, but it is also OK to have different opinions about nulls, and it?s not the role of the language to insist that one or the other is the only valid set of feelings about it.
>> >>>
>> >>> Your second point is what we call ?inventing a new null?; it is a tempting answer, but is overwhelmingly likely to just make the problem worse, because now there are two ill-behaved states.
>> >>>
>> >>>
>> >>> > On Sep 10, 2024, at 10:46 AM, Enrique <enrique.arizonbenito at gmail.com> wrote:
>> >>> >
>> >>> > REF: https://openjdk.org/jeps/8303099
>> >>> >
>> >>> > Feedback 1:
>> >>> >
>> >>> > Using the syntax "Foo?" for nullables values does not discourage the
>> >>> > use of nulls in code.
>> >>> >
>> >>> > In my experience working with Kotlin, novice (and not so novice)
>> >>> > developers just find themselves comfortable enough adding an extra
>> >>> > character and continue to infest code with nulls.
>> >>> >
>> >>> > The syntax to use null must be "disgusting enough" in order to
>> >>> > discourage people from using it.
>> >>> >
>> >>> > For example something like Foo!!!NullBackwardCompliant!!!. This syntax
>> >>> > is ugly enough to scare people about using it.
>> >>> >
>> >>> >
>> >>> > Feedback 2:
>> >>> > Most people naively tends to use null in next scenarios:
>> >>> >
>> >>> > * A class/record must be initialized, but due to the data flow, some
>> >>> > of its members are not yet known in "present time". They depend on
>> >>> > future input data/processing.
>> >>> > * Some member must not take any value in a given context.
>> >>> >
>> >>> > Ideally the JVM would be extended to support "FUTURE" and "NA" (Not
>> >>> > Apply) values in parallel to null. Any read must throw a
>> >>> > FuturePointerException or NAPointerException.
>> >>> > While the behaviour looks similar to the current null and
>> >>> > NullPointerException, it makes error debugging much easier to
>> >>> > understand:
>> >>> > * A FuturePointerException promptly warns about some race condition:
>> >>> > Some code tried to read a value before some process (maybe another
>> >>> > thread) initialized it.
>> >>> > * A NAPointerException promptly warns about some error in the business
>> >>> > logic. Some code didn't contemplate the NA scenario.
>> >>> >
>> >>> > "catch" blocks will also be able to make much more sensible decisions
>> >>> > (when compared to the pervert NullPointerException).
>> >>> >
>> >>> > Without any JVM extension, a compiler most probably can automate a
>> >>> > similar behavior with a syntax similar to:
>> >>> >
>> >>> > var Foo1 = Future
>> >>> > var Foo2 = NA
>> >>> >
>> >>> > Foo1 and Foo2 are **NOT** nullables.
>> >>> >
>> >>> >  Foo2 becomes a constant (It will never change once defined and the
>> >>> > compiler can make many verifications out of the box).
>> >>> >
>> >>> >  Foo1 must never be read until a given value is provided (after which
>> >>> > it will probably become constant).
>> >>> >
>> >>> >
>> >>> > My two cents!
>> >>> >
>> >>> > Enrique Ariz?n Benito
>> >>> > Software Gardener
>> >>>
>> >>
>> >>

From chagedorn at openjdk.org  Mon Sep 16 10:59:27 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 16 Sep 2024 10:59:27 GMT
Subject: [lworld] Integrated: 8340190: [lworld] Fix test group after
 JDK-8328461
Message-ID: <ID2ES0E3YZTpjpGaobU2i7R8h8Q-k8lXfcYC67Rxw8E=.f5b4b231-3866-413b-a8c9-c6a63851e238@github.com>

[JDK-8328461](https://bugs.openjdk.org/browse/JDK-8328461) renamed the folder `serviceability/jvmti/Valhalla` -> `serviceability/jvmti/valhalla` and forgot to update the corresponding jtreg test group. This lets various tasks fail in our CI.

Thanks,
Christian

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

Commit messages:
 - 8340190: [lworld] Fix test group after JDK-8328461

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

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

From chagedorn at openjdk.org  Mon Sep 16 10:59:27 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 16 Sep 2024 10:59:27 GMT
Subject: [lworld] Integrated: 8340190: [lworld] Fix test group after
 JDK-8328461
In-Reply-To: <ID2ES0E3YZTpjpGaobU2i7R8h8Q-k8lXfcYC67Rxw8E=.f5b4b231-3866-413b-a8c9-c6a63851e238@github.com>
References: <ID2ES0E3YZTpjpGaobU2i7R8h8Q-k8lXfcYC67Rxw8E=.f5b4b231-3866-413b-a8c9-c6a63851e238@github.com>
Message-ID: <iYpvsbx0LIj8O00qUgFiobZ-za2uNRwHxjM-OAv4-ro=.85ded3b4-abb8-48a7-b9c9-2fd66810ea21@github.com>

On Mon, 16 Sep 2024 10:55:02 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8328461](https://bugs.openjdk.org/browse/JDK-8328461) renamed the folder `serviceability/jvmti/Valhalla` -> `serviceability/jvmti/valhalla` and forgot to update the corresponding jtreg test group. This lets various tasks fail in our CI.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 570da752
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/570da75281b138ac29b6f32b8d84661f839a17a8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8340190: [lworld] Fix test group after JDK-8328461

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

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

From bkilambi at openjdk.org  Mon Sep 16 11:45:24 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 16 Sep 2024 11:45:24 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
Message-ID: <9tD3R5twBGQzJH4DJck9cT5zlXP8TWtaTvIkdWyKWcw=.d6d77131-1515-492c-9ea6-b918c30474a8@github.com>

On Thu, 12 Sep 2024 08:12:18 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Hi @jatin-bhateja , I have implemented these intrinsics in floating point in this patch. I also have another version where I tried implementing isInfinite in integer arithmetic for aarch64. I have created a draft PR here - https://github.com/openjdk/valhalla/pull/1242/commits/e095b2d47a4c28bece8fc0fcbc656da713feb132
> 
> I avoided generating the ReinterpretS2HF nodes in the mid-end which will make the "src" to be in a GPR and made the implementation in integer arithmetic easier and resulted in significant gains which can be seen in the commit message of the draft PR.
> 
> I have also tried implementing similar integer logic on x86 (in the draft PR) and I could see ~2.6x better performance than the case without the intrinsic (I have however not tried to implement the vpclass instruction for FP16 and compare performance).
> 
> Keeping the RenterpretS2HF nodes would mean that we need to move the `src` from an FPR to a GPR in the backend, before executing the integer operations which proved to be costly and not very beneficial.
> 
> What do you think of not using ReinterpretS2HF node for these intrinsics and keeping the `src` in a GPR instead? I know that technically FP16 is floating point (even if storage is `short`) and we have always implemented the `src` in an FPR so as to generate FP instructions but I was wondering if this tweak is ok if we see good performance gains? Looking forward to hearing your feedback. Thanks!

> Hi @Bhavana-Kilambi , Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? e.g. isNaNTest := (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..

Hi @jatin-bhateja , I just tried for isNaN and the Java version is 13% faster than intrinsic (both with FP16 instructions and integer arithmetic). Do you think it's better to default to the java version instead of using intrinsics? I havent' tried for isFinite and isInfinite.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2352683852

From dsimms at openjdk.org  Mon Sep 16 11:55:49 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 16 Sep 2024 11:55:49 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <Epx75EKGYiQW7LFGJ8WgxEeZ7_KclUp1Eoh0OB014Rg=.1b11638e-2823-4d48-af08-883be15de9dd@github.com>

Merge jdk-23+19

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

Commit messages:
 - Adjust makefile copying for JDK-8326947
 - Adjust code to new Node::emit() decl
 - Merge tag 'jdk-23+19' into lworld_merge_jdk_23_19
 - 8330467: NoClassDefFoundError when lambda is in a hidden class
 - 8311098: Change comment in verificationType.hpp to refer to _sym
 - 8317376: Minor improvements to the 'this' escape analyzer
 - 8319516: AIX System::loadLibrary needs support to load a shared library from an archive object
 - 8325469: Freeze/Thaw code can crash in the presence of OSR frames
 - 8325494: C2: Broken graph after not skipping CastII node anymore for Assertion Predicates after JDK-8309902
 - 8329595: spurious  variable "might not have been initialized" on static final field
 - ... and 88 more: https://git.openjdk.org/valhalla/compare/f4f1ec68...04bd7ec1

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

Changes: https://git.openjdk.org/valhalla/pull/1246/files
  Stats: 26309 lines in 528 files changed: 11117 ins; 12081 del; 3111 mod
  Patch: https://git.openjdk.org/valhalla/pull/1246.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1246/head:pull/1246

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

From bkilambi at openjdk.org  Mon Sep 16 12:30:51 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 16 Sep 2024 12:30:51 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v2]
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <W2hd2IEKPEWGmJ8CMwBc0dn_C69Ca-PKINwUQQM7vpM=.1e25d6b9-4cab-4b56-bbb5-004d627d0531@github.com>

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

Bhavana Kilambi 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:

 - Address review comments
 - Merge branch 'lworld+fp16'
 - 8339473: Add support for FP16 isFinite, isInfinite and isNaN
   
   This patch adds intrinsic support for FP16 isNaN, isFinite and
   isInfinite methods and also adds aarch64 backend for these intrinsics.
   
   Tested all FP16 related tests successfully on aarch64.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1239/files
  - new: https://git.openjdk.org/valhalla/pull/1239/files/1d1dfb33..2f8e22ce

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

  Stats: 883 lines in 12 files changed: 836 ins; 22 del; 25 mod
  Patch: https://git.openjdk.org/valhalla/pull/1239.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1239/head:pull/1239

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

From dsimms at openjdk.org  Tue Sep 17 05:57:25 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 17 Sep 2024 05:57:25 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <Epx75EKGYiQW7LFGJ8WgxEeZ7_KclUp1Eoh0OB014Rg=.1b11638e-2823-4d48-af08-883be15de9dd@github.com>
References: <Epx75EKGYiQW7LFGJ8WgxEeZ7_KclUp1Eoh0OB014Rg=.1b11638e-2823-4d48-af08-883be15de9dd@github.com>
Message-ID: <NqgynfKj3uqlM7oULTbwl2YKcw1mHu3WXqgf0cIuse8=.ab7e87aa-f7c7-4333-872f-0a66208efb76@github.com>

On Mon, 16 Sep 2024 11:51:13 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+19

This pull request has now been integrated.

Changeset: 207ed66f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/207ed66f8fba7051a0d056f0a6ff65eed9d75416
Stats:     26309 lines in 528 files changed: 11117 ins; 12081 del; 3111 mod

Merge jdk

Merge jdk-23+19

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

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

From bkilambi at openjdk.org  Tue Sep 17 09:56:15 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 17 Sep 2024 09:56:15 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
 <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
Message-ID: <VWfUQxGK_itW5iMcgo1gQ0N_w_sEC_WJ7v1mg7Q3SGc=.0259b00f-79b3-4ccb-9b43-d0bbd6cdf17d@github.com>

On Fri, 13 Sep 2024 07:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @jatin-bhateja , I have implemented these intrinsics in floating point in this patch. I also have another version where I tried implementing isInfinite in integer arithmetic for aarch64. I have created a draft PR here - https://github.com/openjdk/valhalla/pull/1242/commits/e095b2d47a4c28bece8fc0fcbc656da713feb132
>> 
>> I avoided generating the ReinterpretS2HF nodes in the mid-end which will make the "src" to be in a GPR and made the implementation in integer arithmetic easier and resulted in significant gains which can be seen in the commit message of the draft PR.
>> 
>> I have also tried implementing similar integer logic on x86 (in the draft PR) and I could see ~2.6x better performance than the case without the intrinsic (I have however not tried to implement the vpclass instruction for FP16 and compare performance).
>> 
>> Keeping the RenterpretS2HF nodes would mean that we need to move the `src` from an FPR to a GPR in the backend, before executing the integer operations which proved to be costly and not very beneficial.
>> 
>> What do you think of not using ReinterpretS2HF node for these intrinsics and keeping the `src` in a GPR instead? I know that technically FP16 is floating point (even if storage is `short`) and we have always implemented the `src` in an FPR so as to generate FP instructions but I was wondering if this tweak is ok if we see good performance gains? Looking forward to hearing your feedback. Thanks!
>
> Hi @Bhavana-Kilambi , 
> Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? 
> e.g.  isNaNTest :=  (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..

Hi @jatin-bhateja , just tested the other two intrinsics as well. I do get huge performance gains (on aarch64) with the java versions. I used these - 


@IntrinsicCandidate
    public static boolean isNaN(Float16 f16) {
        return ((float16ToRawShortBits(f16) & 0x7e00) == 0x7e00);
    }



@IntrinsicCandidate
    public static boolean isInfinite(Float16 f16) {
        return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & 0x7fff) == 0;
    }



@IntrinsicCandidate
    public static boolean isFinite(Float16 f16) {
        return !(isInfinite(f16) || isNaN(f16));
     }


I see these gains compared to the intrinsic version uploaded in the latest patch on this PR - 

Benchmark               (SIZE)    Gain
FP16Ops.isFiniteHF      65504     1.18409353876134
FP16Ops.isInfiniteHF    65504     1.57611028955779
FP16Ops.isNaNHF         65504     1.48276431718062



Do you think it's better to not have any intrinsics at all for these operations?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2355104899

From jbhateja at openjdk.org  Tue Sep 17 12:14:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Sep 2024 12:14:33 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
 <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
Message-ID: <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>

On Fri, 13 Sep 2024 07:09:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @jatin-bhateja , I have implemented these intrinsics in floating point in this patch. I also have another version where I tried implementing isInfinite in integer arithmetic for aarch64. I have created a draft PR here - https://github.com/openjdk/valhalla/pull/1242/commits/e095b2d47a4c28bece8fc0fcbc656da713feb132
>> 
>> I avoided generating the ReinterpretS2HF nodes in the mid-end which will make the "src" to be in a GPR and made the implementation in integer arithmetic easier and resulted in significant gains which can be seen in the commit message of the draft PR.
>> 
>> I have also tried implementing similar integer logic on x86 (in the draft PR) and I could see ~2.6x better performance than the case without the intrinsic (I have however not tried to implement the vpclass instruction for FP16 and compare performance).
>> 
>> Keeping the RenterpretS2HF nodes would mean that we need to move the `src` from an FPR to a GPR in the backend, before executing the integer operations which proved to be costly and not very beneficial.
>> 
>> What do you think of not using ReinterpretS2HF node for these intrinsics and keeping the `src` in a GPR instead? I know that technically FP16 is floating point (even if storage is `short`) and we have always implemented the `src` in an FPR so as to generate FP instructions but I was wondering if this tweak is ok if we see good performance gains? Looking forward to hearing your feedback. Thanks!
>
> Hi @Bhavana-Kilambi , 
> Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? 
> e.g.  isNaNTest :=  (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..

> Hi @jatin-bhateja , just tested the other two intrinsics as well. I do get huge performance gains (on aarch64) with the java versions. I used these -
> 
> ```
> @IntrinsicCandidate
>     public static boolean isNaN(Float16 f16) {
>         return ((float16ToRawShortBits(f16) & 0x7e00) == 0x7e00);
>     }
> ```
> 
> ```
> @IntrinsicCandidate
>     public static boolean isInfinite(Float16 f16) {
>         return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & 0x7fff) == 0;
>     }
> ```
> 
> ```
> @IntrinsicCandidate
>     public static boolean isFinite(Float16 f16) {
>         return !(isInfinite(f16) || isNaN(f16));
>      }
> ```
> 
> I see these gains compared to the intrinsic version uploaded in the latest patch on this PR -
> 
> ```
> Benchmark               (SIZE)    Gain
> FP16Ops.isFiniteHF      65504     1.18409353876134
> FP16Ops.isInfiniteHF    65504     1.57611028955779
> FP16Ops.isNaNHF         65504     1.48276431718062
> ```
> 
> Do you think it's better to not have any intrinsics at all for these operations?

Thanks @Bhavana-Kilambi , yes it will be optimal, your java versions still carries @IntrinsicCandidate, hope we are not accedently running intrinsics, if that is not the case then making only a java side change should suffice as its also easily auto-vectorizatable

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2355541564

From bkilambi at openjdk.org  Tue Sep 17 12:14:33 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 17 Sep 2024 12:14:33 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
 <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
 <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
Message-ID: <iz6qKMUOxBWpGdm3N1LajxJxIy-CjluBEI2zsyJIRXk=.5eeea27d-d91d-46c5-ab2d-8fb5f9f4c1f7@github.com>

On Tue, 17 Sep 2024 12:09:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Hi @jatin-bhateja , just tested the other two intrinsics as well. I do get huge performance gains (on aarch64) with the java versions. I used these -
> > ```
> > @IntrinsicCandidate
> >     public static boolean isNaN(Float16 f16) {
> >         return ((float16ToRawShortBits(f16) & 0x7e00) == 0x7e00);
> >     }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > ```
> > @IntrinsicCandidate
> >     public static boolean isInfinite(Float16 f16) {
> >         return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & 0x7fff) == 0;
> >     }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > ```
> > @IntrinsicCandidate
> >     public static boolean isFinite(Float16 f16) {
> >         return !(isInfinite(f16) || isNaN(f16));
> >      }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I see these gains compared to the intrinsic version uploaded in the latest patch on this PR -
> > ```
> > Benchmark               (SIZE)    Gain
> > FP16Ops.isFiniteHF      65504     1.18409353876134
> > FP16Ops.isInfiniteHF    65504     1.57611028955779
> > FP16Ops.isNaNHF         65504     1.48276431718062
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Do you think it's better to not have any intrinsics at all for these operations?
> 
> Thanks @Bhavana-Kilambi , yes it will be optimal, your java versions still carries @IntrinsicCandidate, hope we are not accedently running intrinsics, if that is not the case then making only a java side change should suffice as its also easily auto-vectorizatable

Thanks, I will make the necessary changes. I ran the tests with the `-XX:DisableIntrinsic` flag to test the java code and not run the intrinsics

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2355548147

From bkilambi at openjdk.org  Wed Sep 18 10:00:36 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 18 Sep 2024 10:00:36 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:

  Change java side implementation instead of adding intrinsics

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1239/files
  - new: https://git.openjdk.org/valhalla/pull/1239/files/2f8e22ce..a116fbe8

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

  Stats: 803 lines in 14 files changed: 0 ins; 188 del; 615 mod
  Patch: https://git.openjdk.org/valhalla/pull/1239.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1239/head:pull/1239

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

From bkilambi at openjdk.org  Wed Sep 18 10:00:36 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 18 Sep 2024 10:00:36 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
 <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
 <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
Message-ID: <dHlmAVHGMKgQl8gY7JCHMpMygGiAhEAJ1t1oPgu9egw=.8a24f55a-7c22-47fd-b9fa-1cb65af0087f@github.com>

On Tue, 17 Sep 2024 12:09:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @Bhavana-Kilambi , 
>> Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? 
>> e.g.  isNaNTest :=  (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..
>
>> Hi @jatin-bhateja , just tested the other two intrinsics as well. I do get huge performance gains (on aarch64) with the java versions. I used these -
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isNaN(Float16 f16) {
>>         return ((float16ToRawShortBits(f16) & 0x7e00) == 0x7e00);
>>     }
>> ```
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isInfinite(Float16 f16) {
>>         return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & 0x7fff) == 0;
>>     }
>> ```
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isFinite(Float16 f16) {
>>         return !(isInfinite(f16) || isNaN(f16));
>>      }
>> ```
>> 
>> I see these gains compared to the intrinsic version uploaded in the latest patch on this PR -
>> 
>> ```
>> Benchmark               (SIZE)    Gain
>> FP16Ops.isFiniteHF      65504     1.18409353876134
>> FP16Ops.isInfiniteHF    65504     1.57611028955779
>> FP16Ops.isNaNHF         65504     1.48276431718062
>> ```
>> 
>> Do you think it's better to not have any intrinsics at all for these operations?
> 
> Thanks @Bhavana-Kilambi , yes it will be optimal, your java versions still carries @IntrinsicCandidate, hope we are not accedently running intrinsics, if that is not the case then making only a java side change should suffice as its also easily auto-vectorizatable

Hi @jatin-bhateja , I have uploaded a new patch with changes in the java implementation instead of using intrinsics for these three operations. I have new performance results with this patch here - 


Benchmark               Gain vs FP16 insns      Gain vs default
FP16Ops.isFiniteHF      1.64                    2.36
FP16Ops.isInfiniteHF    1.56                    2.97
FP16Ops.isNaNHF	        1.49                    1.62


The second column shows the ratio of thrpt between this patch and theprevious one which implements these operations as intrinsics (either in FP16 or integer arithmetic) and the third column is the ratio of thrpt between this patch and the default JDK implementation which requires the result to first be converted to FP32 before computing the result.

Please review. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2358025460

From dsimms at openjdk.org  Wed Sep 18 13:44:21 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 18 Sep 2024 13:44:21 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <mwo9AwEjqWG18Pq_7bJZUn39LxebzrpMaQZ-WGdq4Fo=.4d1e3139-9da5-429e-9b0b-05bda6857646@github.com>

Merge jdk-23+20

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

Commit messages:
 - Fixed JDK-8300148 merge
 - Merge fixes
 - Merge jdk-23+20
 - 8328703: Illegal accesses in Java_jdk_internal_org_jline_terminal_impl_jna_linux_CLibraryImpl_ioctl0
 - 8331097: Tests build is broken after pr/18914
 - 8329797: Shenandoah: Default case invoked for: "MaxL" (bad AD file)
 - 8325373: Improve StackCounter error reporting for bad switch cases
 - 8330815: Use pattern matching for instanceof in KeepAliveCache
 - 8331030: langtools/tools/javac/tree tests fail with SOE with fastdebug and -Xcomp
 - 8322135: Printing JTable in Windows L&F throws InternalError: HTHEME is null
 - ... and 98 more: https://git.openjdk.org/valhalla/compare/207ed66f...dc82be00

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

Changes: https://git.openjdk.org/valhalla/pull/1247/files
  Stats: 37944 lines in 515 files changed: 20506 ins; 15299 del; 2139 mod
  Patch: https://git.openjdk.org/valhalla/pull/1247.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1247/head:pull/1247

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

From dsimms at openjdk.org  Wed Sep 18 18:34:28 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 18 Sep 2024 18:34:28 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <mwo9AwEjqWG18Pq_7bJZUn39LxebzrpMaQZ-WGdq4Fo=.4d1e3139-9da5-429e-9b0b-05bda6857646@github.com>
References: <mwo9AwEjqWG18Pq_7bJZUn39LxebzrpMaQZ-WGdq4Fo=.4d1e3139-9da5-429e-9b0b-05bda6857646@github.com>
Message-ID: <LbhgJBCWamso1Srbf2B0Td3kYX0o8wuYpSLpN4rC9n4=.1cc65dc3-dcfb-408a-8917-8a7fba46d759@github.com>

On Wed, 18 Sep 2024 13:38:25 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+20

This pull request has now been integrated.

Changeset: 318e39a3
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/318e39a3c8f901419337c4718e0b3fc82bbe8df3
Stats:     37944 lines in 515 files changed: 20506 ins; 15299 del; 2139 mod

Merge jdk

Merge jdk-23+20

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

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

From dsimms at openjdk.org  Thu Sep 19 06:58:19 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 19 Sep 2024 06:58:19 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <IZoggc5FgBC5GQs3Nb1ywNLUN1yhiFlO-UQdjumZNl8=.7ae57696-3eef-4990-a931-fddc3395298b@github.com>

Merge tag 'jdk-23+21' into lworld_merge_jdk_23_21
Added tag jdk-23+21 for changeset e833bfc8

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

Commit messages:
 - Merge tag 'jdk-23+21' into lworld_merge_jdk_23_21
 - 8331222: Malformed text in the jpackage doc page
 - 8331427: Rename confusingly named ArraysSupport.signedHashCode
 - 8331212: Error recovery for broken switch expressions could be improved
 - 8331142: Add test for number of loader threads in BasicDirectoryModel
 - 8330969: scalability issue with loaded JVMTI agent
 - 8331393: AArch64: u32 _partial_subtype_ctr loaded/stored as 64
 - 8318682: SA decoding of scalar replaced objects is broken
 - 8331207: Misleading example in DateFormat#parse docs
 - 8329223: Parallel: Parallel GC resizes heap even if -Xms = -Xmx
 - ... and 59 more: https://git.openjdk.org/valhalla/compare/318e39a3...89786607

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

Changes: https://git.openjdk.org/valhalla/pull/1249/files
  Stats: 15146 lines in 1354 files changed: 4412 ins; 7219 del; 3515 mod
  Patch: https://git.openjdk.org/valhalla/pull/1249.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1249/head:pull/1249

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

From dsimms at openjdk.org  Thu Sep 19 09:59:02 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 19 Sep 2024 09:59:02 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <IZoggc5FgBC5GQs3Nb1ywNLUN1yhiFlO-UQdjumZNl8=.7ae57696-3eef-4990-a931-fddc3395298b@github.com>
References: <IZoggc5FgBC5GQs3Nb1ywNLUN1yhiFlO-UQdjumZNl8=.7ae57696-3eef-4990-a931-fddc3395298b@github.com>
Message-ID: <v1FpbBVT6dUMxgHhBG4cMqy8xKZo30OR3SUtsFuzp4A=.6a24fb79-fae5-47fc-b348-08f3d1e4fced@github.com>

On Thu, 19 Sep 2024 06:51:18 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-23+21' into lworld_merge_jdk_23_21
> Added tag jdk-23+21 for changeset e833bfc8

This pull request has now been integrated.

Changeset: 0f494172
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0f494172a19ae63b777ab14ec9da9f863fd7fa69
Stats:     15146 lines in 1354 files changed: 4412 ins; 7219 del; 3515 mod

Merge jdk

Merge jdk-23+21

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

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

From jbhateja at openjdk.org  Thu Sep 19 11:44:49 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 19 Sep 2024 11:44:49 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
Message-ID: <MqvFyGbDlSiIMRQg5fZo_tPKbF7Hgx5qnKhuuhszCQY=.2e4e7daa-47ab-4cf6-ab2b-d6bffdbf8744@github.com>

On Wed, 18 Sep 2024 10:00:36 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java side implementation instead of adding intrinsics

LGTM.

Best Regards,
Jatin

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1239#pullrequestreview-2315284621

From bkilambi at openjdk.org  Thu Sep 19 14:25:07 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 19 Sep 2024 14:25:07 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <MqvFyGbDlSiIMRQg5fZo_tPKbF7Hgx5qnKhuuhszCQY=.2e4e7daa-47ab-4cf6-ab2b-d6bffdbf8744@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
 <MqvFyGbDlSiIMRQg5fZo_tPKbF7Hgx5qnKhuuhszCQY=.2e4e7daa-47ab-4cf6-ab2b-d6bffdbf8744@github.com>
Message-ID: <MLBtum6OJeh0FkZfr25d_EpC34B1cROny3hwkdE15i0=.e678ce01-b8ce-47a8-83ed-8b1e736ccc7e@github.com>

On Thu, 19 Sep 2024 11:42:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> LGTM.
> 
> Best Regards, Jatin
> 
> PS: I have done some test refactoring, let me know if its ok with you. [test_refactoring.txt](https://github.com/user-attachments/files/17059007/test_refactoring.txt)

Thanks for the refactor. I think this looks cleaner. I will update the patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2361136287

From darcy at openjdk.org  Thu Sep 19 17:21:59 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 19 Sep 2024 17:21:59 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
Message-ID: <xPXTSFKVpucMafYYjvFidNSA0ebNEn9PgfpRnWZsQbI=.f8c2af3a-e481-4b84-a660-f128a9e7981c@github.com>

On Wed, 18 Sep 2024 10:00:36 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java side implementation instead of adding intrinsics

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

> 444:      * @see Double#isNaN(double)
> 445:      */
> 446:     public static boolean isNaN(Float16 f16) {

With changing the implementation if isNaN, isFinite, etc. to bit-based, the regression tests should be updated to cover more cases. In particular, different NaN bit patterns should be tested.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1239#discussion_r1767310337

From bkilambi at openjdk.org  Fri Sep 20 09:05:55 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 20 Sep 2024 09:05:55 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <xPXTSFKVpucMafYYjvFidNSA0ebNEn9PgfpRnWZsQbI=.f8c2af3a-e481-4b84-a660-f128a9e7981c@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
 <xPXTSFKVpucMafYYjvFidNSA0ebNEn9PgfpRnWZsQbI=.f8c2af3a-e481-4b84-a660-f128a9e7981c@github.com>
Message-ID: <NuIdPtAEHdZItEJ3GOTandSs8lBmePf_MWJkdOn01n8=.64e1c5c6-5f48-4d15-a40a-b24fcf76b758@github.com>

On Thu, 19 Sep 2024 17:19:10 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change java side implementation instead of adding intrinsics
>
> src/java.base/share/classes/java/lang/Float16.java line 446:
> 
>> 444:      * @see Double#isNaN(double)
>> 445:      */
>> 446:     public static boolean isNaN(Float16 f16) {
> 
> With changing the implementation if isNaN, isFinite, etc. to bit-based, the regression tests should be updated to cover more cases. In particular, different NaN bit patterns should be tested.

Hi @jddarcy , thank you for the review. I will add more input patterns to be tested.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1239#discussion_r1768253608

From rriggs at openjdk.org  Fri Sep 20 19:55:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Sep 2024 19:55:29 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes
Message-ID: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>

Serialization and deerialization of value classes. 
For java.base value classes migrated from identity classes:
  - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
  - Must have a constructor or static factory method:
    - annotated with jdk.internal.value.DeserializeConstrucctor
    - constructor parameters must match order and types of serializable fields of the class
  - Value class must not have superclass with fields; only Object or abstract w/o fields
  - Uses same technique as for Records to extract and concat values from stream to invoke constructor
  - Migrated value classes are serialized using the same format/fields as the identity class

Non-migrated value classes throw InvalidClassException

Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.

Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.

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

Commit messages:
 - 8340409: [lworld] Simple serialization and deserialization of core migrated classes

Changes: https://git.openjdk.org/valhalla/pull/1248/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1248&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340409
  Stats: 3163 lines in 21 files changed: 2584 ins; 420 del; 159 mod
  Patch: https://git.openjdk.org/valhalla/pull/1248.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1248/head:pull/1248

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

From dsimms at openjdk.org  Mon Sep 23 10:59:27 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 23 Sep 2024 10:59:27 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>

Merge jdk-23+22

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

Commit messages:
 - Adjust for JDK-8323058 API naming changes
 - Realign cast_arguments with JDK-8322726 code
 - Merge tag 'jdk-23+22' into lworld_merge_jdk_23_22
 - 8322753: RISC-V: C2 ReverseBytesV
 - 8331541: [i386] linking with libjvm.so fails after JDK-8283326
 - 8331886: Allow markdown src file overrides
 - 8331939: Add custom hook for TestImage
 - 8330275: Crash in XMark::follow_array
 - 8331941: Make CollectedHeap::parallel_object_iterator public
 - 8331924: Parallel: Remove unused MutableSpace::mangle_unused_area_complete
 - ... and 100 more: https://git.openjdk.org/valhalla/compare/0f494172...98cd627b

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

Changes: https://git.openjdk.org/valhalla/pull/1250/files
  Stats: 9333 lines in 420 files changed: 5279 ins; 1707 del; 2347 mod
  Patch: https://git.openjdk.org/valhalla/pull/1250.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1250/head:pull/1250

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

From bkilambi at openjdk.org  Mon Sep 23 16:53:12 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 23 Sep 2024 16:53:12 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v4]
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:

  Add more regression tests for FP16 isFinite, isInfinite, isNaN

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1239/files
  - new: https://git.openjdk.org/valhalla/pull/1239/files/a116fbe8..e965b58c

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

  Stats: 131 lines in 2 files changed: 48 ins; 8 del; 75 mod
  Patch: https://git.openjdk.org/valhalla/pull/1239.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1239/head:pull/1239

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

From bkilambi at openjdk.org  Mon Sep 23 16:53:12 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 23 Sep 2024 16:53:12 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
Message-ID: <H-BW2pnHwsdLR9IDghmZ1VWYDOAvdHJCb29mh4KBRiM=.acb248b5-7675-459c-8bf1-1617ffe682ab@github.com>

On Wed, 18 Sep 2024 10:00:36 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change java side implementation instead of adding intrinsics

Hi @jddarcy @jatin-bhateja , I have updated the patch to test for the full range of NaN values for FP16. Please review. Thanks !

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2368830402

From darcy at openjdk.org  Mon Sep 23 21:33:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Sep 2024 21:33:49 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v4]
In-Reply-To: <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
Message-ID: <D0vw2efWS0BLL1BBfw1oT-k9SlorPP6BXH9spx-k5vI=.3241253a-fbd8-431e-a9f7-251ce8f9c70f@github.com>

On Mon, 23 Sep 2024 16:53:12 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more regression tests for FP16 isFinite, isInfinite, isNaN

Marked as reviewed by darcy (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1239#pullrequestreview-2323406177

From darcy at openjdk.org  Mon Sep 23 21:33:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 23 Sep 2024 21:33:49 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v3]
In-Reply-To: <NuIdPtAEHdZItEJ3GOTandSs8lBmePf_MWJkdOn01n8=.64e1c5c6-5f48-4d15-a40a-b24fcf76b758@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <pEUWI-Lj3ECIQNAwjLiNEmN2W6yxuYUocGkAlXQboEU=.aa4b82c6-fd2f-4f94-9456-d1c8b41cb52c@github.com>
 <xPXTSFKVpucMafYYjvFidNSA0ebNEn9PgfpRnWZsQbI=.f8c2af3a-e481-4b84-a660-f128a9e7981c@github.com>
 <NuIdPtAEHdZItEJ3GOTandSs8lBmePf_MWJkdOn01n8=.64e1c5c6-5f48-4d15-a40a-b24fcf76b758@github.com>
Message-ID: <q9UhstSF5cXaBUJtE36PDcBK4kbHZni3Tl6aZVUapnA=.44e69e5f-b7e5-4657-a15a-f0995f89b3a5@github.com>

On Fri, 20 Sep 2024 09:03:05 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Float16.java line 446:
>> 
>>> 444:      * @see Double#isNaN(double)
>>> 445:      */
>>> 446:     public static boolean isNaN(Float16 f16) {
>> 
>> With changing the implementation if isNaN, isFinite, etc. to bit-based, the regression tests should be updated to cover more cases. In particular, different NaN bit patterns should be tested.
>
> Hi @jddarcy , thank you for the review. I will add more input patterns to be tested.

Thanks for the update; looks fine.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1239#discussion_r1772141156

From bkilambi at openjdk.org  Tue Sep 24 08:23:52 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 24 Sep 2024 08:23:52 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
 <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
 <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
Message-ID: <O_uYkf3zoagsgJOlTIyIViqgk3BVUF0BnMIeZ1HL7A4=.831fbf3e-69c0-4fe3-b480-d310bf3b885c@github.com>

On Tue, 17 Sep 2024 12:09:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @Bhavana-Kilambi , 
>> Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? 
>> e.g.  isNaNTest :=  (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..
>
>> Hi @jatin-bhateja , just tested the other two intrinsics as well. I do get huge performance gains (on aarch64) with the java versions. I used these -
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isNaN(Float16 f16) {
>>         return ((float16ToRawShortBits(f16) & 0x7e00) == 0x7e00);
>>     }
>> ```
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isInfinite(Float16 f16) {
>>         return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & 0x7fff) == 0;
>>     }
>> ```
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isFinite(Float16 f16) {
>>         return !(isInfinite(f16) || isNaN(f16));
>>      }
>> ```
>> 
>> I see these gains compared to the intrinsic version uploaded in the latest patch on this PR -
>> 
>> ```
>> Benchmark               (SIZE)    Gain
>> FP16Ops.isFiniteHF      65504     1.18409353876134
>> FP16Ops.isInfiniteHF    65504     1.57611028955779
>> FP16Ops.isNaNHF         65504     1.48276431718062
>> ```
>> 
>> Do you think it's better to not have any intrinsics at all for these operations?
> 
> Thanks @Bhavana-Kilambi , yes it will be optimal, your java versions still carries @IntrinsicCandidate, hope we are not accedently running intrinsics, if that is not the case then making only a java side change should suffice as its also easily auto-vectorizatable

Hi @jatin-bhateja , Hope the changes you suggested for the JTREG testcase are ok? I am marking it ready for integration -

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2370589845

From duke at openjdk.org  Tue Sep 24 08:23:52 2024
From: duke at openjdk.org (duke)
Date: Tue, 24 Sep 2024 08:23:52 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v4]
In-Reply-To: <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
Message-ID: <UFE_l5_XCCNlbLCvD6Xr0Vp3qktnssfAYQLxISYKtOY=.18346751-f45d-481d-a606-baff922ce287@github.com>

On Mon, 23 Sep 2024 16:53:12 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more regression tests for FP16 isFinite, isInfinite, isNaN

@Bhavana-Kilambi 
Your change (at version e965b58c14887c5fbcd53c8708d626d6669ff1b4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2370593990

From dsimms at openjdk.org  Tue Sep 24 10:11:04 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 24 Sep 2024 10:11:04 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>
References: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>
Message-ID: <couPfNXsnNFtsnopfsg2bJmFQnEnxK9ug06iTPh3Hj0=.ee0dfafe-681e-4a97-bb8a-02373669212b@github.com>

> Merge jdk-23+22

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

 - Merge jdk-23+23
 - 8302850: Implement C1 clone intrinsic that reuses arraycopy code for primitive arrays
   
   Reviewed-by: dlong, roland
 - 8329839: Cleanup ZPhysicalMemoryBacking trace logging
   
   Reviewed-by: stefank, ayang
 - 8332236: javac crashes with module imports and implicitly declared class
   
   Reviewed-by: vromero
 - 8330795: C2: assert((uint)type <= T_CONFLICT && _zero_type[type] != nullptr) failed: bad type with -XX:-UseCompressedClassPointers
   
   Reviewed-by: kvn
 - 8325932: Replace ATTRIBUTE_NORETURN with direct [[noreturn]]
   
   Reviewed-by: kbarrett, dholmes
 - 8332248: (fc) java/nio/channels/FileChannel/BlockDeviceSize.java failed with RuntimeException
   
   Reviewed-by: alanb
 - 8322008: Exclude some CDS tests from running with -Xshare:off
   
   Reviewed-by: lmesnik, iklam
 - 8313674: (fc) java/nio/channels/FileChannel/BlockDeviceSize.java should test for more block devices
   
   Reviewed-by: alanb, bpb
 - 8332042: Move MEMFLAGS to its own include file
   
   Reviewed-by: jsjolen, stefank
 - ... and 53 more: https://git.openjdk.org/valhalla/compare/98cd627b...031b75e5

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1250/files
  - new: https://git.openjdk.org/valhalla/pull/1250/files/98cd627b..031b75e5

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

  Stats: 19594 lines in 361 files changed: 10238 ins; 6422 del; 2934 mod
  Patch: https://git.openjdk.org/valhalla/pull/1250.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1250/head:pull/1250

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

From dsimms at openjdk.org  Tue Sep 24 13:34:45 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 24 Sep 2024 13:34:45 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>
References: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>
Message-ID: <U58t96ZGmwr0oCcviymhspwF0uRN6dTOv3hFQiFQhTs=.32435fb2-8bb8-4728-99fb-b99eb4e88451@github.com>

> Merge jdk-23+22

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

 - Merge tag 'jdk-23+24' into lworld_merge_jdk_23_22
   
   Added tag jdk-23+24 for changeset 9d332e65
 - 8307193: Several Swing jtreg tests use class.forName on L&F classes
   
   Reviewed-by: abhiscxk, prr
 - 8332490: JMH org.openjdk.bench.java.util.zip.InflaterInputStreams.inflaterInputStreamRead OOM
   
   Reviewed-by: aturbanov, redestad
 - 8332739: Problemlist compiler/codecache/CheckLargePages until JDK-8332654 is fixed
   
   Reviewed-by: kvn, dcubed
 - 8332463: Byte conditional pattern case element dominates short constant case element
   
   Reviewed-by: vromero
 - 8329718: Incorrect `@since` tags in elements in jdk.compiler and java.compiler
   
   Reviewed-by: darcy, jjg
 - 8332740: [BACKOUT] JDK-8331081 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
   
   Reviewed-by: mikael, prr, jlahoda
 - 8332096: hotspot-ide-project fails with this-escape
   
   Reviewed-by: erikj
 - 8331081: 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version
   
   Reviewed-by: jlahoda
 - 8332071: Convert package.html files in `java.management.rmi` to package-info.java
   8332376: Add `@since` tags to `java.management.rmi`
   
   Reviewed-by: kevinw, rriggs
 - ... and 83 more: https://git.openjdk.org/valhalla/compare/031b75e5...92736836

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1250/files
  - new: https://git.openjdk.org/valhalla/pull/1250/files/031b75e5..92736836

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

  Stats: 47195 lines in 669 files changed: 38304 ins; 6420 del; 2471 mod
  Patch: https://git.openjdk.org/valhalla/pull/1250.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1250/head:pull/1250

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

From dsimms at openjdk.org  Tue Sep 24 20:10:08 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 24 Sep 2024 20:10:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>
References: <-K7OyKsDCUgsQdVvbPQKEGY0HwUmIWwprcU3HT-G6MU=.d59cbf25-7ff0-4e1d-832d-b1aea5e2a6e2@github.com>
Message-ID: <UZ6jRNMthWmHsvOF8qEQyQ8t3ueu5htfWq-Ofzkb2wQ=.6073b719-08b5-467e-b9f5-193a33ec5839@github.com>

On Mon, 23 Sep 2024 10:53:31 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+22

This pull request has now been integrated.

Changeset: 5d6d3ce7
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5d6d3ce782ac213f6c400eb70c6b9cfe9691f06a
Stats:     76025 lines in 1361 files changed: 53803 ins; 14531 del; 7691 mod

Merge jdk

Merge jdk-23+22, jdk-23+23 and jdk-23+24

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

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

From amenkov at openjdk.org  Tue Sep 24 23:00:25 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 24 Sep 2024 23:00:25 GMT
Subject: [lworld] RFR: 8325583: [lworld] Develop a test for value class
 redefinition
Message-ID: <K2KB-qsTfeBal4nImMwaVQ5-YfGkH6AiKZwxz8JLaJQ=.b45f321c-56c5-45b6-b7cb-faaaaa490032@github.com>

Added tests for redefine/retransform of value classes

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

Commit messages:
 - jcheck
 - redefine_class_tests

Changes: https://git.openjdk.org/valhalla/pull/1252/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325583
  Stats: 539 lines in 20 files changed: 518 ins; 3 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/1252.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1252/head:pull/1252

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

From amenkov at openjdk.org  Tue Sep 24 23:15:50 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 24 Sep 2024 23:15:50 GMT
Subject: [lworld] Integrated: 8325583: [lworld] Develop a test for value class
 redefinition
In-Reply-To: <K2KB-qsTfeBal4nImMwaVQ5-YfGkH6AiKZwxz8JLaJQ=.b45f321c-56c5-45b6-b7cb-faaaaa490032@github.com>
References: <K2KB-qsTfeBal4nImMwaVQ5-YfGkH6AiKZwxz8JLaJQ=.b45f321c-56c5-45b6-b7cb-faaaaa490032@github.com>
Message-ID: <8Xd0r5pQ8FzCauY_G2oarvUeT6IuiwqefiTzGJ7w6ZM=.a0b920b7-6ce7-4b01-b263-a4e8e9570843@github.com>

On Tue, 24 Sep 2024 22:51:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Added tests for redefine/retransform of value classes

This pull request has now been integrated.

Changeset: 2ba22560
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2ba22560dfd88f9adb84682f4ffb1631547df3b2
Stats:     539 lines in 20 files changed: 518 ins; 3 del; 18 mod

8325583: [lworld] Develop a test for value class redefinition

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

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

From mcimadamore at openjdk.org  Wed Sep 25 15:09:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 15:09:13 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <FGfwQbQL3cVBozNJIzUii31Qupo1IO_Cd-CjAWBptKI=.0a8811ad-a7b6-4203-be7a-9f95936da3df@github.com>

On Tue, 24 Sep 2024 21:13:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is not generating null checks for runtime execution for method invocations and array writes

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

> 1970:         // outer instance of a super(...) call appears as first parameter).
> 1971:         MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth);
> 1972:         List<Type> erasedPts = msym.externalType(types).getParameterTypes();

Should we revert these lines (and others in this class) to whatever is in mainline?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1251#discussion_r1775418509

From vromero at openjdk.org  Wed Sep 25 15:09:12 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 25 Sep 2024 15:09:12 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes
Message-ID: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>

javac is not generating null checks for runtime execution for method invocations and array writes

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

Commit messages:
 - Merge with remote branch
 - 8340125: [lw5] null checks are not being generated for method invocations and array writes
 - 8340125: [lw5] null checks are not being generated for method invocations and array writes

Changes: https://git.openjdk.org/valhalla/pull/1251/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1251&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340125
  Stats: 328 lines in 6 files changed: 272 ins; 22 del; 34 mod
  Patch: https://git.openjdk.org/valhalla/pull/1251.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1251/head:pull/1251

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

From vromero at openjdk.org  Wed Sep 25 15:12:53 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 25 Sep 2024 15:12:53 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes
In-Reply-To: <FGfwQbQL3cVBozNJIzUii31Qupo1IO_Cd-CjAWBptKI=.0a8811ad-a7b6-4203-be7a-9f95936da3df@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
 <FGfwQbQL3cVBozNJIzUii31Qupo1IO_Cd-CjAWBptKI=.0a8811ad-a7b6-4203-be7a-9f95936da3df@github.com>
Message-ID: <fhw9gNsy45NF_PPklrJSPzlYAd0qgdXlV-UC-96k4o4=.4e217c6b-e067-4d4c-bb2a-62ed603bb79b@github.com>

On Wed, 25 Sep 2024 15:05:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> javac is not generating null checks for runtime execution for method invocations and array writes
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 1972:
> 
>> 1970:         // outer instance of a super(...) call appears as first parameter).
>> 1971:         MethodSymbol msym = (MethodSymbol)TreeInfo.symbol(tree.meth);
>> 1972:         List<Type> erasedPts = msym.externalType(types).getParameterTypes();
> 
> Should we revert these lines (and others in this class) to whatever is in mainline?

sure will do

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1251#discussion_r1775424953

From vromero at openjdk.org  Wed Sep 25 15:25:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 25 Sep 2024 15:25:30 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v2]
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <blzuq7dzMrL1EN0u7UUIba0ReBAVARAcM_m28sMIS5U=.b3f5ed0e-9860-4219-addc-e28a4e5558a6@github.com>

> javac is not generating null checks for runtime execution for method invocations and array writes

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1251/files
  - new: https://git.openjdk.org/valhalla/pull/1251/files/98f741ea..aaf95a05

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

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

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

From mcimadamore at openjdk.org  Wed Sep 25 15:25:31 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Sep 2024 15:25:31 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v2]
In-Reply-To: <blzuq7dzMrL1EN0u7UUIba0ReBAVARAcM_m28sMIS5U=.b3f5ed0e-9860-4219-addc-e28a4e5558a6@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
 <blzuq7dzMrL1EN0u7UUIba0ReBAVARAcM_m28sMIS5U=.b3f5ed0e-9860-4219-addc-e28a4e5558a6@github.com>
Message-ID: <EpkvDkKh1SyFOa9GSFEcCRNXNYXIoLa5snTfsPBmSK8=.694a8c15-31a9-48fd-94c8-4487ef92c956@github.com>

On Wed, 25 Sep 2024 15:21:39 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> javac is not generating null checks for runtime execution for method invocations and array writes
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java line 522:

> 520:         tree.vartype = translate(tree.vartype, null);
> 521:         if (tree.init != null) {
> 522:             if (types.isNonNullable(tree.type) && !types.isNonNullable(tree.init.type)) {

I see why you did this. The synthetic casts are added by `TransTypes` in the various visitor methods. This makes sense because the casts are only required for method calls and field accesses.

My feeling is that most of this remains true also for null checks. E.g. you need to insert a check when you are translating a _variable_ (field, local, method parameter), or a _method call_ - in these cases there might be some nullness markers (on the variable, or on the method return) that should be taken into account, and compared with the "expected" nullness. If a "nullness" mismatch is found, a null-check should be inserted.

So I wonder if the main `translate` method should go from this:


translate(expr, expectedErasedType)


To this:


translate(expr, expectedErasedType, expectedNullness)


And the conversions "pushed" down in the visitor, in a similar way as what we do today for synthetic casts.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1251#discussion_r1775443714

From amenkov at openjdk.org  Wed Sep 25 22:15:17 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 25 Sep 2024 22:15:17 GMT
Subject: [lworld] Integrated: 8340977: Remove ignore tag from FieldAccessModify
 test
Message-ID: <ULLzn2uf5sNc8-nT5IXRCGkQhmCB08Cs7vjDdf-HLKU=.e0ada380-3d9b-4530-80f5-f2a2875f12f4@github.com>

removed missed ignore tag

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

Commit messages:
 - fix

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

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

From amenkov at openjdk.org  Wed Sep 25 22:15:17 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 25 Sep 2024 22:15:17 GMT
Subject: [lworld] Integrated: 8340977: Remove ignore tag from FieldAccessModify
 test
In-Reply-To: <ULLzn2uf5sNc8-nT5IXRCGkQhmCB08Cs7vjDdf-HLKU=.e0ada380-3d9b-4530-80f5-f2a2875f12f4@github.com>
References: <ULLzn2uf5sNc8-nT5IXRCGkQhmCB08Cs7vjDdf-HLKU=.e0ada380-3d9b-4530-80f5-f2a2875f12f4@github.com>
Message-ID: <i-XEdD7F3sGdzeVGyZCeWlhsdPLSTTbFaG1drarCiac=.da7d7132-4c96-461d-9f8f-7ab11001de33@github.com>

On Wed, 25 Sep 2024 22:03:04 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> removed missed ignore tag

This pull request has now been integrated.

Changeset: c219abcd
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c219abcd578c8c08af05db6b495a4eceda91ef87
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8340977: Remove ignore tag from FieldAccessModify test

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

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

From bkilambi at openjdk.org  Thu Sep 26 02:15:50 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 26 Sep 2024 02:15:50 GMT
Subject: [lworld+fp16] Integrated: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
Message-ID: <W-sqrEnfF4MN4G8TeX4spwy4to8lBwENRHT7jqQRBHo=.a3ed225c-36bf-412a-8a68-11e873a8d5ac@github.com>

On Wed, 11 Sep 2024 08:37:38 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
> 
> Tested all FP16 related tests successfully on aarch64.

This pull request has now been integrated.

Changeset: 3f42a1c9
Author:    Bhavana Kilambi <bkilambi at openjdk.org>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3f42a1c9b9fc806e79e56ff794a745749feb823e
Stats:     138 lines in 2 files changed: 57 ins; 12 del; 69 mod

8339473: Add support for FP16 isFinite, isInfinite and isNaN

Reviewed-by: jbhateja, darcy

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

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

From jbhateja at openjdk.org  Thu Sep 26 03:38:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 03:38:51 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN
In-Reply-To: <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <hEeH--7zfSsOV6n5eeJT-JR96TllRp5RWszo2BWQQrQ=.39e79f34-c0c5-4125-a6ad-dca857fa275c@github.com>
 <sm1Ka5ZOCftBnRpkuxSGQtF-IxZoZeKGXh6soPLD908=.e80f068a-0f4c-4059-9531-d7e4936f4d7d@github.com>
 <dpFKUMTjxCwnT6jMmCVjpPzH_X-izBlWw9xj9hKWbyk=.89f64a8c-dc14-480a-a59f-55784a64bf92@github.com>
Message-ID: <4UcHgU2CGU7rIHEAJ4teyNkHbRDEaXHDJe45kg1pbLk=.1a43bba9-097c-4554-9e2d-b4980caefc0d@github.com>

On Tue, 17 Sep 2024 12:09:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @Bhavana-Kilambi , 
>> Did you trying modifying the Java implementation and measuring the performance with intrinsic solution ? 
>> e.g.  isNaNTest :=  (Float16.float16ToRawShortValue() & 0x7e00) == 0x7e00 etc..
>
>> Hi @jatin-bhateja , just tested the other two intrinsics as well. I do get huge performance gains (on aarch64) with the java versions. I used these -
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isNaN(Float16 f16) {
>>         return ((float16ToRawShortBits(f16) & 0x7e00) == 0x7e00);
>>     }
>> ```
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isInfinite(Float16 f16) {
>>         return ((float16ToRawShortBits(f16) ^ float16ToRawShortBits(POSITIVE_INFINITY)) & 0x7fff) == 0;
>>     }
>> ```
>> 
>> ```
>> @IntrinsicCandidate
>>     public static boolean isFinite(Float16 f16) {
>>         return !(isInfinite(f16) || isNaN(f16));
>>      }
>> ```
>> 
>> I see these gains compared to the intrinsic version uploaded in the latest patch on this PR -
>> 
>> ```
>> Benchmark               (SIZE)    Gain
>> FP16Ops.isFiniteHF      65504     1.18409353876134
>> FP16Ops.isInfiniteHF    65504     1.57611028955779
>> FP16Ops.isNaNHF         65504     1.48276431718062
>> ```
>> 
>> Do you think it's better to not have any intrinsics at all for these operations?
> 
> Thanks @Bhavana-Kilambi , yes it will be optimal, your java versions still carries @IntrinsicCandidate, hope we are not accedently running intrinsics, if that is not the case then making only a java side change should suffice as its also easily auto-vectorizatable

> Hi @jatin-bhateja , Hope the changes you suggested for the JTREG testcase are ok? I am marking it ready for integration -
> 
> /integrate

Hi @Bhavana-Kilambi ,  I think we can take same approach for unary operations - Float16.negate and Float16.abs and remove explicit intrinsification, java side implimentation is auto-vectorizable and performance should be at par with explicit intrinsic.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2375792389

From jbhateja at openjdk.org  Thu Sep 26 03:54:53 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 03:54:53 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v4]
In-Reply-To: <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
Message-ID: <mbxZcn7RlSoC6dL5Py81XJSSzb5AkjNcGJZC0a0Glz4=.8644125d-886e-4570-a297-3e350f44bbb5@github.com>

On Mon, 23 Sep 2024 16:53:12 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 isNaN, isFinite and isInfinite methods and also adds aarch64 backend for these intrinsics.
>> 
>> Tested all FP16 related tests successfully on aarch64.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more regression tests for FP16 isFinite, isInfinite, isNaN

Since Float16 is a value type, hence C2 will always create a scalarized IR "InlineTypeNode" for it even if we don't intrinsify it. 
Consider following byte code sequence of Float16.abs
![image](https://github.com/user-attachments/assets/c30b0c41-2139-4663-af6a-c0724033ce83)

getfiled will directly return the scalar 'short' field which after subsequent logical and will return absolute value. I checked SVE does have direct instruction to negate IEEE 754 binary16 encoded value, but don't know about its latency and performance compared to logical operations.  For x86, FP16 ISA does not have a direct negation instruction so java implementation should be equally performant.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2375810571

From jbhateja at openjdk.org  Thu Sep 26 08:30:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 08:30:33 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations
Message-ID: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>

- Adding micro-benchmarks for various Float16 operations.
- Adding similarity search targeting micro-benchmarks.

Please find below the results of performance testing over recently released Intel Xeon6 Granite Rapids:-


Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms


Best Regrads,
Jatin

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

Commit messages:
 - Update Float16OpsBenchmark.java
 - 8341003: [lworld+fp16] Benchmarks for various Float16 operations

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

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

From bkilambi at openjdk.org  Thu Sep 26 08:39:51 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 26 Sep 2024 08:39:51 GMT
Subject: [lworld+fp16] RFR: 8339473: Add support for FP16 isFinite,
 isInfinite and isNaN [v4]
In-Reply-To: <mbxZcn7RlSoC6dL5Py81XJSSzb5AkjNcGJZC0a0Glz4=.8644125d-886e-4570-a297-3e350f44bbb5@github.com>
References: <wagEddMSA_tFbF2PoR2HPbnM4mIiEo7S_IvWGCc4cjI=.878d6931-fbea-42d2-821f-e2dbfa206a8e@github.com>
 <mP9x1f6qDS5UpLUqFEpIYCXu81xnjbodnfz78AXM3eM=.c357ceba-c12b-40f5-ab2d-0db4a5c6c116@github.com>
 <mbxZcn7RlSoC6dL5Py81XJSSzb5AkjNcGJZC0a0Glz4=.8644125d-886e-4570-a297-3e350f44bbb5@github.com>
Message-ID: <sjctAXuHRo0dM_ZwxuUxUdEk90-wP5ggLxWaizBxpAE=.04c457e9-f987-4ef6-b650-143d40829d8e@github.com>

On Thu, 26 Sep 2024 03:51:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add more regression tests for FP16 isFinite, isInfinite, isNaN
>
> Since Float16 is a value type, hence C2 will always create a scalarized IR "InlineTypeNode" for it even if we don't intrinsify it. 
> Consider following byte code sequence of Float16.abs
> ![image](https://github.com/user-attachments/assets/c30b0c41-2139-4663-af6a-c0724033ce83)
> 
> getfiled will directly return the scalar 'short' field which after subsequent logical and will return absolute value. I checked SVE does have direct instruction to negate IEEE 754 binary16 encoded value, but don't know about its latency and performance compared to logical operations.  For x86, FP16 ISA does not have a direct negation instruction so java implementation should be equally performant.

@jatin-bhateja Sure, I'll look into replacing intrinsics with java code for other unary operations too (or wherever there's bit manipulation possible). Thanks for the explanation!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1239#issuecomment-2376310583

From jbhateja at openjdk.org  Thu Sep 26 09:05:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 09:05:00 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
Message-ID: <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>

> - Adding micro-benchmarks for various Float16 operations.
> - Adding similarity search targeting micro-benchmarks.
> 
> Please find below the results of performance testing over Intel Xeon6 Granite Rapids:-
> 
> 
> Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
> Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
> Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
> Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
> Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
> Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
> Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms
> 
> 
> Best Regrads,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Update benchmark

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1254/files
  - new: https://git.openjdk.org/valhalla/pull/1254/files/1bfdd3c4..6c988b7c

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

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

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

From jbhateja at openjdk.org  Thu Sep 26 09:15:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 09:15:22 GMT
Subject: [lworld+fp16] Integrated: 8341005: [lworld+fp16] Disable
 intrinsification of Float16.abs and Float16.negate for x86 target
Message-ID: <uuM3YM_1QGQqSq3r9sM1Tjdkf3bNeDYXUj75sicmV90=.2c32f41f-406d-4a1b-b1c0-8ae252a80b7c@github.com>

- Java side implementation is efficient and auto-vectorizable.
- Unlike AARCH64 SVE, x86 FP16 ISA does not support direct negation instruction.

No performance impact seen in benchmarks.

Best Regard,
Jatin

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

Commit messages:
 - 8341005: [lworld+fp16] Revert intrinsification of Float16.abs and Float16.negate for x86 target

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

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

From jbhateja at openjdk.org  Thu Sep 26 09:15:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 09:15:22 GMT
Subject: [lworld+fp16] Integrated: 8341005: [lworld+fp16] Disable
 intrinsification of Float16.abs and Float16.negate for x86 target
In-Reply-To: <uuM3YM_1QGQqSq3r9sM1Tjdkf3bNeDYXUj75sicmV90=.2c32f41f-406d-4a1b-b1c0-8ae252a80b7c@github.com>
References: <uuM3YM_1QGQqSq3r9sM1Tjdkf3bNeDYXUj75sicmV90=.2c32f41f-406d-4a1b-b1c0-8ae252a80b7c@github.com>
Message-ID: <Gw0KAJOV5x0vV47WU1-atW1AtX1i82SQgmwvJIZOoRA=.467bc03f-d68c-481e-8876-d250e7839935@github.com>

On Thu, 26 Sep 2024 09:07:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Java side implementation is efficient and auto-vectorizable.
> - Unlike AARCH64 SVE, x86 FP16 ISA does not support direct negation instruction.
> 
> No performance impact seen in benchmarks.
> 
> Best Regard,
> Jatin

This pull request has now been integrated.

Changeset: fb5b1b16
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fb5b1b16c57266508afd96f6a78f90996d28017f
Stats:     62 lines in 2 files changed: 0 ins; 60 del; 2 mod

8341005: [lworld+fp16] Disable intrinsification of Float16.abs and Float16.negate for x86 target

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

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

From jbhateja at openjdk.org  Thu Sep 26 10:46:43 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 26 Sep 2024 10:46:43 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
Message-ID: <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>

On Thu, 26 Sep 2024 09:05:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Adding micro-benchmarks for various Float16 operations.
>> - Adding similarity search targeting micro-benchmarks.
>> 
>> Please find below the results of performance testing over Intel Xeon6 Granite Rapids:-
>> 
>> 
>> Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
>> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
>> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
>> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
>> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
>> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
>> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
>> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
>> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
>> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
>> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
>> Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
>> Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
>> Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
>> Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
>> Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
>> Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms
>> 
>> 
>> Best Regrads,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark

Hi @Bhavana-Kilambi , I see vector IR in almost all the micros apart from three i.e. isNaN, isFinite and isInfinity with following command

`numactl --cpunodebind=1 -l java -jar target/benchmarks.jar  -jvmArgs "-XX:+TraceNewVectors" -p vectorDim=512 -f 1 -i 2 -wi 1 -w 30 org.openjdk.bench.java.lang.Float16OpsBenchmark.<BM_NAME>
`

Indicates Java implementation in some cases is not auto-vectorizing, after tuning we can verify with this benchmark.

Kindly let me know if the micro looks good, I can integrate it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2376589198

From dsimms at openjdk.org  Thu Sep 26 15:01:26 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 26 Sep 2024 15:01:26 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <HqVZaZzhU-ghvnJmRfeklP-cTiaaJicFKiIzHQ0jXgg=.ea07e1f4-dcfd-4423-95cf-2925cf3a184b@github.com>

Merge jdk-23+25

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

Commit messages:
 - Fixed JDK-8329203 using "init_mark()" with unstable klass while compacting
 - Adjust LoadableDescriptors in classfile changes
 - Merge tag 'jdk-23+25' into lworld_merge_jdk_23_25
 - 8333189: Make sure clang on linux uses lld as linker
 - 8332919: SA PointerLocation needs to print a newline after dumping java thread info for JNI Local Ref
 - 8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't use finalization
 - 8332259: JvmtiTrace::safe_get_thread_name fails if current thread is in native state
 - 8333149: ubsan : memset on nullptr target detected in jvmtiEnvBase.cpp get_object_monitor_usage
 - 8320999: RISC-V: C2 RotateLeftV
 - 8321543: Update NSS to version 3.96
 - ... and 90 more: https://git.openjdk.org/valhalla/compare/2ba22560...97968f0b

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

Changes: https://git.openjdk.org/valhalla/pull/1256/files
  Stats: 20210 lines in 590 files changed: 12390 ins; 4383 del; 3437 mod
  Patch: https://git.openjdk.org/valhalla/pull/1256.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1256/head:pull/1256

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

From bkilambi at openjdk.org  Thu Sep 26 15:41:52 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 26 Sep 2024 15:41:52 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
Message-ID: <OLqQunLL8X72C4e2I6d2H1FxKsJZIhYdoCX1t-N1vA4=.3ba82b02-35da-4a6c-8f97-6fa39d7908db@github.com>

On Thu, 26 Sep 2024 10:42:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update benchmark
>
> Hi @Bhavana-Kilambi , I see vector IR in almost all the micros apart from three i.e. isNaN, isFinite and isInfinity with following command
> 
> `numactl --cpunodebind=1 -l java -jar target/benchmarks.jar  -jvmArgs "-XX:+TraceNewVectors" -p vectorDim=512 -f 1 -i 2 -wi 1 -w 30 org.openjdk.bench.java.lang.Float16OpsBenchmark.<BM_NAME>
> `
> 
> Indicates Java implementation in those cases is not getting auto-vectorized, we didn't had benchmarks earlier, after tuning we can verify with this new benchmark.
> 
> Kindly let me know if the micro looks good, I can integrate it.

Hi @jatin-bhateja , thanks for doing the micros.
Can I please ask why are you benchmarking/testing the cosine similarity tests specifically? Are there any real world usecases which are similar to these for FP16 for which you have written these smaller benchmark kernels?

Also, regarding the performance results you posted for the Intel machine, have you compared it with anything else (like the default FP32 implementation/case without the intrinsics or the scalar FP16 version) so that we can better interpret the scores?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2377319124

From jbhateja at openjdk.org  Fri Sep 27 07:09:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Sep 2024 07:09:00 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
Message-ID: <H0ogo1qy8Pnvp8K6TGXGzQNMVBMD9joHLF0EvdnV3Zw=.31fec242-d4f1-4d14-bd2c-ef2bf676b7d9@github.com>

On Thu, 26 Sep 2024 10:42:14 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update benchmark
>
> Hi @Bhavana-Kilambi , I see vector IR in almost all the micros apart from three i.e. isNaN, isFinite and isInfinity with following command
> 
> `numactl --cpunodebind=1 -l java -jar target/benchmarks.jar  -jvmArgs "-XX:+TraceNewVectors" -p vectorDim=512 -f 1 -i 2 -wi 1 -w 30 org.openjdk.bench.java.lang.Float16OpsBenchmark.<BM_NAME>
> `
> 
> Indicates Java implementation in those cases is not getting auto-vectorized, we didn't had benchmarks earlier, after tuning we can verify with this new benchmark.
> 
> Kindly let me know if the micro looks good, I can integrate it.

> Hi @jatin-bhateja , thanks for doing the micros. Can I please ask why are you benchmarking/testing the cosine similarity tests specifically? Are there any real world usecases which are similar to these for FP16 for which you have written these smaller benchmark kernels?
> 
> Also, regarding the performance results you posted for the Intel machine, have you compared it with anything else (like the default FP32 implementation for FP16/case without the intrinsics or the scalar FP16 version) so that we can better interpret the scores?

Hi @Bhavana-Kilambi , This patch adds **micro benchmarks** for all Float16 APIs optimized uptill now.
**Macro-benchmarks** demonstrates use case for low precision semantic search primitives.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378550615

From bkilambi at openjdk.org  Fri Sep 27 07:50:53 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 27 Sep 2024 07:50:53 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <H0ogo1qy8Pnvp8K6TGXGzQNMVBMD9joHLF0EvdnV3Zw=.31fec242-d4f1-4d14-bd2c-ef2bf676b7d9@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
 <H0ogo1qy8Pnvp8K6TGXGzQNMVBMD9joHLF0EvdnV3Zw=.31fec242-d4f1-4d14-bd2c-ef2bf676b7d9@github.com>
Message-ID: <PaIVUtPW0QUtfh7R7U1xO2iQVlVHZnUoFtfchRFEScA=.620cd74b-e6db-4699-baa4-408ca7180591@github.com>

On Fri, 27 Sep 2024 07:06:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @Bhavana-Kilambi , I see vector IR in almost all the micros apart from three i.e. isNaN, isFinite and isInfinity with following command
>> 
>> `numactl --cpunodebind=1 -l java -jar target/benchmarks.jar  -jvmArgs "-XX:+TraceNewVectors" -p vectorDim=512 -f 1 -i 2 -wi 1 -w 30 org.openjdk.bench.java.lang.Float16OpsBenchmark.<BM_NAME>
>> `
>> 
>> Indicates Java implementation in those cases is not getting auto-vectorized, we didn't had benchmarks earlier, after tuning we can verify with this new benchmark.
>> 
>> Kindly let me know if the micro looks good, I can integrate it.
>
>> Hi @jatin-bhateja , thanks for doing the micros. Can I please ask why are you benchmarking/testing the cosine similarity tests specifically? Are there any real world usecases which are similar to these for FP16 for which you have written these smaller benchmark kernels?
>> 
>> Also, regarding the performance results you posted for the Intel machine, have you compared it with anything else (like the default FP32 implementation for FP16/case without the intrinsics or the scalar FP16 version) so that we can better interpret the scores?
> 
> Hi @Bhavana-Kilambi , This patch adds **micro benchmarks** for all Float16 APIs optimized uptill now.
> **Macro-benchmarks** demonstrates use case for low precision semantic search primitives.

@jatin-bhateja , Thanks! While we are at the topic, can I ask if there are any real-world usescases or workloads that you are targeting the FP16 work for and maybe plan to do performance testing in the future?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378632353

From jbhateja at openjdk.org  Fri Sep 27 07:53:52 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Sep 2024 07:53:52 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <H0ogo1qy8Pnvp8K6TGXGzQNMVBMD9joHLF0EvdnV3Zw=.31fec242-d4f1-4d14-bd2c-ef2bf676b7d9@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
 <H0ogo1qy8Pnvp8K6TGXGzQNMVBMD9joHLF0EvdnV3Zw=.31fec242-d4f1-4d14-bd2c-ef2bf676b7d9@github.com>
Message-ID: <whkd_10axe_dX2pSOJrNKqKXMYYISZXgtSm3Eh0QThs=.34df7c86-4c2a-4ecc-b9ce-ce4719c6d2e6@github.com>

On Fri, 27 Sep 2024 07:06:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Hi @jatin-bhateja , thanks for doing the micros. Can I please ask why are you benchmarking/testing the cosine similarity tests specifically? Are there any real world usecases which are similar to these for FP16 for which you have written these smaller benchmark kernels?
> > Also, regarding the performance results you posted for the Intel machine, have you compared it with anything else (like the default FP32 implementation for FP16/case without the intrinsics or the scalar FP16 version) so that we can better interpret the scores?
> 
> Hi @Bhavana-Kilambi , This patch adds **micro benchmarks** for all Float16 APIs optimized uptill now. **Macro-benchmarks** demonstrates use case for low precision semantic search primitives.

Hey,  for baseline we should not pass --enable-preview since it will prohibit following
- Flat layout of Float16 arrays.
- Creating valhalla specific IR needed for intrinsification.

Here are the first baseline numbers without --enable-primitive.


Benchmark                                               (vectorDim)   Mode  Cnt     Score   Error   Units
Float16OpsBenchmark.absBenchmark                               1024  thrpt    2    99.424          ops/ms
Float16OpsBenchmark.addBenchmark                               1024  thrpt    2    97.498          ops/ms
Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2   525.360          ops/ms
Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    51.132          ops/ms
Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    46.921          ops/ms
Float16OpsBenchmark.divBenchmark                               1024  thrpt    2    97.186          ops/ms
Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2   583.051          ops/ms
Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    56.133          ops/ms
Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2    81.386          ops/ms
Float16OpsBenchmark.getExponentBenchmark                       1024  thrpt    2  2257.619          ops/ms
Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2  3086.476          ops/ms
Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2  1718.411          ops/ms
Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2  1685.557          ops/ms
Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2    92.078          ops/ms
Float16OpsBenchmark.minBenchmark                               1024  thrpt    2    63.377          ops/ms
Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2    98.202          ops/ms
Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2    98.158          ops/ms
Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2    83.760          ops/ms
Float16OpsBenchmark.subBenchmark                               1024  thrpt    2    98.200          ops/ms


Following are the number where we do allow flat array layout, but only disable intrinsics (-XX:DisableIntrinsics=<INTIN_ID>+).



Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25978.876          ops/ms
Float16OpsBenchmark.addBenchmark                               1024  thrpt    2   6406.685          ops/ms
Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.877          ops/ms
Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2     76.680          ops/ms
Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2     53.692          ops/ms
Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   3227.037          ops/ms
Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    740.490          ops/ms
Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2     83.747          ops/ms
Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2    256.399          ops/ms
Float16OpsBenchmark.getExponentBenchmark                       1024  thrpt    2   2135.678          ops/ms
Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3916.860          ops/ms
Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1497.417          ops/ms
Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2747.704          ops/ms
Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2   3625.708          ops/ms
Float16OpsBenchmark.minBenchmark                               1024  thrpt    2   3628.261          ops/ms
Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2   6340.403          ops/ms
Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25727.870          ops/ms
Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2    157.519          ops/ms
Float16OpsBenchmark.subBenchmark                               1024  thrpt    2   6404.047          ops/ms

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378638423

From dsimms at openjdk.org  Fri Sep 27 07:56:37 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 27 Sep 2024 07:56:37 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <HqVZaZzhU-ghvnJmRfeklP-cTiaaJicFKiIzHQ0jXgg=.ea07e1f4-dcfd-4423-95cf-2925cf3a184b@github.com>
References: <HqVZaZzhU-ghvnJmRfeklP-cTiaaJicFKiIzHQ0jXgg=.ea07e1f4-dcfd-4423-95cf-2925cf3a184b@github.com>
Message-ID: <080agidXZMCNj6xhAGsvEIXEaf88NbOCz2yFQXiqoaE=.9ee87e31-99c7-4dcd-b1f6-0916c9346b6d@github.com>

> Merge jdk-23+25

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

  Adjust SuperInit results

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1256/files
  - new: https://git.openjdk.org/valhalla/pull/1256/files/97968f0b..cd4ec509

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

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

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

From dsimms at openjdk.org  Fri Sep 27 08:00:59 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 27 Sep 2024 08:00:59 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <HqVZaZzhU-ghvnJmRfeklP-cTiaaJicFKiIzHQ0jXgg=.ea07e1f4-dcfd-4423-95cf-2925cf3a184b@github.com>
References: <HqVZaZzhU-ghvnJmRfeklP-cTiaaJicFKiIzHQ0jXgg=.ea07e1f4-dcfd-4423-95cf-2925cf3a184b@github.com>
Message-ID: <_T0jHjYQcQYiPLZeCICrITUbckhpIKS82be-z5wwOyY=.1fe5ec2c-f6ac-4b3a-9511-fcde8bd318e3@github.com>

On Thu, 26 Sep 2024 14:56:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+25

This pull request has now been integrated.

Changeset: 2c876c9c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2c876c9c0ce2a4753a196a5b22910a3ec1e360e5
Stats:     20212 lines in 591 files changed: 12390 ins; 4384 del; 3438 mod

Merge jdk

Merge jdk-23+25

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

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

From jbhateja at openjdk.org  Fri Sep 27 08:08:54 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Sep 2024 08:08:54 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <whkd_10axe_dX2pSOJrNKqKXMYYISZXgtSm3Eh0QThs=.34df7c86-4c2a-4ecc-b9ce-ce4719c6d2e6@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <1VM5sll5oOArhMkM07lHKcCuPFy3W0RTsH6j4oDUtPU=.e5a6eef6-7017-4383-a407-e6507db1cfd6@github.com>
 <H0ogo1qy8Pnvp8K6TGXGzQNMVBMD9joHLF0EvdnV3Zw=.31fec242-d4f1-4d14-bd2c-ef2bf676b7d9@github.com>
 <whkd_10axe_dX2pSOJrNKqKXMYYISZXgtSm3Eh0QThs=.34df7c86-4c2a-4ecc-b9ce-ce4719c6d2e6@github.com>
Message-ID: <0dDUt7Eg7DxmP24DsA9b8mDGNGvHKw5Ix6X9XNkh2-w=.9251add4-4400-4953-96fe-d96ad28d78b4@github.com>

On Fri, 27 Sep 2024 07:51:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Hi @jatin-bhateja , thanks for doing the micros. Can I please ask why are you benchmarking/testing the cosine similarity tests specifically? Are there any real world usecases which are similar to these for FP16 for which you have written these smaller benchmark kernels?
>>> 
>>> Also, regarding the performance results you posted for the Intel machine, have you compared it with anything else (like the default FP32 implementation for FP16/case without the intrinsics or the scalar FP16 version) so that we can better interpret the scores?
>> 
>> Hi @Bhavana-Kilambi , This patch adds **micro benchmarks** for all Float16 APIs optimized uptill now.
>> **Macro-benchmarks** demonstrates use case for low precision semantic search primitives.
>
>> > Hi @jatin-bhateja , thanks for doing the micros. Can I please ask why are you benchmarking/testing the cosine similarity tests specifically? Are there any real world usecases which are similar to these for FP16 for which you have written these smaller benchmark kernels?
>> > Also, regarding the performance results you posted for the Intel machine, have you compared it with anything else (like the default FP32 implementation for FP16/case without the intrinsics or the scalar FP16 version) so that we can better interpret the scores?
>> 
>> Hi @Bhavana-Kilambi , This patch adds **micro benchmarks** for all Float16 APIs optimized uptill now. **Macro-benchmarks** demonstrates use case for low precision semantic search primitives.
> 
> Hey,  for baseline we should not pass --enable-preview since it will prohibit following
> - Flat layout of Float16 arrays.
> - Creating valhalla specific IR needed for intrinsification.
> 
> Here are the first baseline numbers without --enable-primitive.
> 
> 
> Benchmark                                               (vectorDim)   Mode  Cnt     Score   Error   Units
> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2    99.424          ops/ms
> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2    97.498          ops/ms
> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2   525.360          ops/ms
> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    51.132          ops/ms
> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    46.921          ops/ms
> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2    97.186          ops/ms
> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2   583.051          ops/ms
> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    56.133          ops/ms
> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2    81.386          ops/ms
> Float16OpsBenchmark.getExponentBenchmark                       1024  thrpt    2  2257.619          ops/ms
> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2  3086.476          ops/ms
> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2  1718.411          ops/ms
> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2  1685.557          ops/ms
> Float16OpsBenchmark.maxBenchma...

> @jatin-bhateja , Thanks! While we are at the topic, can I ask if there are any real-world usescases or workloads that you are targeting the FP16 work for and maybe plan to do performance testing in the future?

Hey, we have some ideas, but for now my intent is to add micros/few demonstrating macro for each API we have accelerated.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378652894

From bkilambi at openjdk.org  Fri Sep 27 08:08:55 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 27 Sep 2024 08:08:55 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
Message-ID: <Xzf4D1nxnUyRB6bdVukK0AAyg49UR1AarE-2f3rGRbo=.304a1d7e-c879-45ee-98d3-91a0430fca5b@github.com>

On Thu, 26 Sep 2024 09:05:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Adding micro-benchmarks for various Float16 operations.
>> - Adding similarity search targeting micro-benchmarks.
>> 
>> Please find below the results of performance testing over Intel Xeon6 Granite Rapids:-
>> 
>> 
>> Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
>> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
>> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
>> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
>> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
>> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
>> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
>> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
>> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
>> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
>> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
>> Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
>> Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
>> Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
>> Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
>> Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
>> Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms
>> 
>> 
>> Best Regrads,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark

Thanks for sharing the numbers.  So in the first case, without the `--enable-preview` flag, it would have generated only scalar FP32 operations and in the second case where it is allowed to have flat array layout, it generates vector instructions but for FP32 right?

I am just running the tests on one of our machines. Can I just confirm in a while please? The tests otherwise look fine to me..

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378653699
PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378679007

From jbhateja at openjdk.org  Fri Sep 27 08:08:55 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Sep 2024 08:08:55 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <Xzf4D1nxnUyRB6bdVukK0AAyg49UR1AarE-2f3rGRbo=.304a1d7e-c879-45ee-98d3-91a0430fca5b@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <Xzf4D1nxnUyRB6bdVukK0AAyg49UR1AarE-2f3rGRbo=.304a1d7e-c879-45ee-98d3-91a0430fca5b@github.com>
Message-ID: <JzJQwJfM-e5Q61dh-1WiMQ-L1NwS7UiMgI_RZYE5ORs=.7ef68d86-aece-4a63-aea1-2f47fd0fd66f@github.com>

On Fri, 27 Sep 2024 08:00:04 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Thanks for sharing the numbers. So in the first case, without the `--enable-preview` flag, it would have generated only scalar FP32 operations and in the second case where it is allowed to have flat array layout, it generates vector instructions but for FP32 right?

Yes.

Let me know if you have other comments on micros,  or kindly approve if its good to integrate.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378660202

From dsimms at openjdk.org  Fri Sep 27 09:31:22 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 27 Sep 2024 09:31:22 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <IdwArU3NQWZDaYj2q2F0KpxVx6W_Dnxi0sj0ujC4LNs=.aa88a89b-bc7a-4af7-82eb-ecaa095ca673@github.com>

Merge jdk-23+26 and jdk-23+27

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

Commit messages:
 - Merge tag 'jdk-23+27' into lworld_merge_jdk_23_26
 - 8332920: C2: Partial Peeling is wrongly applied for CmpU with negative limit
 - 8333931: Problemlist serviceability/jvmti/vthread/CarrierThreadEventNotification
 - 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317
 - 8333722: Fix CompilerDirectives for non-compiler JVM variants
 - Merge tag 'jdk-23+26' into lworld_merge_jdk_23_26
 - 8333743: Change .jcheck/conf branches property to match valid branches
 - 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
 - 8333674: Disable CollectorPolicy.young_min_ergo_vm for PPC64
 - 8333647: C2 SuperWord: some additional PopulateIndex tests
 - ... and 141 more: https://git.openjdk.org/valhalla/compare/2c876c9c...45e8794a

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

Changes: https://git.openjdk.org/valhalla/pull/1257/files
  Stats: 26182 lines in 643 files changed: 16508 ins; 7046 del; 2628 mod
  Patch: https://git.openjdk.org/valhalla/pull/1257.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1257/head:pull/1257

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

From bkilambi at openjdk.org  Fri Sep 27 09:55:54 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 27 Sep 2024 09:55:54 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
Message-ID: <dCG3xdiHNDuTgRoNA9H9Pssdo3dTYj0WW7ZDdtjFH68=.c54f5b6d-1599-4024-81e9-358a67e6fd88@github.com>

On Thu, 26 Sep 2024 09:05:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Adding micro-benchmarks for various Float16 operations.
>> - Adding similarity search targeting micro-benchmarks.
>> 
>> Please find below the results of performance testing over Intel Xeon6 Granite Rapids:-
>> 
>> 
>> Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
>> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
>> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
>> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
>> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
>> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
>> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
>> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
>> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
>> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
>> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
>> Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
>> Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
>> Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
>> Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
>> Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
>> Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms
>> 
>> 
>> Best Regrads,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark

Looks good to me. Thanks.

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

Marked as reviewed by bkilambi (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1254#pullrequestreview-2333288171

From bkilambi at openjdk.org  Fri Sep 27 10:01:58 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Fri, 27 Sep 2024 10:01:58 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
Message-ID: <IKykgUjf32keyUCH_1K6zn-C3ul4P--g2BkVFYFmOgo=.cf30802d-ec5e-4c4d-878c-f6c6c6fb58f5@github.com>

On Thu, 26 Sep 2024 09:05:00 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Adding micro-benchmarks for various Float16 operations.
>> - Adding similarity search targeting micro-benchmarks.
>> 
>> Please find below the results of performance testing over Intel Xeon6 Granite Rapids:-
>> 
>> 
>> Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
>> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
>> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
>> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
>> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
>> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
>> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
>> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
>> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
>> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
>> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
>> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
>> Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
>> Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
>> Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
>> Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
>> Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
>> Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms
>> 
>> 
>> Best Regrads,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark

btw are you generating min instruction for max and max instruction for min in `c2_MacroAssembler_x86.cpp` ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2378907062

From jbhateja at openjdk.org  Fri Sep 27 19:42:52 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Sep 2024 19:42:52 GMT
Subject: [lworld+fp16] Integrated: 8341003: [lworld+fp16] Benchmarks for
 various Float16 operations
In-Reply-To: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
Message-ID: <kI1rk6zJePQcZTEy5bF8wsdVW9kV4m5P2fA1j-I9dqI=.3b68ac9a-ff80-4bba-b134-6fed3a3a1ffd@github.com>

On Thu, 26 Sep 2024 08:24:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Adding micro-benchmarks for various Float16 operations.
> - Adding similarity search targeting micro-benchmarks.
> 
> Please find below the results of performance testing over Intel Xeon6 Granite Rapids:-
> 
> 
> Benchmark                                               (vectorDim)   Mode  Cnt      Score   Error   Units
> Float16OpsBenchmark.absBenchmark                               1024  thrpt    2  25605.990          ops/ms
> Float16OpsBenchmark.addBenchmark                               1024  thrpt    2  19222.468          ops/ms
> Float16OpsBenchmark.cosineSimilarityDequantizedFP16            1024  thrpt    2    528.738          ops/ms
> Float16OpsBenchmark.cosineSimilarityDoubleRoundingFP16         1024  thrpt    2    660.018          ops/ms
> Float16OpsBenchmark.cosineSimilaritySingleRoundingFP16         1024  thrpt    2    659.799          ops/ms
> Float16OpsBenchmark.divBenchmark                               1024  thrpt    2   1974.039          ops/ms
> Float16OpsBenchmark.euclideanDistanceDequantizedFP16           1024  thrpt    2    743.071          ops/ms
> Float16OpsBenchmark.euclideanDistanceFP16                      1024  thrpt    2    682.440          ops/ms
> Float16OpsBenchmark.fmaBenchmark                               1024  thrpt    2  14052.422          ops/ms
> Float16OpsBenchmark.isFiniteBenchmark                          1024  thrpt    2   3851.234          ops/ms
> Float16OpsBenchmark.isInfiniteBenchmark                        1024  thrpt    2   1496.207          ops/ms
> Float16OpsBenchmark.isNaNBenchmark                             1024  thrpt    2   2778.822          ops/ms
> Float16OpsBenchmark.maxBenchmark                               1024  thrpt    2  19231.326          ops/ms
> Float16OpsBenchmark.minBenchmark                               1024  thrpt    2  19257.589          ops/ms
> Float16OpsBenchmark.mulBenchmark                               1024  thrpt    2  19236.498          ops/ms
> Float16OpsBenchmark.negateBenchmark                            1024  thrpt    2  25938.789          ops/ms
> Float16OpsBenchmark.sqrtBenchmark                              1024  thrpt    2   1759.051          ops/ms
> Float16OpsBenchmark.subBenchmark                               1024  thrpt    2  19242.967          ops/ms
> 
> 
> Best Regrads,
> Jatin

This pull request has now been integrated.

Changeset: 0ce9f0fa
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ce9f0fa94c1cd66aeb8ae4763ef59a1d6841dc9
Stats:     235 lines in 1 file changed: 235 ins; 0 del; 0 mod

8341003: [lworld+fp16] Benchmarks for various Float16 operations

Reviewed-by: bkilambi

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

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

From jbhateja at openjdk.org  Fri Sep 27 19:42:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 27 Sep 2024 19:42:51 GMT
Subject: [lworld+fp16] RFR: 8341003: [lworld+fp16] Benchmarks for various
 Float16 operations [v2]
In-Reply-To: <IKykgUjf32keyUCH_1K6zn-C3ul4P--g2BkVFYFmOgo=.cf30802d-ec5e-4c4d-878c-f6c6c6fb58f5@github.com>
References: <x5K0s4A3vxFybA6jX6MX9JSx1icX4f1d5sUgTJ-ARBo=.ea33557e-b544-4a36-a4a8-ee61e5c1dc00@github.com>
 <mqp5Ak4DsN8RFHMnwcniifCUFRCzNiOQag2YUKxnuS0=.219d2c21-b43b-4bca-b13d-437865cc7233@github.com>
 <IKykgUjf32keyUCH_1K6zn-C3ul4P--g2BkVFYFmOgo=.cf30802d-ec5e-4c4d-878c-f6c6c6fb58f5@github.com>
Message-ID: <O7JVVaXBrr5m9wshmvrL4ZFoL4ottoLSPKQVJJFaer0=.76218e1b-04aa-4e2a-9186-588c811be119@github.com>

On Fri, 27 Sep 2024 09:58:52 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> btw are you generating min instruction for max and max instruction for min in `c2_MacroAssembler_x86.cpp` ?

My bad, good catch, Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1254#issuecomment-2379936493

From vromero at openjdk.org  Sat Sep 28 03:09:19 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 28 Sep 2024 03:09:19 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v3]
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <CccQr4Wr5M-evyB_t09TCDSPEt-RTyAT6bwYTQu3HLA=.7844df7a-7616-4753-b268-7d84d310d640@github.com>

> javac is not generating null checks for runtime execution for method invocations and array writes

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

  experimental code review

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1251/files
  - new: https://git.openjdk.org/valhalla/pull/1251/files/aaf95a05..abb05f89

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

  Stats: 56 lines in 1 file changed: 32 ins; 10 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1251.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1251/head:pull/1251

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

From jbhateja at openjdk.org  Sun Sep 29 13:53:28 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 29 Sep 2024 13:53:28 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
Message-ID: <ZsoOXmLZNjSf1HepvzbrWwuxOngYvaPjo59iHwKf4Mg=.4c7c707b-37aa-422e-b9bd-2316f26a5233@github.com>

- Merge latest lworld into lworld+fp16
- Randomize input vectors for existing Float16 scalar intrinsic test.
- Fix min / max instruction sequence in x86 macro assembler.
- Remove redundant IR checks for ABS / NEGATE operation.

All Float16 and Valhalla test are passing with this merge.
Benchmarks performance is intact.

Best Regards,
Jatin

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

Commit messages:
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_lworld
 - Merge jdk
 - 8333189: Make sure clang on linux uses lld as linker
 - 8332919: SA PointerLocation needs to print a newline after dumping java thread info for JNI Local Ref
 - 8333013: Update vmTestbase/nsk/share/LocalProcess.java to don't use finalization
 - 8332259: JvmtiTrace::safe_get_thread_name fails if current thread is in native state
 - 8333149: ubsan : memset on nullptr target detected in jvmtiEnvBase.cpp get_object_monitor_usage
 - 8320999: RISC-V: C2 RotateLeftV
 - 8321543: Update NSS to version 3.96
 - 8331865: Consolidate size and alignment checks in LayoutPath
 - ... and 729 more: https://git.openjdk.org/valhalla/compare/0ce9f0fa...3298b00b

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

Changes: https://git.openjdk.org/valhalla/pull/1258/files
  Stats: 203024 lines in 4173 files changed: 116983 ins; 63386 del; 22655 mod
  Patch: https://git.openjdk.org/valhalla/pull/1258.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1258/head:pull/1258

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

From jbhateja at openjdk.org  Sun Sep 29 13:53:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 29 Sep 2024 13:53:29 GMT
Subject: [lworld+fp16] Integrated: Merge lworld
In-Reply-To: <ZsoOXmLZNjSf1HepvzbrWwuxOngYvaPjo59iHwKf4Mg=.4c7c707b-37aa-422e-b9bd-2316f26a5233@github.com>
References: <ZsoOXmLZNjSf1HepvzbrWwuxOngYvaPjo59iHwKf4Mg=.4c7c707b-37aa-422e-b9bd-2316f26a5233@github.com>
Message-ID: <ToeS81HrZEtD6Zxl9d9UkP3fp7Ga2YcejOVey7xyktA=.14f8ebf8-ecb2-4b5c-8455-bd008a8b865d@github.com>

On Sun, 29 Sep 2024 13:42:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Merge latest lworld into lworld+fp16
> - Randomize input vectors for existing Float16 scalar intrinsic test.
> - Fix min / max instruction sequence in x86 macro assembler.
> - Remove redundant IR checks for ABS / NEGATE operation.
> 
> All Float16 and Valhalla test are passing with this merge.
> Benchmarks performance is intact.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: f302bbcb
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f302bbcbe3bd8a17eb91633627023bbef6da5ffc
Stats:     203024 lines in 4173 files changed: 116983 ins; 63386 del; 22655 mod

Merge lworld

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

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

From dsimms at openjdk.org  Mon Sep 30 07:37:00 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 30 Sep 2024 07:37:00 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <IdwArU3NQWZDaYj2q2F0KpxVx6W_Dnxi0sj0ujC4LNs=.aa88a89b-bc7a-4af7-82eb-ecaa095ca673@github.com>
References: <IdwArU3NQWZDaYj2q2F0KpxVx6W_Dnxi0sj0ujC4LNs=.aa88a89b-bc7a-4af7-82eb-ecaa095ca673@github.com>
Message-ID: <_VEKtylyL2W4ua0A7BUmsZwdkJW67AT4uGZ54ILeCeQ=.cda318c3-d7fe-4c79-91a5-4bf758c232c0@github.com>

On Fri, 27 Sep 2024 09:25:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-23+26 and jdk-23+27

This pull request has now been integrated.

Changeset: 66e105ee
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/66e105ee7c5df9c293feb689625971c857fa4264
Stats:     26182 lines in 643 files changed: 16508 ins; 7046 del; 2628 mod

Merge jdk

Merge jdk-23+26 and jdk-23+27

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

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

From vromero at openjdk.org  Mon Sep 30 15:09:53 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Sep 2024 15:09:53 GMT
Subject: Integrated: Merge lworld
Message-ID: <Zi17MG8y1_EE5lHuAbfm5MxQqYGVtNA3bm05plNHeWY=.fd5af421-95f4-4d4f-8c9f-4da8c9e844ff@github.com>

Merge branch 'lworld' into lw5_merge_lworld
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - 8340027: [lw5] the ACC_STRICT flag is not being set for non-nullable static fields
 - Merge lworld
 - 8339357: [lw5] make non-nullable instance fields strict
 - 8339339: [lw5] javac should issue an error if a null-restricted field is left uninitialized, fix override related warnings
 - 8338910: [lw5] enhance the Signature attribute to represent nullability
 - Improve support for nullable types and arrays
 - 8339087: [lw5] remove parametric types related warnings
 - Add option to disable parametric nullness by default
 - Add inference support for nullable types
 - ... and 48 more: https://git.openjdk.org/valhalla/compare/2c876c9c...05858131

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

Changes: https://git.openjdk.org/valhalla/pull/1259/files
  Stats: 6584 lines in 105 files changed: 6473 ins; 10 del; 101 mod
  Patch: https://git.openjdk.org/valhalla/pull/1259.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1259/head:pull/1259

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

From vromero at openjdk.org  Mon Sep 30 15:09:56 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Sep 2024 15:09:56 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <Zi17MG8y1_EE5lHuAbfm5MxQqYGVtNA3bm05plNHeWY=.fd5af421-95f4-4d4f-8c9f-4da8c9e844ff@github.com>
References: <Zi17MG8y1_EE5lHuAbfm5MxQqYGVtNA3bm05plNHeWY=.fd5af421-95f4-4d4f-8c9f-4da8c9e844ff@github.com>
Message-ID: <Cr5mITcVSb9_ZVhV7dc21Prvg4ucxW1mp0YEPvxeVnU=.713d8d75-3eec-4694-8adc-e904b001d54a@github.com>

On Mon, 30 Sep 2024 15:01:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

This pull request has now been integrated.

Changeset: 6e55dbb2
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6e55dbb2b47861f7afc440944f8d84c9b19dcd49
Stats:     182898 lines in 3816 files changed: 107063 ins; 56214 del; 19621 mod

Merge lworld

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

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

From vromero at openjdk.org  Mon Sep 30 15:15:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Sep 2024 15:15:26 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v4]
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <VL7sOggrNZw0goWCxqUA3wqGPtChToMLOV0xeX1u9_Y=.9f10a716-7600-405c-a939-e2f88f4a88a0@github.com>

> javac is not generating null checks for runtime execution for method invocations and array writes

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

 - Merge branch 'lw5' into JDK-8340125
 - experimental code review
 - addressing review comments
 - Merge with remote branch
 - 8340125: [lw5] null checks are not being generated for method invocations and array writes
 - 8340125: [lw5] null checks are not being generated for method invocations and array writes

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

Changes: https://git.openjdk.org/valhalla/pull/1251/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1251&range=03
  Stats: 348 lines in 6 files changed: 293 ins; 22 del; 33 mod
  Patch: https://git.openjdk.org/valhalla/pull/1251.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1251/head:pull/1251

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

From rgiulietti at openjdk.org  Mon Sep 30 15:54:14 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Sep 2024 15:54:14 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16
Message-ID: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>

Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.

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

Commit messages:
 - 8341245: Add 'shortest length' toString() to Float16

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

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

From rgiulietti at openjdk.org  Mon Sep 30 15:56:52 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 30 Sep 2024 15:56:52 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16
In-Reply-To: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
Message-ID: <e4Q1acjGE9XOCR15Yj-NLgYjF3qbElnVBy7dK6-quXI=.b25ac21b-2843-4b72-b346-99601dc59436@github.com>

On Mon, 30 Sep 2024 15:48:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.

_All_ possible `Float16` outputs are thoroughly tested (in about 1 s).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1260#issuecomment-2383583690