From thartmann at openjdk.org  Wed Nov  1 05:58:38 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Nov 2023 05:58:38 GMT
Subject: [lworld] Integrated: 8315745: [lworld] "Meet Not Symmetric" failures
In-Reply-To: <JlKdpyZ8hRu0K8zhNcUL-XazjHvmsVNIsa8CgfvolTc=.c2d7bbf1-07bb-4c3e-a4b4-d31bd4509205@github.com>
References: <JlKdpyZ8hRu0K8zhNcUL-XazjHvmsVNIsa8CgfvolTc=.c2d7bbf1-07bb-4c3e-a4b4-d31bd4509205@github.com>
Message-ID: <2gbYWTjY6y3n7vRSKIpcpWj-xSXICE5PifxtPFhwnKg=.3221c478-ddf1-4327-9bef-95d3364dc371@github.com>

On Tue, 31 Oct 2023 18:11:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The following two independent issues showed up with stress testing.
> 
> 
> === Meet Not Symmetric ===
> t   =                   not flat:not null free:narrowoop: java/lang/Object:BotPTR *[int:0..max-2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *
> this=                   flat:not flat:not null free:top[int:0..max-2] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+bot):null_free *,iid=top (inline_depth=1)
> mt=(t meet this)=       not flat:not null free:narrowoop: java/lang/Object:BotPTR *[int:0..max-2] (java/lang/Cloneable,java/io/Serializable):NotNull:exact *
> t_dual=                 stable:flat:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:exact:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
> this_dual=              stable:bottom[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):NotNull * (inline_depth=-1)
> mt_dual=                stable:flat:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:exact:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
> mt_dual meet t_dual=    stable:flat:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:exact:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop)
> mt_dual meet this_dual= stable:bottom[int:max-2..0] (java/lang/Cloneable,java/io/Serializable):NotNull * (inline_depth=-1)
> 
> 
> The problem is that `mt_dual meet this_dual != this_dual` with `mt_dual->_field_offset == TOP` and `this_dual->_field_offset == TOP` because the `_field_offset` of the result is `BOTTOM`. The fix is to adjust the code in `TypeAryPtr::xmeet_helper` to not set the field offset from `TOP` to `BOTTOM`.
> 
> 
> === Meet Not Symmetric ===
> t   =                   stable:flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop) (speculative=stable:flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDepthTop)[int:max..0] (java/lang/Cloneable,java/io/Serializable):AnyNull:flat(+top):null_free *,iid=top (inline_depth=InlineDepthTop))
> this=                   stable:flat:not flat:not null free:narrowoop: java/lang/Object:TopPTR *,iid=top (inline_depth=InlineDe...

This pull request has now been integrated.

Changeset: d5a1584e
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d5a1584e18782926b941ebe19d8d00f5fa8736de
Stats:     14 lines in 1 file changed: 8 ins; 1 del; 5 mod

8315745: [lworld] "Meet Not Symmetric" failures

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

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


From thartmann at openjdk.org  Wed Nov  1 08:38:57 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Nov 2023 08:38:57 GMT
Subject: [lworld] RFR: 8315744: [lworld] SubTypeCheckNode::sub asserts with
 "should be not null"
Message-ID: <T2XiCsiBmZnvTpsPgq1OgXHg9vaXaQV92Cvpe6heQAg=.edcae5cd-a174-44b2-be54-c804a7ef8de5@github.com>

[JDK-8303279](https://bugs.openjdk.org/browse/JDK-8303279) added an assert that we now hit in Valhalla because the subtype of a `SubTypeCheckNode` is not known to be non-null. The problem is that when pushing InlineTypeNodes through Phis, we lose track of the fact that the Phi is non-null. There's some existing logic for that but it's broken.

Thanks,
Tobias

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

Commit messages:
 - 8315744: [lworld] SubTypeCheckNode::sub asserts with "should be not null"

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

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


From thartmann at openjdk.org  Wed Nov  1 12:04:29 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 1 Nov 2023 12:04:29 GMT
Subject: [lworld] Integrated: 8315744: [lworld] SubTypeCheckNode::sub asserts
 with "should be not null"
In-Reply-To: <T2XiCsiBmZnvTpsPgq1OgXHg9vaXaQV92Cvpe6heQAg=.edcae5cd-a174-44b2-be54-c804a7ef8de5@github.com>
References: <T2XiCsiBmZnvTpsPgq1OgXHg9vaXaQV92Cvpe6heQAg=.edcae5cd-a174-44b2-be54-c804a7ef8de5@github.com>
Message-ID: <jMJBir61DOaqhj1ag8jhROCzG6AZK0QcH8OEMyMaVaI=.e967f88f-7322-4944-8726-72eec690a8c6@github.com>

On Wed, 1 Nov 2023 08:31:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8303279](https://bugs.openjdk.org/browse/JDK-8303279) added an assert that we now hit in Valhalla because the subtype of a `SubTypeCheckNode` is not known to be non-null. The problem is that when pushing InlineTypeNodes through Phis, we lose track of the fact that the Phi is non-null. There's some existing logic for that but it's broken.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: c328c5fc
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c328c5fcd8e91084ba0da65781e935bec1df3263
Stats:     15 lines in 2 files changed: 0 ins; 9 del; 6 mod

8315744: [lworld] SubTypeCheckNode::sub asserts with "should be not null"

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

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


From vromero at openjdk.org  Wed Nov  1 18:59:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Nov 2023 18:59:47 GMT
Subject: Integrated: Merge lworld
Message-ID: <92EvR5w_mgNmZbBS-a0Yto8x1qqxSbmm4U-g4hW0GUU=.1e6c2b30-7c1b-4ebf-8c8b-f1dc5d291a0b@github.com>

Merge branch 'lworld' into lw5_merge_lworld

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - Merge lworld
 - 8318117: [lw5] create a switch for null-restricted types
 - 8316628: [lw5] remove vnew, aconst_init, and withfield
 - Merge lworld
 - 8316561: [lw5] class file attribute NullRestricted shouldn't be generated for arrays
 - 8316325: [lw5] sync javac with the current JVMS, particularly assertions on new class attributes
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - ... and 25 more: https://git.openjdk.org/valhalla/compare/c328c5fc...3410f1dd

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

Changes: https://git.openjdk.org/valhalla/pull/945/files
  Stats: 8248 lines in 294 files changed: 4475 ins; 2616 del; 1157 mod
  Patch: https://git.openjdk.org/valhalla/pull/945.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/945/head:pull/945

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


From vromero at openjdk.org  Wed Nov  1 18:59:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Nov 2023 18:59:47 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <92EvR5w_mgNmZbBS-a0Yto8x1qqxSbmm4U-g4hW0GUU=.1e6c2b30-7c1b-4ebf-8c8b-f1dc5d291a0b@github.com>
References: <92EvR5w_mgNmZbBS-a0Yto8x1qqxSbmm4U-g4hW0GUU=.1e6c2b30-7c1b-4ebf-8c8b-f1dc5d291a0b@github.com>
Message-ID: <D_3tuBRrJ7N3JI7bqiiRTkQoTfc5ZMxPmOWCEVlcB3Y=.b4d5dd97-d711-42b6-b4e8-2695303cd90c@github.com>

On Wed, 1 Nov 2023 18:52:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld

This pull request has now been integrated.

Changeset: 11ad37d5
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/11ad37d58b872397292b8a29455c54091935e6dc
Stats:     29 lines in 3 files changed: 8 ins; 10 del; 11 mod

Merge lworld

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

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


From thartmann at openjdk.org  Mon Nov  6 12:48:06 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Nov 2023 12:48:06 GMT
Subject: [lworld] RFR: 8319528: [lworld] Remove T_PRIMITIVE_OBJECT from JIT
 code
Message-ID: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>

The JIT code does not need `T_PRIMITIVE_OBJECT` anymore because there are now other ways to determine if a type is null-free / flattenable. I replaced all usages in C1 and C2.

I also changed the calling convention code to now use `T_METADATA` / `T_VOID` delimiters for scalarized arguments instead of `T_PRIMITIVE_OBJECT` / `T_VOID`. We still need to handle `T_PRIMITIVE_OBJECT` in the signature though until Q-types go away but most of the remaining usages are trivial to remove.

Best regards,
Tobias

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

Commit messages:
 - More removals
 - Easy removals

Changes: https://git.openjdk.org/valhalla/pull/946/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319528
  Stats: 227 lines in 46 files changed: 24 ins; 91 del; 112 mod
  Patch: https://git.openjdk.org/valhalla/pull/946.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/946/head:pull/946

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


From thartmann at openjdk.org  Mon Nov  6 12:54:08 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Nov 2023 12:54:08 GMT
Subject: [lworld] RFR: 8319528: [lworld] Remove T_PRIMITIVE_OBJECT from JIT
 code [v2]
In-Reply-To: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
References: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
Message-ID: <8KwwZv0dNiVF0vJ-ZAtYZwcGu8y5YCLXusu31LYdO3Q=.c5537c8a-4ab9-4f2e-8c84-6ef6878f5460@github.com>

> The JIT code does not need `T_PRIMITIVE_OBJECT` anymore because there are now other ways to determine if a type is null-free / flattenable. I replaced all usages in C1 and C2.
> 
> I also changed the calling convention code to now use `T_METADATA` / `T_VOID` delimiters for scalarized arguments instead of `T_PRIMITIVE_OBJECT` / `T_VOID`. We still need to handle `T_PRIMITIVE_OBJECT` in the signature though until Q-types go away but most of the remaining usages are trivial to remove.
> 
> Best regards,
> Tobias

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

  Restored handling in c_calling_convention

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/946/files
  - new: https://git.openjdk.org/valhalla/pull/946/files/dff12a99..59b0f5fc

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

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

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


From thartmann at openjdk.org  Mon Nov  6 13:07:18 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Nov 2023 13:07:18 GMT
Subject: [lworld] RFR: 8319528: [lworld] Remove T_PRIMITIVE_OBJECT from JIT
 code [v3]
In-Reply-To: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
References: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
Message-ID: <optIvQaY1tRg1cXniPMQbGLp601A5npgG3asxAaQ12U=.fa45dbe8-53f2-4c72-af1f-01a4d61c85e3@github.com>

> The JIT code does not need `T_PRIMITIVE_OBJECT` anymore because there are now other ways to determine if a type is null-free / flattenable. I replaced all usages in C1 and C2.
> 
> I also changed the calling convention code to now use `T_METADATA` / `T_VOID` delimiters for scalarized arguments instead of `T_PRIMITIVE_OBJECT` / `T_VOID`. We still need to handle `T_PRIMITIVE_OBJECT` in the signature though until Q-types go away but most of the remaining usages are trivial to remove.
> 
> Best regards,
> Tobias

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

 - Merge branch 'lworld' into basic_type_cleanup
 - Restored handling in c_calling_convention
 - More removals
 - Easy removals

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/946/files
  - new: https://git.openjdk.org/valhalla/pull/946/files/59b0f5fc..fd69da11

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

  Stats: 29 lines in 3 files changed: 8 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/946.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/946/head:pull/946

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


From thartmann at openjdk.org  Mon Nov  6 15:46:52 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 6 Nov 2023 15:46:52 GMT
Subject: [lworld] RFR: 8319528: [lworld] Remove T_PRIMITIVE_OBJECT from JIT
 code [v4]
In-Reply-To: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
References: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
Message-ID: <aYa6QtswqNM4zfJL_mSdUfyjhWKbWVs89vLionkaZH0=.1d833635-0909-447b-bbff-14cb64e1af13@github.com>

> The JIT code does not need `T_PRIMITIVE_OBJECT` anymore because there are now other ways to determine if a type is null-free / flattenable. I replaced all usages in C1 and C2.
> 
> I also changed the calling convention code to now use `T_METADATA` / `T_VOID` delimiters for scalarized arguments instead of `T_PRIMITIVE_OBJECT` / `T_VOID`. We still need to handle `T_PRIMITIVE_OBJECT` in the signature though until Q-types go away but most of the remaining usages are trivial to remove.
> 
> Best regards,
> Tobias

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

  Bug fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/946/files
  - new: https://git.openjdk.org/valhalla/pull/946/files/fd69da11..7ef79452

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

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

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


From thartmann at openjdk.org  Tue Nov  7 08:02:03 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 7 Nov 2023 08:02:03 GMT
Subject: [lworld] Integrated: 8319528: [lworld] Remove T_PRIMITIVE_OBJECT from
 JIT code
In-Reply-To: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
References: <epg15HBJ2oqCLoX_LLeby65GSDi9VzYkieC53sjh1Kc=.ee991784-d95c-46c9-acde-55c463a6b158@github.com>
Message-ID: <xzDBtYZpcZjrW1ZCY7Q7TqbI55SM88yotfVGlQ8Ewlc=.6aa815fb-c26e-4354-8f8a-311ae27a21a7@github.com>

On Mon, 6 Nov 2023 12:43:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The JIT code does not need `T_PRIMITIVE_OBJECT` anymore because there are now other ways to determine if a type is null-free / flattenable. I replaced all usages in C1 and C2.
> 
> I also changed the calling convention code to now use `T_METADATA` / `T_VOID` delimiters for scalarized arguments instead of `T_PRIMITIVE_OBJECT` / `T_VOID`. We still need to handle `T_PRIMITIVE_OBJECT` in the signature though until Q-types go away but most of the remaining usages are trivial to remove.
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: d62c55dd
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d62c55dd99c4050f620c2626438cf83c1f08e022
Stats:     226 lines in 45 files changed: 24 ins; 91 del; 111 mod

8319528: [lworld] Remove T_PRIMITIVE_OBJECT from JIT code

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

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


From dsimms at openjdk.org  Mon Nov 13 10:21:15 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 13 Nov 2023 10:21:15 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <jRQ2Tl52buZOwah3xt5PUCQUQTfW8zYeG6d7A0hugeA=.9c36f59e-0ff8-4409-be87-0ea9af20edb7@github.com>

Merge jdk-22+12

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

Commit messages:
 - Fix for JDK-8308984 using a register map reg (rcx)
 - Merge tag 'jdk-22+12' into lworld_merge_jdk_22_12
 - 8314734: Remove unused field TypeVariableImpl.EMPTY_ANNOTATION_ARRAY
 - 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters
 - 8314679: SA fails to properly attach to JVM after having just detached from a different JVM
 - 8280743: HSDB "Monitor Cache Dump" command might throw NPE
 - 8175874: Update Security.insertProviderAt to specify behavior when requested position is out of range.
 - 8294535: Add screen capture functionality to PassFailJFrame
 - 8314746: Remove unused private put* methods from DirectByteBufferR
 - 8314810: (fs) java/nio/file/Files/CopyInterference.java should use TestUtil::supportsLinks
 - ... and 75 more: https://git.openjdk.org/valhalla/compare/c328c5fc...742a6aed

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

Changes: https://git.openjdk.org/valhalla/pull/948/files
  Stats: 6123 lines in 348 files changed: 4249 ins; 730 del; 1144 mod
  Patch: https://git.openjdk.org/valhalla/pull/948.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/948/head:pull/948

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


From dsimms at openjdk.org  Mon Nov 13 13:24:34 2023
From: dsimms at openjdk.org (David Simms)
Date: Mon, 13 Nov 2023 13:24:34 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <jRQ2Tl52buZOwah3xt5PUCQUQTfW8zYeG6d7A0hugeA=.9c36f59e-0ff8-4409-be87-0ea9af20edb7@github.com>
References: <jRQ2Tl52buZOwah3xt5PUCQUQTfW8zYeG6d7A0hugeA=.9c36f59e-0ff8-4409-be87-0ea9af20edb7@github.com>
Message-ID: <-VGIX4v2pkVuH4UXc30PBR-9yXLCzWh1ui5VxaUIVQY=.f404c427-4ebf-4324-8672-a6e604234210@github.com>

On Mon, 13 Nov 2023 10:13:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+12

This pull request has now been integrated.

Changeset: 6e31ad2f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6e31ad2fddbb24c138f1684c88943a8e509844f5
Stats:     6123 lines in 348 files changed: 4249 ins; 730 del; 1144 mod

Merge jdk

Merge jdk-22+12

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

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


From dsimms at openjdk.org  Tue Nov 14 09:48:39 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 14 Nov 2023 09:48:39 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <TpWBAUdyw-RLvUnIecmnJXJ64v3IEYw4lg4Z72XxprM=.e0753bcc-11a9-4cef-9722-a7f87d8d4d03@github.com>

Merge jdk-22+13

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

Commit messages:
 - Logical merge fix
 - Merge tag 'jdk-22+13' into lworld_merge_jdk_22_13
 - 8314651: G1: Fix -Wconversion warnings in static fields of HeapRegion
 - 8315206: RISC-V: hwprobe query is_set return wrong value
 - 8314024: SIGSEGV in PhaseIdealLoop::build_loop_late_post_work due to bad immediate dominator info
 - 8315213: java/lang/ProcessHandle/TreeTest.java test enhance output of children
 - 8315214: Do not run sun/tools/jhsdb tests concurrently
 - 8314056: Remove runtime platform check from frem/drem
 - 8312428: PKCS11 tests fail with NSS 3.91
 - 8189685: need PerfMemory class update and a volatile_static_field support in VMStructs
 - ... and 57 more: https://git.openjdk.org/valhalla/compare/6e31ad2f...6a3d5a5a

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

Changes: https://git.openjdk.org/valhalla/pull/950/files
  Stats: 7855 lines in 278 files changed: 5615 ins; 927 del; 1313 mod
  Patch: https://git.openjdk.org/valhalla/pull/950.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/950/head:pull/950

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


From thartmann at openjdk.org  Tue Nov 14 14:04:23 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 14 Nov 2023 14:04:23 GMT
Subject: [lworld] RFR: 8319967: [lworld] TypeAryPtr::cast_to_not_null_free hits
 assert(!not_null_free || !is_flat()) failed: inconsistency
Message-ID: <uqe2I0gpoZT3YWZfFASjKU24QvGJo-vBeY0R758Xpb4=.68449288-78f5-4da7-8b5e-d3a3702e57e0@github.com>

I hit this very intermittent failure with stress testing and was able to extract a simple test. [JDK-8227634](https://bugs.openjdk.org/browse/JDK-8227634) added the following optimization: When casting an element loaded from an array to a known type, we use that type information to set not-null-free not-flat properties of the array (also when storing an object of a known type to an array). Now that optimization gets confused when we load a field of an element from a flat array. In the failing case (see `TestArrays::test150`), we load an Object field from a flat array element and cast it to String. The optimization then incorrectly assumes that we are casting the (primitive type) element and casts the array to not-flat which fails because the array is known to be flat. The actual fix is the additional `!ary_t->is_flat()` check in `GraphKit::gen_checkcast`. The rest is refactoring that changes `flat_array` to `flat_in_array` which is more precise.

Thanks,
Tobias

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

Commit messages:
 - 8319967: [lworld] TypeAryPtr::cast_to_not_null_free hits assert(\!not_null_free || \!is_flat()) failed: inconsistency

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

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


From jbhateja at openjdk.org  Tue Nov 14 15:03:32 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 14 Nov 2023 15:03:32 GMT
Subject: [lworld+vector] RFR: 8319971: [lworld+vector] Fallback implementation
 cleanups.
Message-ID: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>

Some cleanup related to Unsafe APIs based fallback implementation.

Best Regards,
Jatin

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

Commit messages:
 - jchecks fix
 - 8319971: [lworld+vector] Fallback implementation cleanups.

Changes: https://git.openjdk.org/valhalla/pull/949/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=949&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319971
  Stats: 895 lines in 39 files changed: 104 ins; 28 del; 763 mod
  Patch: https://git.openjdk.org/valhalla/pull/949.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/949/head:pull/949

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


From jbhateja at openjdk.org  Tue Nov 14 15:07:54 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 14 Nov 2023 15:07:54 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable intrinsification
 of Unsafe.finishPrivateBuffer.
Message-ID: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>

Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 

In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.

New behavior of unsafe inline expanders
1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.

This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.

In addition compiler is now preventing elimination of allocation in larval state.

Validation Status:-
  - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.

Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - Regression fixes
 - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.

Changes: https://git.openjdk.org/valhalla/pull/952/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=952&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319972
  Stats: 77 lines in 7 files changed: 21 ins; 23 del; 33 mod
  Patch: https://git.openjdk.org/valhalla/pull/952.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/952/head:pull/952

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


From thartmann at openjdk.org  Tue Nov 14 16:29:02 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 14 Nov 2023 16:29:02 GMT
Subject: [lworld] Integrated: 8319967: [lworld]
 TypeAryPtr::cast_to_not_null_free hits assert(!not_null_free || !is_flat())
 failed: inconsistency
In-Reply-To: <uqe2I0gpoZT3YWZfFASjKU24QvGJo-vBeY0R758Xpb4=.68449288-78f5-4da7-8b5e-d3a3702e57e0@github.com>
References: <uqe2I0gpoZT3YWZfFASjKU24QvGJo-vBeY0R758Xpb4=.68449288-78f5-4da7-8b5e-d3a3702e57e0@github.com>
Message-ID: <IpEL2H7GYmLOC7sz9R0bGGVa24LJ4S68p6VhYTsfFlk=.835e9f58-7b6c-436b-b77f-3d065f9445e3@github.com>

On Tue, 14 Nov 2023 13:57:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I hit this very intermittent failure with stress testing and was able to extract a simple test. [JDK-8227634](https://bugs.openjdk.org/browse/JDK-8227634) added the following optimization: When casting an element loaded from an array to a known type, we use that type information to set not-null-free not-flat properties of the array (also when storing an object of a known type to an array). Now that optimization gets confused when we load a field of an element from a flat array. In the failing case (see `TestArrays::test150`), we load an Object field from a flat array element and cast it to String. The optimization then incorrectly assumes that we are casting the (primitive type) element and casts the array to not-flat which fails because the array is known to be flat. The actual fix is the additional `!ary_t->is_flat()` check in `GraphKit::gen_checkcast`. The rest is refactoring that changes `flat_array` to `flat_in_array` which is more precise.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 6be441a4
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6be441a4decbd85cd51c26e1699a34bbc2281d24
Stats:     111 lines in 13 files changed: 11 ins; 1 del; 99 mod

8319967: [lworld] TypeAryPtr::cast_to_not_null_free hits assert(!not_null_free || !is_flat()) failed: inconsistency

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

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


From xgong at openjdk.org  Wed Nov 15 02:29:55 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 02:29:55 GMT
Subject: [lworld+vector] RFR: 8319971: [lworld+vector] Fallback
 implementation cleanups.
In-Reply-To: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
References: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
Message-ID: <Eo4YvKRj_0H93ZPRPGfhRLnd5DArxEUUHb0pc5jZoaE=.9da4b662-fe29-4b51-b67d-68128f15288f@github.com>

On Mon, 13 Nov 2023 16:08:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Some cleanup related to Unsafe APIs based fallback implementation.
> 
> Best Regards,
> Jatin

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 59:

> 57: 
> 58:     static final Unsafe U = Unsafe.getUnsafe();
> 59: 

Can we reuse `U` defined in `ByteVector.java` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/949#discussion_r1393554013


From xgong at openjdk.org  Wed Nov 15 04:03:00 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 04:03:00 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <s9WoWqk8bvQJJ1m685yibE5AfjZ-VrsY_h_bJQ1YAUI=.542892a7-c9e4-47f4-a5f9-4a6b634dd7fc@github.com>

On Tue, 14 Nov 2023 15:00:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Nice job @jatin-bhateja! Verified on NEON with `-XX:+DeoptimizeALot`! 

But I still have some questions that I don't understand very well, together with the reason that you disabled the intrinsify to `finishPrivateBuffer` before.
1. Here is what I pasted from the previous PR:
> Disable inline expansion of Unsafe.finishPrivateBuffer. This is fixing the incorrectness problems seen with masked operations loop e.g.
vt = newPayload();
vt = Unsafe.makePrivateBuffer(vt);
for (int i = 0; i < Double128.length; i++) {
     if (mask[i]) {
          Unsafe.putDouble(vt, apply(src[i]));
     }
}
Unsafe.putDouble() modifies memory state of an InlineTypeNode by storing a new value in payload buffer, it also re-materializes InlineTypeNode from modified memory state. This causes incorrectness if second mask value is false as entire payload is overwritten with default value and earlier lane updates are over-written. In order to be safe, disabling intrinsification of finishPrivateBuffer if incoming argument node is of VectorPayload* type, so that it always receive updated buffer argument.

You mean this causes incorrectness if second mask value is false because the entire payload is overwritten with default value. Do you mean it is optimized to the default value? But if not all its fields are `0`, how this happen? And I cannot see the direct relationship with intrinsifying of `finishPrivateBuffer`. Could you please clarify more?

2. In this PR, I understand the main fixing is avoiding the scalarization of `InlineType` buffer if it is in larval state, right? I guess this is the main cause of the jtreg regression with `-XX:+DeoptimizeALot`? But I still cannot understand the direct relationship with intrinsifying of `finishPrivateBuffer`. Do you mean with the elimination of scalarization for larval state buffer, the above issue in point 1 is gone?

Going through with this PR now. I still need time learning it. 

Thanks,
Xiaohong

src/hotspot/share/opto/library_call.cpp line 2634:

> 2632:     if (alloc != nullptr) {
> 2633:       assert(alloc->_larval, "InlineType instance must be in _larval state for unsafe put operation.\n");
> 2634:     }

Can we move this check after line2397 (https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/library_call.cpp#L2397), and remove the same assertion between line2351-2359 (https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/library_call.cpp#L2351) ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1811772053
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1393600527


From xgong at openjdk.org  Wed Nov 15 04:13:02 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 04:13:02 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>

On Tue, 14 Nov 2023 15:00:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

> 1022: 
> 1023:   store(kit, alloc_oop, alloc_oop, vk);
> 1024:   return alloc_oop;

Why not setting the oop to allocated buffer and return the `InlineTypeNode` ? We may have optimizations for Unsafe access for `InlineTypeNode` input.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1393611657


From xgong at openjdk.org  Wed Nov 15 06:14:46 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 06:14:46 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <R4iamBDuzosipSYB22t0mUzsKAfYeLX5zQD0dPuZYuY=.97e40dcf-0f2f-47da-8cd8-db85722290ab@github.com>

On Tue, 14 Nov 2023 15:00:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

I see the new IR framework check failures in test `compiler/valhalla/inlinetypes/TestIntrinsics.java` with this PR on NEON. 
See the log below:

One or more @IR rules failed:

Failed IR Rules (1) of Methods (1)
----------------------------------
1) Method "public void compiler.valhalla.inlinetypes.TestIntrinsics.test22(compiler.valhalla.inlinetypes.MyValue1)" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeatureOr={}, applyIfCPUFeature={}, counts={}, failOn={"_#CALL_UNSAFE#I_", "_#ALLOC#I_"}, applyIfAnd={}, applyIfOr={}, applyIfNot={})"
     > Phase "PrintOptoAssembly":
       - failOn: Graph contains forbidden nodes:
         * Constraint 2: "(.*precise compiler/valhalla/inlinetypes/MyValue.*\R(.*(?i:mov|xorl|nop|spill).*\R)*.*_new_instance_Java)"
           - Matched forbidden node:
             * 618 +   mov  R1, precise compiler/valhalla/inlinetypes/MyValue1: 0x0000ffff3c5ce718 (compiler/valhalla/inlinetypes/MyInterface):Constant:exact * # ptr
               624     mov R2, #1       # int
               628     call,static 0x0000ffff8bddf240   // ==>  wrapper for: _new_instance_Java

>>> Check stdout for compilation output of the failed methods

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1811866137


From xgong at openjdk.org  Wed Nov 15 06:42:59 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 06:42:59 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>

On Tue, 14 Nov 2023 15:00:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?

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

> 1966:         // and transition the allocation into larval state.
> 1967:         ret = ret->as_InlineType()->make_larval(this);
> 1968:       }

As my understanding, the expected behavior is compiler should guarantee the returned `InlineTypeNode` has a larval state buffer after calling `makePrivateBuffer()`, right? Why do we still need this here?

src/hotspot/share/opto/library_call.cpp line 2667:

> 2665:      return false;
> 2666:   }
> 2667:   const TypeInstPtr* ptr = buffer->bottom_type()->isa_instptr();

Please move this before line-2680.

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

> 962:   if (alloc->_larval) {
> 963:     return false;
> 964:   }

Does it need to also add such checks in `InlineTypeNode::make_scalar_in_safepoints` ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1811888621
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1393699005
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1393706966
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1393709519


From xgong at openjdk.org  Wed Nov 15 07:40:22 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 07:40:22 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
Message-ID: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>

Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.

Here is the log:


 Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
 assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match

 JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
 Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
 Problematic frame:
 V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8


The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.

This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.

This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).

[1] https://github.com/openjdk/valhalla/pull/918

Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.

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

Commit messages:
 - 8319945: [lworld+vector] Fix vector api jtreg crash with "-XX:-EnableVectorSupport"

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

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


From xgong at openjdk.org  Wed Nov 15 08:59:54 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 15 Nov 2023 08:59:54 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <XSPoMyX2x0QX4H-ypowEOxsznnSE8OSkb1ZCL7jSSQQ=.f54464c9-3a78-42b9-89e2-7a139909621d@github.com>

On Tue, 14 Nov 2023 15:00:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

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

> 1037:   kit->insert_mem_bar(Op_MemBarStoreStore, alloc->proj_out_or_null(AllocateNode::RawAddress));
> 1038: 
> 1039:   return InlineTypeNode::make_from_oop(kit, obj, vk->inline_klass(), !vk->maybe_null());

I think this is the root cause of incorrectness in https://bugs.openjdk.org/browse/JDK-8317659. The field values of the `InlineTypeNode` are not updated from the changed oop buffer.

So can we just make `Unsafe.finishPrivateBuffer()` accept `InlineTypeNode` like before, checking its oop is in larval state, and return `make_from_oop()` here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1393865533


From dsimms at openjdk.org  Wed Nov 15 09:06:57 2023
From: dsimms at openjdk.org (David Simms)
Date: Wed, 15 Nov 2023 09:06:57 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <TpWBAUdyw-RLvUnIecmnJXJ64v3IEYw4lg4Z72XxprM=.e0753bcc-11a9-4cef-9722-a7f87d8d4d03@github.com>
References: <TpWBAUdyw-RLvUnIecmnJXJ64v3IEYw4lg4Z72XxprM=.e0753bcc-11a9-4cef-9722-a7f87d8d4d03@github.com>
Message-ID: <pMcd1NP8U2GotcF2vL0nkVb0RxQLlL-bzC_D1aisvug=.6cb60807-4488-404d-abde-354e2e2480c0@github.com>

On Tue, 14 Nov 2023 09:39:37 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+13

This pull request has now been integrated.

Changeset: 481893b8
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/481893b8fbbee8a957a4a7fcba3545eff2293e62
Stats:     7855 lines in 278 files changed: 5615 ins; 927 del; 1313 mod

Merge jdk

Merge jdk-22+13

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

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


From dsimms at openjdk.org  Thu Nov 16 05:58:40 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 16 Nov 2023 05:58:40 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <omK0-uh6IV5taC41bqr4X5c-KsNlhv5Vf8qoS23uzW4=.827f2c35-ed0b-4aef-9cf7-4236fd11c5a8@github.com>

* Merge jdk-22+14
* @TobiHartmann solved the JDK-8314997 conflict

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

Commit messages:
 - @TobiHartmann solved the JDK-8314997 conflict
 - Merge tag 'jdk-22+14' into lworld_merge_jdk_22_14
 - 8311964: Some jtreg tests failing on x86 with error 'unrecognized VM options' (C2 flags)
 - 8315689: G1: Remove unused init_hash_seed
 - 8315579: SPARC64 builds are broken after JDK-8304913
 - 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API
 - 8288660: JavaDoc should be more helpful if it doesn't recognize a tag
 - 8315377: C2: assert(u->find_out_with(Op_AddP) == nullptr) failed: more than 2 chained AddP nodes?
 - 8315648: Add test for JDK-8309979 changes
 - 8315612: RISC-V: intrinsic for unsignedMultiplyHigh
 - ... and 78 more: https://git.openjdk.org/valhalla/compare/481893b8...76972900

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

Changes: https://git.openjdk.org/valhalla/pull/954/files
  Stats: 13586 lines in 348 files changed: 9699 ins; 2425 del; 1462 mod
  Patch: https://git.openjdk.org/valhalla/pull/954.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/954/head:pull/954

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


From jbhateja at openjdk.org  Thu Nov 16 06:24:19 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 06:24:19 GMT
Subject: [lworld+vector] RFR: 8319971: [lworld+vector] Fallback
 implementation cleanups. [v2]
In-Reply-To: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
References: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
Message-ID: <l7dCRJzBv8tAna7a5SRhDDQ2eXiKoEhK_IaxI-yUT1Q=.b15c12c1-07b3-4dae-ad94-735d40b7a9f3@github.com>

> Some cleanup related to Unsafe APIs based fallback implementation.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Removing redundant definition.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/949/files
  - new: https://git.openjdk.org/valhalla/pull/949/files/d2ba4208..c9fbf66c

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

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

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


From jbhateja at openjdk.org  Thu Nov 16 07:22:53 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 07:22:53 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
Message-ID: <-tNM03h6Tf5fXimgRP7Q0ctIdeiqnRF4avbdXUz3pRg=.f8ea31e0-0ad9-45e2-b8f4-c91dd82cee0e@github.com>

On Wed, 15 Nov 2023 06:22:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
>> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
>> 
>> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
>> 
>> New behavior of unsafe inline expanders
>> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
>> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
>> 
>> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
>> 
>> In addition compiler is now preventing elimination of allocation in larval state.
>> 
>> Validation Status:-
>>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> src/hotspot/share/opto/graphKit.cpp line 1968:
> 
>> 1966:         // and transition the allocation into larval state.
>> 1967:         ret = ret->as_InlineType()->make_larval(this);
>> 1968:       }
> 
> As my understanding, the expected behavior is compiler should guarantee the returned `InlineTypeNode` has a larval state buffer after calling `makePrivateBuffer()`, right? Why do we still need this here?

This it to handle larval state propagation if makePrivateBuffer is not inline expanded, in such a case native implementation gets called and at compile time there is not way to detect larval state.

> src/hotspot/share/opto/macro.cpp line 964:
> 
>> 962:   if (alloc->_larval) {
>> 963:     return false;
>> 964:   }
> 
> Does it need to also add such checks in `InlineTypeNode::make_scalar_in_safepoints` ?

With new behavior, a value object in larval state is already allocated over heap and should not be scalarized to InlineTypeNode.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395247961
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395248178


From jbhateja at openjdk.org  Thu Nov 16 07:33:51 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 07:33:51 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <XSPoMyX2x0QX4H-ypowEOxsznnSE8OSkb1ZCL7jSSQQ=.f54464c9-3a78-42b9-89e2-7a139909621d@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <XSPoMyX2x0QX4H-ypowEOxsznnSE8OSkb1ZCL7jSSQQ=.f54464c9-3a78-42b9-89e2-7a139909621d@github.com>
Message-ID: <3IdfnSJFbtXITwmSe-dNvy1-OsvYPZ9Cm8G_7gTPB4k=.68df2415-0624-4383-8870-8419634c7456@github.com>

On Wed, 15 Nov 2023 08:57:34 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
>> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
>> 
>> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
>> 
>> New behavior of unsafe inline expanders
>> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
>> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
>> 
>> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
>> 
>> In addition compiler is now preventing elimination of allocation in larval state.
>> 
>> Validation Status:-
>>   - All the VectorAPI JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> src/hotspot/share/opto/inlinetypenode.cpp line 1039:
> 
>> 1037:   kit->insert_mem_bar(Op_MemBarStoreStore, alloc->proj_out_or_null(AllocateNode::RawAddress));
>> 1038: 
>> 1039:   return InlineTypeNode::make_from_oop(kit, obj, vk->inline_klass(), !vk->maybe_null());
> 
> I think this is the root cause of incorrectness in https://bugs.openjdk.org/browse/JDK-8317659. The field values of the `InlineTypeNode` are not updated from the changed oop buffer.
> 
> So can we just make `Unsafe.finishPrivateBuffer()` accept `InlineTypeNode` like before, checking its oop is in larval state, and return `make_from_oop()` here?

Following is the API sequence to modify a vector lane.


obj =  Unsafe.makePrivateBuffer(Value.default);
Unsafe.putDouble(obj, OFFSET, value);
obj = Unsafe.finishPrivateBuffer(obj);


In case putDouble is not in-line expanded, compiler makes a call to Unsafe_MakePrivateBuffer native implimentation. There is no way for compiler to detect any JVM state changes since put* returns a void. Thus finishPrivateBuffer will directly use default value and this will cause incorrectness, preventing scalarization ie. creating an InlineTypeNode b/w  make and finish private buffer will fix this problem.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395260160


From xgong at openjdk.org  Thu Nov 16 07:33:53 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 16 Nov 2023 07:33:53 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <-tNM03h6Tf5fXimgRP7Q0ctIdeiqnRF4avbdXUz3pRg=.f8ea31e0-0ad9-45e2-b8f4-c91dd82cee0e@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <-tNM03h6Tf5fXimgRP7Q0ctIdeiqnRF4avbdXUz3pRg=.f8ea31e0-0ad9-45e2-b8f4-c91dd82cee0e@github.com>
Message-ID: <APmrHwWRP-9epdSZz2wkvtFv_xSI1acx1VzktftW10w=.55b0f9ac-cf74-4ac5-9bf1-0e51533ce286@github.com>

On Thu, 16 Nov 2023 07:20:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/macro.cpp line 964:
>> 
>>> 962:   if (alloc->_larval) {
>>> 963:     return false;
>>> 964:   }
>> 
>> Does it need to also add such checks in `InlineTypeNode::make_scalar_in_safepoints` ?
>
> With new behavior, a value object in larval state is already allocated over heap and should not be scalarized to InlineTypeNode.

Yes, that's true. So can we still generate the `InlineTypeNode` with the larval state buffer as its oops like before? And we can avoid its scalarization by just checking the larval state.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395260684


From jbhateja at openjdk.org  Thu Nov 16 07:58:54 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 07:58:54 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <APmrHwWRP-9epdSZz2wkvtFv_xSI1acx1VzktftW10w=.55b0f9ac-cf74-4ac5-9bf1-0e51533ce286@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <-tNM03h6Tf5fXimgRP7Q0ctIdeiqnRF4avbdXUz3pRg=.f8ea31e0-0ad9-45e2-b8f4-c91dd82cee0e@github.com>
 <APmrHwWRP-9epdSZz2wkvtFv_xSI1acx1VzktftW10w=.55b0f9ac-cf74-4ac5-9bf1-0e51533ce286@github.com>
Message-ID: <l35AF96CwcoP_QKkddPx9iCg5UKyc630rrUBy_ynk0U=.f500dc62-9a21-4196-af55-7fb78f3ffdef@github.com>

On Thu, 16 Nov 2023 07:30:09 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> With new behavior, a value object in larval state is already allocated over heap and should not be scalarized to InlineTypeNode.
>
> Yes, that's true. So can we still generate the `InlineTypeNode` with the larval state buffer as its oops like before? And we can avoid its scalarization by just checking the larval state.

Agree. We added special handling to preserve larval state during de-opt, so for the time being shouldn't it be sufficient?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395282551


From jbhateja at openjdk.org  Thu Nov 16 08:04:07 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 08:04:07 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
Message-ID: <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>

On Wed, 15 Nov 2023 06:40:37 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?

I plan to do it separately for JDK-8239003, there have been lots of changes into lworld recently.

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1813955998


From xgong at openjdk.org  Thu Nov 16 08:18:54 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 16 Nov 2023 08:18:54 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <l35AF96CwcoP_QKkddPx9iCg5UKyc630rrUBy_ynk0U=.f500dc62-9a21-4196-af55-7fb78f3ffdef@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <-tNM03h6Tf5fXimgRP7Q0ctIdeiqnRF4avbdXUz3pRg=.f8ea31e0-0ad9-45e2-b8f4-c91dd82cee0e@github.com>
 <APmrHwWRP-9epdSZz2wkvtFv_xSI1acx1VzktftW10w=.55b0f9ac-cf74-4ac5-9bf1-0e51533ce286@github.com>
 <l35AF96CwcoP_QKkddPx9iCg5UKyc630rrUBy_ynk0U=.f500dc62-9a21-4196-af55-7fb78f3ffdef@github.com>
Message-ID: <XaCXOnv6YTOeWH1wXt9S9oL4xxB9sCtyga8wAHPI_U4=.40d3aa59-f469-44bc-8489-d02604706fe8@github.com>

On Thu, 16 Nov 2023 07:53:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes, that's true. So can we still generate the `InlineTypeNode` with the larval state buffer as its oops like before? And we can avoid its scalarization by just checking the larval state.
>
> Agree. We added special handling to preserve larval state during de-opt, so for the time being shouldn't it be sufficient?

I think so. We also need to add the same larval check in https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/inlinetypenode.cpp#L365 to avoid the scalarization of the `InlineType`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395305778


From xgong at openjdk.org  Thu Nov 16 08:22:54 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 16 Nov 2023 08:22:54 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>
Message-ID: <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>

On Thu, 16 Nov 2023 08:00:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?
> 
> I plan to do it separately for JDK-8239003, there have been lots of changes into lworld recently.

Sounds good to me!

>> src/hotspot/share/opto/graphKit.cpp line 1968:
>> 
>>> 1966:         // and transition the allocation into larval state.
>>> 1967:         ret = ret->as_InlineType()->make_larval(this);
>>> 1968:       }
>> 
>> As my understanding, the expected behavior is compiler should guarantee the returned `InlineTypeNode` has a larval state buffer after calling `makePrivateBuffer()`, right? Why do we still need this here?
>
> This it to handle larval state propagation if makePrivateBuffer is not inline expanded, in such a case native implementation gets called and at compile time there is not way to detect larval state.

I see. Thanks! Sounds reasonable. The native implementation of `makePrivateBuffer()` also marks the larval bit of the object. Can we get some help from it?

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1813980005
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395309122


From xgong at openjdk.org  Thu Nov 16 08:28:52 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 16 Nov 2023 08:28:52 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <3IdfnSJFbtXITwmSe-dNvy1-OsvYPZ9Cm8G_7gTPB4k=.68df2415-0624-4383-8870-8419634c7456@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <XSPoMyX2x0QX4H-ypowEOxsznnSE8OSkb1ZCL7jSSQQ=.f54464c9-3a78-42b9-89e2-7a139909621d@github.com>
 <3IdfnSJFbtXITwmSe-dNvy1-OsvYPZ9Cm8G_7gTPB4k=.68df2415-0624-4383-8870-8419634c7456@github.com>
Message-ID: <SYzUxPgS5kbWANGSJOl28fnmL1fHhj7YjRAObChhUlk=.5f1d00a4-2a21-4003-aa38-4239429b8d62@github.com>

On Thu, 16 Nov 2023 07:29:46 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 1039:
>> 
>>> 1037:   kit->insert_mem_bar(Op_MemBarStoreStore, alloc->proj_out_or_null(AllocateNode::RawAddress));
>>> 1038: 
>>> 1039:   return InlineTypeNode::make_from_oop(kit, obj, vk->inline_klass(), !vk->maybe_null());
>> 
>> I think this is the root cause of incorrectness in https://bugs.openjdk.org/browse/JDK-8317659. The field values of the `InlineTypeNode` are not updated from the changed oop buffer.
>> 
>> So can we just make `Unsafe.finishPrivateBuffer()` accept `InlineTypeNode` like before, checking its oop is in larval state, and return `make_from_oop()` here?
>
> Following is the API sequence to modify a vector lane.
> 
> 
> obj =  Unsafe.makePrivateBuffer(Value.default);
> Unsafe.putDouble(obj, OFFSET, value);
> obj = Unsafe.finishPrivateBuffer(obj);
> 
> 
> In case putDouble is not in-line expanded, compiler makes a call to Unsafe_MakePrivateBuffer native implimentation. There is no way for compiler to detect any JVM state changes since put* returns a void. Thus finishPrivateBuffer will directly use default value and this will cause incorrectness, preventing scalarization ie. creating an InlineTypeNode b/w  make and finish private buffer will fix this problem.

Per my personal understanding, I see that we may miss the memory dependency for above case with the original `fnishPrivateBuffer()` intrinsifaction. But with above changes, it can add the memory dependency to `Unsafe.putDouble`, as `make_from_oop()` can generate the load operations from the private buffer. So the issue is fixing. Right?

I still cannot undersand the relationship with `scalarization` happened between them, as the memory dependence is added (the buffer has def-use) between them, how the scalarization is happened?  Please correct me if any misunderstanding!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395317585


From dsimms at openjdk.org  Thu Nov 16 08:51:04 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 16 Nov 2023 08:51:04 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <omK0-uh6IV5taC41bqr4X5c-KsNlhv5Vf8qoS23uzW4=.827f2c35-ed0b-4aef-9cf7-4236fd11c5a8@github.com>
References: <omK0-uh6IV5taC41bqr4X5c-KsNlhv5Vf8qoS23uzW4=.827f2c35-ed0b-4aef-9cf7-4236fd11c5a8@github.com>
Message-ID: <TuBEAd7d3wAaXgPMwkUyRGQjNRtpRld1i6rslbKxEmM=.0ab51793-952c-4805-8d37-9ed74907e778@github.com>

On Thu, 16 Nov 2023 05:52:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> * Merge jdk-22+14
> * @TobiHartmann solved the JDK-8314997 conflict

This pull request has now been integrated.

Changeset: 24e0c059
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/24e0c059b8d02057abbfb02b52209692e44d94e5
Stats:     13586 lines in 348 files changed: 9699 ins; 2425 del; 1462 mod

Merge jdk

Merge jdk-22+14

Co-authored-by: Tobias Hartmann <thartmann at openjdk.org>

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

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


From xgong at openjdk.org  Thu Nov 16 09:21:54 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 16 Nov 2023 09:21:54 GMT
Subject: [lworld+vector] RFR: 8319971: [lworld+vector] Fallback
 implementation cleanups. [v2]
In-Reply-To: <l7dCRJzBv8tAna7a5SRhDDQ2eXiKoEhK_IaxI-yUT1Q=.b15c12c1-07b3-4dae-ad94-735d40b7a9f3@github.com>
References: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
 <l7dCRJzBv8tAna7a5SRhDDQ2eXiKoEhK_IaxI-yUT1Q=.b15c12c1-07b3-4dae-ad94-735d40b7a9f3@github.com>
Message-ID: <xb0Oq4PmPQhTszisCoUeH8wwl7cIul8KLkfWPuBLs2s=.fd682bfe-c83b-47c5-8e24-fa477d2a9911@github.com>

On Thu, 16 Nov 2023 06:24:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Some cleanup related to Unsafe APIs based fallback implementation.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing redundant definition.

LGTM!

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

Marked as reviewed by xgong (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/949#pullrequestreview-1733889028


From jbhateja at openjdk.org  Thu Nov 16 09:52:12 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 09:52:12 GMT
Subject: [lworld+vector] Integrated: 8319971: [lworld+vector] Fallback
 implementation cleanups.
In-Reply-To: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
References: <qoPuC_IWlg_aXiGyvC3e4kuPPRANIrsWZ7HYprBH_Hc=.aa787a31-5853-4272-89ec-dcb44cd887e0@github.com>
Message-ID: <1X0EE5Vhu5hPKGLlsVgVwLLBoDrvcsuahew90HHZi_s=.61132df4-30fd-4d3f-ae91-9bd24aaeef7d@github.com>

On Mon, 13 Nov 2023 16:08:45 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Some cleanup related to Unsafe APIs based fallback implementation.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 89a86558
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/89a86558856cda64a065e7e7dd5dbc5331131012
Stats:     833 lines in 39 files changed: 42 ins; 28 del; 763 mod

8319971: [lworld+vector] Fallback implementation cleanups.

Reviewed-by: xgong

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

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


From jbhateja at openjdk.org  Thu Nov 16 10:12:56 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 10:12:56 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>
 <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
Message-ID: <NFY2UNLStJ6iQBx_F-X_kUC5o039AhzI388XkGvhPi0=.265634d0-62bc-4609-bdf0-b94976c29402@github.com>

On Thu, 16 Nov 2023 08:19:06 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> This it to handle larval state propagation if makePrivateBuffer is not inline expanded, in such a case native implementation gets called and at compile time there is no way to detect larval state.
>
> I see. Thanks! Sounds reasonable. The native implementation of `makePrivateBuffer()` also marks the larval bit of the object. Can we get some help from it?

Idea here is to prevent scalarization of value objects in larval state, above check ensures that InlineTypeNode rematerialized from return value of non-inlined makePrivateBuffer are rebuffered and transitioned into larval state.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395459796


From jbhateja at openjdk.org  Thu Nov 16 10:21:52 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 10:21:52 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <SYzUxPgS5kbWANGSJOl28fnmL1fHhj7YjRAObChhUlk=.5f1d00a4-2a21-4003-aa38-4239429b8d62@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <XSPoMyX2x0QX4H-ypowEOxsznnSE8OSkb1ZCL7jSSQQ=.f54464c9-3a78-42b9-89e2-7a139909621d@github.com>
 <3IdfnSJFbtXITwmSe-dNvy1-OsvYPZ9Cm8G_7gTPB4k=.68df2415-0624-4383-8870-8419634c7456@github.com>
 <SYzUxPgS5kbWANGSJOl28fnmL1fHhj7YjRAObChhUlk=.5f1d00a4-2a21-4003-aa38-4239429b8d62@github.com>
Message-ID: <6qbFyMbiD8iB4EOCR1nXQc7nBejGLvmHGPArBqRXWww=.42d41674-c814-4f1c-b3a0-a6c9cdb76936@github.com>

On Thu, 16 Nov 2023 08:26:38 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Per my personal understanding, I see that we may miss the memory dependency for above case with the original `fnishPrivateBuffer()` intrinsifaction. But with above changes, it can add the memory dependency to `Unsafe.putDouble`, as `make_from_oop()` can generate the load operations from the private buffer. So the issue is fixing. Right?
> 
Yes, idea is to rematerialize scalarized representation only though finishPrivateBuffer. 

However, on your observation related to memory dependency binding on finishPrivate buffer is agnostic to intrinsification of putDouble. 
  
> I still cannot understand the relationship with `scalarization` happened between them, as the memory dependence is added (the buffer has def-use) between them, how the scalarization is happened? Please correct me if any misunderstanding!

Scalarization effect is only seen by users of finishPrivateBuffer when InlineTypeNode is rematerialized.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1395473361


From jbhateja at openjdk.org  Thu Nov 16 10:34:23 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 16 Nov 2023 10:34:23 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v2]
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <qIw_YRKk0IsPBgE2dFGeaw3rdb-YdH90s-hqPjrbG0Q=.5e4d3823-a728-484b-9bd1-46a3aa1b32b7@github.com>

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI and Valhalla JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolutions

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/952/files
  - new: https://git.openjdk.org/valhalla/pull/952/files/f8757970..23acb6bd

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

  Stats: 29 lines in 2 files changed: 12 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/952.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/952/head:pull/952

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


From dsimms at openjdk.org  Thu Nov 16 13:57:51 2023
From: dsimms at openjdk.org (David Simms)
Date: Thu, 16 Nov 2023 13:57:51 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <-oc3VZxFb6yXGbgh8MXW_PUIqK-J0uG6Hn7CC5cwTu4=.782b786b-d554-40b7-9a1a-1c9bd5a6774d@github.com>

Merge jdk-22+15

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

Commit messages:
 - Logical merge errors
 - Merge tag 'jdk-22+15' into lworld_merge_jdk_22_15
 - 6228794: java.text.ChoiceFormat pattern behavior is not well documented.
 - 8314226: Series of colon-style fallthrough switch cases with guards compiled incorrectly
 - 8316087: Test SignedLoggerFinderTest.java is still failing
 - 8315934: RISC-V: Disable conservative fences per vendor
 - 8316021: Serial: Remove unused Generation::post_compact
 - 8316050: Use hexadecimal encoding in MemorySegment::toString
 - 8314612: TestUnorderedReduction.java fails with -XX:MaxVectorSize=32 and -XX:+AlignVector
 - 8311207: Cleanup for Optimization for UUID.toString
 - ... and 92 more: https://git.openjdk.org/valhalla/compare/24e0c059...590858ba

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

Changes: https://git.openjdk.org/valhalla/pull/955/files
  Stats: 24501 lines in 1389 files changed: 12062 ins; 8357 del; 4082 mod
  Patch: https://git.openjdk.org/valhalla/pull/955.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/955/head:pull/955

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


From dsimms at openjdk.org  Fri Nov 17 07:59:04 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 17 Nov 2023 07:59:04 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <-oc3VZxFb6yXGbgh8MXW_PUIqK-J0uG6Hn7CC5cwTu4=.782b786b-d554-40b7-9a1a-1c9bd5a6774d@github.com>
References: <-oc3VZxFb6yXGbgh8MXW_PUIqK-J0uG6Hn7CC5cwTu4=.782b786b-d554-40b7-9a1a-1c9bd5a6774d@github.com>
Message-ID: <C313R9rOsmMD20dRimXRdM99Vq57bV3uc2s_6oO_kPs=.f05b3cd8-c167-4194-9440-de39ffd1dc1e@github.com>

> Merge jdk-22+15

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

  Problem list 8320296

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/955/files
  - new: https://git.openjdk.org/valhalla/pull/955/files/590858ba..0702e8d7

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

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

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


From dsimms at openjdk.org  Fri Nov 17 07:59:06 2023
From: dsimms at openjdk.org (David Simms)
Date: Fri, 17 Nov 2023 07:59:06 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <-oc3VZxFb6yXGbgh8MXW_PUIqK-J0uG6Hn7CC5cwTu4=.782b786b-d554-40b7-9a1a-1c9bd5a6774d@github.com>
References: <-oc3VZxFb6yXGbgh8MXW_PUIqK-J0uG6Hn7CC5cwTu4=.782b786b-d554-40b7-9a1a-1c9bd5a6774d@github.com>
Message-ID: <SeDm6mSA4cKKvZhGIpw4aBKxwAYc3aJpaYudWseXOgY=.2f7a378a-0826-4b54-93f0-31e61a7eabae@github.com>

On Thu, 16 Nov 2023 13:49:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-22+15

This pull request has now been integrated.

Changeset: 6e6ac6c9
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6e6ac6c9aa52d377578bbb1d741f87ac534ed33c
Stats:     24503 lines in 1389 files changed: 12064 ins; 8357 del; 4082 mod

Merge jdk

Merge jdk-22+15

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

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


From xgong at openjdk.org  Mon Nov 20 01:21:53 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 20 Nov 2023 01:21:53 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
Message-ID: <PTTp2sQhtVxXkOj0pkYRhQdwGoZKp_B-Zr4W5YV3vzI=.7afbe81a-e2b9-4bff-afc5-3ca7d8043106@github.com>

On Wed, 15 Nov 2023 07:33:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
> 
> Here is the log:
> 
> 
>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
> 
>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
> 
> 
> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
> 
> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
> 
> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
> 
> [1] https://github.com/openjdk/valhalla/pull/918
> 
> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.

@jatin-bhateja , could you please take a look at this PR? Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1818066228


From xgong at openjdk.org  Mon Nov 20 01:39:51 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 20 Nov 2023 01:39:51 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v2]
In-Reply-To: <NFY2UNLStJ6iQBx_F-X_kUC5o039AhzI388XkGvhPi0=.265634d0-62bc-4609-bdf0-b94976c29402@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>
 <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
 <NFY2UNLStJ6iQBx_F-X_kUC5o039AhzI388XkGvhPi0=.265634d0-62bc-4609-bdf0-b94976c29402@github.com>
Message-ID: <Z1MeI0TQcknuxZ7U9sQWQsniG8cXIrOObCDflrdKJJg=.f3f874f1-d481-4a7b-b0cd-97e51998bf9e@github.com>

On Thu, 16 Nov 2023 10:10:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> I see. Thanks! Sounds reasonable. The native implementation of `makePrivateBuffer()` also marks the larval bit of the object. Can we get some help from it?
>
> Idea here is to prevent scalarization of value objects in larval state, above check ensures that InlineTypeNode rematerialized from return value of non-inlined makePrivateBuffer are rebuffered and transitioned into larval state.

It makes sense to me. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1398564307


From thartmann at openjdk.org  Mon Nov 20 11:38:36 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Nov 2023 11:38:36 GMT
Subject: [lworld] RFR: 8320080: [lworld] SubTypeCheckNode::sub asserts with
 "should be not null"
Message-ID: <6z6VRsvh8P9AqiNuckeCg4PZLiEHAN6emHF8ixRSl_s=.b2110f0d-1d6a-4fc8-98b6-dcbac6ba023f@github.com>

Similar to [JDK-8315744](https://bugs.openjdk.org/browse/JDK-8315744), we hit an assert because the subtype of a SubTypeCheckNode is not known to be non-null. The problem is that when pushing casts up through InlineTypeNodes in `ConstraintCastNode::Ideal`, we lose track of the null-free information.

I also re-added still required `T_PRIMITIVE_OBJECT` in the compiler replay implementation that I accidentally removed with https://git.openjdk.org/valhalla/pull/946.

Thanks,
Tobias

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

Commit messages:
 - 8320080: [lworld] SubTypeCheckNode::sub asserts with "should be not null"

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

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


From thartmann at openjdk.org  Mon Nov 20 13:23:53 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 20 Nov 2023 13:23:53 GMT
Subject: [lworld] Integrated: 8320080: [lworld] SubTypeCheckNode::sub asserts
 with "should be not null"
In-Reply-To: <6z6VRsvh8P9AqiNuckeCg4PZLiEHAN6emHF8ixRSl_s=.b2110f0d-1d6a-4fc8-98b6-dcbac6ba023f@github.com>
References: <6z6VRsvh8P9AqiNuckeCg4PZLiEHAN6emHF8ixRSl_s=.b2110f0d-1d6a-4fc8-98b6-dcbac6ba023f@github.com>
Message-ID: <RtD5ykx4SuNf_9NRTJuFxsZ8Y9HDEb-CQohSXOqG5KE=.9f93384a-a8e4-4a6e-9c3e-21718225a3ce@github.com>

On Mon, 20 Nov 2023 11:31:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to [JDK-8315744](https://bugs.openjdk.org/browse/JDK-8315744), we hit an assert because the subtype of a SubTypeCheckNode is not known to be non-null. The problem is that when pushing casts up through InlineTypeNodes in `ConstraintCastNode::Ideal`, we lose track of the null-free information.
> 
> I also re-added still required `T_PRIMITIVE_OBJECT` in the compiler replay implementation that I accidentally removed with https://git.openjdk.org/valhalla/pull/946.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 3f3a7be0
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3f3a7be085db25e1a990a5a3ec214d3679b751ec
Stats:     22 lines in 4 files changed: 22 ins; 0 del; 0 mod

8320080: [lworld] SubTypeCheckNode::sub asserts with "should be not null"

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

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


From fparain at openjdk.org  Mon Nov 20 18:10:14 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 20 Nov 2023 18:10:14 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points
Message-ID: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>

Adding internal null-restricted storage API points

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

Commit messages:
 - Remove empty line
 - More tests migrated
 - Fix test
 - Test code cleanup
 - Fix javadoc
 - Merge remote-tracking branch 'upstream/lworld' into annotations
 - Add support for atomicity plus various fixes
 - Adding internal null-restricted storage API points

Changes: https://git.openjdk.org/valhalla/pull/947/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=947&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320437
  Stats: 1140 lines in 26 files changed: 1023 ins; 17 del; 100 mod
  Patch: https://git.openjdk.org/valhalla/pull/947.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/947/head:pull/947

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


From mchung at openjdk.org  Mon Nov 20 18:10:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 20 Nov 2023 18:10:17 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points
In-Reply-To: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
Message-ID: <XmMfxDkej9ugRzc67p7dN7iLxZnzxhfOpcAF-3a-TD4=.72d61a56-c47e-4a4a-af78-eba83dbd2f02@github.com>

On Tue, 7 Nov 2023 14:48:04 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Adding internal null-restricted storage API points

src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 594:

> 592:      *         {@link jdk.internal.vm.annotation.ImplicitlyConstructible}
> 593:      */
> 594:     public static native Object[] newNullRestrictedArray(Class<?> componentType,

I think this API should be moved to some other runtime class.    VMSupport is the support class used by JVM CI, JVM TI, and attach mechanism.

What about `jdk.internal.value.ValueClassSupport` or `jdk.internal.misc.VM` for now?   We can find a better home later.

src/java.base/share/native/libjava/VMSupport.c line 44:

> 42:     return JVM_GetTemporaryDirectory(env);
> 43: }
> 44: 

Nit: should have no change in this file.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1385746690
PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1397797222


From thartmann at openjdk.org  Tue Nov 21 10:41:05 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Nov 2023 10:41:05 GMT
Subject: [lworld] RFR: 8320225: [lworld] TestBasicFunctionality::test20 fails
 intermittently because it does not correctly handle coalescing of
 subword stores
Message-ID: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>

`TestBasicFunctionality::test20` fails intermittently if one of the randomly chosen field values of a value object is zero because that will lead to slightly different type information for the captured stores that initialize the object. 

Passing case:

299  StoreP  === 330 375 285 290  [[ 302 304 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
304  StoreL  === 330 299 289 302  [[ 308 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
308  StoreNKlass  === 330 304 306 331  [[ 316 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
316  StoreI  === 330 308 315 57  [[ 280 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
311  StoreL  === 279 280 309 310  [[ 246 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[245],3161 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
246  StoreL  === 279 311 254 188  [[ 314 ]]  @compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact+24 *, name=l, idx=11;  Memory: @rawptr:BotPTR, idx=Raw; !orig=3166 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
314  StoreL  === 279 246 312 313  [[ 231 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3178 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)


Failing case:

300  StoreP  === 337 384 286 291  [[ 303 305 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
305  StoreL  === 337 300 290 303  [[ 309 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
309  StoreNKlass  === 337 305 307 338  [[ 317 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
317  StoreI  === 337 309 316 57  [[ 343 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
343  StoreL  === 337 317 322 184  [[ 281 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[323]
312  StoreL  === 280 281 310 311  [[ 315 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3163 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
315  StoreL  === 280 312 313 314  [[ 234 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[250],3180 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
``` 

In the failing case, the `343  StoreL` is a zeroing store that's separated from the other non-zero `StoreL` by a memory Phi and thus not detected as a store to field `l`. The fix is to make the test more robust by matching on the number of `STORE_L` instead.

Thanks,
Tobias

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

Commit messages:
 - 8320225: [lworld] TestBasicFunctionality::test20 fails intermittently because it does not correctly handle coalescing of subword stores

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

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


From thartmann at openjdk.org  Tue Nov 21 14:28:12 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Nov 2023 14:28:12 GMT
Subject: [lworld] RFR: 8320225: [lworld] TestBasicFunctionality::test20
 fails intermittently because it does not correctly handle coalescing of
 subword stores [v2]
In-Reply-To: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>
References: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>
Message-ID: <b4kvLKOJEpiTEOwaAXuihHVbbtTCyxII5ASeu1-OlY0=.25a3fcc6-1e6e-4e78-baf7-dd9a898b12a8@github.com>

> `TestBasicFunctionality::test20` fails intermittently if one of the randomly chosen field values of a value object is zero because that will lead to slightly different type information for the captured stores that initialize the object. 
> 
> Passing case:
> 
> 299  StoreP  === 330 375 285 290  [[ 302 304 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 304  StoreL  === 330 299 289 302  [[ 308 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 308  StoreNKlass  === 330 304 306 331  [[ 316 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 316  StoreI  === 330 308 315 57  [[ 280 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 311  StoreL  === 279 280 309 310  [[ 246 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[245],3161 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 246  StoreL  === 279 311 254 188  [[ 314 ]]  @compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact+24 *, name=l, idx=11;  Memory: @rawptr:BotPTR, idx=Raw; !orig=3166 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 314  StoreL  === 279 246 312 313  [[ 231 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3178 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 
> 
> Failing case:
> 
> 300  StoreP  === 337 384 286 291  [[ 303 305 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 305  StoreL  === 337 300 290 303  [[ 309 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 309  StoreNKlass  === 337 305 307 338  [[ 317 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 317  StoreI  === 337 309 316 57  [[ 343 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 343  StoreL  === 337 317 322 184  [[ 281 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[323]
> 312  StoreL  === 280 281 310 311  [[ 315 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3163 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 315  StoreL  === 280 312 313 314  [[ 234 ]]  @ra...

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

  Removed it

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/957/files
  - new: https://git.openjdk.org/valhalla/pull/957/files/8a878522..5875bf01

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

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

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


From thartmann at openjdk.org  Tue Nov 21 14:28:15 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Nov 2023 14:28:15 GMT
Subject: [lworld] RFR: 8320225: [lworld] TestBasicFunctionality::test20
 fails intermittently because it does not correctly handle coalescing of
 subword stores
In-Reply-To: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>
References: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>
Message-ID: <ugBz2dQgOeLYcfQ8cx31YJPbaj_jx3GnAoHKBlpL1nw=.def73f14-e92e-49be-8fab-c25d8687eb02@github.com>

On Tue, 21 Nov 2023 10:35:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `TestBasicFunctionality::test20` fails intermittently if one of the randomly chosen field values of a value object is zero because that will lead to slightly different type information for the captured stores that initialize the object. 
> 
> Passing case:
> 
> 299  StoreP  === 330 375 285 290  [[ 302 304 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 304  StoreL  === 330 299 289 302  [[ 308 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 308  StoreNKlass  === 330 304 306 331  [[ 316 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 316  StoreI  === 330 308 315 57  [[ 280 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 311  StoreL  === 279 280 309 310  [[ 246 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[245],3161 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 246  StoreL  === 279 311 254 188  [[ 314 ]]  @compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact+24 *, name=l, idx=11;  Memory: @rawptr:BotPTR, idx=Raw; !orig=3166 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 314  StoreL  === 279 246 312 313  [[ 231 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3178 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 
> 
> Failing case:
> 
> 300  StoreP  === 337 384 286 291  [[ 303 305 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 305  StoreL  === 337 300 290 303  [[ 309 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 309  StoreNKlass  === 337 305 307 338  [[ 317 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 317  StoreI  === 337 309 316 57  [[ 343 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 343  StoreL  === 337 317 322 184  [[ 281 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[323]
> 312  StoreL  === 280 281 310 311  [[ 315 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3163 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 315  StoreL  === 280 312 313 314  [[ 234 ]]  @ra...

On second thought, this is still not sufficient because depending on which field values are zero, C2 will replace some of the stores by `StoreI`s instead:


 302  StoreP  === 337 382 288 293  [[ 305 307 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
 307  StoreL  === 337 302 292 305  [[ 311 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
 311  StoreNKlass  === 337 307 309 338  [[ 321 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
 321  StoreI  === 337 311 320 57  [[ 323 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
 323  StoreI  === 337 321 322 57  [[ 283 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
 316  StoreI  === 282 283 314 315  [[ 249 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3159 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:96 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 477)
 249  StoreL  === 282 316 257 191  [[ 319 ]]  @compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact+24 *, name=l, idx=11;  Memory: @rawptr:BotPTR, idx=Raw; !orig=3164 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:96 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 477)
 319  StoreL  === 282 249 317 318  [[ 234 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[251],3176 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:96 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 477)
``` 

Let's just remove the IR rule instead, it does not have much value anyway.

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

PR Comment: https://git.openjdk.org/valhalla/pull/957#issuecomment-1821018469


From thartmann at openjdk.org  Tue Nov 21 14:28:18 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Nov 2023 14:28:18 GMT
Subject: [lworld] Integrated: 8320225: [lworld] TestBasicFunctionality::test20
 fails intermittently because it does not correctly handle coalescing
 of subword stores
In-Reply-To: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>
References: <1Di4ugyVeOWD7AAS1mGCiNTg9_sh0w_EDloSQb0FTZg=.20526b18-12a6-4ce4-882a-a476c4f8e0bd@github.com>
Message-ID: <_ykv1lzA6nwe9LKjDgsScMIpgoXgz1bkzpTa6uO3M2U=.453aa59e-ec3e-4b46-889f-f95eb2835132@github.com>

On Tue, 21 Nov 2023 10:35:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `TestBasicFunctionality::test20` fails intermittently if one of the randomly chosen field values of a value object is zero because that will lead to slightly different type information for the captured stores that initialize the object. 
> 
> Passing case:
> 
> 299  StoreP  === 330 375 285 290  [[ 302 304 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 304  StoreL  === 330 299 289 302  [[ 308 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 308  StoreNKlass  === 330 304 306 331  [[ 316 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 316  StoreI  === 330 308 315 57  [[ 280 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 311  StoreL  === 279 280 309 310  [[ 246 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[245],3161 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 246  StoreL  === 279 311 254 188  [[ 314 ]]  @compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact+24 *, name=l, idx=11;  Memory: @rawptr:BotPTR, idx=Raw; !orig=3166 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 314  StoreL  === 279 246 312 313  [[ 231 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3178 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 
> 
> Failing case:
> 
> 300  StoreP  === 337 384 286 291  [[ 303 305 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 305  StoreL  === 337 300 290 303  [[ 309 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 309  StoreNKlass  === 337 305 307 338  [[ 317 ]]  @null  Memory: @rawptr:BotPTR, idx=Raw;
> 317  StoreI  === 337 309 316 57  [[ 343 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
> 343  StoreL  === 337 317 322 184  [[ 281 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[323]
> 312  StoreL  === 280 281 310 311  [[ 315 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw; !orig=[248],3163 !jvms: MyValue1::<vnew> @ bci:82 (line 57) MyValue1::setV4 @ bci:40 (line 178) MyValue1::createWithFieldsInline @ bci:106 (line 89) TestBasicFunctionality::test20 @ bci:6 (line 475)
> 315  StoreL  === 280 312 313 314  [[ 234 ]]  @ra...

This pull request has now been integrated.

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

8320225: [lworld] TestBasicFunctionality::test20 fails intermittently because it does not correctly handle coalescing of subword stores

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

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


From thartmann at openjdk.org  Tue Nov 21 14:49:49 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Nov 2023 14:49:49 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points
In-Reply-To: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
Message-ID: <0IoNu9QIH-gkMbXIL5QHtty09RFP4u3B0AbxtnR6UDg=.09fff16b-b0fc-4b17-b7b4-e57d77477b48@github.com>

On Tue, 7 Nov 2023 14:48:04 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Adding internal null-restricted storage API points

test/hotspot/jtreg/runtime/valhalla/inlinetypes/StaticFieldsTest.java line 143:

> 141:     @LooselyConsistentValue
> 142:     static primitive class ClassG {
> 143:         @NullRestricted

Should be `value class`, right?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1400709695


From fparain at openjdk.org  Tue Nov 21 14:58:55 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 21 Nov 2023 14:58:55 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v2]
In-Reply-To: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
Message-ID: <4CajzSKvuxiYWeWwdLC9p0Go3QC3WGgGV2ewSjpJW0E=.e9203343-b6f4-46d1-bd69-6e9ffa10d84d@github.com>

> Adding internal null-restricted storage API points

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

  Fix wrong class type in test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/947/files
  - new: https://git.openjdk.org/valhalla/pull/947/files/afe34de2..bb704830

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

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

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


From fparain at openjdk.org  Tue Nov 21 14:58:58 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 21 Nov 2023 14:58:58 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v2]
In-Reply-To: <0IoNu9QIH-gkMbXIL5QHtty09RFP4u3B0AbxtnR6UDg=.09fff16b-b0fc-4b17-b7b4-e57d77477b48@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <0IoNu9QIH-gkMbXIL5QHtty09RFP4u3B0AbxtnR6UDg=.09fff16b-b0fc-4b17-b7b4-e57d77477b48@github.com>
Message-ID: <oUTaPj_hGDOJMH9ZYPX1DW0Bj5lwHkBlF8Q1n6cLpF8=.c7aa3951-397c-4dbe-a329-5df2d54b867d@github.com>

On Tue, 21 Nov 2023 14:44:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix wrong class type in test
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/StaticFieldsTest.java line 143:
> 
>> 141:     @LooselyConsistentValue
>> 142:     static primitive class ClassG {
>> 143:         @NullRestricted
> 
> Should be `value class`, right?

Good catch, fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1400724856


From thartmann at openjdk.org  Tue Nov 21 15:38:42 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 21 Nov 2023 15:38:42 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v2]
In-Reply-To: <4CajzSKvuxiYWeWwdLC9p0Go3QC3WGgGV2ewSjpJW0E=.e9203343-b6f4-46d1-bd69-6e9ffa10d84d@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <4CajzSKvuxiYWeWwdLC9p0Go3QC3WGgGV2ewSjpJW0E=.e9203343-b6f4-46d1-bd69-6e9ffa10d84d@github.com>
Message-ID: <82H_8ltKYCFfgFZ1MTDu0xzE5BdZ7rz5RHWN20EsD64=.1cd76297-de2e-4ae4-bb87-138acf480762@github.com>

On Tue, 21 Nov 2023 14:58:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong class type in test

test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 152:

> 150:         // Asserts.assertNotNull(e, "Error should have been thrown");
> 151:         // Asserts.assertTrue(e.getClass() == NoClassDefFoundError.class, "Must be a NoClassDefFoundError");
> 152:         // Asserts.assertTrue(e.getCause().getClass() == ExceptionInInitializerError.class, "Must be an ExceptionInInitializerError");

I would suggest to use `/*` `*/` for uncommenting because it does not affect git blame history of the other lines.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1400786616


From jbhateja at openjdk.org  Tue Nov 21 16:45:54 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 21 Nov 2023 16:45:54 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v3]
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <ryIYsVvLrsekw0mqddj6XLGGYp_GIInbSR0AChGvYu4=.3de1d327-9216-40cd-8d39-f9ddf1eae2de@github.com>

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI and Valhalla JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja 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 five additional commits since the last revision:

 - Some more fixes and cleanups
 - Merge branch 'lworld+vector' of http://github.com/openjdk/valhalla into JDK-8319972
 - Review comments resolutions
 - Regression fixes
 - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/952/files
  - new: https://git.openjdk.org/valhalla/pull/952/files/23acb6bd..2c5e7e87

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

  Stats: 869 lines in 43 files changed: 38 ins; 28 del; 803 mod
  Patch: https://git.openjdk.org/valhalla/pull/952.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/952/head:pull/952

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


From fparain at openjdk.org  Tue Nov 21 19:00:12 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 21 Nov 2023 19:00:12 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
Message-ID: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>

> Adding internal null-restricted storage API points

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

  Field inheritance check should be limited to instance fields

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/947/files
  - new: https://git.openjdk.org/valhalla/pull/947/files/bb704830..539d53ef

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

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

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


From jbhateja at openjdk.org  Wed Nov 22 06:25:34 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 06:25:34 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>
 <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
Message-ID: <T5eu8FadSxw80VF35RzcpbaW33UG81k0rOGL0Ufwvqo=.541aa494-622a-4a9d-ad14-c06138499e25@github.com>

On Thu, 16 Nov 2023 08:19:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?
>> 
>> I plan to do it separately for JDK-8239003, there have been lots of changes into lworld recently.
>
>> > Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?
>> 
>> I plan to do it separately for JDK-8239003, there have been lots of changes into lworld recently.
> 
> Sounds good to me!

Hi @XiaohongGong , Let me know if there are any further clarification here, else I can integrate this.

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1822181136


From xgong at openjdk.org  Wed Nov 22 06:45:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Nov 2023 06:45:40 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v3]
In-Reply-To: <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>
Message-ID: <pQU94dqP1bUDvqyK53g1Du85XqmnpaXUMO4L1IEQGg4=.a816280f-4b06-423b-af0a-5f8f9932416c@github.com>

On Wed, 15 Nov 2023 04:10:07 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja 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 five additional commits since the last revision:
>> 
>>  - Some more fixes and cleanups
>>  - Merge branch 'lworld+vector' of http://github.com/openjdk/valhalla into JDK-8319972
>>  - Review comments resolutions
>>  - Regression fixes
>>  - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.
>
> src/hotspot/share/opto/inlinetypenode.cpp line 1024:
> 
>> 1022: 
>> 1023:   store(kit, alloc_oop, alloc_oop, vk);
>> 1024:   return alloc_oop;
> 
> Why not setting the oop to allocated buffer and return the `InlineTypeNode` ? We may have optimizations for Unsafe access for `InlineTypeNode` input.

Any feedback on this please?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401571532


From xgong at openjdk.org  Wed Nov 22 06:45:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Nov 2023 06:45:40 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v3]
In-Reply-To: <ryIYsVvLrsekw0mqddj6XLGGYp_GIInbSR0AChGvYu4=.3de1d327-9216-40cd-8d39-f9ddf1eae2de@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <ryIYsVvLrsekw0mqddj6XLGGYp_GIInbSR0AChGvYu4=.3de1d327-9216-40cd-8d39-f9ddf1eae2de@github.com>
Message-ID: <flPyR2dTmA3PrDexNntEbZxXzf9fgGmW1A4tzwZD4co=.ae7fea7a-3f32-4115-af59-9465126e0d5b@github.com>

On Tue, 21 Nov 2023 16:45:54 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
>> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
>> 
>> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
>> 
>> New behavior of unsafe inline expanders
>> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
>> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
>> 
>> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
>> 
>> In addition compiler is now preventing elimination of allocation in larval state.
>> 
>> Validation Status:-
>>   - All the VectorAPI and Valhalla JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja 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 five additional commits since the last revision:
> 
>  - Some more fixes and cleanups
>  - Merge branch 'lworld+vector' of http://github.com/openjdk/valhalla into JDK-8319972
>  - Review comments resolutions
>  - Regression fixes
>  - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.

src/hotspot/share/opto/library_call.cpp line 2663:

> 2661:   if (!buffer->bottom_type()->is_inlinetypeptr()) {
> 2662:      return false;
> 2663:   }

Suggestion:

  // Incoming value should be a buffer with inline type and not InlineTypeNode.
  if (buffer->is_InlineType() || !buffer->bottom_type()->is_inlinetypeptr()) {
     return false;
  }

src/hotspot/share/opto/parse1.cpp line 1782:

> 1780:           // Scalarize null in src block to be able to merge it with inline type in target block
> 1781:           assert(gvn().type(n)->is_zero_type(), "Should have been scalarized");
> 1782:           map()->set_req(j, InlineTypeNode::make_null(gvn(), t->inline_klass()));

Did you check why this assertion is hit for larval state buffer? I mean is it possible that the inline type buffer in larval state should not go to this path.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401573004
PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401575243


From jbhateja at openjdk.org  Wed Nov 22 07:41:36 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 07:41:36 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v3]
In-Reply-To: <pQU94dqP1bUDvqyK53g1Du85XqmnpaXUMO4L1IEQGg4=.a816280f-4b06-423b-af0a-5f8f9932416c@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>
 <pQU94dqP1bUDvqyK53g1Du85XqmnpaXUMO4L1IEQGg4=.a816280f-4b06-423b-af0a-5f8f9932416c@github.com>
Message-ID: <UMVM3wsLQ1FJ0QxMFat8f8mX0Zelpp96-Spq9MJdt0o=.d5c909de-6903-4d5f-8994-69e25ac87d16@github.com>

On Wed, 22 Nov 2023 06:34:26 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 1024:
>> 
>>> 1022: 
>>> 1023:   store(kit, alloc_oop, alloc_oop, vk);
>>> 1024:   return alloc_oop;
>> 
>> Why not setting the oop to allocated buffer and return the `InlineTypeNode` ? We may have optimizations for Unsafe access for `InlineTypeNode` input.
>
> Any feedback on this please?

The whole idea is to avoid scalarization for value objects in laval state and not construct InlineTypeNode till we encounter a finishPrivateBuffer. A value object is transitioned into larval state to make it mutable, since Unsafe.put* APIs do not modify the JVM state hence to be safe it's better to keep value objects as oops b/w make and finish private buffer, patch also disables re-materialization of InlineTypeNode from updated memory state in Unsafe.put* inline expanders.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401622841


From jbhateja at openjdk.org  Wed Nov 22 07:52:41 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 07:52:41 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v3]
In-Reply-To: <flPyR2dTmA3PrDexNntEbZxXzf9fgGmW1A4tzwZD4co=.ae7fea7a-3f32-4115-af59-9465126e0d5b@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <ryIYsVvLrsekw0mqddj6XLGGYp_GIInbSR0AChGvYu4=.3de1d327-9216-40cd-8d39-f9ddf1eae2de@github.com>
 <flPyR2dTmA3PrDexNntEbZxXzf9fgGmW1A4tzwZD4co=.ae7fea7a-3f32-4115-af59-9465126e0d5b@github.com>
Message-ID: <5BXKBREHWDBlASfbFHP96Vo40kxjXVWl4zEzpacumNE=.593cd5f0-1e79-484d-9c9f-cad692cfcf53@github.com>

On Wed, 22 Nov 2023 06:39:52 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja 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 five additional commits since the last revision:
>> 
>>  - Some more fixes and cleanups
>>  - Merge branch 'lworld+vector' of http://github.com/openjdk/valhalla into JDK-8319972
>>  - Review comments resolutions
>>  - Regression fixes
>>  - 8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.
>
> src/hotspot/share/opto/parse1.cpp line 1782:
> 
>> 1780:           // Scalarize null in src block to be able to merge it with inline type in target block
>> 1781:           assert(gvn().type(n)->is_zero_type(), "Should have been scalarized");
>> 1782:           map()->set_req(j, InlineTypeNode::make_null(gvn(), t->inline_klass()));
> 
> Did you check why this assertion is hit for larval state buffer? I mean is it possible that the inline type buffer in larval state should not go to this path.

Since make_larval now generates the oop hence will hit upon this control path, we no longer create InlineTypeNode for value objects in larval state.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401632358


From jbhateja at openjdk.org  Wed Nov 22 08:12:59 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 08:12:59 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v4]
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <swJAjFEML7mpiqnxKKjNGJ7_JfiN2WzJRC6aH9k_j-0=.90e5815e-81a3-471d-b6cd-00390c772c3a@github.com>

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI and Valhalla JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Styling comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/952/files
  - new: https://git.openjdk.org/valhalla/pull/952/files/2c5e7e87..1280eebf

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

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

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


From xgong at openjdk.org  Wed Nov 22 09:09:29 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Nov 2023 09:09:29 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v4]
In-Reply-To: <UMVM3wsLQ1FJ0QxMFat8f8mX0Zelpp96-Spq9MJdt0o=.d5c909de-6903-4d5f-8994-69e25ac87d16@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>
 <pQU94dqP1bUDvqyK53g1Du85XqmnpaXUMO4L1IEQGg4=.a816280f-4b06-423b-af0a-5f8f9932416c@github.com>
 <UMVM3wsLQ1FJ0QxMFat8f8mX0Zelpp96-Spq9MJdt0o=.d5c909de-6903-4d5f-8994-69e25ac87d16@github.com>
Message-ID: <HyYegn139RpPA3BHjY8DVBquoyKt0_SfTsZddchrIF8=.d9b22fdb-bf5c-4d71-96f4-8798ce96165c@github.com>

On Wed, 22 Nov 2023 07:39:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Any feedback on this please?
>
> The whole idea is to avoid scalarization for value objects in laval state and not construct InlineTypeNode till we encounter a finishPrivateBuffer. A value object is transitioned into larval state to make it mutable, since Unsafe.put* APIs do not modify the JVM state hence to be safe it's better to keep value objects as oops b/w make and finish private buffer, patch also disables re-materialization of InlineTypeNode from updated memory state in Unsafe.put* inline expanders.

Yes, I understand your intention. And it makes sense to me. My question is whether we can keep the InlineType with a larval state before, and forbiting the scalarization for it between make/finish private buffer. Changing `InlineType` totally to the oop buffer looks too heavy to me.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401720310


From jbhateja at openjdk.org  Wed Nov 22 09:40:38 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 09:40:38 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v4]
In-Reply-To: <HyYegn139RpPA3BHjY8DVBquoyKt0_SfTsZddchrIF8=.d9b22fdb-bf5c-4d71-96f4-8798ce96165c@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>
 <pQU94dqP1bUDvqyK53g1Du85XqmnpaXUMO4L1IEQGg4=.a816280f-4b06-423b-af0a-5f8f9932416c@github.com>
 <UMVM3wsLQ1FJ0QxMFat8f8mX0Zelpp96-Spq9MJdt0o=.d5c909de-6903-4d5f-8994-69e25ac87d16@github.com>
 <HyYegn139RpPA3BHjY8DVBquoyKt0_SfTsZddchrIF8=.d9b22fdb-bf5c-4d71-96f4-8798ce96165c@github.com>
Message-ID: <FWf94GXxaeutvw3qjZrbAqTVIW2iS5rbT0OQYlqAmto=.706aa7a4-7a6f-4f4b-8c91-13df8dc93e46@github.com>

On Wed, 22 Nov 2023 09:06:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The whole idea is to avoid scalarization for value objects in laval state and not construct InlineTypeNode till we encounter a finishPrivateBuffer. A value object is transitioned into larval state to make it mutable, since Unsafe.put* APIs do not modify the JVM state hence to be safe it's better to keep value objects as oops b/w make and finish private buffer, patch also disables re-materialization of InlineTypeNode from updated memory state in Unsafe.put* inline expanders.
>
> Yes, I understand your intention. And it makes sense to me. My question is whether we can keep the InlineType with a larval state before, and forbiting the scalarization for it between make/finish private buffer. Changing `InlineType` totally to the oop buffer looks too heavy to me.

Generating InlineTypeNode in make_larval will also necessitate re-materialization of such a node in Unsafe.put* expander which is problematic, given that put only modifies the memory state, totally avoiding creation of InlineTypeNode for value objects in larval state will fix this.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401762189


From xgong at openjdk.org  Wed Nov 22 09:58:39 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Nov 2023 09:58:39 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v4]
In-Reply-To: <swJAjFEML7mpiqnxKKjNGJ7_JfiN2WzJRC6aH9k_j-0=.90e5815e-81a3-471d-b6cd-00390c772c3a@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <swJAjFEML7mpiqnxKKjNGJ7_JfiN2WzJRC6aH9k_j-0=.90e5815e-81a3-471d-b6cd-00390c772c3a@github.com>
Message-ID: <j0Wi0Zh5X3LRXj2d40imZkJiG9RRIu6puuBFrWQ6UWo=.5af7adfc-fecf-4e5d-ac0e-dfdab9023c66@github.com>

On Wed, 22 Nov 2023 08:12:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
>> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
>> 
>> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
>> 
>> New behavior of unsafe inline expanders
>> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
>> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
>> 
>> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
>> 
>> In addition compiler is now preventing elimination of allocation in larval state.
>> 
>> Validation Status:-
>>   - All the VectorAPI and Valhalla JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Styling comments

Marked as reviewed by xgong (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/952#pullrequestreview-1743984884


From xgong at openjdk.org  Wed Nov 22 09:58:40 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Wed, 22 Nov 2023 09:58:40 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer. [v4]
In-Reply-To: <FWf94GXxaeutvw3qjZrbAqTVIW2iS5rbT0OQYlqAmto=.706aa7a4-7a6f-4f4b-8c91-13df8dc93e46@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <Dv9Bzt1YjBeGztqRi68YPW0yIs5jgsj78iHPQfbaZvQ=.bb4dbf10-9d77-4071-8b52-2d6baa162f13@github.com>
 <pQU94dqP1bUDvqyK53g1Du85XqmnpaXUMO4L1IEQGg4=.a816280f-4b06-423b-af0a-5f8f9932416c@github.com>
 <UMVM3wsLQ1FJ0QxMFat8f8mX0Zelpp96-Spq9MJdt0o=.d5c909de-6903-4d5f-8994-69e25ac87d16@github.com>
 <HyYegn139RpPA3BHjY8DVBquoyKt0_SfTsZddchrIF8=.d9b22fdb-bf5c-4d71-96f4-8798ce96165c@github.com>
 <FWf94GXxaeutvw3qjZrbAqTVIW2iS5rbT0OQYlqAmto=.706aa7a4-7a6f-4f4b-8c91-13df8dc93e46@github.com>
Message-ID: <AgN6wKMMIo_vtsLvKwCLn-jRJh-Z293Zq_UbIChCgoQ=.4fc425d2-bd12-4073-b031-0fbe3fcd0301@github.com>

On Wed, 22 Nov 2023 09:38:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes, I understand your intention. And it makes sense to me. My question is whether we can keep the InlineType with a larval state before, and forbiting the scalarization for it between make/finish private buffer. Changing `InlineType` totally to the oop buffer looks too heavy to me.
>
> Generating InlineTypeNode in make_larval will also necessitate re-materialization of such a node in Unsafe.put* expander which is problematic, given that put only modifies the memory state, totally avoiding creation of InlineTypeNode for value objects in larval state will fix this.

OK. Thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/952#discussion_r1401787858


From jbhateja at openjdk.org  Wed Nov 22 13:07:43 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 13:07:43 GMT
Subject: [lworld+vector] RFR: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
 <gEZ44BvmxfsaDr3CS_nVbS2czRU6dZFYNyxcJzxCtbk=.1173e366-68c8-4815-b672-830bb6b15961@github.com>
 <3I3BX4tAtk8zzsPECnVMM0I2qOujPAiQXtYPwePS60M=.b1e3f56f-cbe6-4393-a328-0893a151ea41@github.com>
 <MgPU1YS3iKAeR224QeiRz6cbNnw409Oa9qVgn6qDwVw=.ffcf6fb6-85a0-4f94-ad9f-e16062207520@github.com>
Message-ID: <DSeUkdRGYKee_BmfR1gc2pq8iuU-W_klClIr2mOuIkE=.3b9b5acc-9ce0-44fd-98bc-4492beeac5ad@github.com>

On Thu, 16 Nov 2023 08:19:56 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>>> Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?
>> 
>> I plan to do it separately for JDK-8239003, there have been lots of changes into lworld recently.
>
>> > Do you think it's better to push the main changes (I mean the elimination scalarization of larval state buffer) to `lworld` branch, which may get more reviews from other people?
>> 
>> I plan to do it separately for JDK-8239003, there have been lots of changes into lworld recently.
> 
> Sounds good to me!

Thanks @XiaohongGong

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

PR Comment: https://git.openjdk.org/valhalla/pull/952#issuecomment-1822732399


From jbhateja at openjdk.org  Wed Nov 22 13:07:44 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 22 Nov 2023 13:07:44 GMT
Subject: [lworld+vector] Integrated: 8319972: [lworld+vector] Enable
 intrinsification of Unsafe.finishPrivateBuffer.
In-Reply-To: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
References: <UoHGyHykawCf1AAT6kvwEc8Kf94_auXc_E1zINHg7WY=.5f4a246b-a110-458b-9e4b-125194423486@github.com>
Message-ID: <waHIugXSF6kc4gwf9Vw54wFVzfIC9D4BSfNZSuD7w0o=.f55608c2-cdf8-4af9-85ed-03a62129f6d1@github.com>

On Tue, 14 Nov 2023 15:00:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Re-enabling intrinsification of Unsafe.finishPrivateBuffer to fix performance degradation seen in Vector API JMH micro benchmarks. It's intrinsifation was disabled to fix incorrectness caused due to missing inductive InlineType Phi node in loops with Unsafe.put* operations. Since Unsafe.put* APIs returns a void hence JVM state is not altered and ciTypeFlow dataflow analysis does not encounter a inductive definition in the loop, due to this C2 parser misses creating an inductive phi node on
> encountering [loop header block](https://github.com/openjdk/valhalla/blob/lworld%2Bvector/src/hotspot/share/opto/parse1.cpp#L696). 
> 
> In order to maintain IR compliance with ciTypeFlow analysis C2 should prevent scalarizing value object b/w make and finish private buffer calls.
> 
> New behavior of unsafe inline expanders
> 1) makePrivate: Receive InlineTypeNode input and return initialized buffer in larval state.
> 2) finishPrivateBuffer: Receive value object buffer input and return rematerialize InlineTypeNode in non-larval state.
> 
> This may result into creation of unbalanced phi node at control flow merges where one of the phi input may InlineTypeNode and other is a buffer of compatible value type, but the IR still remains valid.
> 
> In addition compiler is now preventing elimination of allocation in larval state.
> 
> Validation Status:-
>   - All the VectorAPI and Valhalla JTREG tests are now passing at various AVX level with / wo -XX:+DoptimizeALot.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 7df90dfd
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7df90dfd83be7bba1c248ccdc12e060bfa31367c
Stats:     160 lines in 18 files changed: 39 ins; 51 del; 70 mod

8319972: [lworld+vector] Enable intrinsification of Unsafe.finishPrivateBuffer.

Reviewed-by: xgong

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

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


From xgong at openjdk.org  Thu Nov 23 01:20:30 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Thu, 23 Nov 2023 01:20:30 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
Message-ID: <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>

On Wed, 15 Nov 2023 07:33:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
> 
> Here is the log:
> 
> 
>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
> 
>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
> 
> 
> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
> 
> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
> 
> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
> 
> [1] https://github.com/openjdk/valhalla/pull/918
> 
> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.

@jatin-bhateja , could you please take a look at this PR? Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1823716406


From jbhateja at openjdk.org  Thu Nov 23 11:13:33 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 23 Nov 2023 11:13:33 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
 <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
Message-ID: <5J-OSdBtoHB1i_dNkrzJvY3EhsSBeCQF_j1L6koAKJ8=.5f25e058-6233-4ac6-8a70-db947c16ea3d@github.com>

On Thu, 23 Nov 2023 01:17:28 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
>> 
>> Here is the log:
>> 
>> 
>>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
>> 
>>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>>  Problematic frame:
>>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
>> 
>> 
>> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
>> 
>> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
>> 
>> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
>> 
>> [1] https://github.com/openjdk/valhalla/pull/918
>> 
>> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.
>
> @jatin-bhateja , could you please take a look at this PR? Thanks a lot!

Hi @XiaohongGong ,
Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1824240575


From thartmann at openjdk.org  Thu Nov 23 11:53:41 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 23 Nov 2023 11:53:41 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v2]
In-Reply-To: <4CajzSKvuxiYWeWwdLC9p0Go3QC3WGgGV2ewSjpJW0E=.e9203343-b6f4-46d1-bd69-6e9ffa10d84d@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <4CajzSKvuxiYWeWwdLC9p0Go3QC3WGgGV2ewSjpJW0E=.e9203343-b6f4-46d1-bd69-6e9ffa10d84d@github.com>
Message-ID: <5CftI4g96jPIdXhbsc8RUMYb_p-f9x2-2HvHkpodghI=.acca7d13-9341-463f-bd3a-a54809c7f917@github.com>

On Tue, 21 Nov 2023 14:58:55 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix wrong class type in test

test/hotspot/jtreg/runtime/valhalla/inlinetypes/AnnotationsTests.java line 52:

> 50:         Class c = tests.getClass();
> 51:         for (Method m : c.getDeclaredMethods()) {
> 52:           if (m.getName().startsWith("test_")) {

Nit: Test should use 4-whitespace indentation.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1403269848


From thartmann at openjdk.org  Thu Nov 23 12:39:27 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 23 Nov 2023 12:39:27 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
Message-ID: <UqhoZL_Gp9YlVSATYW63Ou7BaTAvGY9pfbXKiUfbHGc=.e1628acb-d076-403d-a394-ede51d7306a8@github.com>

On Tue, 21 Nov 2023 19:00:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field inheritance check should be limited to instance fields

test/hotspot/jtreg/runtime/valhalla/inlinetypes/VolatileTest.java line 31:

> 29:  * @modules java.base/jdk.internal.misc
> 30:  * @library /test/lib
> 31:  * @compile -XDenablePrimitiveClasses --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED VolatileTest.java

You could also remove the `-XDenablePrimitiveClasses` now from all tests.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1403327306


From thartmann at openjdk.org  Fri Nov 24 09:30:36 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 24 Nov 2023 09:30:36 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
Message-ID: <z1uLeq8z8hNJQStAo7o9fid5bQS3Cus1ST0ntbE0qcY=.1e7f5943-6e5c-42c9-a503-53c1a9dbf008@github.com>

On Tue, 21 Nov 2023 19:00:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field inheritance check should be limited to instance fields

Sorry for all the delayed comments, I'm reviewing this while trying to convert some of the C2 tests. The following test fails when disabling `EnablePrimitiveClasses`:

`java --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports java.base/jdk.internal.misc=ALL-UNNAMED -cp . -XX:+EnableValhalla -XX:-EnablePrimitiveClasses -Xint Test`


# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f665bbba4cb, pid=1616701, tid=1616702
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-11-20-1024510.tobias...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-11-20-1024510.tobias..., interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xc174cb]  FieldLayoutBuilder::inline_class_field_sorting(JavaThread*)+0x4cb

Stack: [0x00007f665ad49000,0x00007f665ae4a000],  sp=0x00007f665ae46b90,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc174cb]  FieldLayoutBuilder::inline_class_field_sorting(JavaThread*)+0x4cb  (array.hpp:126)
V  [libjvm.so+0xc1d3e7]  FieldLayoutBuilder::compute_inline_class_layout(JavaThread*)+0x27  (fieldLayoutBuilder.cpp:871)
V  [libjvm.so+0xc1daaa]  FieldLayoutBuilder::build_layout(JavaThread*)+0x1a  (fieldLayoutBuilder.cpp:1013)
V  [libjvm.so+0x98da69]  ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, JavaThread*)+0x1799  (classFileParser.cpp:6631)
V  [libjvm.so+0x98ee62]  ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x392  (classFileParser.cpp:6022)
V  [libjvm.so+0x1215f23]  KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0x133  (klassFactory.cpp:201)
V  [libjvm.so+0x17b19c3]  SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*)+0xb3  (systemDictionary.cpp:947)
V  [libjvm.so+0x102dae2]  jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*)+0x242  (jvm.cpp:952)
V  [libjvm.so+0x102dd54]  JVM_DefineClassWithSource+0x94  (jvm.cpp:1119)
C  [libjava.so+0xf2d2]  Java_java_lang_ClassLoader_defineClass1+0x182  (ClassLoader.c:139)




import jdk.internal.misc.VM;
import jdk.internal.vm.annotation.ImplicitlyConstructible;
import jdk.internal.vm.annotation.LooselyConsistentValue;
import jdk.internal.vm.annotation.NullRestricted;

public class Test {

    @ImplicitlyConstructible
    @LooselyConsistentValue
    static value class MyValueEmpty {

    }

    @ImplicitlyConstructible
    @LooselyConsistentValue
    static value class EmptyContainer {
        @NullRestricted
        MyValueEmpty empty = new MyValueEmpty();
    }

    public static void main(String[] args) {
        new EmptyContainer();
    }
}

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

Changes requested by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/947#pullrequestreview-1747601428


From thartmann at openjdk.org  Fri Nov 24 09:35:33 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 24 Nov 2023 09:35:33 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
Message-ID: <31P1vDBBRQXD42tChFy81ykVnoN-qXDdJbdX31n6SNs=.f99ff660-db38-4392-895c-c747a797aeb5@github.com>

On Tue, 21 Nov 2023 19:00:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field inheritance check should be limited to instance fields

This test (classes are equivalent to other test) fails only with `-XX:InlineFieldMaxFlatSize=0` but passes with default values:


Exception in thread "main" java.lang.RuntimeException: Failed
	at Test.main(Test.java:23)



    public static void main(String[] args) {
        if (new EmptyContainer() != EmptyContainer.default) {
            throw new RuntimeException("Failed");
        }
    }
``` 

I assume that's because it uses `.default` which will go away?

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

Changes requested by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/947#pullrequestreview-1747608338


From thartmann at openjdk.org  Fri Nov 24 10:05:40 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 24 Nov 2023 10:05:40 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
Message-ID: <rLXVePcUiwwyDTg-Z5gzXcElkuFwKnoWPXjW6QR46n4=.ca7c7b38-05d6-44e1-b920-20c0d65ad0ef@github.com>

On Tue, 21 Nov 2023 19:00:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field inheritance check should be limited to instance fields

I found another issue. Below test passes with default arguments but fails with `-XX:InlineFieldMaxFlatSize=0 `:

``` 
Exception in thread "main" java.lang.RuntimeException: Failed
	at Test.main(Test.java:26)



    public static void main(String[] args) {
        EmptyContainer empty = new EmptyContainer();
        EmptyContainer[] array = (EmptyContainer[])VM.newNullRestrictedArray(EmptyContainer.class, 1);
        array[0] = new EmptyContainer();
        if (empty != array[0]) {
            throw new RuntimeException("Failed");
        }
    }

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1825426459


From thartmann at openjdk.org  Fri Nov 24 11:10:34 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 24 Nov 2023 11:10:34 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
Message-ID: <flmyzXi_HRs5gyjOTV2UmSIwCjwdVhQpbet7cSzGiRc=.ce235cad-c380-4c77-ab42-6ad18b87dc78@github.com>

On Tue, 21 Nov 2023 19:00:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field inheritance check should be limited to instance fields

test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 134:

> 132:         Asserts.assertTrue(e.getClass() == NoClassDefFoundError.class, "Must be a NoClassDefFoundError");
> 133:         Asserts.assertTrue(e.getCause().getClass() == ExceptionInInitializerError.class, "Must be an ExceptionInInitializerError");
> 134:         // Transition model (annotations and array factory) doesn't permit multi-dimentional arrays tests

Shouldn't we support multi-dimensional arrays as well? Or are there any blockers?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1404233890


From xgong at openjdk.org  Mon Nov 27 01:19:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 27 Nov 2023 01:19:27 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
 <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
Message-ID: <fI8w7OgAtNKZjPOFjLm1JlnQpXx2YjBIudbdp3b3itA=.f198eaa2-37d6-407c-a14f-76eef9dd2452@github.com>

On Thu, 23 Nov 2023 01:17:28 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
>> 
>> Here is the log:
>> 
>> 
>>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
>> 
>>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>>  Problematic frame:
>>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
>> 
>> 
>> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
>> 
>> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
>> 
>> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
>> 
>> [1] https://github.com/openjdk/valhalla/pull/918
>> 
>> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.
>
> @jatin-bhateja , could you please take a look at this PR? Thanks a lot!

> Hi @XiaohongGong , Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.

Yes, considering that it is only used by C2 now, it's safe removing the multifields special handing. I suggest keeping it as it is now. One reason is the code may cannot be tested effectively, another is I'm considering whether we can take a further refactory to the multifields vectorization/scalarization in future. We may just keep the scalarized multifields in ci stage, and do the vectorization just in c2 compiler. So that all the special handling in ci could be cleaned-out. I plan to have a try for this in future.

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1826986123


From jbhateja at openjdk.org  Mon Nov 27 04:53:25 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 27 Nov 2023 04:53:25 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <fI8w7OgAtNKZjPOFjLm1JlnQpXx2YjBIudbdp3b3itA=.f198eaa2-37d6-407c-a14f-76eef9dd2452@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
 <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
 <fI8w7OgAtNKZjPOFjLm1JlnQpXx2YjBIudbdp3b3itA=.f198eaa2-37d6-407c-a14f-76eef9dd2452@github.com>
Message-ID: <Lx8T9GE-sY0i-eCxxKl6rJ09WZF6K1kyfqARB1VRK_A=.57f92886-c093-458a-ba78-e4eaeaeb90ec@github.com>

On Mon, 27 Nov 2023 01:16:29 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Hi @XiaohongGong , Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.
> 
> Yes, considering that it is only used by C2 now, it's safe removing the multifields special handing. I suggest keeping it as it is now. One reason is the code may cannot be tested effectively, another is I'm considering whether we can take a further refactory to the multifields vectorization/scalarization in future. We may just keep the scalarized multifields in ci stage, and do the vectorization just in c2 compiler. So that all the special handling in ci could be cleaned-out. I plan to have a try for this in future.

Hi @XiaohongGong ,

Sounds reasonable to me, can you kindly add a TODO in field_index_by_offset for multifile handling, we can remove it once our alternate implementation is in place, other change looks ok to me. In future if it's used by C1 then we may need to introduce special handling for multifield since ci model is shared by compilers. 

Best Regards,
Jatin

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1827121445


From xgong at openjdk.org  Mon Nov 27 07:38:43 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 27 Nov 2023 07:38:43 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport" [v2]
In-Reply-To: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
Message-ID: <zw39kSq74d8nvCyHCkU7YwTeun3bsw-ekkIEwXv0mR8=.e23768ab-7d21-4d8f-929f-97da1ba6c8ef@github.com>

> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
> 
> Here is the log:
> 
> 
>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
> 
>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
> 
> 
> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
> 
> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
> 
> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
> 
> [1] https://github.com/openjdk/valhalla/pull/918
> 
> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Add TODO comment in "ciInlineKlass::field_index_by_offset()"

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/953/files
  - new: https://git.openjdk.org/valhalla/pull/953/files/a23e09ff..0ecefc94

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

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

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


From xgong at openjdk.org  Mon Nov 27 09:34:37 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Mon, 27 Nov 2023 09:34:37 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <Lx8T9GE-sY0i-eCxxKl6rJ09WZF6K1kyfqARB1VRK_A=.57f92886-c093-458a-ba78-e4eaeaeb90ec@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
 <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
 <fI8w7OgAtNKZjPOFjLm1JlnQpXx2YjBIudbdp3b3itA=.f198eaa2-37d6-407c-a14f-76eef9dd2452@github.com>
 <Lx8T9GE-sY0i-eCxxKl6rJ09WZF6K1kyfqARB1VRK_A=.57f92886-c093-458a-ba78-e4eaeaeb90ec@github.com>
Message-ID: <4SuGq6Tth8SvCO0xA5klxgE76CyfaY2jm36hZAsEExs=.4bb9ab57-489a-4149-b94e-4d1c81a473f8@github.com>

On Mon, 27 Nov 2023 04:50:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Hi @XiaohongGong , Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.
>> 
>> Yes, considering that it is only used by C2 now, it's safe removing the multifields special handing. I suggest keeping it as it is now. One reason is the code may cannot be tested effectively, another is I'm considering whether we can take a further refactory to the multifields vectorization/scalarization in future. We may just keep the scalarized multifields in ci stage, and do the vectorization just in c2 compiler. So that all the special handling in ci could be cleaned-out. I plan to have a try for this in future.
>
>> > Hi @XiaohongGong , Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.
>> 
>> Yes, considering that it is only used by C2 now, it's safe removing the multifields special handing. I suggest keeping it as it is now. One reason is the code may cannot be tested effectively, another is I'm considering whether we can take a further refactory to the multifields vectorization/scalarization in future. We may just keep the scalarized multifields in ci stage, and do the vectorization just in c2 compiler. So that all the special handling in ci could be cleaned-out. I plan to have a try for this in future.
> 
> Hi @XiaohongGong ,
> 
> Sounds reasonable to me, can you kindly add a TODO in field_index_by_offset for multifile handling, we can remove it once our alternate implementation is in place, other change looks ok to me. In future if it's used by C1 then we may need to introduce special handling for multifield since ci model is shared by compilers. 
> 
> Best Regards,
> Jatin

Hi @jatin-bhateja , your comments have been addressed. Please help take a look again. Thanks a lot!

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1827463387


From jbhateja at openjdk.org  Mon Nov 27 10:13:31 2023
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 27 Nov 2023 10:13:31 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport" [v2]
In-Reply-To: <zw39kSq74d8nvCyHCkU7YwTeun3bsw-ekkIEwXv0mR8=.e23768ab-7d21-4d8f-929f-97da1ba6c8ef@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
 <zw39kSq74d8nvCyHCkU7YwTeun3bsw-ekkIEwXv0mR8=.e23768ab-7d21-4d8f-929f-97da1ba6c8ef@github.com>
Message-ID: <6AfeAp6ZyzdCcD8cv6u_8LF_DvDTW6oIGgyqtk6oP50=.e98e1466-92e0-49f4-b8c1-4f94964f1342@github.com>

On Mon, 27 Nov 2023 07:38:43 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
>> 
>> Here is the log:
>> 
>> 
>>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
>> 
>>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>>  Problematic frame:
>>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
>> 
>> 
>> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
>> 
>> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
>> 
>> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
>> 
>> [1] https://github.com/openjdk/valhalla/pull/918
>> 
>> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add TODO comment in "ciInlineKlass::field_index_by_offset()"

Marked as reviewed by jbhateja (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/953#pullrequestreview-1750074276


From fparain at openjdk.org  Mon Nov 27 19:27:36 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 27 Nov 2023 19:27:36 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <31P1vDBBRQXD42tChFy81ykVnoN-qXDdJbdX31n6SNs=.f99ff660-db38-4392-895c-c747a797aeb5@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
 <31P1vDBBRQXD42tChFy81ykVnoN-qXDdJbdX31n6SNs=.f99ff660-db38-4392-895c-c747a797aeb5@github.com>
Message-ID: <72wYonsYN7Uq_iy-_OukLwm_dnWFDKvkCmtnq4hBT9o=.81819c84-46f5-4503-94bb-42f37742ecef@github.com>

On Fri, 24 Nov 2023 09:32:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This test (classes are equivalent to other test) fails only with `-XX:InlineFieldMaxFlatSize=0` but passes with default values:
> 
> ```
> Exception in thread "main" java.lang.RuntimeException: Failed
> 	at Test.main(Test.java:23)
> ```
> 
> ```
>     public static void main(String[] args) {
>         if (new EmptyContainer() != EmptyContainer.default) {
>             throw new RuntimeException("Failed");
>         }
>     }
> ```
> 
> I assume that's because it uses `.default` which will go away?

`.default` will eventually be removed, so its implementation (`aconst_init`) hasn't been changed, even if trying to use the default value on a class without `@ImplicitlyConstructible` is wrong.
But here the problem is different. The newly created EmptyContainer has been created by a constructor which explicitly initialized the empty field with a reference to an instance of MyEmptyValue. The EmptyContainer.default value is the default value created by the VM, and the VM is lazy on null-free non-flat fields. The whole default value is initialized will zeroes, which is equivalent to initializing non-flat fields with a null reference, but on read, the VM substitute this null reference with the default value of the field's type. The Java code used for the substitutability test, called from `if_acmpeq` when two values of the same type are compared, is aware of the VM lazy initialization of null-free non-flat fields and usually recognizes this situation and perform the same substitution. The problem here is that the substitutability code doesn't recognize the field as a non-free non-flat field, because it isn't aware that the `@NullRestricited` annotation has the same effect as a 
 Q-descriptor in the field signature. So, the substitutability code performs a simple comparison between the reference from the initialized field and the null reference of the default value, finds them different and returns a value indicating that the two arguments are different.

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1828471889


From xgong at openjdk.org  Tue Nov 28 00:45:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 28 Nov 2023 00:45:27 GMT
Subject: [lworld+vector] RFR: 8319945: [lworld+vector] Fix vector api jtreg
 crash with "-XX:-EnableVectorSupport"
In-Reply-To: <Lx8T9GE-sY0i-eCxxKl6rJ09WZF6K1kyfqARB1VRK_A=.57f92886-c093-458a-ba78-e4eaeaeb90ec@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
 <Ky_VDmtc9eDWZeAVuod1JY-GiPHvKaNbPTEzqeg6m2c=.1bafed53-7587-4789-b559-5a9a56782361@github.com>
 <fI8w7OgAtNKZjPOFjLm1JlnQpXx2YjBIudbdp3b3itA=.f198eaa2-37d6-407c-a14f-76eef9dd2452@github.com>
 <Lx8T9GE-sY0i-eCxxKl6rJ09WZF6K1kyfqARB1VRK_A=.57f92886-c093-458a-ba78-e4eaeaeb90ec@github.com>
Message-ID: <ewlsCyKArCNgDV156GwvE8WI_uKXQi-36arNDcJtjGY=.95cae08c-1415-4ff9-b0dc-aac723ae0ba7@github.com>

On Mon, 27 Nov 2023 04:50:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> Hi @XiaohongGong , Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.
>> 
>> Yes, considering that it is only used by C2 now, it's safe removing the multifields special handing. I suggest keeping it as it is now. One reason is the code may cannot be tested effectively, another is I'm considering whether we can take a further refactory to the multifields vectorization/scalarization in future. We may just keep the scalarized multifields in ci stage, and do the vectorization just in c2 compiler. So that all the special handling in ci could be cleaned-out. I plan to have a try for this in future.
>
>> > Hi @XiaohongGong , Can you please also add multifield special handling in **_ciInlineKlass::field_index_by_offset(int offset)_**. As of now its only used by C2 and functionalty looks safe.
>> 
>> Yes, considering that it is only used by C2 now, it's safe removing the multifields special handing. I suggest keeping it as it is now. One reason is the code may cannot be tested effectively, another is I'm considering whether we can take a further refactory to the multifields vectorization/scalarization in future. We may just keep the scalarized multifields in ci stage, and do the vectorization just in c2 compiler. So that all the special handling in ci could be cleaned-out. I plan to have a try for this in future.
> 
> Hi @XiaohongGong ,
> 
> Sounds reasonable to me, can you kindly add a TODO in field_index_by_offset for multifile handling, we can remove it once our alternate implementation is in place, other change looks ok to me. In future if it's used by C1 then we may need to introduce special handling for multifield since ci model is shared by compilers. 
> 
> Best Regards,
> Jatin

Thanks for the review @jatin-bhateja !

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

PR Comment: https://git.openjdk.org/valhalla/pull/953#issuecomment-1828876937


From xgong at openjdk.org  Tue Nov 28 00:45:27 2023
From: xgong at openjdk.org (Xiaohong Gong)
Date: Tue, 28 Nov 2023 00:45:27 GMT
Subject: [lworld+vector] Integrated: 8319945: [lworld+vector] Fix vector api
 jtreg crash with "-XX:-EnableVectorSupport"
In-Reply-To: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
References: <sicDgrKJCuOkrESGpycPkCqhvQl9pAWlTabaqeGhosI=.ab0fbfde-3286-4f1a-800a-0d5db80446a7@github.com>
Message-ID: <uoKhJIHcRh7W9eg0bOKW4ufV6kqUNiYN0Ghh7WXZ3-I=.cdcd6f59-7993-4c1a-869b-efbe103d75ad@github.com>

On Wed, 15 Nov 2023 07:33:40 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Several vector api jtreg tests crash with `"-XX:-EnableVectorSupport"` when running on machines that the operations of vector payload can be vectorized.
> 
> Here is the log:
> 
> 
>  Internal Error (valhalla/src/hotspot/share/opto/library_call.cpp:2465), pid=467482, tid=467499
>  assert(bt == alias_type->basic_type() || bt == T_PRIMITIVE_OBJECT) failed: should match
> 
>  JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-git-5b2fa0aab)
>  Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-git-5b2fa0aab, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
>  Problematic frame:
>  V [[libjvm.so](http://libjvm.so/)+0x11b1738] LibraryCallKit::inline_unsafe_access(bool, BasicType, LibraryCallKit::AccessKind, bool)+0x13e8
> 
> 
> The reason is the matched field of the given offset in the vector payload is not found when using Usafe's access methods. And the root cause is when the operations of the multifields are vectorizable in C2, only the multifield base is added into the holder klass's non-static fields list in ci stage. Hence when accessing other multifields by Unsafe's get/put methods (which is the fall-back java implementation of current vector operations), the fields cannot be found with the given field offset.
> 
> This issue is involved by [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980) (see [1]), which refactors the multifields parsing in ci stage. The special handling for multifields in `ciInstanceKlass::get_field_by_offset` is removed. Adding it back can fix this issue.
> 
> This patch also reverted the special consideration for multifields when printing out the JVM state in a safepoint. It is not needed anymore, because the fields of an `InlineTypeNode` in C2 is always consistent with the holder klass's non-static fields after [JDK-8314980](https://bugs.openjdk.java.net/browse/JDK-8314980).
> 
> [1] https://github.com/openjdk/valhalla/pull/918
> 
> Verified with Vector API jtreg tests with `-XX:-EnableVectorSupport`, and all tests clean.

This pull request has now been integrated.

Changeset: 6d74481c
Author:    Xiaohong Gong <xgong at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6d74481c82bac61171dc3396fa847fb25473e0e0
Stats:     48 lines in 3 files changed: 21 ins; 19 del; 8 mod

8319945: [lworld+vector] Fix vector api jtreg crash with "-XX:-EnableVectorSupport"

Reviewed-by: jbhateja

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

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


From dsimms at openjdk.org  Tue Nov 28 10:04:35 2023
From: dsimms at openjdk.org (David Simms)
Date: Tue, 28 Nov 2023 10:04:35 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
Message-ID: <xX7OMxHD1nRmU1VKuPE1qjZ_u9RDZBJ4AQyD3wo4tjw=.ee340eb5-829f-42e8-8a85-2f27c28ee806@github.com>

On Tue, 21 Nov 2023 19:00:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Field inheritance check should be limited to instance fields

+1 to Tobias's comments, otherwise looking good

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/947#pullrequestreview-1752498001


From thartmann at openjdk.org  Tue Nov 28 10:56:41 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 Nov 2023 10:56:41 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <72wYonsYN7Uq_iy-_OukLwm_dnWFDKvkCmtnq4hBT9o=.81819c84-46f5-4503-94bb-42f37742ecef@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
 <31P1vDBBRQXD42tChFy81ykVnoN-qXDdJbdX31n6SNs=.f99ff660-db38-4392-895c-c747a797aeb5@github.com>
 <72wYonsYN7Uq_iy-_OukLwm_dnWFDKvkCmtnq4hBT9o=.81819c84-46f5-4503-94bb-42f37742ecef@github.com>
Message-ID: <7uaaqrwGT-jqzgdk3fhq-mthObhbMH04FjV50EQFyEA=.69e7b69e-e0f6-4e0d-8b83-97b397c4acc9@github.com>

On Mon, 27 Nov 2023 19:24:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> The problem here is that the substitutability code doesn't recognize the field as a non-free non-flat field, because it isn't aware that the @NullRestricited annotation has the same effect as a Q-descriptor in the field signature. So, the substitutability code performs a simple comparison between the reference from the initialized field and the null reference of the default value, finds them different and returns a value indicating that the two arguments are different.

Right, I hit the same issue when converting some other tests not using `.default`. Do you plan to adjust the substitutability code accordingly?

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1829576714


From thartmann at openjdk.org  Tue Nov 28 12:23:31 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 28 Nov 2023 12:23:31 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <z1uLeq8z8hNJQStAo7o9fid5bQS3Cus1ST0ntbE0qcY=.1e7f5943-6e5c-42c9-a503-53c1a9dbf008@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
 <z1uLeq8z8hNJQStAo7o9fid5bQS3Cus1ST0ntbE0qcY=.1e7f5943-6e5c-42c9-a503-53c1a9dbf008@github.com>
Message-ID: <FqFRw0NN5g9nsSdiL44GX2ZUhI1C7quKcDlbxoQdToU=.21769017-f7e4-4fab-ae92-43167a213a61@github.com>

On Fri, 24 Nov 2023 09:28:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> ```
> #  SIGSEGV (0xb) at pc=0x00007f665bbba4cb, pid=1616701, tid=1616702
> #
> # JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-11-20-1024510.tobias...)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-11-20-1024510.tobias..., interpreted mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0xc174cb]  FieldLayoutBuilder::inline_class_field_sorting(JavaThread*)+0x4cb```

I see as similar crash with this test:


import jdk.internal.vm.annotation.ImplicitlyConstructible;
import jdk.internal.vm.annotation.LooselyConsistentValue;
import jdk.internal.vm.annotation.NullRestricted;

@ImplicitlyConstructible
@LooselyConsistentValue
value class MyValue {
    int x = 0;
}

public class Test {
    @NullRestricted
    MyValue vtField2;
    
    public static void main(String[] args) {

    }
}


`java --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports java.base/jdk.internal.misc=ALL-UNNAMED Test`


# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fda53888090, pid=1828532, tid=1828533
#
# JRE version: Java(TM) SE Runtime Environment (22.0) (fastdebug build 22-lworld4ea-2023-11-20-1024510.tobias...)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 22-lworld4ea-2023-11-20-1024510.tobias..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xc18090]  FieldLayoutBuilder::regular_field_sorting(JavaThread*)+0x500

Stack: [0x00007fda52a16000,0x00007fda52b17000],  sp=0x00007fda52b13ac0,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc18090]  FieldLayoutBuilder::regular_field_sorting(JavaThread*)+0x500  (array.hpp:126)
V  [libjvm.so+0xc1d797]  FieldLayoutBuilder::compute_regular_layout(JavaThread*)+0x27  (fieldLayoutBuilder.cpp:822)
V  [libjvm.so+0xc1dad5]  FieldLayoutBuilder::build_layout(JavaThread*)+0x45  (fieldLayoutBuilder.cpp:1015)
V  [libjvm.so+0x98da69]  ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, JavaThread*)+0x1799  (classFileParser.cpp:6631)
V  [libjvm.so+0x98ee62]  ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x392  (classFileParser.cpp:6022)
``` 

Setting `-XX:+EnablePrimitiveClasses` makes the issue disappear.

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1829733554


From fparain at openjdk.org  Tue Nov 28 15:57:28 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 28 Nov 2023 15:57:28 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v4]
In-Reply-To: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
Message-ID: <EISArRMhYmpmb7K0DM76lEYiyGzr2JPUtnl3zNjCqV4=.90c22d99-2d58-475e-bfac-ed65ba827561@github.com>

> Adding internal null-restricted storage API points

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

  Change effects of EnableValhalla/EnablePrimitiveClasses flags

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/947/files
  - new: https://git.openjdk.org/valhalla/pull/947/files/539d53ef..3f505b4c

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

  Stats: 206 lines in 8 files changed: 5 ins; 1 del; 200 mod
  Patch: https://git.openjdk.org/valhalla/pull/947.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/947/head:pull/947

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


From fparain at openjdk.org  Wed Nov 29 14:34:36 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 29 Nov 2023 14:34:36 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v3]
In-Reply-To: <flmyzXi_HRs5gyjOTV2UmSIwCjwdVhQpbet7cSzGiRc=.ce235cad-c380-4c77-ab42-6ad18b87dc78@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <TxwvQBBe9l37KhvloSjZ9SGuBoAFuk5gj53od7fauNk=.a9f243f0-8bef-4bfd-a1e8-019f1cfe43d9@github.com>
 <flmyzXi_HRs5gyjOTV2UmSIwCjwdVhQpbet7cSzGiRc=.ce235cad-c380-4c77-ab42-6ad18b87dc78@github.com>
Message-ID: <Ruk0QenK9TQ2FyI35OU9-gEyop0Ai61HZmJ6nSy-OLc=.3af7686c-e21f-4c2e-bbcd-041e0089ffe5@github.com>

On Fri, 24 Nov 2023 11:08:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Field inheritance check should be limited to instance fields
>
> test/hotspot/jtreg/runtime/valhalla/inlinetypes/ClassInitializationFailuresTest.java line 134:
> 
>> 132:         Asserts.assertTrue(e.getClass() == NoClassDefFoundError.class, "Must be a NoClassDefFoundError");
>> 133:         Asserts.assertTrue(e.getCause().getClass() == ExceptionInInitializerError.class, "Must be an ExceptionInInitializerError");
>> 134:         // Transition model (annotations and array factory) doesn't permit multi-dimentional arrays tests
> 
> Shouldn't we support multi-dimensional arrays as well? Or are there any blockers?

The new API to create flat arrays only supports single-dimension arrays. But because multi-dimensional arrays are basically a set of reference arrays with only the last-dimension array being an array of the element type, it is possible to create manually multi-dimensional arrays on top of this API.
Those tests were checking the behavior of `multianewarray` but with the removal of Q-descriptors, this bytecode cannot be used to create multi-dimensional arrays with a flat last-dimension array.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/947#discussion_r1409372298


From fparain at openjdk.org  Wed Nov 29 14:56:43 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 29 Nov 2023 14:56:43 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v4]
In-Reply-To: <EISArRMhYmpmb7K0DM76lEYiyGzr2JPUtnl3zNjCqV4=.90c22d99-2d58-475e-bfac-ed65ba827561@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <EISArRMhYmpmb7K0DM76lEYiyGzr2JPUtnl3zNjCqV4=.90c22d99-2d58-475e-bfac-ed65ba827561@github.com>
Message-ID: <b2JC3B6QIZha03ZxKVilx53xY_9C1Oj35NjgrEgjaRw=.22de6a4d-7f02-449d-8ca2-711c628ac833@github.com>

On Tue, 28 Nov 2023 15:57:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change effects of EnableValhalla/EnablePrimitiveClasses flags

Last push should fix all cases where crashes were prevented by adding back `-XX:+EnablePrimitiveClasses`.

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1832050132


From fparain at openjdk.org  Wed Nov 29 18:49:49 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 29 Nov 2023 18:49:49 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v5]
In-Reply-To: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
Message-ID: <M0Eb4oYAqSJa9gNjO4J3D0UtEqQJfkw0lfwsfOvfhfU=.2c17d07e-8ad0-4cbe-b0ab-f78ed081646d@github.com>

> Adding internal null-restricted storage API points

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

  Fix EnableValhalla/EnablePrimitiveClasses flags on aarch64

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/947/files
  - new: https://git.openjdk.org/valhalla/pull/947/files/3f505b4c..5b5bdfc5

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

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

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


From rriggs at openjdk.org  Wed Nov 29 23:11:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Nov 2023 23:11:29 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v5]
In-Reply-To: <M0Eb4oYAqSJa9gNjO4J3D0UtEqQJfkw0lfwsfOvfhfU=.2c17d07e-8ad0-4cbe-b0ab-f78ed081646d@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <M0Eb4oYAqSJa9gNjO4J3D0UtEqQJfkw0lfwsfOvfhfU=.2c17d07e-8ad0-4cbe-b0ab-f78ed081646d@github.com>
Message-ID: <7fDRdD-acTjHA1E2hV0K_k_yFjDOiiAjE0t_azd_8o4=.0b204899-f0ad-43fa-bb84-8c0ed2df73d4@github.com>

On Wed, 29 Nov 2023 18:49:49 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix EnableValhalla/EnablePrimitiveClasses flags on aarch64

The substitutably code is using a VarHandle, that bottoms out in Unsafe.getValue(o, offset, valueType).
Does the VM using a  lazy encoding of the default instance as null result in code using unsafe having to know about the VM representation? 
I'd like to think NOT, but I don't think Unsafe has enough information about the field stored at offset to do the right thing.
My second choice is that the VarHandle for the field replaces the literal null of a @NullRestricted field with the default.

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1832843917


From fparain at openjdk.org  Thu Nov 30 14:07:41 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 30 Nov 2023 14:07:41 GMT
Subject: [lworld] RFR: 8320437: [lworld] Adding internal null-restricted
 storage API points [v5]
In-Reply-To: <M0Eb4oYAqSJa9gNjO4J3D0UtEqQJfkw0lfwsfOvfhfU=.2c17d07e-8ad0-4cbe-b0ab-f78ed081646d@github.com>
References: <d6cPIt-QYqf-9XIwCL8UR9d9uPga4nu3b7OoqgHRgso=.b4bbd087-0a41-4d90-8527-fe093ba13f47@github.com>
 <M0Eb4oYAqSJa9gNjO4J3D0UtEqQJfkw0lfwsfOvfhfU=.2c17d07e-8ad0-4cbe-b0ab-f78ed081646d@github.com>
Message-ID: <UGwLHdRjjtjrlqEO3CfoAKpgMmw3UJB9D6U4WW3R_FA=.d66f6c58-d236-4a31-b82c-c36337e7debe@github.com>

On Wed, 29 Nov 2023 18:49:49 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Adding internal null-restricted storage API points
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix EnableValhalla/EnablePrimitiveClasses flags on aarch64

Right now, the substitution of the null reference with the default value is performed in Unsafe:

```    public Object getReference(Object o, long offset, Class<?> type) {
        Object ref = getReference(o, offset);
        if (ref == null && PrimitiveClass.isPrimitiveValueType(type)) {
            // If the type of the returned reference is a primitive value type,
            // return an uninitialized default value if null
            ref = uninitializedDefaultValue(type);
        }
        return ref;
    }

The problem in this method is that there's no information about the field except the offset, so it would be expensive to retrieve the field information to check the presence of the @NullRestricted annotation.
Moving the logic to VarHandle would make sense to me.

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

PR Comment: https://git.openjdk.org/valhalla/pull/947#issuecomment-1833845365