From fparain at openjdk.org  Fri Mar  1 21:01:05 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 1 Mar 2024 21:01:05 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401
Message-ID: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>

Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.

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

Commit messages:
 - First C1 fix to support JEP 401

Changes: https://git.openjdk.org/valhalla/pull/1029/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1029&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327150
  Stats: 144 lines in 19 files changed: 14 ins; 109 del; 21 mod
  Patch: https://git.openjdk.org/valhalla/pull/1029.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1029/head:pull/1029

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


From dsimms at openjdk.org  Mon Mar  4 11:16:16 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 4 Mar 2024 11:16:16 GMT
Subject: [lworld] RFR: 8327213: [lworld] Valhalla runtime testing move to
 classfile API
Message-ID: <SRNRRkmWWLWIkFwEIJIhtQmqFBElJmkYceXg1mlXHeM=.9a68a51e-1702-4c0d-93ad-3d9863ef6781@github.com>

Move from the experimental bytecode API to the classfile API

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

Commit messages:
 - 8327213: [lworld] Valhalla runtime testing move to classfile API

Changes: https://git.openjdk.org/valhalla/pull/1030/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1030&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327213
  Stats: 406 lines in 5 files changed: 63 ins; 170 del; 173 mod
  Patch: https://git.openjdk.org/valhalla/pull/1030.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1030/head:pull/1030

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


From thartmann at openjdk.org  Mon Mar  4 13:39:59 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 4 Mar 2024 13:39:59 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401
In-Reply-To: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
Message-ID: <KCL9BoYBzdGyzZSfU4B2tq2IYVPOdA2CCBNewZm_wgI=.c10b8cb5-ee60-42e8-94c2-88c3830f4a35@github.com>

On Fri, 1 Mar 2024 20:57:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.

Thanks for working on this, Fred! Do all compiler tests now pass with `-XX:TieredStopAtLevel=3` or is there some work left?

src/hotspot/share/c1/c1_Compiler.cpp line 260:

> 258:     if (PrintCFGToFile) {  // borrowing flag for JDK build
> 259:       tty->print_cr("Starting C1 compilation of %s.%s", method->holder()->name()->as_utf8(), method->name()->as_utf8());
> 260:     }

Why do you need this?

src/hotspot/share/c1/c1_Instruction.hpp line 2068:

> 2066:       // FIXME: Removal of NewInlineTypeInstance instruction makes those assert hard to write
> 2067:       // assert(x->as_NewInlineTypeInstance() == nullptr || y->type() == objectNull, "Sanity check");
> 2068:       // assert(y->as_NewInlineTypeInstance() == nullptr || x->type() == objectNull, "Sanity check");

Let's remove these checks for now.

src/hotspot/share/c1/c1_Runtime1.cpp line 373:

> 371:   h->initialize(CHECK);
> 372:   oop obj = nullptr;
> 373:   if(h->is_empty_inline_type()) {

Suggestion:

  if (h->is_empty_inline_type()) {

src/hotspot/share/c1/c1_Runtime1.cpp line 374:

> 372:   oop obj = nullptr;
> 373:   if(h->is_empty_inline_type()) {
> 374:     assert(h->is_inline_klass(), "Sanity check");

Below `InlineKlass::cast` will already assert that.

src/hotspot/share/c1/c1_Runtime1.cpp line 375:

> 373:   if(h->is_empty_inline_type()) {
> 374:     assert(h->is_inline_klass(), "Sanity check");
> 375:     assert(InlineKlass::cast(h)->default_value() != nullptr, "");

This can be moved below and check `obj != nullptr` directly.

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

PR Review: https://git.openjdk.org/valhalla/pull/1029#pullrequestreview-1914324112
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511173608
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511173264
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511169072
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511170599
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511171181


From fparain at openjdk.org  Mon Mar  4 14:10:58 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 4 Mar 2024 14:10:58 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401
In-Reply-To: <KCL9BoYBzdGyzZSfU4B2tq2IYVPOdA2CCBNewZm_wgI=.c10b8cb5-ee60-42e8-94c2-88c3830f4a35@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
 <KCL9BoYBzdGyzZSfU4B2tq2IYVPOdA2CCBNewZm_wgI=.c10b8cb5-ee60-42e8-94c2-88c3830f4a35@github.com>
Message-ID: <RnY5n2BuD9EJ_uszWF7WKBMJP08ckn3alNvXJhUbbm8=.2e1b2f08-d354-4cc2-84fb-107c34ef21aa@github.com>

On Mon, 4 Mar 2024 13:36:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
>> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.
>
> src/hotspot/share/c1/c1_Compiler.cpp line 260:
> 
>> 258:     if (PrintCFGToFile) {  // borrowing flag for JDK build
>> 259:       tty->print_cr("Starting C1 compilation of %s.%s", method->holder()->name()->as_utf8(), method->name()->as_utf8());
>> 260:     }
> 
> Why do you need this?

Oops, remaining of tracing during debugging. Removed.

> src/hotspot/share/c1/c1_Instruction.hpp line 2068:
> 
>> 2066:       // FIXME: Removal of NewInlineTypeInstance instruction makes those assert hard to write
>> 2067:       // assert(x->as_NewInlineTypeInstance() == nullptr || y->type() == objectNull, "Sanity check");
>> 2068:       // assert(y->as_NewInlineTypeInstance() == nullptr || x->type() == objectNull, "Sanity check");
> 
> Let's remove these checks for now.

OK

> src/hotspot/share/c1/c1_Runtime1.cpp line 373:
> 
>> 371:   h->initialize(CHECK);
>> 372:   oop obj = nullptr;
>> 373:   if(h->is_empty_inline_type()) {
> 
> Suggestion:
> 
>   if (h->is_empty_inline_type()) {

Fixed.

> src/hotspot/share/c1/c1_Runtime1.cpp line 374:
> 
>> 372:   oop obj = nullptr;
>> 373:   if(h->is_empty_inline_type()) {
>> 374:     assert(h->is_inline_klass(), "Sanity check");
> 
> Below `InlineKlass::cast` will already assert that.

Removed.

> src/hotspot/share/c1/c1_Runtime1.cpp line 375:
> 
>> 373:   if(h->is_empty_inline_type()) {
>> 374:     assert(h->is_inline_klass(), "Sanity check");
>> 375:     assert(InlineKlass::cast(h)->default_value() != nullptr, "");
> 
> This can be moved below and check `obj != nullptr` directly.

Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511223684
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511222524
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511218396
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511221526
PR Review Comment: https://git.openjdk.org/valhalla/pull/1029#discussion_r1511221856


From fparain at openjdk.org  Mon Mar  4 14:38:09 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 4 Mar 2024 14:38:09 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401
In-Reply-To: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
Message-ID: <mmal9A_51QUioOW0QsJiUPQQYYCkUjFAAXwOBly3gP0=.d2621552-aaa3-4c62-86a3-b1e2c45343a0@github.com>

On Fri, 1 Mar 2024 20:57:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.

Those fixes allow many C1 tests to pass, for instance all tests in TestC1.java now pass in scenarios #0 and #3, but the whole test fails because of scenarios #1 and #4 which involve C2.
Running all tests in test/hotspot/jtreg/compiler/valhalla/inlinetypes with `-XX:TieredStopAtLevel=3` shows many errors due to C2 (`assert(false) failed: Should have been buffered`), some verifier errors, and some tests not compliant with the new type hierarchy rules for value classes. But unless I missed them, I didn't notice failures directly caused by C1. However, it doesn't guarantee that once fixed, the problematic tests mentioned above will pass with C1.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1029#issuecomment-1976716141


From fparain at openjdk.org  Mon Mar  4 14:38:09 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 4 Mar 2024 14:38:09 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401 [v2]
In-Reply-To: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
Message-ID: <aP00jghoD9zrPamX9dawTvU_1Zmg6SFhMq54cQOkXtc=.deed2147-422e-46db-b9b7-331b840be3e7@github.com>

> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.

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

  Fixes from Tobias' review

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1029/files
  - new: https://git.openjdk.org/valhalla/pull/1029/files/9879e314..9c064501

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

  Stats: 12 lines in 3 files changed: 1 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1029.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1029/head:pull/1029

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


From thartmann at openjdk.org  Mon Mar  4 14:41:04 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 4 Mar 2024 14:41:04 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401 [v2]
In-Reply-To: <aP00jghoD9zrPamX9dawTvU_1Zmg6SFhMq54cQOkXtc=.deed2147-422e-46db-b9b7-331b840be3e7@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
 <aP00jghoD9zrPamX9dawTvU_1Zmg6SFhMq54cQOkXtc=.deed2147-422e-46db-b9b7-331b840be3e7@github.com>
Message-ID: <CK8e_EeLDyHqXcjXk-yTwJDHY6LO5is3Pc-9GYobMpw=.7d02b9d8-921b-412d-b919-2f31318a1aee@github.com>

On Mon, 4 Mar 2024 14:38:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
>> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes from Tobias' review

Okay, thanks for the details. Looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1029#pullrequestreview-1914486140


From fparain at openjdk.org  Mon Mar  4 14:47:56 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 4 Mar 2024 14:47:56 GMT
Subject: [lworld] RFR: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401 [v2]
In-Reply-To: <aP00jghoD9zrPamX9dawTvU_1Zmg6SFhMq54cQOkXtc=.deed2147-422e-46db-b9b7-331b840be3e7@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
 <aP00jghoD9zrPamX9dawTvU_1Zmg6SFhMq54cQOkXtc=.deed2147-422e-46db-b9b7-331b840be3e7@github.com>
Message-ID: <V6c9V1SRvikIq7iX1gwymXyc4lOUJsRkVHXKXSySSvY=.cef67a1e-4edd-48e7-8c5a-319a3fd59b78@github.com>

On Mon, 4 Mar 2024 14:38:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
>> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixes from Tobias' review

Thanks for the reviews Tobias.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1029#issuecomment-1976743858


From fparain at openjdk.org  Mon Mar  4 14:47:57 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 4 Mar 2024 14:47:57 GMT
Subject: [lworld] Integrated: 8327150: [lworld] Update C1 to support new value
 construction scheme from JEP 401
In-Reply-To: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
References: <rXN3TESFVeQR5WT0XVokpXKEyZzljK1Ig8u33XIZqVo=.311ed603-e0d3-4faa-b2b1-3cd4995f3568@github.com>
Message-ID: <l7u_yfbkMMolgIk443KNHOZelBd75uEecJUN0Erywr4=.eded0838-9fd4-4c4f-b9d2-a5fa625828ea@github.com>

On Fri, 1 Mar 2024 20:57:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix value creation in C1, remove the old special node for value creation and out everything under the NewInstance node.
> There's also a fix in can_be_inline_klass() method that was causing a wrong behavior for acmp.

This pull request has now been integrated.

Changeset: 2742ec77
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2742ec77d2accaaa05ec9f1fa63f1f03ab52a0db
Stats:     141 lines in 18 files changed: 9 ins; 113 del; 19 mod

8327150: [lworld] Update C1 to support new value construction scheme from JEP 401

Reviewed-by: thartmann

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

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


From fparain at openjdk.org  Mon Mar  4 21:41:18 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 4 Mar 2024 21:41:18 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a complete
 rework
Message-ID: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>

Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.

Fred

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

Commit messages:
 - Fix exception message
 - Merge remote-tracking branch 'upstream/lworld' into preload
 - Preloading reworked

Changes: https://git.openjdk.org/valhalla/pull/999/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=999&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327253
  Stats: 829 lines in 13 files changed: 578 ins; 143 del; 108 mod
  Patch: https://git.openjdk.org/valhalla/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/999/head:pull/999

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


From dsimms at openjdk.org  Tue Mar  5 06:50:03 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 5 Mar 2024 06:50:03 GMT
Subject: [lworld] RFR: 8327280: [lworld] aarch64 compilation fails without
 support for JDK-8327150
Message-ID: <tGXFNoqqRFYzBEzO-vFOtoap4PQ-xYwfs4AYGV26vMM=.3c151d1f-1b2f-448b-85f4-b15ee95251d8@github.com>

Remove the old "new inline instance" code

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

Commit messages:
 - 8327280: [lworld] aarch64 compilation fails without support for JDK-8327150

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

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


From dsimms at openjdk.org  Tue Mar  5 07:26:53 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 5 Mar 2024 07:26:53 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework
In-Reply-To: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
Message-ID: <QWUAwAaFl2WMZUxmQU90cZ0v705-ta_bYnX0AQue1rc=.2f887b83-5a73-4ce0-bb13-e75f1a842f9b@github.com>

On Wed, 7 Feb 2024 20:26:10 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
> 
> Fred

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1:

> 1: /*

Fairly minor change for aarch64, could we include that too ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/999#discussion_r1512242613


From fparain at openjdk.org  Tue Mar  5 13:51:11 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 13:51:11 GMT
Subject: [lworld] RFR: 8327374: [lworld] Fix C1 build in aarch64
Message-ID: <T-NsBbZmMQdWdhw66B3GNViXisjcUYha262ga7NkO78=.54c0cc71-bc2b-4b13-90b4-55eb30f46c75@github.com>

Small fixes on aarch64 to fix build after JDK-8327150 changes.

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

Commit messages:
 - Fix C1 build on aarch64

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

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


From dsimms at openjdk.org  Tue Mar  5 14:43:55 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 5 Mar 2024 14:43:55 GMT
Subject: [lworld] Integrated: 8327213: [lworld] Valhalla runtime testing move
 to classfile API
In-Reply-To: <SRNRRkmWWLWIkFwEIJIhtQmqFBElJmkYceXg1mlXHeM=.9a68a51e-1702-4c0d-93ad-3d9863ef6781@github.com>
References: <SRNRRkmWWLWIkFwEIJIhtQmqFBElJmkYceXg1mlXHeM=.9a68a51e-1702-4c0d-93ad-3d9863ef6781@github.com>
Message-ID: <WQ_ht5U9AT5pC22LY-jdS-TuT_2VM8n_i7wAf859nTg=.d131d4c5-ed8d-44fd-9885-3e36e1e0130d@github.com>

On Mon, 4 Mar 2024 11:12:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Move from the experimental bytecode API to the classfile API

This pull request has now been integrated.

Changeset: 1f410430
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b
Stats:     406 lines in 5 files changed: 63 ins; 170 del; 173 mod

8327213: [lworld] Valhalla runtime testing move to classfile API

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

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


From fparain at openjdk.org  Tue Mar  5 14:49:02 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 14:49:02 GMT
Subject: [lworld] RFR: 8327374: [lworld] Fix C1 build in aarch64
In-Reply-To: <T-NsBbZmMQdWdhw66B3GNViXisjcUYha262ga7NkO78=.54c0cc71-bc2b-4b13-90b4-55eb30f46c75@github.com>
References: <T-NsBbZmMQdWdhw66B3GNViXisjcUYha262ga7NkO78=.54c0cc71-bc2b-4b13-90b4-55eb30f46c75@github.com>
Message-ID: <mEOJkG1bJ4_poHRVyEkP-Vqq_-oMhmf0ImeJX6UTRm0=.9c21c671-bce8-4f8f-a0e9-61c19c1bf24b@github.com>

On Tue, 5 Mar 2024 13:46:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fixes on aarch64 to fix build after JDK-8327150 changes.

Duplicate of https://github.com/openjdk/valhalla/pull/1031

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

PR Comment: https://git.openjdk.org/valhalla/pull/1032#issuecomment-1978939564


From fparain at openjdk.org  Tue Mar  5 14:49:03 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 14:49:03 GMT
Subject: [lworld] Withdrawn: 8327374: [lworld] Fix C1 build in aarch64
In-Reply-To: <T-NsBbZmMQdWdhw66B3GNViXisjcUYha262ga7NkO78=.54c0cc71-bc2b-4b13-90b4-55eb30f46c75@github.com>
References: <T-NsBbZmMQdWdhw66B3GNViXisjcUYha262ga7NkO78=.54c0cc71-bc2b-4b13-90b4-55eb30f46c75@github.com>
Message-ID: <31aNJLPx-_VzJ9QRsYBTtE76HImPL7MzCI6gvnTYri8=.525734d6-b748-46b9-9a3a-61ce9aa93601@github.com>

On Tue, 5 Mar 2024 13:46:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fixes on aarch64 to fix build after JDK-8327150 changes.

This pull request has been closed without being integrated.

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

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


From fparain at openjdk.org  Tue Mar  5 14:56:02 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 14:56:02 GMT
Subject: [lworld] RFR: 8327280: [lworld] aarch64 compilation fails without
 support for JDK-8327150
In-Reply-To: <tGXFNoqqRFYzBEzO-vFOtoap4PQ-xYwfs4AYGV26vMM=.3c151d1f-1b2f-448b-85f4-b15ee95251d8@github.com>
References: <tGXFNoqqRFYzBEzO-vFOtoap4PQ-xYwfs4AYGV26vMM=.3c151d1f-1b2f-448b-85f4-b15ee95251d8@github.com>
Message-ID: <R7irUlCJ1rDw-8Bb9lNvm_P_O09773PBePBbWmGcuPI=.7c0dc51b-53c1-4add-a745-d5d98ae9c807@github.com>

On Tue, 5 Mar 2024 06:46:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Remove the old "new inline instance" code

LGTM, thank you for fixing aarch64.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1031#pullrequestreview-1917263110


From dsimms at openjdk.org  Tue Mar  5 14:56:02 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 5 Mar 2024 14:56:02 GMT
Subject: [lworld] Integrated: 8327280: [lworld] aarch64 compilation fails
 without support for JDK-8327150
In-Reply-To: <tGXFNoqqRFYzBEzO-vFOtoap4PQ-xYwfs4AYGV26vMM=.3c151d1f-1b2f-448b-85f4-b15ee95251d8@github.com>
References: <tGXFNoqqRFYzBEzO-vFOtoap4PQ-xYwfs4AYGV26vMM=.3c151d1f-1b2f-448b-85f4-b15ee95251d8@github.com>
Message-ID: <GagWzB-57ufnpPLfxhl14oHB6jAeKAg3kUxbUyBo9Gc=.f62861b6-c3b8-43d3-a04f-f6fbe0c6a7aa@github.com>

On Tue, 5 Mar 2024 06:46:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Remove the old "new inline instance" code

This pull request has now been integrated.

Changeset: 70c25b34
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/70c25b34f93be6db1765d49156040d7174f56598
Stats:     27 lines in 3 files changed: 0 ins; 25 del; 2 mod

8327280: [lworld] aarch64 compilation fails without support for JDK-8327150

Reviewed-by: fparain

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

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


From dan.heidinga at oracle.com  Tue Mar  5 15:06:30 2024
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Tue, 5 Mar 2024 15:06:30 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
Message-ID: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>

(Cross-posting to both valhalla-dev and lilliput-dev)

Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward.  I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post.

Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:

* is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.

* is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a ?substitutability? test is required.

For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.

Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).

We use two bits to identify the special cases of arrays:

* is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.

* is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.

Arrays ? being identity objects ? need both their hash codes and locking bits.

This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we?re working on reconfirming those results.

How does this approach fit with the current Lilliput plans?

--Dan

[0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240305/1472fa42/attachment.htm>

From vromero at openjdk.org  Tue Mar  5 16:29:21 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Mar 2024 16:29:21 GMT
Subject: [lworld] RFR: 8327235: [lworld] remove the 'enablePrimitiveClasses'
 compiler option from tests
Message-ID: <IG9mKZAlEP1lIzWIJewNLDQIVtClbfRDARmwX0dJdLI=.f7fd352b-53c8-48e5-9685-9a4f6f616853@github.com>

just removing the `enablePrimitiveClasses` compiler option which is now a no-op

TIA

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

Commit messages:
 - 8327235: [lworld] remove the 'enablePrimitiveClasses' compiler option from tests

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

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


From vromero at openjdk.org  Tue Mar  5 16:35:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Mar 2024 16:35:09 GMT
Subject: [lworld] RFR: 8327235: [lworld] remove the
 'enablePrimitiveClasses' compiler option from tests [v2]
In-Reply-To: <IG9mKZAlEP1lIzWIJewNLDQIVtClbfRDARmwX0dJdLI=.f7fd352b-53c8-48e5-9685-9a4f6f616853@github.com>
References: <IG9mKZAlEP1lIzWIJewNLDQIVtClbfRDARmwX0dJdLI=.f7fd352b-53c8-48e5-9685-9a4f6f616853@github.com>
Message-ID: <dX8pF3_PvyJPmYfDThsM8Cdb6NqUxnTh5DQmTnT-rMU=.14b896e6-26a4-48fb-88c0-b802bcdbe9f6@github.com>

> just removing the `enablePrimitiveClasses` compiler option which is now a no-op
> 
> TIA

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

 - Merge lworld
 - 8327235: [lworld] remove the 'enablePrimitiveClasses' compiler option from tests

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

Changes: https://git.openjdk.org/valhalla/pull/1033/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1033&range=01
  Stats: 36 lines in 28 files changed: 0 ins; 7 del; 29 mod
  Patch: https://git.openjdk.org/valhalla/pull/1033.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1033/head:pull/1033

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


From vromero at openjdk.org  Tue Mar  5 16:35:09 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Mar 2024 16:35:09 GMT
Subject: [lworld] Integrated: 8327235: [lworld] remove the
 'enablePrimitiveClasses' compiler option from tests
In-Reply-To: <IG9mKZAlEP1lIzWIJewNLDQIVtClbfRDARmwX0dJdLI=.f7fd352b-53c8-48e5-9685-9a4f6f616853@github.com>
References: <IG9mKZAlEP1lIzWIJewNLDQIVtClbfRDARmwX0dJdLI=.f7fd352b-53c8-48e5-9685-9a4f6f616853@github.com>
Message-ID: <3VMaerSOIVdSjdW2DzYyOGCrKTnxSSKn-G534vtGEG0=.3ea45ac1-e871-4056-a2e7-497ebf5fa166@github.com>

On Tue, 5 Mar 2024 16:25:16 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just removing the `enablePrimitiveClasses` compiler option which is now a no-op
> 
> TIA

This pull request has now been integrated.

Changeset: 614f7fc0
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/614f7fc09ea82ea234f1e7fd063ceb4a0fb3fb39
Stats:     36 lines in 28 files changed: 0 ins; 7 del; 29 mod

8327235: [lworld] remove the 'enablePrimitiveClasses' compiler option from tests

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

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


From rkennke at amazon.de  Tue Mar  5 15:31:59 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Tue, 5 Mar 2024 15:31:59 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
Message-ID: <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>

Hi Dan,

Thank you for the information, that is very useful! Yes, I agree that we should negotiate about this ;-)

I have two questions:
- Are there requirements/constraints on your side on the position of some of the bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to indicate self-forwarding in the GC. It kinda needs to be that bit, because we expect that the header can also be overlaid with a forwarding pointer, and those use all bits except the lowest 3. (See: https://github.com/openjdk/jdk/pull/17755)
- Are any of the bits required during (full) GC? For example, in Lilliput, we want to make the hash-code use only 2 bits, and allocate the storage for the actual hash-code on-demand. However, this means that we need the hash-code bits to determine the object?s size, and therefore must not displace the hash-bits during GC (not even temporarily). This is also true for the Klass* bits, that we plan to go into the object header as well. (See: https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and https://github.com/openjdk/lilliput/pull/137)

For a descriptions of our current plans (which are likely to change until we?re done), see the JEP:
https://openjdk.org/jeps/450

Thanks,
Roman


> On Mar 5, 2024, at 4:06?PM, Dan Heidinga <dan.heidinga at oracle.com> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> (Cross-posting to both valhalla-dev and lilliput-dev)
>  Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward.  I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post.
>  Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:
>  * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.
>  * is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a ?substitutability? test is required.
>  For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.
>  Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).
>  We use two bits to identify the special cases of arrays:
>  * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.
>  * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.
>  Arrays ? being identity objects ? need both their hash codes and locking bits.
>  This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we?re working on reconfirming those results.
>  How does this approach fit with the current Lilliput plans?
>  --Dan
>  [0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From thomas.stuefe at gmail.com  Tue Mar  5 16:28:56 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 5 Mar 2024 17:28:56 +0100
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
Message-ID: <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>

Hi Dan,

In addition to Roman's answer, we plan to reduce the Klasspointer to 22
bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and
still leave us with 4 unused bits.

Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this
year I think this is nowhere documented yet. I feel guilty but have been
swamped since returning from FOSDEM.

[1] https://github.com/openjdk/lilliput/pull/128
[2]
https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/

Cheers, Thomas

On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga <dan.heidinga at oracle.com> wrote:

> (Cross-posting to both valhalla-dev and lilliput-dev)
>
>
>
> Valhalla?s markword usage and Lilliput?s desire to shrink the object
> header require some careful collaboration to find a design that let?s both
> projects move forward.  I?d like to lay out the current Valhalla markword
> use so that we can look at how it fits with Lilliput?s plans and ensure we
> can make the right trade-offs together.  There may be clever encodings
> (reusing the locking bits?) but it makes sense to do that together ? hence
> the cross-post.
>
>
>
> Valhalla uses 4 markword bits [0], two for instances and two for arrays.
> The bits are:
>
>
>
> * is_larval: This is bit is dynamic and indicates the state change from
> when a value instance can be updated (during construction) to when it
> becomes immutable.  We need this bit to ensure correctness of off-label
> construction and debugging apis as well as to ensure values being
> constructed are never aliased with fully constructed values.
>
>
>
> * is_value_type: this bit is static and is used to identify value
> instances.  This bit speeds acmp and other identity sensitive operations so
> that non-value code doesn?t experience a regression.  Before values, acmp
> could use pointer comparison to test if two instance were the same.  With
> values a ?substitutability? test is required.
>
>
>
> For value instances, neither the hash code nor their locking bits are
> required.  Value hash codes are computed similarly to the substitutability
> test and values cannot be locked or synchronized on.
>
>
>
> Arrays of values are identity objects and, like other reference array
> types, are compatible with Object[] or interface arrays (assuming the
> values implement the interface).
>
>
>
> We use two bits to identify the special cases of arrays:
>
>
>
> * is_flat_array: Indicates that the array elements have been flattened and
> that data must be copied in/out of the array when accessing the elements.
>
>
>
> * is_null_free_array: indicates that the array rejects null elements and
> will throw an exception when code attempts to store null into the array.
>
>
>
> Arrays ? being identity objects ? need both their hash codes and locking
> bits.
>
>
>
> This is what Valhalla is using the current prototypes.  Early performance
> experiments led us to this design and we?re working on reconfirming those
> results.
>
>
>
> How does this approach fit with the current Lilliput plans?
>
>
>
> --Dan
>
>
>
> [0]
> https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240305/b43e8265/attachment.htm>

From fparain at openjdk.org  Tue Mar  5 19:11:14 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 19:11:14 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v2]
In-Reply-To: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
Message-ID: <acSSZ06y7iKUo6l0Xs0XCUHpPk7iQw-qJy4a7j2-i1w=.98d44a62-1ab5-4cc1-ab41-edcad3d6c143@github.com>

> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
> 
> Fred

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

 - Merge remote-tracking branch 'upstream/lworld' into preload
 - Merge remote-tracking branch 'upstream/lworld' into preload
 - Fix exception message
 - Merge remote-tracking branch 'upstream/lworld' into preload
 - Preloading reworked

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

Changes: https://git.openjdk.org/valhalla/pull/999/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=999&range=01
  Stats: 829 lines in 13 files changed: 578 ins; 143 del; 108 mod
  Patch: https://git.openjdk.org/valhalla/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/999/head:pull/999

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


From fparain at openjdk.org  Tue Mar  5 19:22:15 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 19:22:15 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v3]
In-Reply-To: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
Message-ID: <vTscydTykMnV2wlqf50TeNyaMGNw9-zjdhXltqws2kk=.99d8ff43-2071-4022-be56-874477115ba4@github.com>

> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
> 
> Fred

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

  Fix aarch64

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/999/files
  - new: https://git.openjdk.org/valhalla/pull/999/files/c50604fb..4e33cfae

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

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

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


From fparain at openjdk.org  Tue Mar  5 19:22:16 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 5 Mar 2024 19:22:16 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v3]
In-Reply-To: <QWUAwAaFl2WMZUxmQU90cZ0v705-ta_bYnX0AQue1rc=.2f887b83-5a73-4ce0-bb13-e75f1a842f9b@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
 <QWUAwAaFl2WMZUxmQU90cZ0v705-ta_bYnX0AQue1rc=.2f887b83-5a73-4ce0-bb13-e75f1a842f9b@github.com>
Message-ID: <6r4B3RXJ_sb-qKEakZnbcXRpJP56aJMNMHr_fvkul_4=.0df90894-ec25-488c-9f82-4f2b2fd11f43@github.com>

On Tue, 5 Mar 2024 07:24:09 GMT, David Simms <dsimms at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch64
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 1:
> 
>> 1: /*
> 
> Fairly minor change for aarch64, could we include that too ?

Good catch! Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/999#discussion_r1513374503


From mchung at openjdk.org  Tue Mar  5 20:33:54 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 5 Mar 2024 20:33:54 GMT
Subject: [lworld] RFR: 8327080: [lworld] Update Valhalla micros to JEP 401
In-Reply-To: <iY5gzreR5ThBzRjcJkyWYDPfW6UsIMju7gyKBqruzRE=.4641005a-6031-4796-ab4e-075aa508e783@github.com>
References: <iY5gzreR5ThBzRjcJkyWYDPfW6UsIMju7gyKBqruzRE=.4641005a-6031-4796-ab4e-075aa508e783@github.com>
Message-ID: <5KiPVhmEfhY7I8gS6fvY-69LhFrKxBxe7vHHPRcOmgE=.13546f4d-717f-4b28-b198-e7e98a6c3882@github.com>

On Thu, 29 Feb 2024 22:44:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A bulk update to change "primitive class" to "value class, remove .ref and replace .default with no-arg constructor. 
> Plus other changes to get the benchmarks to compile.
> 
> No assertions are made beyond compilation.  The generated benchmarks.jar is well formed and can list the benchmarks.
> 
> The makefile rule build-microbenchmark is re-enabled for the `test` target.

LGTM.   This patch allows the microbenchmarks target to be enabled again.   As Sergey commented offline, these microbenchmarks should be completely rewritten.

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

Marked as reviewed by mchung (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1028#pullrequestreview-1918079942


From rriggs at openjdk.org  Tue Mar  5 21:54:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Mar 2024 21:54:57 GMT
Subject: [lworld] Integrated: 8327080: [lworld] Update Valhalla micros to JEP
 401
In-Reply-To: <iY5gzreR5ThBzRjcJkyWYDPfW6UsIMju7gyKBqruzRE=.4641005a-6031-4796-ab4e-075aa508e783@github.com>
References: <iY5gzreR5ThBzRjcJkyWYDPfW6UsIMju7gyKBqruzRE=.4641005a-6031-4796-ab4e-075aa508e783@github.com>
Message-ID: <SlZZy57k9msX9SYUPiQ6gQmRzN1kpiKeIjbJfYgBsGA=.e0a009be-2733-4b88-b3a9-904394f6994d@github.com>

On Thu, 29 Feb 2024 22:44:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A bulk update to change "primitive class" to "value class, remove .ref and replace .default with no-arg constructor. 
> Plus other changes to get the benchmarks to compile.
> 
> No assertions are made beyond compilation.  The generated benchmarks.jar is well formed and can list the benchmarks.
> 
> The makefile rule build-microbenchmark is re-enabled for the `test` target.

This pull request has now been integrated.

Changeset: d632066e
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d632066e9460c53eaae81c480771f14dcc569e8f
Stats:     707 lines in 116 files changed: 75 ins; 2 del; 630 mod

8327080: [lworld] Update Valhalla micros to JEP 401

Reviewed-by: mchung

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

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


From jbhateja at openjdk.org  Wed Mar  6 07:00:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Mar 2024 07:00:20 GMT
Subject: [lworld+vector] RFR: JDK 8327435: [lworld+vector] Align existing
 Vector API support with JEP 401
Message-ID: <UD3cQmHxuq7LWjk4MAuFMCPt0wmkADofNwAqFsYy1kQ=.4212f06b-c791-4462-a978-e61d5b7e6e44@github.com>

-  Align existing vector API java side implementation with JEP 401[1] and future JEP Null-Restricted Value Class Types[2]
-  Existing primitive value class based vector payloads becomes value classes decorated with LosselyConsistent and ImplicitlyConstructible annotations, this
   relaxes atomicity constraints on instance updates and guarantees initialization by a default value.
-  Payload field in concrete values classes is NullRestricted to promote its flattening.
-  In future we can consider making publicly exposed abstract vector classes as sealed classes to restrict its sub-classing by known concrete vector classes.

All existing Vector API JTREG tests are passing at various AVX level with/wo -XX:+DeoptimizeALot.

Best Regards,
Jatin
[1] https://openjdk.org/jeps/401
[2] https://openjdk.org/jeps/8316779

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

Commit messages:
 - JDK-8327435: [lworld+vector] Align existing Vector API support with JEP 401

Changes: https://git.openjdk.org/valhalla/pull/1034/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1034&range=00
  Stats: 316 lines in 40 files changed: 234 ins; 22 del; 60 mod
  Patch: https://git.openjdk.org/valhalla/pull/1034.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1034/head:pull/1034

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


From jbhateja at openjdk.org  Wed Mar  6 07:28:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Mar 2024 07:28:00 GMT
Subject: [lworld+vector] Integrated: JDK 8327435: [lworld+vector] Align
 existing Vector API support with JEP 401
In-Reply-To: <UD3cQmHxuq7LWjk4MAuFMCPt0wmkADofNwAqFsYy1kQ=.4212f06b-c791-4462-a978-e61d5b7e6e44@github.com>
References: <UD3cQmHxuq7LWjk4MAuFMCPt0wmkADofNwAqFsYy1kQ=.4212f06b-c791-4462-a978-e61d5b7e6e44@github.com>
Message-ID: <-g6jw6tldV9YJFCPqyDriUB4wno3_ln_-Toi7aIdWB0=.a7aff9d1-e8c6-46e5-8a30-3350308b5f74@github.com>

On Wed, 6 Mar 2024 06:55:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> -  Align existing vector API java side implementation with JEP 401[1] and future JEP Null-Restricted Value Class Types[2]
> -  Existing primitive value class based vector payloads becomes value classes decorated with LosselyConsistent and ImplicitlyConstructible annotations, this
>    relaxes atomicity constraints on instance updates and guarantees initialization by a default value.
> -  Payload field in concrete values classes is NullRestricted to promote its flattening.
> -  In future we can consider making publicly exposed abstract vector classes as sealed classes to restrict its sub-classing by known concrete vector classes.
> 
> All existing Vector API JTREG tests are passing at various AVX level with/wo -XX:+DeoptimizeALot.
> 
> Best Regards,
> Jatin
> [1] https://openjdk.org/jeps/401
> [2] https://openjdk.org/jeps/8316779

This pull request has now been integrated.

Changeset: ff8a4159
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ff8a41599711ddc7fd79365253a4146f0f16c4a8
Stats:     316 lines in 40 files changed: 234 ins; 22 del; 60 mod

JDK 8327435: [lworld+vector] Align existing Vector API support with JEP 401

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

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


From forax at univ-mlv.fr  Wed Mar  6 09:11:39 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 6 Mar 2024 10:11:39 +0100 (CET)
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
Message-ID: <1144724541.22149694.1709716299480.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Roman Kennke" <rkennke at amazon.de>
> To: "Dan Heidinga" <dan.heidinga at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>, "lilliput-dev" <lilliput-dev at openjdk.org>
> Sent: Tuesday, March 5, 2024 4:31:59 PM
> Subject: Re: Sharing the markword (aka Valhalla's markword use)

> Hi Dan,
> 
> Thank you for the information, that is very useful! Yes, I agree that we should
> negotiate about this ;-)
> 
> I have two questions:
> - Are there requirements/constraints on your side on the position of some of the
> bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to
> indicate self-forwarding in the GC. It kinda needs to be that bit, because we
> expect that the header can also be overlaid with a forwarding pointer, and
> those use all bits except the lowest 3. (See:
> https://github.com/openjdk/jdk/pull/17755)
> - Are any of the bits required during (full) GC? For example, in Lilliput, we
> want to make the hash-code use only 2 bits, and allocate the storage for the
> actual hash-code on-demand. However, this means that we need the hash-code bits
> to determine the object?s size, and therefore must not displace the hash-bits
> during GC (not even temporarily). This is also true for the Klass* bits, that
> we plan to go into the object header as well. (See:
> https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and
> https://github.com/openjdk/lilliput/pull/137)
> 
> For a descriptions of our current plans (which are likely to change until we?re
> done), see the JEP:
> https://openjdk.org/jeps/450
> 

For the compact identity hashcode, i wonder if for arrays the hashCode storage should be always present.
Independantly of Valhalla, relocating a big array just for the hashCode does not seem to be a good strategy, and it also exacerbates the allocation failure issue.
In that case, is_flat_array and is_null_free_array can be bits that share the same storage as the hashCode. 

> Thanks,
> Roman
> 

R?mi

> 
>> On Mar 5, 2024, at 4:06?PM, Dan Heidinga <dan.heidinga at oracle.com> wrote:
>> 
>> CAUTION: This email originated from outside of the organization. Do not click
>> links or open attachments unless you can confirm the sender and know the
>> content is safe.
>> 
>> (Cross-posting to both valhalla-dev and lilliput-dev)
>>  Valhalla?s markword usage and Lilliput?s desire to shrink the object header
>>  require some careful collaboration to find a design that let?s both projects
>>  move forward.  I?d like to lay out the current Valhalla markword use so that we
>>  can look at how it fits with Lilliput?s plans and ensure we can make the right
>>  trade-offs together.  There may be clever encodings (reusing the locking bits?)
>>  but it makes sense to do that together ? hence the cross-post.
>>  Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The
>>  bits are:
>>  * is_larval: This is bit is dynamic and indicates the state change from when a
>>  value instance can be updated (during construction) to when it becomes
>>  immutable.  We need this bit to ensure correctness of off-label construction
>>  and debugging apis as well as to ensure values being constructed are never
>>  aliased with fully constructed values.
>>  * is_value_type: this bit is static and is used to identify value instances.
>>  This bit speeds acmp and other identity sensitive operations so that non-value
>>  code doesn?t experience a regression.  Before values, acmp could use pointer
>>  comparison to test if two instance were the same.  With values a
>>  ?substitutability? test is required.
>>  For value instances, neither the hash code nor their locking bits are required.
>>  Value hash codes are computed similarly to the substitutability test and
>>  values cannot be locked or synchronized on.
>>  Arrays of values are identity objects and, like other reference array types, are
>>  compatible with Object[] or interface arrays (assuming the values implement the
>>  interface).
>>  We use two bits to identify the special cases of arrays:
>>  * is_flat_array: Indicates that the array elements have been flattened and that
>>  data must be copied in/out of the array when accessing the elements.
>>  * is_null_free_array: indicates that the array rejects null elements and will
>>  throw an exception when code attempts to store null into the array.
>>  Arrays ? being identity objects ? need both their hash codes and locking bits.
>>  This is what Valhalla is using the current prototypes.  Early performance
>>  experiments led us to this design and we?re working on reconfirming those
>>  results.
>>  How does this approach fit with the current Lilliput plans?
>>  --Dan
>>  [0]
>>  https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69
> 
> 
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879


From dsimms at openjdk.org  Wed Mar  6 12:55:58 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 6 Mar 2024 12:55:58 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v3]
In-Reply-To: <vTscydTykMnV2wlqf50TeNyaMGNw9-zjdhXltqws2kk=.99d8ff43-2071-4022-be56-874477115ba4@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
 <vTscydTykMnV2wlqf50TeNyaMGNw9-zjdhXltqws2kk=.99d8ff43-2071-4022-be56-874477115ba4@github.com>
Message-ID: <haagyO9HYt4vK5yeG-2pkputRR20KxQ-kM-q66Ys-KU=.dc39bbc3-6b06-4433-a72f-f6b600b4b015@github.com>

On Tue, 5 Mar 2024 19:22:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
>> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix aarch64

Marked as reviewed by dsimms (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/999#pullrequestreview-1919657591


From fparain at openjdk.org  Wed Mar  6 15:08:26 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 6 Mar 2024 15:08:26 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v4]
In-Reply-To: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
Message-ID: <FgWOvoBK2CjkC7pC0waSEhL-kRHHLgrXbpLRU8DoW2k=.eaa9904c-52f5-493c-98fe-a74274d49d9a@github.com>

> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
> 
> Fred

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

  Improve consistency of logging messages

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/999/files
  - new: https://git.openjdk.org/valhalla/pull/999/files/4e33cfae..41e18687

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

  Stats: 57 lines in 4 files changed: 12 ins; 1 del; 44 mod
  Patch: https://git.openjdk.org/valhalla/pull/999.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/999/head:pull/999

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


From dsimms at openjdk.org  Wed Mar  6 15:15:56 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 6 Mar 2024 15:15:56 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v4]
In-Reply-To: <FgWOvoBK2CjkC7pC0waSEhL-kRHHLgrXbpLRU8DoW2k=.eaa9904c-52f5-493c-98fe-a74274d49d9a@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
 <FgWOvoBK2CjkC7pC0waSEhL-kRHHLgrXbpLRU8DoW2k=.eaa9904c-52f5-493c-98fe-a74274d49d9a@github.com>
Message-ID: <epS-U-0TFr0_Sugl0hXdxiB2N2pD0pBwvs2RZkWB24g=.aed7024d-c454-4b81-aff0-2291cb19e08e@github.com>

On Wed, 6 Mar 2024 15:08:26 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
>> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve consistency of logging messages

LGTM !

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/999#pullrequestreview-1920030025


From fparain at openjdk.org  Wed Mar  6 15:15:56 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 6 Mar 2024 15:15:56 GMT
Subject: [lworld] RFR: 8327253: [lworld] Preloading of classes needs a
 complete rework [v4]
In-Reply-To: <FgWOvoBK2CjkC7pC0waSEhL-kRHHLgrXbpLRU8DoW2k=.eaa9904c-52f5-493c-98fe-a74274d49d9a@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
 <FgWOvoBK2CjkC7pC0waSEhL-kRHHLgrXbpLRU8DoW2k=.eaa9904c-52f5-493c-98fe-a74274d49d9a@github.com>
Message-ID: <Ab3faW66dwzMKtY1S1CoyRgdMstUz-RJEf01wiMJz6w=.cd65f736-8d91-4e24-85ea-3551794ed638@github.com>

On Wed, 6 Mar 2024 15:08:26 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
>> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve consistency of logging messages

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/999#issuecomment-1981096717


From fparain at openjdk.org  Wed Mar  6 15:15:57 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 6 Mar 2024 15:15:57 GMT
Subject: [lworld] Integrated: 8327253: [lworld] Preloading of classes needs a
 complete rework
In-Reply-To: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
References: <T0elZfK-prD6dVYnwGgKl9BZ5YxZS-vwHTSixKa0Xjw=.c044d5fd-ee87-4bf8-aa34-f5d3df48eb28@github.com>
Message-ID: <aKzQdBWePgnH4mFG6RhuyovoC90kDhbr5taQyzuo5nk=.d15c660a-e2e0-4768-ad7b-94cb73cad806@github.com>

On Wed, 7 Feb 2024 20:26:10 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Rework of class preloading to fix existing issues and support new preloading scheme (see CR for details).
> Also change the array of inline types fields classes from InlineKlass** to Array<InlineKlass*>*, much easier to manage.
> 
> Fred

This pull request has now been integrated.

Changeset: 509b4ea5
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/509b4ea54c6676c183cc2dae323db24b20f11a11
Stats:     847 lines in 15 files changed: 591 ins; 144 del; 112 mod

8327253: [lworld] Preloading of classes needs a complete rework

Reviewed-by: dsimms

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

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


From dan.heidinga at oracle.com  Wed Mar  6 15:20:06 2024
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Wed, 6 Mar 2024 15:20:06 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
Message-ID: <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>

Values lack identity so it?s possible for them to be deduplicated (or even duplicated!) at any point when they are not in the larval state.  That would mean we?d need the is_larval bit to be stable to any process (gc?) that may be responsible for (de)duplication.

The other three bits shouldn?t be required during GC and can be re-derived from the klass metadata.

--Dan

From: Kennke, Roman <rkennke at amazon.de>
Date: Tuesday, March 5, 2024 at 10:36?AM
To: Dan Heidinga <dan.heidinga at oracle.com>
Cc: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>, lilliput-dev at openjdk.org <lilliput-dev at openjdk.org>
Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use)
Hi Dan,

Thank you for the information, that is very useful! Yes, I agree that we should negotiate about this ;-)

I have two questions:
- Are there requirements/constraints on your side on the position of some of the bits? For example, in Lilliput, we use the 3rd bit (ex-biased-locking-bit) to indicate self-forwarding in the GC. It kinda needs to be that bit, because we expect that the header can also be overlaid with a forwarding pointer, and those use all bits except the lowest 3. (See: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$<https://urldefense.com/v3/__https:/github.com/openjdk/jdk/pull/17755__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7N6zqFW$> )
- Are any of the bits required during (full) GC? For example, in Lilliput, we want to make the hash-code use only 2 bits, and allocate the storage for the actual hash-code on-demand. However, this means that we need the hash-code bits to determine the object?s size, and therefore must not displace the hash-bits during GC (not even temporarily). This is also true for the Klass* bits, that we plan to go into the object header as well. (See: https://wiki.openjdk.org/display/lilliput/Compact+Identity+Hashcode and https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$<https://urldefense.com/v3/__https:/github.com/openjdk/lilliput/pull/137__;!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-5pRnCoP$> )

For a descriptions of our current plans (which are likely to change until we?re done), see the JEP:
https://openjdk.org/jeps/450

Thanks,
Roman


> On Mar 5, 2024, at 4:06?PM, Dan Heidinga <dan.heidinga at oracle.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
> (Cross-posting to both valhalla-dev and lilliput-dev)
>  Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward.  I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post.
>  Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:
>  * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.
>  * is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a ?substitutability? test is required.
>  For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.
>  Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).
>  We use two bits to identify the special cases of arrays:
>  * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.
>  * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.
>  Arrays ? being identity objects ? need both their hash codes and locking bits.
>  This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we?re working on reconfirming those results.
>  How does this approach fit with the current Lilliput plans?
>  --Dan
>  [0] https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!JxZ8PqhuJWDsPahgznChIyJFjicveLxZzz6sXkeFcm1qVUooZnn1vWmVrT_U3_NTTffaeWpr2d9q-7L0Qht7$>





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

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

From dan.heidinga at oracle.com  Wed Mar  6 15:32:29 2024
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Wed, 6 Mar 2024 15:32:29 +0000
Subject: [External] : Re: Sharing the markword (aka Valhalla's markword
 use)
In-Reply-To: <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
Message-ID: <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>

4 free bits ? just what we need! =)

One of the challenges for J9 over the last few years has been finding header bits.  J9 went to a ?single word header?, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they?re put per class (layout gaps are a pretty common choice).  This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases.

Small headers are good but how small is small enough?  This isn?t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project?s ability to use bits.  There?s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously.

--Dan

From: Thomas St?fe <thomas.stuefe at gmail.com>
Date: Tuesday, March 5, 2024 at 11:29?AM
To: Dan Heidinga <dan.heidinga at oracle.com>
Cc: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>, lilliput-dev at openjdk.org <lilliput-dev at openjdk.org>, Kennke, Roman <rkennke at amazon.de>
Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use)
Hi Dan,

In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits.

Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM.

[1] https://github.com/openjdk/lilliput/pull/128<https://urldefense.com/v3/__https:/github.com/openjdk/lilliput/pull/128__;!!ACWV5N9M2RV99hQ!PPjaKd3dzefPi5J12SrLjrLq2BqkNeagM8dE_nfiajwgcMEV9BiaTi1iPIsjg4e1xXgI9i5kLSLro0bVV1vyUKLi$>
[2] https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/<https://urldefense.com/v3/__https:/fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/__;!!ACWV5N9M2RV99hQ!PPjaKd3dzefPi5J12SrLjrLq2BqkNeagM8dE_nfiajwgcMEV9BiaTi1iPIsjg4e1xXgI9i5kLSLro0bVV5vWqERE$>

Cheers, Thomas

On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga <dan.heidinga at oracle.com<mailto:dan.heidinga at oracle.com>> wrote:
(Cross-posting to both valhalla-dev and lilliput-dev)

Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward.  I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post.

Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:

* is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.

* is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a ?substitutability? test is required.

For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.

Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).

We use two bits to identify the special cases of arrays:

* is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.

* is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.

Arrays ? being identity objects ? need both their hash codes and locking bits.

This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we?re working on reconfirming those results.

How does this approach fit with the current Lilliput plans?

--Dan

[0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!PPjaKd3dzefPi5J12SrLjrLq2BqkNeagM8dE_nfiajwgcMEV9BiaTi1iPIsjg4e1xXgI9i5kLSLro0bVV4DF62Mv$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240306/93a65632/attachment.htm>

From rriggs at openjdk.org  Wed Mar  6 18:40:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Mar 2024 18:40:57 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutitable
 comparison of float/double should use raw bits [v2]
In-Reply-To: <PYgZSuPWNktvKbJZp3nmDfw5ubBMESbig6Y8_0q0NMI=.7565e8ca-9c37-47f2-9029-ce252b91190b@github.com>
References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com>
 <PYgZSuPWNktvKbJZp3nmDfw5ubBMESbig6Y8_0q0NMI=.7565e8ca-9c37-47f2-9029-ce252b91190b@github.com>
Message-ID: <tRNlAGPRCby3dHxELI9ZoMdpMLUGGkJLKG2141pQTXA=.f1f209a5-f885-4714-b67d-bfabbcdd2ebe@github.com>

On Fri, 9 Feb 2024 16:48:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update the substitutability implementation to match the new JLS for JEP 401.
>> Float and double values should be compared for equality using the raw bits.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change to ObjectMethods to avoid changing behavior of equals for floats in records.
>   Create a separate cache of method pointers for substitutablity test for primitives in ValueObjectMethods.

Start fresh after rebase.

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

PR Comment: https://git.openjdk.org/valhalla/pull/998#issuecomment-1981545649


From rriggs at openjdk.org  Wed Mar  6 18:40:58 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Mar 2024 18:40:58 GMT
Subject: [lworld] Withdrawn: 8298659: [lworld] ValueObject isSubstutitable
 comparison of float/double should use raw bits
In-Reply-To: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com>
References: <7cho8mKIB_BzPORmZELTLS7Z83TztRwxkvApvFlsdIk=.b09cf560-c185-40bd-9ae6-aff9085a31a2@github.com>
Message-ID: <HfhD_R3CDVScZRCvz36-4jZu5dFqsZPhn6b8xyBwdek=.9f513ef8-2f7e-4480-9956-0e608d7a7ea6@github.com>

On Wed, 7 Feb 2024 19:22:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update the substitutability implementation to match the new JLS for JEP 401.
> Float and double values should be compared for equality using the raw bits.

This pull request has been closed without being integrated.

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

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


From rkennke at amazon.de  Wed Mar  6 18:43:29 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Wed, 6 Mar 2024 18:43:29 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
 <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
Message-ID: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>

Hi Dan,

> 4 free bits ? just what we need! =)

Yes, but my questions about constraints remain.

>  One of the challenges for J9 over the last few years has been finding header bits.  J9 went to a ?single word header?, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they?re put per class (layout gaps are a pretty common choice).  This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases.
>  Small headers are good but how small is small enough?  This isn?t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project?s ability to use bits.  There?s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously.

I understand. My point of view is that it doesn?t make a lot of sense to not do a tremendously useful optimization like 8- or 4-byte headers, just because we may need something in the future. But I agree that we should try to make it flexible enough to accommodate future needs, or at least make it relatively easy.

Let?s first lay out a rough plan about what we?re planning to do with class-pointers.

Currently, compressed class-pointers are 32 bits wide, and from what I can tell, is more than enough to address as many classes as anybody would want.

For 8-byte headers, our plan is to use 22 bits and still address enough classes (see Thomas? part of the FOSDEM presentation). This leaves enough bits for 31 bit hashcode, 4 Valhalla bits, 4 age bits, 1 self-forwarding bits and 2 lock bits.

We have a plan how we can make the class-pointer much smaller. Based on the observation that most workloads only require a few 10000 classes, let?s say 15 bits is ?enough? and not wasteful. Workloads that require more often generate those classes, which often don?t have many instances (e.g. only 1). In order to address arbitrary many classes, we would require one more bit that indicates that the class-pointer should be loaded from a dedicated field - this could be compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 class-bits from the header, we can determine the details later. We can also determine the exact number of bits later. The point is that we can make the class-pointer small enough to accommodate, say, 99% of all workloads and flexible enough for everything else. Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), we?d still have a reserve of 3 bits. We could use them for more classes, or reserve them for future use. It does not seem unreasonable to make the class-bits even smaller, in case we ever need more bits.

Also, if we ever need a bit only for arrays (wasn?t one of the Valhalla bits only for arrays?), we?d have one bit that we can use from the array-length field.

Let me know what you think.

Roman


>  --Dan
>  From: Thomas St?fe <thomas.stuefe at gmail.com>
> Date: Tuesday, March 5, 2024 at 11:29?AM
> To: Dan Heidinga <dan.heidinga at oracle.com>
> Cc: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>, lilliput-dev at openjdk.org <lilliput-dev at openjdk.org>, Kennke, Roman <rkennke at amazon.de>
> Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use)
> Hi Dan,
>  In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits.
>  Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM.
>  [1] https://github.com/openjdk/lilliput/pull/128
> [2] https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/
>  Cheers, Thomas
>  On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga <dan.heidinga at oracle.com> wrote:
> (Cross-posting to both valhalla-dev and lilliput-dev)
>  Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward.  I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post.
>  Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:
>  * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.
>  * is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a ?substitutability? test is required.
>  For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.
>  Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).
>  We use two bits to identify the special cases of arrays:
>  * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.
>  * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.
>  Arrays ? being identity objects ? need both their hash codes and locking bits.
>  This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we?re working on reconfirming those results.
>  How does this approach fit with the current Lilliput plans?
>  --Dan
>  [0] https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp#L69





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From rkennke at amazon.de  Wed Mar  6 18:47:09 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Wed, 6 Mar 2024 18:47:09 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
 <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
 <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
Message-ID: <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de>

> 
> We have a plan how we can make the class-pointer much smaller. Based on the observation that most workloads only require a few 10000 classes, let?s say 15 bits is ?enough? and not wasteful. Workloads that require more often generate those classes, which often don?t have many instances (e.g. only 1). In order to address arbitrary many classes, we would require one more bit that indicates that the class-pointer should be loaded from a dedicated field - this could be compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 class-bits from the header

I shall add that this is possible because we know at class-loading time whether or not we?re going to exceed the class-addressing-limit, and reserve the extra Klass* field at class-loading time, during field layout, and allocate all affected instances with that extra field right from the start, no stunts needed like with the compact I-hash stuff.

Roman




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From mchung at openjdk.org  Wed Mar  6 21:16:47 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Mar 2024 21:16:47 GMT
Subject: [lworld] Integrated: 8327498: [lworld] Remove Q-descriptor change from
 ASM and other clean up
Message-ID: <Mb2SuFxrS4e_8NDuEGkyVdXXw6G_L6isflq0aKCk_og=.55469bab-b1a6-427c-8c39-3f584fa9b081@github.com>

Remove the changes to support Q-descriptor and other clean up to match the master version.

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

Commit messages:
 - 8327498: [lworld] Remove Q-descriptor change from ASM and other clean up

Changes: https://git.openjdk.org/valhalla/pull/1036/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327498
  Stats: 98 lines in 27 files changed: 4 ins; 62 del; 32 mod
  Patch: https://git.openjdk.org/valhalla/pull/1036.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1036/head:pull/1036

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


From mchung at openjdk.org  Wed Mar  6 21:16:48 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Mar 2024 21:16:48 GMT
Subject: [lworld] Integrated: 8327498: [lworld] Remove Q-descriptor change from
 ASM and other clean up
In-Reply-To: <Mb2SuFxrS4e_8NDuEGkyVdXXw6G_L6isflq0aKCk_og=.55469bab-b1a6-427c-8c39-3f584fa9b081@github.com>
References: <Mb2SuFxrS4e_8NDuEGkyVdXXw6G_L6isflq0aKCk_og=.55469bab-b1a6-427c-8c39-3f584fa9b081@github.com>
Message-ID: <39NSxNzdwtbswYgzkfEscseFTA74hyLPZ64p5tiwWIc=.07c60126-2cb0-479a-b5ee-bf67074cb46f@github.com>

On Wed, 6 Mar 2024 21:03:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Remove the changes to support Q-descriptor and other clean up to match the master version.

This pull request has now been integrated.

Changeset: 676fe489
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/676fe489048fc1601d10bdc71b5c0d2c97cea59c
Stats:     98 lines in 27 files changed: 4 ins; 62 del; 32 mod

8327498: [lworld] Remove Q-descriptor change from ASM and other clean up

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

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


From forax at univ-mlv.fr  Thu Mar  7 00:53:36 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 Mar 2024 01:53:36 +0100 (CET)
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
 <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
 <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
 <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de>
Message-ID: <1565557114.22597080.1709772816897.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Roman Kennke" <rkennke at amazon.de>
> To: "Dan Heidinga" <dan.heidinga at oracle.com>
> Cc: "Thomas St?fe" <thomas.stuefe at gmail.com>, "valhalla-dev" <valhalla-dev at openjdk.org>, "lilliput-dev"
> <lilliput-dev at openjdk.org>
> Sent: Wednesday, March 6, 2024 7:47:09 PM
> Subject: Re: Sharing the markword (aka Valhalla's markword use)

>> 
>> We have a plan how we can make the class-pointer much smaller. Based on the
>> observation that most workloads only require a few 10000 classes, let?s say 15
>> bits is ?enough? and not wasteful. Workloads that require more often generate
>> those classes, which often don?t have many instances (e.g. only 1). In order to
>> address arbitrary many classes, we would require one more bit that indicates
>> that the class-pointer should be loaded from a dedicated field - this could be
>> compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15
>> class-bits from the header
> 
> I shall add that this is possible because we know at class-loading time whether
> or not we?re going to exceed the class-addressing-limit, and reserve the extra
> Klass* field at class-loading time, during field layout, and allocate all
> affected instances with that extra field right from the start, no stunts needed
> like with the compact I-hash stuff.

and

> Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), 
> we?d still have a reserve of 3 bits. We could use them for more classes, or
> reserve them for future use. It does not seem unreasonable to make the
> class-bits even smaller, in case we ever need more bits.

If you have 2 bits for the hash, you need the compact identity hash optimization too.
So splitting the classpointer to save more bits is a third optimization.

Liliput 64 uses compressed classpointer (22 bits) and lightweight locking,
Liliput 32 uses compact identity hash (2 bits) with storage inflation on demand (plus all the above),
Liliput 16 uses split classpointer (plus all the above). 

> 
> Roman
> 

R?mi

> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879


From vromero at openjdk.org  Thu Mar  7 01:02:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Mar 2024 01:02:58 GMT
Subject: [lworld] RFR: 8326990: [lworld] make value classes a preview feature
Message-ID: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>

Javac changes to make value classes a preview feature,

TIA

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

Commit messages:
 - modifying regression tests
 - minor changes
 - Merge lworld
 - 8326990: [lworld] make value classes a preview feature

Changes: https://git.openjdk.org/valhalla/pull/1037/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1037&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326990
  Stats: 118 lines in 31 files changed: 51 ins; 43 del; 24 mod
  Patch: https://git.openjdk.org/valhalla/pull/1037.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1037/head:pull/1037

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


From chagedorn at openjdk.org  Thu Mar  7 07:40:57 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 7 Mar 2024 07:40:57 GMT
Subject: [lworld] RFR: 8293541: [lworld] IR verification fails for
 TestLWorld::test109_sharp and test110_sharp
Message-ID: <nUN6ZtRKRAPZ4NMRR01GemMAwnwn4E8oGt8tcN4nbY0=.6e5f1d0f-d621-4ef4-bdee-df24e4febaf1@github.com>

`test109_sharp()` and `test110_sharp()` originally failed because we have no longer beeen able to apply Loop Predication due to the following merge mistake (left previous, middle merged, right new code from mainline):

![image](https://github.com/openjdk/valhalla/assets/17833009/31c5065a-7e8a-4fcd-bc23-241176cfe9a6)

This changed the application of EA for these tests in such a way that we need to apply EA twice (iteratively) to remove the wrapping box object and the inline type allocation. This had the side effect that we missed to re-add a memory phi to the IGVN worklist to apply an optimization to get rid of a diamond-if control flow which blocks Loop Predication. IR matching failed because we could not find the corresponding predicate trap for an expected Hoisted Check Predicate.

This was also a problem in mainline but we had no IR test to catch this. [JDK-8314997](https://bugs.openjdk.org/browse/JDK-8314997) fixed this for mainline and once it was merged with Valhalla, `test109_sharp()` and `test110_sharp()` would now work again.

But I think we should still fix the merge mistake to eagerly try to remove inline type allocations, regardless of their escape/replaceable status as it was originally intended before the merge. This allows us to get rid of some extra EA iterations.

However, fixing this merge mistake caused an assertion failure later in EA which checked that safepoints do not have inline type allocation uses (they should be replaced by `SafePointScalarObjectNodes`). To fix that, we need to make sure that any inline type pointer phi node created for an inline type field here (`create_scalarized_object_description()` -> `value_from_mem()` -> `value_from_mem_phi()`):

https://github.com/openjdk/valhalla/blob/814a5e93cb392a77a43550bf8dab5ab9d52bdcfd/src/hotspot/share/opto/macro.cpp#L378-L379

when trying to create a `SafePointScalarObjectNode` for a safepoint use is eagerly replaced by an `InlineTypeNode`. To achieve that, I've added a call to `push_inline_types_through()` (renamed to `push_inline_types_down()`) which was only used in `PhiNode::Ideal()` before. I've applied some refactoring and renaming to share that code with EA

I've tried out some additional assertions in EA that an inline type pointer phi should already be replaced by an `InlineTypeNode` if possible. But that failed. I think we are missing some optimization opportunities here. As this might be out of scope of this bug, I suggest to file a separate RFE to investigate further.

#### Disabled Test Due to Existing Bug
I disabled TestOnStackReplacement::test3() by uncommenting it. It triggered the following assertion:

assert(outer->outcnt() >= phis + 2 - be_loads && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis

I've had a closer look and it seems like this patch here just revealed an existing rare issue that was only seen with this one test and some stress options. I've filed [JDK-8327465](https://bugs.openjdk.org/browse/JDK-8327465) to not block this fix and follow up on it later.

#### Testing
I performed testing on an older repo state before transitioning to the JEP 401 model to verify the correctness of this patch.

Thanks,
Christian

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

Commit messages:
 - 8293541: [lworld] IR verification fails for TestLWorld::test109_sharp and test110_sharp

Changes: https://git.openjdk.org/valhalla/pull/1038/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293541
  Stats: 190 lines in 5 files changed: 107 ins; 64 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1038.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1038/head:pull/1038

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


From rkennke at amazon.de  Thu Mar  7 08:59:47 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Thu, 7 Mar 2024 08:59:47 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <1565557114.22597080.1709772816897.JavaMail.zimbra@univ-eiffel.fr>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
 <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
 <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
 <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de>
 <1565557114.22597080.1709772816897.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <27A37359-093E-4763-ABA9-A5AEA7C7CCDD@amazon.de>

>>> We have a plan how we can make the class-pointer much smaller. Based on the
>>> observation that most workloads only require a few 10000 classes, let?s say 15
>>> bits is ?enough? and not wasteful. Workloads that require more often generate
>>> those classes, which often don?t have many instances (e.g. only 1). In order to
>>> address arbitrary many classes, we would require one more bit that indicates
>>> that the class-pointer should be loaded from a dedicated field - this could be
>>> compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15
>>> class-bits from the header
>> 
>> I shall add that this is possible because we know at class-loading time whether
>> or not we?re going to exceed the class-addressing-limit, and reserve the extra
>> Klass* field at class-loading time, during field layout, and allocate all
>> affected instances with that extra field right from the start, no stunts needed
>> like with the compact I-hash stuff.
> 
> and
> 
>> Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking),
>> we?d still have a reserve of 3 bits. We could use them for more classes, or
>> reserve them for future use. It does not seem unreasonable to make the
>> class-bits even smaller, in case we ever need more bits.
> 
> If you have 2 bits for the hash, you need the compact identity hash optimization too.
> So splitting the classpointer to save more bits is a third optimization.
> 
> Liliput 64 uses compressed classpointer (22 bits) and lightweight locking,
> Liliput 32 uses compact identity hash (2 bits) with storage inflation on demand (plus all the above),
> Liliput 16 uses split classpointer (plus all the above).

Not quite.

Lilliput 64 uses 22 bit compressed class-pointer, 31 bits I-hash and 4 age, 4 Valhalla, 1 self-forwarding and 2 lock bits.

Lilliput 32 would use 16 (possibly up to 19) bits class-pointer, 2 I-hash-bits, and the others same as above.

We don?t currently have plans for Lilliput 16. While that may be possible, I would expect diminishing returns because of extra efforts (CPU cycles and/or out-of-heap storage) to squeeze the bits.

Roman





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From vromero at openjdk.org  Thu Mar  7 21:33:25 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Mar 2024 21:33:25 GMT
Subject: [lworld] RFR: 8326990: [lworld] make value classes a preview
 feature [v2]
In-Reply-To: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
References: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
Message-ID: <iHep5bX1vPYrL5hBkobpT5xldiAhcLZZu5a5V0Pztno=.6fefd826-3c7c-4e43-92ec-12e0a609b5f0@github.com>

> Javac changes to make value classes a preview feature,
> 
> TIA

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

  enable preview VM support

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1037/files
  - new: https://git.openjdk.org/valhalla/pull/1037/files/de86978e..630dc629

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

  Stats: 94 lines in 32 files changed: 38 ins; 12 del; 44 mod
  Patch: https://git.openjdk.org/valhalla/pull/1037.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1037/head:pull/1037

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


From rriggs at openjdk.org  Thu Mar  7 22:03:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Mar 2024 22:03:24 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutiable comparison
 of float/double should use raw bits
Message-ID: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>

Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.

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

Commit messages:
 - 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits

Changes: https://git.openjdk.org/valhalla/pull/1039/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298659
  Stats: 81 lines in 2 files changed: 66 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1039.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1039/head:pull/1039

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


From mchung at openjdk.org  Thu Mar  7 22:49:30 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 7 Mar 2024 22:49:30 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value class
 if preview feature is enabled
Message-ID: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>

As specified in JEP 401, when preview features are enabled, the following standard library classes are considered to be value classes:

    java.lang.Byte
    java.lang.Short
    java.lang.Integer
    java.lang.Long
    java.lang.Float
    java.lang.Double
    java.lang.Boolean
    java.lang.Character
    java.util.Optional
    java.lang.Number
    java.lang.Record


These value classes are loaded only if --enable-preview is set.    All valhalla tests should have preview enabled to ensure testing with the proper set of library classes.

Testing: Run `jdk_valhalla` and `hotspot_valhalla_runtime` with  `-Xint` with and without `--enable-preview`.  The result is pretty good.  [JDK-8327637](https://bugs.openjdk.org/browse/JDK-8327637) and [JDK-8327639](https://bugs.openjdk.org/browse/JDK-8327639) need further investigation.

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

Commit messages:
 - 8327636: [lworld] Make primitive wrappers be value class if preview feature is enabled

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

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


From liach at openjdk.org  Fri Mar  8 02:07:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Mar 2024 02:07:01 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled
In-Reply-To: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
Message-ID: <mYiZo5CvbGg71Km6METrT4tx1HYERmsusLzfDddhtew=.df619d0c-7270-4534-b292-75376aecb56e@github.com>

On Thu, 7 Mar 2024 22:45:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> As specified in JEP 401, when preview features are enabled, the following standard library classes are considered to be value classes:
> 
>     java.lang.Byte
>     java.lang.Short
>     java.lang.Integer
>     java.lang.Long
>     java.lang.Float
>     java.lang.Double
>     java.lang.Boolean
>     java.lang.Character
>     java.util.Optional
>     java.lang.Number
>     java.lang.Record
> 
> 
> These value classes are loaded only if --enable-preview is set.    All valhalla tests should have preview enabled to ensure testing with the proper set of library classes.
> 
> Testing: Run `jdk_valhalla` and `hotspot_valhalla_runtime` with  `-Xint` with and without `--enable-preview`.  The result is pretty good.  [JDK-8327637](https://bugs.openjdk.org/browse/JDK-8327637) and [JDK-8327639](https://bugs.openjdk.org/browse/JDK-8327639) need further investigation.

https://bugs.openjdk.org/browse/JDK-8327481 can be closed as a duplicate of this.

make/modules/java.base/gensrc/GensrcValueClasses.gmk line 39:

> 37:     java/lang/Character.java \
> 38:     java/lang/Number.java \
> 39:     java/lang/Record.java \

Record is already included in the end of the list.

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

PR Review: https://git.openjdk.org/valhalla/pull/1040#pullrequestreview-1923896364
PR Review Comment: https://git.openjdk.org/valhalla/pull/1040#discussion_r1517073698


From mchung at openjdk.org  Fri Mar  8 03:22:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 03:22:12 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
Message-ID: <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>

> As specified in JEP 401, when preview features are enabled, the following standard library classes are considered to be value classes:
> 
>     java.lang.Byte
>     java.lang.Short
>     java.lang.Integer
>     java.lang.Long
>     java.lang.Float
>     java.lang.Double
>     java.lang.Boolean
>     java.lang.Character
>     java.util.Optional
>     java.lang.Number
>     java.lang.Record
> 
> 
> These value classes are loaded only if --enable-preview is set.    All valhalla tests should have preview enabled to ensure testing with the proper set of library classes.
> 
> Testing: Run `jdk_valhalla` and `hotspot_valhalla_runtime` with  `-Xint` with and without `--enable-preview`.  The result is pretty good.  [JDK-8327637](https://bugs.openjdk.org/browse/JDK-8327637) and [JDK-8327639](https://bugs.openjdk.org/browse/JDK-8327639) need further investigation.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Removed duplicated Record

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1040/files
  - new: https://git.openjdk.org/valhalla/pull/1040/files/8f981c2f..ff15f65e

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

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

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


From mchung at openjdk.org  Fri Mar  8 03:22:12 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 03:22:12 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <mYiZo5CvbGg71Km6METrT4tx1HYERmsusLzfDddhtew=.df619d0c-7270-4534-b292-75376aecb56e@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
 <mYiZo5CvbGg71Km6METrT4tx1HYERmsusLzfDddhtew=.df619d0c-7270-4534-b292-75376aecb56e@github.com>
Message-ID: <9AMRevzXHjHfQMls9oFttk1WJICcuh3IytIuNrqp7Nc=.19286997-583c-40b7-8452-b2ebf39b48a1@github.com>

On Fri, 8 Mar 2024 02:03:10 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed duplicated Record
>
> make/modules/java.base/gensrc/GensrcValueClasses.gmk line 39:
> 
>> 37:     java/lang/Character.java \
>> 38:     java/lang/Number.java \
>> 39:     java/lang/Record.java \
> 
> Record is already included in the end of the list.

Good catch.   Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1040#discussion_r1517116240


From vromero at openjdk.org  Fri Mar  8 04:17:24 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Mar 2024 04:17:24 GMT
Subject: [lworld] RFR: 8326990: [lworld] make value classes a preview
 feature [v3]
In-Reply-To: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
References: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
Message-ID: <PUvm9i6ypSh6c0i8NPT3F65wSzhVSMc4FtNomU8qed0=.2496bc14-2b66-4ad9-864e-ee0b00ba8165@github.com>

> Javac changes to make value classes a preview feature,
> 
> TIA

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

  minor changes to tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1037/files
  - new: https://git.openjdk.org/valhalla/pull/1037/files/630dc629..4acb4f1d

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

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

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


From liach at openjdk.org  Fri Mar  8 04:32:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Mar 2024 04:32:59 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
 <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
Message-ID: <n5XW1xAe9d2-RpYLg1HPCl5GyH2v2K0BpNCxOOP5AJ0=.b5fd958f-b1f9-452f-aa98-688801dfff19@github.com>

On Fri, 8 Mar 2024 03:22:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> As specified in JEP 401, when preview features are enabled, the following standard library classes are considered to be value classes:
>> 
>>     java.lang.Byte
>>     java.lang.Short
>>     java.lang.Integer
>>     java.lang.Long
>>     java.lang.Float
>>     java.lang.Double
>>     java.lang.Boolean
>>     java.lang.Character
>>     java.util.Optional
>>     java.lang.Number
>>     java.lang.Record
>> 
>> 
>> These value classes are loaded only if --enable-preview is set.    All valhalla tests should have preview enabled to ensure testing with the proper set of library classes.
>> 
>> Testing: Run `jdk_valhalla` and `hotspot_valhalla_runtime` with  `-Xint` with and without `--enable-preview`.  The result is pretty good.  [JDK-8327637](https://bugs.openjdk.org/browse/JDK-8327637) and [JDK-8327639](https://bugs.openjdk.org/browse/JDK-8327639) need further investigation.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed duplicated Record

src/java.base/share/classes/sun/invoke/util/VerifyAccess.java line 212:

> 210: 
> 211:             // exports are not setup during early VM initialization
> 212:             if (!jdk.internal.misc.VM.isModuleSystemInited()) {

Should we merge this and the `lookupModule == null` early startup cases, and `assert lookupModule == refModule && refModule == Object.class.getModule()` can become `assert lookupModule == refModule && (refModule == null || refModule == Object.class.getModule())`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1040#discussion_r1517152683


From vromero at openjdk.org  Fri Mar  8 04:49:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Mar 2024 04:49:26 GMT
Subject: [lworld] RFR: 8326990: [lworld] make value classes a preview
 feature [v4]
In-Reply-To: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
References: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
Message-ID: <-o1qiNo4NHVXduXCP2En_o858MrNWotbg_FgwdUkzog=.2efc538f-e8f0-4185-93ab-b4929c683782@github.com>

> Javac changes to make value classes a preview feature,
> 
> TIA

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

  adding enablePreview to test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1037/files
  - new: https://git.openjdk.org/valhalla/pull/1037/files/4acb4f1d..369975b0

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

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

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


From vromero at openjdk.org  Fri Mar  8 04:49:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 8 Mar 2024 04:49:26 GMT
Subject: [lworld] Integrated: 8326990: [lworld] make value classes a preview
 feature
In-Reply-To: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
References: <9cWvBe8IMnGuW9s-uUnt9EA-XsENXe3WfmBJpDZgF1A=.a77dfa37-251a-41f0-882e-7bfd3d471291@github.com>
Message-ID: <-YueQasLgwQstq51FQDDE6pzA9a9-dR8lrF00x_1kqY=.f81392e7-bb13-4f28-98f4-cbe15aa44335@github.com>

On Thu, 7 Mar 2024 00:58:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac changes to make value classes a preview feature,
> 
> TIA

This pull request has now been integrated.

Changeset: 9c21d4c5
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9c21d4c5ff516af4d901fe96d0fd9a0bce3c096f
Stats:     216 lines in 67 files changed: 91 ins; 55 del; 70 mod

8326990: [lworld] make value classes a preview feature

Co-authored-by: Frederic Parain <fparain at openjdk.org>

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

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


From mchung at openjdk.org  Fri Mar  8 04:59:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 04:59:00 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <n5XW1xAe9d2-RpYLg1HPCl5GyH2v2K0BpNCxOOP5AJ0=.b5fd958f-b1f9-452f-aa98-688801dfff19@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
 <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
 <n5XW1xAe9d2-RpYLg1HPCl5GyH2v2K0BpNCxOOP5AJ0=.b5fd958f-b1f9-452f-aa98-688801dfff19@github.com>
Message-ID: <650ldEAkImQKFfrFkjuV9iWLlgOueZT6M9kjrPZXcdg=.9b0e5e09-cf1e-4904-b07e-b103b1ea70df@github.com>

On Fri, 8 Mar 2024 04:30:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed duplicated Record
>
> src/java.base/share/classes/sun/invoke/util/VerifyAccess.java line 212:
> 
>> 210: 
>> 211:             // exports are not setup during early VM initialization
>> 212:             if (!jdk.internal.misc.VM.isModuleSystemInited()) {
> 
> Should we merge this and the `lookupModule == null` early startup cases, and `assert lookupModule == refModule && refModule == Object.class.getModule()` can become `assert lookupModule == refModule && (refModule == null || refModule == Object.class.getModule())`?

It can be simpler:


            // early VM startup case, java.base not defined or module system not initialized
            if (lookupModule == null || !jdk.internal.misc.VM.isModuleSystemInited()) {
                assert lookupModule == refModule;
                return true;
            }

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1040#discussion_r1517165488


From liach at openjdk.org  Fri Mar  8 05:05:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Mar 2024 05:05:58 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <650ldEAkImQKFfrFkjuV9iWLlgOueZT6M9kjrPZXcdg=.9b0e5e09-cf1e-4904-b07e-b103b1ea70df@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
 <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
 <n5XW1xAe9d2-RpYLg1HPCl5GyH2v2K0BpNCxOOP5AJ0=.b5fd958f-b1f9-452f-aa98-688801dfff19@github.com>
 <650ldEAkImQKFfrFkjuV9iWLlgOueZT6M9kjrPZXcdg=.9b0e5e09-cf1e-4904-b07e-b103b1ea70df@github.com>
Message-ID: <-qY-3aqlEgzGsC77q1O_WFt-znvLSnMdt43bdsebByw=.1c24ccc6-51db-4acf-815c-92fd06f7bb1c@github.com>

On Fri, 8 Mar 2024 04:56:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/sun/invoke/util/VerifyAccess.java line 212:
>> 
>>> 210: 
>>> 211:             // exports are not setup during early VM initialization
>>> 212:             if (!jdk.internal.misc.VM.isModuleSystemInited()) {
>> 
>> Should we merge this and the `lookupModule == null` early startup cases, and `assert lookupModule == refModule && refModule == Object.class.getModule()` can become `assert lookupModule == refModule && (refModule == null || refModule == Object.class.getModule())`?
>
> It can be simpler:
> 
> 
>             // early VM startup case, java.base not defined or module system not initialized
>             if (lookupModule == null || !jdk.internal.misc.VM.isModuleSystemInited()) {
>                 assert lookupModule == refModule;
>                 return true;
>             }

Can `Class::getModule` ever return `null` after module system is initialized? If not we can omit the `lookupModule == null` check.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1040#discussion_r1517169212


From mchung at openjdk.org  Fri Mar  8 05:10:03 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 05:10:03 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <-qY-3aqlEgzGsC77q1O_WFt-znvLSnMdt43bdsebByw=.1c24ccc6-51db-4acf-815c-92fd06f7bb1c@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
 <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
 <n5XW1xAe9d2-RpYLg1HPCl5GyH2v2K0BpNCxOOP5AJ0=.b5fd958f-b1f9-452f-aa98-688801dfff19@github.com>
 <650ldEAkImQKFfrFkjuV9iWLlgOueZT6M9kjrPZXcdg=.9b0e5e09-cf1e-4904-b07e-b103b1ea70df@github.com>
 <-qY-3aqlEgzGsC77q1O_WFt-znvLSnMdt43bdsebByw=.1c24ccc6-51db-4acf-815c-92fd06f7bb1c@github.com>
Message-ID: <6ZQDnY_rqVh9bFWtxDFPzn-sjIoBM3K_EIqxTfMT6UU=.80f8cc04-613b-456d-924b-3ef63d63120b@github.com>

On Fri, 8 Mar 2024 05:03:42 GMT, Chen Liang <liach at openjdk.org> wrote:

> Can Class::getModule ever return null after module system is initialized?

No.

`lookupModule == null` when module system is being initialized before java.base is defined.   So the null check needs to be there.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1040#discussion_r1517171301


From dan.heidinga at oracle.com  Fri Mar  8 14:59:14 2024
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Fri, 8 Mar 2024 14:59:14 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
 <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
 <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
Message-ID: <DS0PR10MB62716040B7DEF9FF87FD0A5AE7272@DS0PR10MB6271.namprd10.prod.outlook.com>

(Response in line)

From: Kennke, Roman <rkennke at amazon.de>
Date: Wednesday, March 6, 2024 at 1:43?PM
To: Dan Heidinga <dan.heidinga at oracle.com>
Cc: Thomas St?fe <thomas.stuefe at gmail.com>, valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>, lilliput-dev at openjdk.org <lilliput-dev at openjdk.org>
Subject: [External] : Re: Re: Sharing the markword (aka Valhalla's markword use)
Hi Dan,

> 4 free bits ? just what we need! =)

Yes, but my questions about constraints remain.
Apologies.  I thought I had responded in the other thread.  Three of the bits can be rediscovered / determined from the Klass metadata and I?m not aware of any requirements on the specific bit position.  The 4th bit ? the is_larval bit ? needs to be preserved and we envision uses of it by future (de)duplication processes that may run as part of the gc.  Particular bit position doesn?t matter as long as we can find the bit.
Does that answer your questions?


>  One of the challenges for J9 over the last few years has been finding header bits.  J9 went to a ?single word header?, uses the has_been_hashed | has_been_moved trick for identity hash, and has a more complicated scheme for which classes get lock words (or not) and where they?re put per class (layout gaps are a pretty common choice).  This has limited the ability of new features to get header bits without decreasing gc age bits or stealing a bit from existing use cases.
>  Small headers are good but how small is small enough?  This isn?t a Valhalla concern per se, but a general observation that if we are bumping the limit on bits now, we are limiting all future project?s ability to use bits.  There?s a trade-off here that my experience fighting for bits on J9 says we should be making cautiously.

I understand. My point of view is that it doesn?t make a lot of sense to not do a tremendously useful optimization like 8- or 4-byte headers, just because we may need something in the future. But I agree that we should try to make it flexible enough to accommodate future needs, or at least make it relatively easy.
I?m offering some caution on the value of shrinking the header as small as possible today as it severally restricts future options.  I know you and Thomas and others are taking a principled look at this space to find the best encodings and I want to be a voice for keeping additional slack in the encoding for future projects (Java?s not done after all =)

Let?s first lay out a rough plan about what we?re planning to do with class-pointers.

Currently, compressed class-pointers are 32 bits wide, and from what I can tell, is more than enough to address as many classes as anybody would want.

For 8-byte headers, our plan is to use 22 bits and still address enough classes (see Thomas? part of the FOSDEM presentation). This leaves enough bits for 31 bit hashcode, 4 Valhalla bits, 4 age bits, 1 self-forwarding bits and 2 lock bits.
That?s great.  If we start by planning on 4 Valhalla bits then we can always look at clever encodings as follow tasks when the need for more bits surfaces.
We have a plan how we can make the class-pointer much smaller. Based on the observation that most workloads only require a few 10000 classes, let?s say 15 bits is ?enough? and not wasteful. Workloads that require more often generate those classes, which often don?t have many instances (e.g. only 1). In order to address arbitrary many classes, we would require one more bit that indicates that the class-pointer should be loaded from a dedicated field - this could be compressed 32 bits, or uncompressed 64 bits, or somehow be combined with the 15 class-bits from the header, we can determine the details later. We can also determine the exact number of bits later. The point is that we can make the class-pointer small enough to accommodate, say, 99% of all workloads and flexible enough for everything else. Using those 16 class-bits, and assuming 2(hash)+4(Valhalla)+4(age)+3(locking), we?d still have a reserve of 3 bits. We could use them for more classes, or reserve them for future use. It does not seem unreasonable to make the class-bits even smaller, in case we ever need more bits.

Also, if we ever need a bit only for arrays (wasn?t one of the Valhalla bits only for arrays?), we?d have one bit that we can use from the array-length field.
Two of the bits are for arrays and in the Valhalla we?ve also floated the idea of clever encodings like using the array-length.  The challenge is that such encodings float through the rest of the system and have surprising knock on effects.  As an example, we looked at overloading the high bit of array length in J9 and, although I don?t recall the details, there was an issue with some array bounds checks getting slower as they required additional masks.
It sounds like we have a path forward with bits available for Valhalla without affecting Lilliput?s plans.  Do you see any concerns not listed here?
--Dan


Let me know what you think.

Roman


>  --Dan
>  From: Thomas St?fe <thomas.stuefe at gmail.com>
> Date: Tuesday, March 5, 2024 at 11:29?AM
> To: Dan Heidinga <dan.heidinga at oracle.com>
> Cc: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>, lilliput-dev at openjdk.org <lilliput-dev at openjdk.org>, Kennke, Roman <rkennke at amazon.de>
> Subject: [External] : Re: Sharing the markword (aka Valhalla's markword use)
> Hi Dan,
>  In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits.
>  Unfortunately, outside of our heads and the FOSDEM talk [2] we gave this year I think this is nowhere documented yet. I feel guilty but have been swamped since returning from FOSDEM.
>  [1] https://urldefense.com/v3/__https://github.com/openjdk/lilliput/pull/128__;!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCEZfQ9I9$<https://urldefense.com/v3/__https:/github.com/openjdk/lilliput/pull/128__;!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCEZfQ9I9$>
> [2] https://urldefense.com/v3/__https://fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/__;!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCCetCSuA$<https://urldefense.com/v3/__https:/fosdem.org/2024/schedule/event/fosdem-2024-3015-project-lilliput-compact-object-headers/__;!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCCetCSuA$>
>  Cheers, Thomas
>  On Tue, Mar 5, 2024 at 4:06?PM Dan Heidinga <dan.heidinga at oracle.com> wrote:
> (Cross-posting to both valhalla-dev and lilliput-dev)
>  Valhalla?s markword usage and Lilliput?s desire to shrink the object header require some careful collaboration to find a design that let?s both projects move forward.  I?d like to lay out the current Valhalla markword use so that we can look at how it fits with Lilliput?s plans and ensure we can make the right trade-offs together.  There may be clever encodings (reusing the locking bits?) but it makes sense to do that together ? hence the cross-post.
>  Valhalla uses 4 markword bits [0], two for instances and two for arrays.  The bits are:
>  * is_larval: This is bit is dynamic and indicates the state change from when a value instance can be updated (during construction) to when it becomes immutable.  We need this bit to ensure correctness of off-label construction and debugging apis as well as to ensure values being constructed are never aliased with fully constructed values.
>  * is_value_type: this bit is static and is used to identify value instances.  This bit speeds acmp and other identity sensitive operations so that non-value code doesn?t experience a regression.  Before values, acmp could use pointer comparison to test if two instance were the same.  With values a ?substitutability? test is required.
>  For value instances, neither the hash code nor their locking bits are required.  Value hash codes are computed similarly to the substitutability test and values cannot be locked or synchronized on.
>  Arrays of values are identity objects and, like other reference array types, are compatible with Object[] or interface arrays (assuming the values implement the interface).
>  We use two bits to identify the special cases of arrays:
>  * is_flat_array: Indicates that the array elements have been flattened and that data must be copied in/out of the array when accessing the elements.
>  * is_null_free_array: indicates that the array rejects null elements and will throw an exception when code attempts to store null into the array.
>  Arrays ? being identity objects ? need both their hash codes and locking bits.
>  This is what Valhalla is using the current prototypes.  Early performance experiments led us to this design and we?re working on reconfirming those results.
>  How does this approach fit with the current Lilliput plans?
>  --Dan
>  [0] https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCB8WCdsM$<https://urldefense.com/v3/__https:/github.com/openjdk/valhalla/blob/1f410430df6ef023b82d971a10ee4f0f8dfa2d6b/src/hotspot/share/oops/markWord.hpp*L69__;Iw!!ACWV5N9M2RV99hQ!NEUrYwA0GRM8U1H-5SrLV7vXMk0nr9mDhhPK7lnoKFZQKloskZA2uEpPbroQKnz_-8DCexbKx7peCB8WCdsM$>





Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

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

From rriggs at openjdk.org  Fri Mar  8 15:45:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 15:45:07 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v2]
In-Reply-To: <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
 <YpY0D7pTBR2lLuIUgLsfJQyn8pmu0_PCqPcxyBnTTOg=.4c348f5d-a8b5-4612-aa62-41f598f42a41@github.com>
Message-ID: <K5vHvL1CvDZWdeGlQbiYVuVlTQe6MlpNkPnS520Gwaw=.ad5a3b99-d7c5-4011-b217-bba0e799baba@github.com>

On Fri, 8 Mar 2024 03:22:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> As specified in JEP 401, when preview features are enabled, the following standard library classes are considered to be value classes:
>> 
>>     java.lang.Byte
>>     java.lang.Short
>>     java.lang.Integer
>>     java.lang.Long
>>     java.lang.Float
>>     java.lang.Double
>>     java.lang.Boolean
>>     java.lang.Character
>>     java.util.Optional
>>     java.lang.Number
>>     java.lang.Record
>> 
>> 
>> These value classes are loaded only if --enable-preview is set.    All valhalla tests should have preview enabled to ensure testing with the proper set of library classes.
>> 
>> Testing: Run `jdk_valhalla` and `hotspot_valhalla_runtime` with  `-Xint` with and without `--enable-preview`.  The result is pretty good.  [JDK-8327637](https://bugs.openjdk.org/browse/JDK-8327637) and [JDK-8327639](https://bugs.openjdk.org/browse/JDK-8327639) need further investigation.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed duplicated Record

LGTM

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1040#pullrequestreview-1925156717


From rriggs at openjdk.org  Fri Mar  8 16:12:19 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 16:12:19 GMT
Subject: [lworld] RFR: 8327702: [lworld] Update java.lang.Object mention of
 value classes
Message-ID: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>

Correct java.lang.Object doc for identity and value classes

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

Commit messages:
 - 8327702: [lworld] Update java.lang.Object mention of value classes

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

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


From mchung at openjdk.org  Fri Mar  8 17:49:33 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 17:49:33 GMT
Subject: [lworld] RFR: 8327636: [lworld] Make primitive wrappers be value
 class if preview feature is enabled [v3]
In-Reply-To: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
Message-ID: <MB-BmPqcm4gpAn8ukpw3WLUKi2LNbZHzDY8Gubj4RCY=.80de3c64-25ea-412d-bb8b-1f8a1312ecb7@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240308/9922fce0/attachment.htm>

From mchung at openjdk.org  Fri Mar  8 17:49:33 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 17:49:33 GMT
Subject: [lworld] Integrated: 8327636: [lworld] Make primitive wrappers be
 value class if preview feature is enabled
In-Reply-To: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
References: <2apHhONl55-kzXj4MMLw7WElE_5zmDQ213WkO-ipef0=.26a9b443-0bf9-4f85-a892-b47499f6cbab@github.com>
Message-ID: <KO1ihLVtlnBgICVRSE6GdkeMbKzwk1KWFjdooOJ_DWE=.36b76150-eb1a-49f6-96e6-68323c67e099@github.com>

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

From mchung at openjdk.org  Fri Mar  8 20:24:04 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 8 Mar 2024 20:24:04 GMT
Subject: [lworld] RFR: 8327702: [lworld] Update java.lang.Object mention of
 value classes
In-Reply-To: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>
References: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>
Message-ID: <KIwsJHVP_3RJdYktMEJDKHp1uXt59AIpCS_qDh2yL_Q=.14924f65-23dd-4394-9ed3-fe9dd15f4c97@github.com>

On Fri, 8 Mar 2024 16:07:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct java.lang.Object doc for identity and value classes

Marked as reviewed by mchung (Committer).

src/java.base/share/classes/java/lang/Object.java line 40:

> 38:  * <p>
> 39:  * Subclasses of {@code java.lang.Object} can be either identity classes or value classes.
> 40:  * See {@jls The Java Language Specification 8.1.1.5 value Classes}.

This does not seem highly necessary.   If it's there, maybe worth adding the link to `Class::isIdentity` and `Class::isValue`

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

PR Review: https://git.openjdk.org/valhalla/pull/1041#pullrequestreview-1925775356
PR Review Comment: https://git.openjdk.org/valhalla/pull/1041#discussion_r1518254728


From rriggs at openjdk.org  Fri Mar  8 23:21:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 23:21:34 GMT
Subject: [lworld] RFR: 8327702: [lworld] Update java.lang.Object mention of
 value classes [v2]
In-Reply-To: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>
References: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>
Message-ID: <VE7i34SBhQ15F2k42Z2LSBChn0At1ovN4tJXD6f_nxI=.dbd17e0c-5458-44b3-b7de-f99c818402ab@github.com>

> Correct java.lang.Object doc for identity and value classes

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

  Add links to Class.isIdentity() and Class.isValue()

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1041/files
  - new: https://git.openjdk.org/valhalla/pull/1041/files/86535795..8675c1c0

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

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

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


From liangchenblue at gmail.com  Sat Mar  9 19:52:31 2024
From: liangchenblue at gmail.com (-)
Date: Sat, 9 Mar 2024 13:52:31 -0600
Subject: A quick rundown of the current state of LW401
Message-ID: <CABe8uE3xgbBaKuExkMnFv2-=sOX_MbA5VhzaNk95gABOeP5R=Q@mail.gmail.com>

Hi valhalla community,
Since the introduction of the idea of null restriction, the valhalla model
has undergone a huge brainstorm and become much simpler and more
backward-compatible in the new lw401; however, valhalla-docs is now
outdated, especially part 3, the JVM model, and there is no good single
source of truth to look at for our current status.

Here are the most significant changes from the existing documents per my
understanding:
1. Primitive/Inlined classes become special storage of value classes with
default instance and non-atomicity, removing the artificial primitive-value
split and the Q descriptors, leaving just right information for VM to
choose to inline; now we are looking at checked types, but it is still up
to debate (ASM visitor compatibility concerns from R?mi).
2. Value class construction now reuses new-dup-init sequence (shout out to
John Rose for his innovations), with larval-stage and final semantics
guaranteed by writing before super calls.
3. Identity becomes a feature, valueness is determined by ACC_IDENTITY (old
ACC_SUPER), previous ACC_VALUE and ACC_PERMITS_VALUE gone; abstract classes
can become value yet can be extended by identity classes. Uses custom
handling of Object class (construction, superclass rule) to preserve
compatibility and removed marker interfaces
4. Legacy primitives still somewhat differ from the wrappers, such as ==
for double vs Double raw bits, whether Double/Long should tear (currently
they don't, but their primitives do) but this is more of long-term
consideration
5. VM implementation will consider the compatibility with lilliput, as we
seem to require 4 bits in the header. (value, larval, flattened array,
null-free array)

Am I missing anything important here? I wish we can update the notes
somewhere so that we don't have to dig through the mailing list.

Regards,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240309/aeaba54f/attachment.htm>

From brian.goetz at oracle.com  Sat Mar  9 23:52:20 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 9 Mar 2024 23:52:20 +0000
Subject: A quick rundown of the current state of LW401
In-Reply-To: <CABe8uE3xgbBaKuExkMnFv2-=sOX_MbA5VhzaNk95gABOeP5R=Q@mail.gmail.com>
References: <CABe8uE3xgbBaKuExkMnFv2-=sOX_MbA5VhzaNk95gABOeP5R=Q@mail.gmail.com>
Message-ID: <10D28CDC-84FC-427B-A8C6-AF2D5146CA60@oracle.com>

Yes, it would be great to update the documents, now that the design has settled.  

My mental model here is that this project has been like the ?Spanish Inquisition? sketch by Monty Python:

The main impediment to flattening is identity.  

The two main impediments are Identity and Nullity.  

Identity, Nullity, and implicit constructibility.  

AMONGST the impediments to flattening, are identity, nullity, implicit constructibility, and atomicity?.

Each of these impediments maps to a programming language construct, that gives up unused degrees of freedom:

 - value types give up identity
 - null-restricted variables give up nullability
 - value types with implicit constructors give up the requirement that all creation go through constructors
 - non-atomic / LooselyCoherentValue give up the requirement that loads and stores be atomic with respect to each other

The more you give up, the more flattening you enable.  



> On Mar 9, 2024, at 11:52 AM, liangchenblue at gmail.com wrote:
> 
> Hi valhalla community,
> Since the introduction of the idea of null restriction, the valhalla model has undergone a huge brainstorm and become much simpler and more backward-compatible in the new lw401; however, valhalla-docs is now outdated, especially part 3, the JVM model, and there is no good single source of truth to look at for our current status.
> 
> Here are the most significant changes from the existing documents per my understanding:
> 1. Primitive/Inlined classes become special storage of value classes with default instance and non-atomicity, removing the artificial primitive-value split and the Q descriptors, leaving just right information for VM to choose to inline; now we are looking at checked types, but it is still up to debate (ASM visitor compatibility concerns from R?mi).
> 2. Value class construction now reuses new-dup-init sequence (shout out to John Rose for his innovations), with larval-stage and final semantics guaranteed by writing before super calls.
> 3. Identity becomes a feature, valueness is determined by ACC_IDENTITY (old ACC_SUPER), previous ACC_VALUE and ACC_PERMITS_VALUE gone; abstract classes can become value yet can be extended by identity classes. Uses custom handling of Object class (construction, superclass rule) to preserve compatibility and removed marker interfaces
> 4. Legacy primitives still somewhat differ from the wrappers, such as == for double vs Double raw bits, whether Double/Long should tear (currently they don't, but their primitives do) but this is more of long-term consideration
> 5. VM implementation will consider the compatibility with lilliput, as we seem to require 4 bits in the header. (value, larval, flattened array, null-free array)
> 
> Am I missing anything important here? I wish we can update the notes somewhere so that we don't have to dig through the mailing list.
> 
> Regards,
> Chen Liang


From john.r.rose at oracle.com  Sun Mar 10 03:38:35 2024
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 09 Mar 2024 19:38:35 -0800
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
 <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
Message-ID: <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>

What Dan said.  Here?s more color commentary:

The larval state of a value object can be viewed as an analog of the locked state of an identity object.  In both cases, one specific thread is doing something exclusive to the object.  For values, this larval state is indeed highly exclusive:  The thread that made the value object is also filling in its fields, protected either by the verifier (if it is constructor code) or by some other means (if the fields are being set by privileged non-constructor code).  Unlike a locked identity object, once a value exits the larval state, it is forever an adult; an identity object can be relocked many times.

All that said, the lifecycles are different, but they are similar enough that we can envision using some of the same bit-patterns in parallel.  I am pretty sure that whatever locked state indicator (a bit pattern) that we invent for the object header of an identity object is more than adequate for a value object in its larval state.

So, just have each GC process larvae very much like locked objects, and arrange the header bit patterns to make this easy, by making them be similar.

And, as an aside, in the future the GC or JIT may perform deduplication (or, say, NUMA-sensitive duplication) of values, or any other reorganization that reassigns varying pointers which alias equivalent copies of the same value state.  In such a case, please be sure to treat every larval value object as unique and never aliased to any other value object, however similar.  A larval value is likely to be side-effected to a new state before it becomes adult, which would cause bad failures if it were accidentally treated as aliased to some unrelated value.  Only adult values are legitimate subjects for alias-based optimizations, whether in the JIT or GC.

Regarding the other bits (is-value, is-flat-array, is-null-free-array), those can all be re-hoisted from the Klass object, if for some reason the header needs  to be restored or reset.  After all, those bits are just optimized copies (hoisted into a convenient place in the header), copied from the original information in the Klass object itself.  This hoisting is a performance hack.  We are discussing it at length here because the Valhalla team has determined, at least provisionally, that acceptable product performance requires such a ?hoisting hack?.

I suggest adding, to Klass itself, a field which is a prototype header for the object, with all the right bits in place.  The GC can use that as a starting point when repairing headers that it had to reset.  (I thought we already had something like this somewhere, but a quick check came up empty?)  Currently, it appears we reset object headers from markWord::prototype which is an absolute constant.  Perhaps this function should be refactored to a query to non-static Klass::prototype_mark_word.  That?s just my $0.02; probably stuff like this has been discussed several times.

A final suggestion, which I?ve mentioned elsewhere, but it?s worth repeating:  If we don?t choose to burn whole a bit on the is-value test, we can use a joint bit encoding.  (Similar point for an is-array test, in fact, or for particular subkinds of arrays.)  In either the klass or IHC subfield of the header, we might be able to get away with stating something like, ?if there 10 or more zeroes at the high end of the subfield, then the object is a value, and otherwise it?s not?.  That would steal dynamic range from the subfield for values, but would leave the non-values unscathed (except for the responsibility to avoid that 1/1024 fraction of reserved encodings).  For more details, please see: https://cr.openjdk.org/~jrose/jvm/joint-bit-encodings.html

On 6 Mar 2024, at 7:20, Dan Heidinga wrote:

> Values lack identity so it?s possible for them to be deduplicated (or even duplicated!) at any point when they are not in the larval state.  That would mean we?d need the is_larval bit to be stable to any process (gc?) that may be responsible for (de)duplication.
>
>
>
>  The other three bits shouldn?t be required during GC and can be re-derived from the klass metadata.



From john.r.rose at oracle.com  Sun Mar 10 05:06:01 2024
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 09 Mar 2024 21:06:01 -0800
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
Message-ID: <B872A9D5-DF87-40E1-992C-F0B883C325DE@oracle.com>

On 5 Mar 2024, at 8:28, Thomas St?fe wrote:

> Hi Dan,
>
>  In addition to Roman's answer, we plan to reduce the Klasspointer to 22 bits [1]. For 64-bit headers, this would give us 31-bit i-hash back and still leave us with 4 unused bits.

Thank you for making that clear.

It looks like there are plenty of bits in the 64-bit header for Valhalla, so some of the tricky bit-twiddling suggested in my previous mail is not needed, unless (at some future date) we go to 32-bit headers.  I?m going to make a wild guess that Valhalla is likely to come before 32-bit headers.

IMO, the proposal about loading the prototype header bits out of the Klass metadata is still reasonable to consider, regardless of header size.


From john.r.rose at oracle.com  Sun Mar 10 05:53:25 2024
From: john.r.rose at oracle.com (John Rose)
Date: Sat, 09 Mar 2024 21:53:25 -0800
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CAA-vtUxCPX++bU_rU4PnvOTk2hjyYcbD8ECYtnKRPFyG7zcYcQ@mail.gmail.com>
 <DS0PR10MB6271877B12E81592AFB8303CE7212@DS0PR10MB6271.namprd10.prod.outlook.com>
 <3751A866-5B63-461F-8CA4-C8448004D367@amazon.de>
 <02B3277A-354B-46C1-B44E-018A4D973A4D@amazon.de>
Message-ID: <4BA1192F-97F8-4857-9C13-2DEDDFD5E49B@oracle.com>

On 6 Mar 2024, at 10:47, Kennke, Roman wrote:

> I shall add that this is possible because we know at class-loading time whether or not we?re going to exceed the class-addressing-limit, and reserve the extra Klass* field at class-loading time, during field layout, and allocate all affected instances with that extra field right from the start, no stunts needed like with the compact I-hash stuff.

(What follows is speculation oriented towards an indefinite future?  Apologies in advance to Valhalla-dev for irrelevant stuff.)

Yes, I think this could work.  You could say that if the narrow-klass field is all-zero-bits, or if some separate mode bit is set, then we have to fish the full-klass field out from side storage somewhere in the object.  It?s a new expanded mode of klass storage.

Where is that side storage?  Well, it can?t be a fixed location in the object, so there?s a gap in that design; just a mode bit or an all-zero-bits condition doesn?t help you.

(Why not a fixed location, like offset=4?  Because you might overflow the narrow-klass field?s encoding range, when loading a subclass of a class which already uses the desirable offset=4 slot for a regular instance field.  You can get around this by using offset=-4, but that opens different cans of worms. Better to assume instance fields will compete for offsets with the injected full-klass field.)

You might want to store the offset of the full-klass field in the narrow-klass field, and use your mode bit to decide which access mode to use.  Hence 15 for the narrow-klass, plus 1 for the expansion mode bit.

But, the joint bit encoding trick could be helpful here, to reduce the impact of the mode bit on header density.  Use 16 bits for the narrow-klass field.  Then, if the top 8 bits are nonzero, interpret the narrow-klass field as the identifier of one of the pre-eminent 65280 (2^16-2^8) klasses.  If the top 8 bits are zero, the field encodes an offset to find the full-klass field.  With a separate mode bit, you would only be able to represent 32768 distinct klasses in the narrow-klass field.  This is a typical result for joint bit encodings.

If the bottom 8 bits of the narrow-klass field are available to represent an offset (in the second mode), then the full-klass field can be anywhere in the instance as long as the instance size is at most 256 words.  (Assume scaled access, or else say the limit is 256 bytes.)  Surely if an instance is larger than that, we will know when we load the class into the VM, and before we allocate a klass ID.  If the class is non-final there is a hazard of a subclass requiring a full-klass field.  Thus, loading a non-final class of size 255 or larger requires the VM to allocate a full-klass field, whether it uses that field or not.  But, that?s a 0.4% overhead in instance size, so it?s tolerable.  The 0.4% parameter is a function of the number of bits (8) chosen for the joint bit encoding.

(So don?t take the example too literally.  It might not be 8 bits, and it might not be the actual top or bottom bits.  If your CPU doesn?t have a good scaled-load instruction, maybe the zero bits you want are the bottom 3 and the top 5 of a 16-bit narrow-klass field.  Making any such masked test is easy on all our CPUs.  That?s why I think joint bit encodings can be interesting today.)

However, it?s not clear to me whether the cost of a modal narrow-klass field is going to be bearable.  We?ll have to measure it when the time comes.  Testing one bit (or 8 bits) in an object header is one instruction, but it?s an extra instruction, and in general loading the klass of an instance will be a branchy operations with tiny klass fields, where it is not branchy today.  That could be a problem.  It will at least be a challenge to optimize.  If the increased branchiness is a problem, the solution might well be to stay with the larger 64-bit headers.  When we get there we can test.  Different CPUs will give different results.

Idea to reduce branchiness:  Always load the full-klass pointer, let?s say a 64-bit pointer, from an effective address computed from the object and its header.  The narrow-klass field ALWAYS, without branchiness, contributes the offset (scaled or not) to such a load.  The mode bit and/or joint bits contribute the base address.  The base address is a conditional-move instruction whose inputs are the current object and a constant base address where the first 65280 klasses are on display.  This would push the modality into a single CMOV instruction, removing all branching, at the cost of an extra unconditional indirection.

 hdr = *(int *)obj;
 base0 = (Klass *)obj;
 base1 = Universe::narrow_klass_table(); //constant
 base = is_narrow_klass(hdr) ? base0 : base1; //CMOV
 offset = narrow_klass_field(hdr);
 klass = base[ offset ]; // look folks, no branches!

Example optimization:  If static type information in the JIT can prove that an object reference has no subclasses with non-narrow klass IDs, then the JIT can assume that the ?is_narrow_klass? query above is always true, and fold up the CMOV.

Another example optimization:  If I am doing some x instanceof C operation, and C is final, then I can compare the narrow-klass field of x against the narrow encoding of C, and take that as my final answer.  It?s OK if the narrow-klass field is an expansion signal to look for the full-klass field; I don?t need to do that fetch to finish this particular operation.  There may be several more techniques of this kind to remove branchiness from code that looks at object klasses.

As I said before, all this kind of trickery is relevant mainly to 32-bit headers, not 64-bit headers.  And 32-bit headers may well be in the future, relative to Valhalla.  At that future point, little or none of my speculation at this point may apply.  And yet I speculate, FTR.


From david.holmes at oracle.com  Mon Mar 11 01:22:31 2024
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 11 Mar 2024 11:22:31 +1000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
 <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
 <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
Message-ID: <442947d3-6257-46f0-9354-30c1a7877854@oracle.com>

On 10/03/2024 1:38 pm, John Rose wrote:
> What Dan said.  Here?s more color commentary:
<snip>
> I suggest adding, to Klass itself, a field which is a prototype
> header for the object, with all the right bits in place ... 
> (I thought we already had something like this somewhere, but
> a quick check came up empty?)

We used to have the biased-locking prototype header.

klass.hpp
   // Biased locking support
   // Note: the prototype header is always set up to be at least the
   // prototype markOop. If biased locking is enabled it may further be
   // biasable and have an epoch.
   markOop prototype_header() const      { return _prototype_header; }

Cheers,
David




From thomas.stuefe at gmail.com  Mon Mar 11 08:55:24 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 11 Mar 2024 09:55:24 +0100
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <442947d3-6257-46f0-9354-30c1a7877854@oracle.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
 <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
 <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
 <442947d3-6257-46f0-9354-30c1a7877854@oracle.com>
Message-ID: <CAA-vtUzHtp2KbFm3xPBX_2uWVMYGrK-BR0auU7ExHzH3p7H+vw@mail.gmail.com>

In Lilliput, the prototype header contains the nKlass ID.

Cheers, Thomas

On Mon, Mar 11, 2024 at 2:23?AM David Holmes <david.holmes at oracle.com>
wrote:

> On 10/03/2024 1:38 pm, John Rose wrote:
> > What Dan said.  Here?s more color commentary:
> <snip>
> > I suggest adding, to Klass itself, a field which is a prototype
> > header for the object, with all the right bits in place ...
> > (I thought we already had something like this somewhere, but
> > a quick check came up empty?)
>
> We used to have the biased-locking prototype header.
>
> klass.hpp
>    // Biased locking support
>    // Note: the prototype header is always set up to be at least the
>    // prototype markOop. If biased locking is enabled it may further be
>    // biasable and have an epoch.
>    markOop prototype_header() const      { return _prototype_header; }
>
> Cheers,
> David
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240311/147957b5/attachment.htm>

From rkennke at amazon.de  Mon Mar 11 12:41:16 2024
From: rkennke at amazon.de (Kennke, Roman)
Date: Mon, 11 Mar 2024 12:41:16 +0000
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
 <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
 <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
Message-ID: <647B95C3-385F-4698-8867-3D0629896CBE@amazon.de>

Hi John,

> The larval state of a value object can be viewed as an analog of the locked state of an identity object.  In both cases, one specific thread is doing something exclusive to the object.  For values, this larval state is indeed highly exclusive:  The thread that made the value object is also filling in its fields, protected either by the verifier (if it is constructor code) or by some other means (if the fields are being set by privileged non-constructor code).  Unlike a locked identity object, once a value exits the larval state, it is forever an adult; an identity object can be relocked many times.
> 
> All that said, the lifecycles are different, but they are similar enough that we can envision using some of the same bit-patterns in parallel.  I am pretty sure that whatever locked state indicator (a bit pattern) that we invent for the object header of an identity object is more than adequate for a value object in its larval state.
> 
> So, just have each GC process larvae very much like locked objects, and arrange the header bit patterns to make this easy, by making them be similar.

Can value objects be locked? If not, could value objects use the same bits that are used for locking of identity objects?
Other than that, it should be easy to preserve larvae bit across GC, pretty much like lock-bits.

> And, as an aside, in the future the GC or JIT may perform deduplication (or, say, NUMA-sensitive duplication) of values, or any other reorganization that reassigns varying pointers which alias equivalent copies of the same value state.  In such a case, please be sure to treat every larval value object as unique and never aliased to any other value object, however similar.  A larval value is likely to be side-effected to a new state before it becomes adult, which would cause bad failures if it were accidentally treated as aliased to some unrelated value.  Only adult values are legitimate subjects for alias-based optimizations, whether in the JIT or GC.

Ok, that is good to know.

> Regarding the other bits (is-value, is-flat-array, is-null-free-array), those can all be re-hoisted from the Klass object, if for some reason the header needs  to be restored or reset.  After all, those bits are just optimized copies (hoisted into a convenient place in the header), copied from the original information in the Klass object itself.  This hoisting is a performance hack.  We are discussing it at length here because the Valhalla team has determined, at least provisionally, that acceptable product performance requires such a ?hoisting hack?.

That is also very good to know. It means we don?t have to preserve those bits across GCs or other destructive ops, and can always restore them. Makes life easier.

> I suggest adding, to Klass itself, a field which is a prototype header for the object, with all the right bits in place.

In Lilliput we already have that field, for the Klass-pointer (pretty much restored from the earlier prototype for biased locking). We can add more info bits to that prototype header.

>  The GC can use that as a starting point when repairing headers that it had to reset.  (I thought we already had something like this somewhere, but a quick check came up empty?)  Currently, it appears we reset object headers from markWord::prototype which is an absolute constant.  Perhaps this function should be refactored to a query to non-static Klass::prototype_mark_word.  That?s just my $0.02; probably stuff like this has been discussed several times.

Yup, no problem with that.

> A final suggestion, which I?ve mentioned elsewhere, but it?s worth repeating:  If we don?t choose to burn whole a bit on the is-value test, we can use a joint bit encoding.  (Similar point for an is-array test, in fact, or for particular subkinds of arrays.)  In either the klass or IHC subfield of the header, we might be able to get away with stating something like, ?if there 10 or more zeroes at the high end of the subfield, then the object is a value, and otherwise it?s not?.  That would steal dynamic range from the subfield for values, but would leave the non-values unscathed (except for the responsibility to avoid that 1/1024 fraction of reserved encodings).  For more details, please see: https://cr.openjdk.org/~jrose/jvm/joint-bit-encodings.html

Nice, that might be useful.

Thanks!

Roman



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From thartmann at openjdk.org  Mon Mar 11 13:12:08 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 11 Mar 2024 13:12:08 GMT
Subject: [lworld] RFR: 8293541: [lworld] IR verification fails for
 TestLWorld::test109_sharp and test110_sharp
In-Reply-To: <nUN6ZtRKRAPZ4NMRR01GemMAwnwn4E8oGt8tcN4nbY0=.6e5f1d0f-d621-4ef4-bdee-df24e4febaf1@github.com>
References: <nUN6ZtRKRAPZ4NMRR01GemMAwnwn4E8oGt8tcN4nbY0=.6e5f1d0f-d621-4ef4-bdee-df24e4febaf1@github.com>
Message-ID: <ShFy4J7AX32Nwi9G7e3sdKYSn7L0j8pzuhl3e7_33zs=.8b643b82-4932-4405-9a1e-371e662069b1@github.com>

On Thu, 7 Mar 2024 07:36:41 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `test109_sharp()` and `test110_sharp()` originally failed because we have no longer beeen able to apply Loop Predication due to the following merge mistake (left previous, middle merged, right new code from mainline):
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/31c5065a-7e8a-4fcd-bc23-241176cfe9a6)
> 
> This changed the application of EA for these tests in such a way that we need to apply EA twice (iteratively) to remove the wrapping box object and the inline type allocation. This had the side effect that we missed to re-add a memory phi to the IGVN worklist to apply an optimization to get rid of a diamond-if control flow which blocks Loop Predication. IR matching failed because we could not find the corresponding predicate trap for an expected Hoisted Check Predicate.
> 
> This was also a problem in mainline but we had no IR test to catch this. [JDK-8314997](https://bugs.openjdk.org/browse/JDK-8314997) fixed this for mainline and once it was merged with Valhalla, `test109_sharp()` and `test110_sharp()` would now work again.
> 
> But I think we should still fix the merge mistake to eagerly try to remove inline type allocations, regardless of their escape/replaceable status as it was originally intended before the merge. This allows us to get rid of some extra EA iterations.
> 
> However, fixing this merge mistake caused an assertion failure later in EA which checked that safepoints do not have inline type allocation uses (they should be replaced by `SafePointScalarObjectNodes`). To fix that, we need to make sure that any inline type pointer phi node created for an inline type field here (`create_scalarized_object_description()` -> `value_from_mem()` -> `value_from_mem_phi()`):
> 
> https://github.com/openjdk/valhalla/blob/814a5e93cb392a77a43550bf8dab5ab9d52bdcfd/src/hotspot/share/opto/macro.cpp#L378-L379
> 
> when trying to create a `SafePointScalarObjectNode` for a safepoint use is eagerly replaced by an `InlineTypeNode`. To achieve that, I've added a call to `push_inline_types_through()` (renamed to `push_inline_types_down()`) which was only used in `PhiNode::Ideal()` before. I've applied some refactoring and renaming to share that code with EA
> 
> I've tried out some additional assertions in EA that an inline type pointer phi should already be replaced by an `InlineTypeNode` if possible. But that failed. I think we are missing some optimization opportunities here. As this might be out of scope of this bug, I suggest to file a separate RFE to investigate further....

That looks good to me. Thanks for fixing, Christian!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1038#pullrequestreview-1927781968


From rriggs at openjdk.org  Mon Mar 11 16:32:58 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 16:32:58 GMT
Subject: git: openjdk/valhalla: lworld: 8327702: [lworld] Update
 java.lang.Object mention of value classes
Message-ID: <6d33e4c9-be5f-430e-acd6-b73dbb49efc1@openjdk.org>

Changeset: 13fba3e7
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2024-03-11 16:32:19 +0000
URL:       https://git.openjdk.org/valhalla/commit/13fba3e7606de63fabf7bf34a6314b62a82f4fcd

8327702: [lworld] Update java.lang.Object mention of value classes

Reviewed-by: mchung

! src/java.base/share/classes/java/lang/Object.java



From rriggs at openjdk.org  Mon Mar 11 16:35:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 16:35:26 GMT
Subject: [lworld] Integrated: 8327702: [lworld] Update java.lang.Object mention
 of value classes
In-Reply-To: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>
References: <yNjg4yMF2FKQTl2mvuPXl_gHj1VWICgBWELqtvXyvs0=.3611019f-cee5-45d2-90ee-93e0cff71652@github.com>
Message-ID: <4mv3RB9jCSsjKpAvn2FVRbVeyRQaOB0YGTDnjoKtiA8=.5432dfd9-ecff-482e-b409-e3cea5054f7f@github.com>

On Fri, 8 Mar 2024 16:07:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct java.lang.Object doc for identity and value classes

This pull request has now been integrated.

Changeset: 13fba3e7
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/13fba3e7606de63fabf7bf34a6314b62a82f4fcd
Stats:     7 lines in 1 file changed: 0 ins; 3 del; 4 mod

8327702: [lworld] Update java.lang.Object mention of value classes

Reviewed-by: mchung

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

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


From rriggs at openjdk.org  Mon Mar 11 16:39:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 16:39:22 GMT
Subject: [lworld] RFR: 8327639: [lworld]
 test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails
 with --enable-preview
Message-ID: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>

The test contains a bug in which it attempts to use streams from ModuleReader.list() after the ModuleReader has been closed.  Closing ModuleReader closes the underlying streams to the Jar/Zip file.

The bug is only exercised when a patched module is read. Currently, --enable-preview uses module patching of the java.base module to include a set of classes that have been converted to be value classes.

The test is modified to cache the results of the stream in a List and keep the scoped structure used by try-with-resources.

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

Commit messages:
 - 8327639: [lworld] test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails with --enable-preview

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

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


From rriggs at openjdk.org  Mon Mar 11 16:39:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 16:39:22 GMT
Subject: [lworld] RFR: 8327639: [lworld]
 test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails
 with --enable-preview
In-Reply-To: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
References: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
Message-ID: <iUkFV9BMA57Q75IWWwJlYfZr0fAs0Hg40zr-lxznLi0=.44971edb-dbdc-4be0-9a90-790f9f793203@github.com>

On Mon, 11 Mar 2024 14:31:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test contains a bug in which it attempts to use streams from ModuleReader.list() after the ModuleReader has been closed.  Closing ModuleReader closes the underlying streams to the Jar/Zip file.
> 
> The bug is only exercised when a patched module is read. Currently, --enable-preview uses module patching of the java.base module to include a set of classes that have been converted to be value classes.
> 
> The test is modified to cache the results of the stream in a List and keep the scoped structure used by try-with-resources.

This should/can be fixed in the main line; it is not Valhalla dependent.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1042#issuecomment-1988586833


From mchung at openjdk.org  Mon Mar 11 17:18:06 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 17:18:06 GMT
Subject: [lworld] RFR: 8327639: [lworld]
 test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails
 with --enable-preview
In-Reply-To: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
References: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
Message-ID: <7LTo1-cl2u-6dxhHA7e8RF5C3qYXPc9mc0Zn4YN6hwA=.29b084a8-cc11-43d4-af34-7bd00b80fe87@github.com>

On Mon, 11 Mar 2024 14:31:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test contains a bug in which it attempts to use streams from ModuleReader.list() after the ModuleReader has been closed.  Closing ModuleReader closes the underlying streams to the Jar/Zip file.
> 
> The bug is only exercised when a patched module is read. Currently, --enable-preview uses module patching of the java.base module to include a set of classes that have been converted to be value classes.
> 
> The test is modified to cache the results of the stream in a List and keep the scoped structure used by try-with-resources.

Thanks for fixing this.    It would be good to compute `callerSensitiveMethods(Object.class.getModule())` once and save the resulting List in a static field.   Otherwise looks good.

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

Marked as reviewed by mchung (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1042#pullrequestreview-1928519623


From john.r.rose at oracle.com  Mon Mar 11 17:25:18 2024
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 11 Mar 2024 10:25:18 -0700
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <CAA-vtUzHtp2KbFm3xPBX_2uWVMYGrK-BR0auU7ExHzH3p7H+vw@mail.gmail.com>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
 <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
 <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
 <442947d3-6257-46f0-9354-30c1a7877854@oracle.com>
 <CAA-vtUzHtp2KbFm3xPBX_2uWVMYGrK-BR0auU7ExHzH3p7H+vw@mail.gmail.com>
Message-ID: <574A5F2B-CB68-4163-AA89-3D4B9FC84F67@oracle.com>

Thanks, David; I wondered when Klass::prototype_header came and went.

Thomas, a peek at klass.hpp shows that Klass::prototype_header has 
returned to us in Lilliput, with helpers like oopDesc::init_mark.  Nice. 
  That looks like a good way to manage Valhalla?s new hoisted metadata 
bits as well as other header bits.

On 11 Mar 2024, at 1:55, Thomas St?fe wrote:

> In Lilliput, the prototype header contains the nKlass ID.
>
> Cheers, Thomas
>
> On Mon, Mar 11, 2024 at 2:23?AM David Holmes 
> <david.holmes at oracle.com>
> wrote:
>
>> On 10/03/2024 1:38 pm, John Rose wrote:
>>> What Dan said.  Here?s more color commentary:
>> <snip>
>>> I suggest adding, to Klass itself, a field which is a prototype
>>> header for the object, with all the right bits in place ...
>>> (I thought we already had something like this somewhere, but
>>> a quick check came up empty?)
>>
>> We used to have the biased-locking prototype header.
>>
>> klass.hpp
>>    // Biased locking support
>>    // Note: the prototype header is always set up to be at least the
>>    // prototype markOop. If biased locking is enabled it may further 
>> be
>>    // biasable and have an epoch.
>>    markOop prototype_header() const      { return _prototype_header; 
>> }
>>
>> Cheers,
>> David
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240311/53a600c8/attachment.htm>

From mchung at openjdk.org  Mon Mar 11 17:33:18 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 17:33:18 GMT
Subject: [lworld] RFR: 8327836: [lworld] update java/lang/invoke/VarHandles
 tests with preview feature enabled
Message-ID: <yngOZe8G8U3NHixGovRYHXDvuuEAK_zKf8L688R7Mms=.5c3cd769-7092-4703-a0e9-ced2de92a7f0@github.com>

Update test/jdk/java/lang/invoke/VarHandles valhalla tests with `@enablePreview`

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

Commit messages:
 - 8327836: [lworld] update java/lang/invoke/VarHandles tests with preview feature enabled

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

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


From rriggs at openjdk.org  Mon Mar 11 17:54:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 17:54:59 GMT
Subject: [lworld] RFR: 8327836: [lworld] update java/lang/invoke/VarHandles
 tests with preview feature enabled
In-Reply-To: <yngOZe8G8U3NHixGovRYHXDvuuEAK_zKf8L688R7Mms=.5c3cd769-7092-4703-a0e9-ced2de92a7f0@github.com>
References: <yngOZe8G8U3NHixGovRYHXDvuuEAK_zKf8L688R7Mms=.5c3cd769-7092-4703-a0e9-ced2de92a7f0@github.com>
Message-ID: <JMCKkngYMVGmgFroNcI3frL3FOfQRBNyv4coGLnd1hQ=.2d9f41eb-f0f3-4df7-9f2f-66f2c2532533@github.com>

On Mon, 11 Mar 2024 17:29:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Update test/jdk/java/lang/invoke/VarHandles valhalla tests with `@enablePreview`

Marked as reviewed by rriggs (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1043#pullrequestreview-1928617787


From vromero at openjdk.org  Mon Mar 11 18:03:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Mar 2024 18:03:26 GMT
Subject: RFR: Merge lworld
Message-ID: <P_wn-ZiVXiLgZfd-O7SqARKhf8QkwzGqhSNthXq-va4=.47e11053-25ca-4c5c-b7f4-55fce7c7a2d0@github.com>

Merge lworld into lw5

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

Commit messages:
 - Merge lworld
 - 8326990: [lworld] make value classes a preview feature
 - 8327498: [lworld] Remove Q-descriptor change from ASM and other clean up
 - 8327253: [lworld] Preloading of classes needs a complete rework
 - 8327080: [lworld] Update Valhalla micros to JEP 401
 - 8327235: [lworld] remove the 'enablePrimitiveClasses' compiler option from tests
 - 8327280: [lworld] aarch64 compilation fails without support for JDK-8327150
 - 8327213: [lworld] Valhalla runtime testing move to classfile API
 - 8327150: [lworld] Update C1 to support new value construction scheme from JEP 401
 - 8326707: [lworld] Remove VALUE modifier from Modifier and AccessFlag
 - ... and 10 more: https://git.openjdk.org/valhalla/compare/f47a9e26...e14ff3c6

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

Changes: https://git.openjdk.org/valhalla/pull/1044/files
  Stats: 19471 lines in 699 files changed: 4044 ins; 13229 del; 2198 mod
  Patch: https://git.openjdk.org/valhalla/pull/1044.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1044/head:pull/1044

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


From vromero at openjdk.org  Mon Mar 11 18:08:17 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Mar 2024 18:08:17 GMT
Subject: RFR: Merge lworld [v2]
In-Reply-To: <P_wn-ZiVXiLgZfd-O7SqARKhf8QkwzGqhSNthXq-va4=.47e11053-25ca-4c5c-b7f4-55fce7c7a2d0@github.com>
References: <P_wn-ZiVXiLgZfd-O7SqARKhf8QkwzGqhSNthXq-va4=.47e11053-25ca-4c5c-b7f4-55fce7c7a2d0@github.com>
Message-ID: <lKwgmAr6vlJzne9Hy_e_WBDmFxoDl3jl2_Lvd_lq6b8=.704ad9d3-3162-4f78-8511-28893d747c0f@github.com>

> Merge lworld into lw5

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - 8318117: [lw5] create a switch for null-restricted types
 - ... and 32 more: https://git.openjdk.org/valhalla/compare/9c21d4c5...e14ff3c6

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

Changes: https://git.openjdk.org/valhalla/pull/1044/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1044&range=01
  Stats: 3963 lines in 96 files changed: 3474 ins; 274 del; 215 mod
  Patch: https://git.openjdk.org/valhalla/pull/1044.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1044/head:pull/1044

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


From mchung at openjdk.org  Mon Mar 11 18:09:08 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 11 Mar 2024 18:09:08 GMT
Subject: [lworld] Integrated: 8327836: [lworld] update
 java/lang/invoke/VarHandles tests with preview feature enabled
In-Reply-To: <yngOZe8G8U3NHixGovRYHXDvuuEAK_zKf8L688R7Mms=.5c3cd769-7092-4703-a0e9-ced2de92a7f0@github.com>
References: <yngOZe8G8U3NHixGovRYHXDvuuEAK_zKf8L688R7Mms=.5c3cd769-7092-4703-a0e9-ced2de92a7f0@github.com>
Message-ID: <epKNNCwj3dNK9R23SfgPhYgaagsy-SeDZcsagQm-PiQ=.625d91f8-9f35-4157-875b-4237b002dd0d@github.com>

On Mon, 11 Mar 2024 17:29:00 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Update test/jdk/java/lang/invoke/VarHandles valhalla tests with `@enablePreview`

This pull request has now been integrated.

Changeset: 59731800
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/59731800a5a419ec6a19fa74bfb0b46fbd662751
Stats:     6 lines in 6 files changed: 6 ins; 0 del; 0 mod

8327836: [lworld] update java/lang/invoke/VarHandles tests with preview feature enabled

Reviewed-by: rriggs

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

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


From vromero at openjdk.org  Mon Mar 11 18:08:18 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 11 Mar 2024 18:08:18 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <P_wn-ZiVXiLgZfd-O7SqARKhf8QkwzGqhSNthXq-va4=.47e11053-25ca-4c5c-b7f4-55fce7c7a2d0@github.com>
References: <P_wn-ZiVXiLgZfd-O7SqARKhf8QkwzGqhSNthXq-va4=.47e11053-25ca-4c5c-b7f4-55fce7c7a2d0@github.com>
Message-ID: <8mWrJynUL5KkBzIOiHA6fJHhVZYv9nG61ngmv0EIaxw=.4d6a2642-2735-46de-b920-0579a5b2c856@github.com>

On Mon, 11 Mar 2024 17:58:37 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge lworld into lw5

This pull request has now been integrated.

Changeset: eed76822
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/eed7682284c895f9df1f0f348452aa309d16a999
Stats:     19471 lines in 699 files changed: 4044 ins; 13229 del; 2198 mod

Merge lworld

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

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


From rriggs at openjdk.org  Mon Mar 11 18:47:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 11 Mar 2024 18:47:43 GMT
Subject: [lworld] RFR: 8327639: [lworld]
 test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails
 with --enable-preview [v2]
In-Reply-To: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
References: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
Message-ID: <ujA721LxRCyYUBnnZxN37p2xq8AO0qQRk8g1RWNBDlY=.f95a65c6-f766-42c1-993e-9041d70a3e42@github.com>

> The test contains a bug in which it attempts to use streams from ModuleReader.list() after the ModuleReader has been closed.  Closing ModuleReader closes the underlying streams to the Jar/Zip file.
> 
> The bug is only exercised when a patched module is read. Currently, --enable-preview uses module patching of the java.base module to include a set of classes that have been converted to be value classes.
> 
> The test is modified to cache the results of the stream in a List and keep the scoped structure used by try-with-resources.

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

  Compute the list of caller sensitive methods only once yielding a slight performance improvement.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1042/files
  - new: https://git.openjdk.org/valhalla/pull/1042/files/f0b3f4f0..0348ab38

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

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

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


From john.r.rose at oracle.com  Mon Mar 11 20:11:37 2024
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 11 Mar 2024 13:11:37 -0700
Subject: Sharing the markword (aka Valhalla's markword use)
In-Reply-To: <647B95C3-385F-4698-8867-3D0629896CBE@amazon.de>
References: <DS0PR10MB627117E97B7C4CAC2D007A8FE75E2@DS0PR10MB6271.namprd10.prod.outlook.com>
 <CDB3254D-C119-47F1-B3DB-4D26D6C99DC7@amazon.de>
 <DS0PR10MB62718CC6A9577B30990C3247E7222@DS0PR10MB6271.namprd10.prod.outlook.com>
 <E0F1FF8B-60CE-428A-A78F-2F0572D3F3B3@oracle.com>
 <647B95C3-385F-4698-8867-3D0629896CBE@amazon.de>
Message-ID: <B64AF260-CF4F-4114-9649-727A5B11BA71@oracle.com>

On 11 Mar 2024, at 5:41, Kennke, Roman wrote:
>
> Can value objects be locked? If not, could value objects use the same bits that are used for locking of identity objects?

Fair question.  NO, a larval object is never visible outside the thread which created it, so there is no need to lock.  The blanket rule is that value objects (in larval or adult state) are NEVER locked, and the JVM can throw an exception if somebody tries to lock one.

(There are minor exceptions to the rule about visibility of larvae, but they don?t relate to locking.  The GC needs to look at larvae from its worker threads.  So the GC might needs to distinguish the states with care.  But of course the GC doesn?t perform object locking.  A debugger might ask JVMTI to peek inside a thread, and might even try to call a toString method on objects it sees in there.  We will need some special-casing there to prevent larvae from escaping by that route.)

> Other than that, it should be easy to preserve larvae bit across GC, pretty much like lock-bits.

That would be perfect, IMO.

And if the GC ever does identity-shifting optimizations on values, it can consult those saved larval-bits to get the optimizations.

Full disclosure:  The GC does NOT do such things today, AFAIK.  The JIT?s deoptimization logic DOES create new value identities from debug info, when non-allocated objects must be allocated along slow paths.  In that case, the larval bit might be significant even today.  In any case, good JVM architecture not only supports the optimizations we do today, but anticipates a reasonable range of future optimizations.  Designing such a ?future-proof? architecture is inherently difficult and fallible, but IMO it has been one of Java?s distinctive strengths.

For the other points, it looks like we are on the same page.  Thanks for the responses, Roman.



From scolebourne at joda.org  Mon Mar 11 22:38:13 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 11 Mar 2024 22:38:13 +0000
Subject: Is operator overloading in the Valhalla plan?
Message-ID: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>

Is there a plan for operator overloading in Valhalla? As far as I'm
aware there isn't a public plan, and I'm not asking for one in
response to this email. Instead I'm asking if a plan is likely in the
future and how it fits into Valhalla timescales.

I raise this because of the issue with the meaning of == on
Float/Double value types. Bitwise comparison is absolutely fine and
correct for a JVM-level sameness test. But it is *never* what a
developer wants when writing a business application, hence discussion
of alternative approaches such as normalization.

If == was spelled differently (such as an `Objects.same(a, b)` method)
then the recent debate would be irrelevant. But the current proposal
is:
- the only equals operator is spelled ==
- it works 100% correctly for numeric value types including
Float/Double except for the NaN edge cases
Given these two facts, == *will* be widely used as the equals operator
irrespective of the authors' wishes. Just as it is for Enum and Class
objects. This will inevitably lead to bug reports where == on two
different NaN returns false.

As such, I raise the question as to whether there is any kind of plan
or priority to provide an operator mapping to Object.equal() for all
types in Java, not just value types. If you can say that there is such
a plan, then the == on Float/Double issue mostly goes away.

Stephen


From chagedorn at openjdk.org  Tue Mar 12 06:15:26 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 12 Mar 2024 06:15:26 GMT
Subject: [lworld] Integrated: 8293541: [lworld] IR verification fails for
 TestLWorld::test109_sharp and test110_sharp
In-Reply-To: <nUN6ZtRKRAPZ4NMRR01GemMAwnwn4E8oGt8tcN4nbY0=.6e5f1d0f-d621-4ef4-bdee-df24e4febaf1@github.com>
References: <nUN6ZtRKRAPZ4NMRR01GemMAwnwn4E8oGt8tcN4nbY0=.6e5f1d0f-d621-4ef4-bdee-df24e4febaf1@github.com>
Message-ID: <Bn3L_mnOiFZZ_pe8ZMwJ7se7_7kU5e5fCuz4HoQSiao=.65ca2bf7-2471-4407-9256-17ee2852e1f0@github.com>

On Thu, 7 Mar 2024 07:36:41 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> `test109_sharp()` and `test110_sharp()` originally failed because we have no longer beeen able to apply Loop Predication due to the following merge mistake (left previous, middle merged, right new code from mainline):
> 
> ![image](https://github.com/openjdk/valhalla/assets/17833009/31c5065a-7e8a-4fcd-bc23-241176cfe9a6)
> 
> This changed the application of EA for these tests in such a way that we need to apply EA twice (iteratively) to remove the wrapping box object and the inline type allocation. This had the side effect that we missed to re-add a memory phi to the IGVN worklist to apply an optimization to get rid of a diamond-if control flow which blocks Loop Predication. IR matching failed because we could not find the corresponding predicate trap for an expected Hoisted Check Predicate.
> 
> This was also a problem in mainline but we had no IR test to catch this. [JDK-8314997](https://bugs.openjdk.org/browse/JDK-8314997) fixed this for mainline and once it was merged with Valhalla, `test109_sharp()` and `test110_sharp()` would now work again.
> 
> But I think we should still fix the merge mistake to eagerly try to remove inline type allocations, regardless of their escape/replaceable status as it was originally intended before the merge. This allows us to get rid of some extra EA iterations.
> 
> However, fixing this merge mistake caused an assertion failure later in EA which checked that safepoints do not have inline type allocation uses (they should be replaced by `SafePointScalarObjectNodes`). To fix that, we need to make sure that any inline type pointer phi node created for an inline type field here (`create_scalarized_object_description()` -> `value_from_mem()` -> `value_from_mem_phi()`):
> 
> https://github.com/openjdk/valhalla/blob/814a5e93cb392a77a43550bf8dab5ab9d52bdcfd/src/hotspot/share/opto/macro.cpp#L378-L379
> 
> when trying to create a `SafePointScalarObjectNode` for a safepoint use is eagerly replaced by an `InlineTypeNode`. To achieve that, I've added a call to `push_inline_types_through()` (renamed to `push_inline_types_down()`) which was only used in `PhiNode::Ideal()` before. I've applied some refactoring and renaming to share that code with EA
> 
> I've tried out some additional assertions in EA that an inline type pointer phi should already be replaced by an `InlineTypeNode` if possible. But that failed. I think we are missing some optimization opportunities here. As this might be out of scope of this bug, I suggest to file a separate RFE to investigate further....

This pull request has now been integrated.

Changeset: 7749f995
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7749f995f9377f358200e9e49bf139b6b99286eb
Stats:     190 lines in 5 files changed: 107 ins; 64 del; 19 mod

8293541: [lworld] IR verification fails for TestLWorld::test109_sharp and test110_sharp

Reviewed-by: thartmann

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

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


From rriggs at openjdk.org  Tue Mar 12 13:47:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Mar 2024 13:47:33 GMT
Subject: [lworld] Integrated: 8327639: [lworld]
 test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails
 with --enable-preview
In-Reply-To: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
References: <afLunGNlYozkWJ9MZZSMn0m15Jt2_twnVtk440ZvDcM=.54445c80-0fb9-4687-9ddb-7b9d743d920a@github.com>
Message-ID: <9Bq2Upq80-xv3OCvEK8D6gjss8yS7ePrIMrU9MGzE1k=.cca56c81-a6e5-4505-aa53-e0d19d1dd624@github.com>

On Mon, 11 Mar 2024 14:31:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test contains a bug in which it attempts to use streams from ModuleReader.list() after the ModuleReader has been closed.  Closing ModuleReader closes the underlying streams to the Jar/Zip file.
> 
> The bug is only exercised when a patched module is read. Currently, --enable-preview uses module patching of the java.base module to include a set of classes that have been converted to be value classes.
> 
> The test is modified to cache the results of the stream in a List and keep the scoped structure used by try-with-resources.

This pull request has now been integrated.

Changeset: f0a50deb
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f0a50deb3e1b7e6a91a30a94ce87a1f664ce26dc
Stats:     21 lines in 1 file changed: 9 ins; 3 del; 9 mod

8327639: [lworld] test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java fails with --enable-preview

Reviewed-by: mchung

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

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


From livedinsquares at gmail.com  Tue Mar 12 19:14:05 2024
From: livedinsquares at gmail.com (Jonathan F)
Date: Tue, 12 Mar 2024 12:14:05 -0700
Subject: Is operator overloading in the Valhalla plan?
In-Reply-To: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
References: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
Message-ID: <CABR7qmdMFFqj-bDpHc3JKUTL7Wyj-eYJODJmu_gwrJX_EmkUxg@mail.gmail.com>

I was going to bring up equals() and operator overloading like Stephen, but
for a completely different reason, so here goes? Brian?s said in the past
that an operator notation for equals() is probably not a priority right
now. But I think there?s strong reasons for adding it _at the same time_ as
Valhalla, and IMHO there?s also a good notation available:

- With Valhalla developers will gleefully start using == with their new
value classes (I know I will). Because (a) they?ll be regarded as
?user-defined primitives?, (b) x.equals(y) is so awkward, let alone
!x.equals(y), (c) == may be seen as potentially faster than equals().

- The catch, as we know, is that == _usually_ does what we want for value
classes (which is basically equals()), but usually doesn?t when there are
identity fields. So each class has to document == somewhere as if it?s a
method without a predictable meaning.

Case in point: if Color were a value class, many would assume they can use
== for equality, but that wouldn?t work if the RGBA are stored in an array.
IMHO the solution has to be to wean developers off ==  and onto a new
equals() operator, not to tell them to take more care reading the class?s
Javadoc. It?s too risky.

But no operator seems ideal since = isn?t available: I think that?s why we
are where we are. However? I?d suggest === and (say) =/= would work well if
IDEs are encouraged to _display_ them as the equivalence symbols ? and ?
(U+2261/2262), which IntelliJ IDEA already does. They?re attractive and
make mathematical sense: see various uses in
https://en.wikipedia.org/wiki/Triple_bar . Possibly even allow ? in source
code too - Java is the original Unicode-based language, after all?
If this seems just too novel, it could be pointed out that C?s == never
made sense as a math notation and != even less. I see x ? y (typed as x ===
y) as a clear upgrade from x == y, let alone from x.equals(y). It could
also open the door for other Unicode operators in future.

Jonathan
Jonathan Finn


On 11 March 2024 at 22:38:34, Stephen Colebourne (scolebourne at joda.org)
wrote:

Is there a plan for operator overloading in Valhalla? As far as I'm
aware there isn't a public plan, and I'm not asking for one in
response to this email. Instead I'm asking if a plan is likely in the
future and how it fits into Valhalla timescales.

I raise this because of the issue with the meaning of == on
Float/Double value types. Bitwise comparison is absolutely fine and
correct for a JVM-level sameness test. But it is *never* what a
developer wants when writing a business application, hence discussion
of alternative approaches such as normalization.

If == was spelled differently (such as an `Objects.same(a, b)` method)
then the recent debate would be irrelevant. But the current proposal
is:
- the only equals operator is spelled ==
- it works 100% correctly for numeric value types including
Float/Double except for the NaN edge cases
Given these two facts, == *will* be widely used as the equals operator
irrespective of the authors' wishes. Just as it is for Enum and Class
objects. This will inevitably lead to bug reports where == on two
different NaN returns false.

As such, I raise the question as to whether there is any kind of plan
or priority to provide an operator mapping to Object.equal() for all
types in Java, not just value types. If you can say that there is such
a plan, then the == on Float/Double issue mostly goes away.

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

From brian.goetz at oracle.com  Tue Mar 12 19:29:34 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 12 Mar 2024 15:29:34 -0400
Subject: Is operator overloading in the Valhalla plan?
In-Reply-To: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
References: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
Message-ID: <a9bfd3be-7259-4124-b320-2a7a8169a89f@oracle.com>

Without diving into operator overloading, I think you have this bit 
backwards:

On 3/11/2024 6:38 PM, Stephen Colebourne wrote:
> == *will* be widely used as the equals operator
> irrespective of the authors' wishes. Just as it is for Enum and Class
> objects. This will inevitably lead to bug reports where == on two
> different NaN returns false.

But, this is not the case; there is no case where float== says any NaNs 
are equal to any other, even themselves.? Float== treats _all_ NaNs as 
unequal, even the same NaN bit pattern, even the same variable (f == f).

The anomaly created by the proposed Object== semantics is that a value 
type with a float field may treat the two as Object==, when the 
component fields are not float==, because float== uses neither bitwise 
nor representational equivalence, regardless of NaN bit patterns.? But 
we will see such anomalies whether we pick representational or bitwise 
comparison for values, because float== is already weird.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240312/c7a2f781/attachment.htm>

From brian.goetz at oracle.com  Tue Mar 12 19:39:57 2024
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 12 Mar 2024 15:39:57 -0400
Subject: Is operator overloading in the Valhalla plan?
In-Reply-To: <CABR7qmdMFFqj-bDpHc3JKUTL7Wyj-eYJODJmu_gwrJX_EmkUxg@mail.gmail.com>
References: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
 <CABR7qmdMFFqj-bDpHc3JKUTL7Wyj-eYJODJmu_gwrJX_EmkUxg@mail.gmail.com>
Message-ID: <bed0f69e-59c8-4edc-abfb-2e1d0fc54a2f@oracle.com>

You are right that developers will frequently do dumb things in search 
of concision or perceived performance advantage, but I don't think 
that's a compelling argument for "so then let's create yet another 
spelling for equality".

But, underlying the concern you raise is that developers are frequently 
put in the position of worrying whether to use `==` or `.equals()`.? One 
thing Valhalla does do to make this better, but in a perhaps surprising 
way, is that it makes it practical to just always use equals().

Consider implementing the equals() method of a class like:

 ??? class C {
 ?????? int i;
 ?????? String s;

 ?????? public boolean equals(Object other) {
 ?????????? return other instanceof C c
 ?????????????? && i == c.i
 ?????????????? && s.equals(c.s);
 ?????? }
 ??? }

Until Valhalla, there is no equals method to call on `int`, so using 
`==` for int and `.equals()` for String is the only semantically correct 
move -- and this asymmetry is irritating. But with Valhalla, you can write:

 ?????????? return other instanceof C c
 ?????????????? && i.equals(c.i)
 ?????????????? && s.equals(c.s);

without fear of "oh, but that means I am going to box, which is dumb".? 
The int::equals call will unroll to a simple bitwise field comparison, 
and we can now happily write our equals methods uniformly to use 
`.equals()` 99% of the time, and only when identity really matters do we 
fall back to `==`.

Now, this doesn't do anything for "but I want to type this with as few 
characters as possible", but not having to think about either "which 
comparison do I have to use" (most of the time) and the perceived cost 
of boxing (most of the time) is surprisingly freeing.

If in ten years we decide we still want `===` as a shorthand, it becomes 
purely a syntactic decision, separated from all the accidental 
considerations.? Ask me again then!


On 3/12/2024 3:14 PM, Jonathan F wrote:
> I was going to bring up equals() and operator overloading like 
> Stephen, but for a completely different reason, so here goes? Brian?s 
> said in the past that an operator notation for equals() is probably 
> not a priority right now. But I think there?s strong reasons for 
> adding it _at the same time_ as Valhalla, and IMHO there?s also a good 
> notation available:
>
> - With Valhalla developers will gleefully start using == with their 
> new value classes (I know I will). Because (a) they?ll be regarded as 
> ?user-defined primitives?, (b) x.equals(y) is so awkward, let alone 
> !x.equals(y), (c) == may be seen as potentially faster than equals().
>
> - The catch, as we know, is that == _usually_ does what we want for 
> value classes (which is basically equals()), but usually doesn?t when 
> there are identity fields. So each class has to document == somewhere 
> as if it?s a method without a predictable meaning.
>
> Case in point: if Color were a value class, many would assume they can 
> use == for equality, but that wouldn?t work if the RGBA are stored in 
> an array. IMHO the solution has to be to wean developers off == ?and 
> onto a new equals() operator, not to tell them to take more care 
> reading the class?s Javadoc. It?s too risky.
>
> But no operator seems ideal since = isn?t available: I think that?s 
> why we are where we are. However? I?d suggest === and (say) =/= would 
> work well if IDEs are encouraged to _display_ them as the equivalence 
> symbols ? and ? (U+2261/2262), which IntelliJ IDEA already does. 
> They?re attractive and make mathematical sense: see various uses in 
> https://en.wikipedia.org/wiki/Triple_bar . Possibly even allow ? in 
> source code too - Java is the original Unicode-based language, after all?
> If this seems just too novel, it could be pointed out that C?s == 
> never made sense as a math notation and != even less. I see x ? y 
> (typed as x === y) as a clear upgrade from x == y, let alone from 
> x.equals(y). It could also open the door for other Unicode operators 
> in future.
>
> Jonathan
> Jonathan Finn
>
>
> On 11 March 2024 at 22:38:34, Stephen Colebourne 
> (scolebourne at joda.org) wrote:
>
>> Is there a plan for operator overloading in Valhalla? As far as I'm
>> aware there isn't a public plan, and I'm not asking for one in
>> response to this email. Instead I'm asking if a plan is likely in the
>> future and how it fits into Valhalla timescales.
>>
>> I raise this because of the issue with the meaning of == on
>> Float/Double value types. Bitwise comparison is absolutely fine and
>> correct for a JVM-level sameness test. But it is *never* what a
>> developer wants when writing a business application, hence discussion
>> of alternative approaches such as normalization.
>>
>> If == was spelled differently (such as an `Objects.same(a, b)` method)
>> then the recent debate would be irrelevant. But the current proposal
>> is:
>> - the only equals operator is spelled ==
>> - it works 100% correctly for numeric value types including
>> Float/Double except for the NaN edge cases
>> Given these two facts, == *will* be widely used as the equals operator
>> irrespective of the authors' wishes. Just as it is for Enum and Class
>> objects. This will inevitably lead to bug reports where == on two
>> different NaN returns false.
>>
>> As such, I raise the question as to whether there is any kind of plan
>> or priority to provide an operator mapping to Object.equal() for all
>> types in Java, not just value types. If you can say that there is such
>> a plan, then the == on Float/Double issue mostly goes away.
>>
>> Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240312/6962cac0/attachment.htm>

From mchung at openjdk.org  Tue Mar 12 20:15:55 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Mar 2024 20:15:55 GMT
Subject: [lworld] Integrated: 8328019: [lworld] clean up library changes left
 from primitive class support
Message-ID: <31-9VlgpIcqpFiURhlFqB7pA9frIfUha7o_XFRthLiI=.2c9da617-1543-43c3-a1f3-b6d52626061c@github.com>

Clean up method handle change for JEP 401 and revert some leftover changes.

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

Commit messages:
 - 8328019: [lworld] clean up library changes left from primitive class support

Changes: https://git.openjdk.org/valhalla/pull/1045/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1045&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328019
  Stats: 231 lines in 17 files changed: 5 ins; 143 del; 83 mod
  Patch: https://git.openjdk.org/valhalla/pull/1045.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1045/head:pull/1045

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


From mchung at openjdk.org  Tue Mar 12 20:15:55 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 12 Mar 2024 20:15:55 GMT
Subject: [lworld] Integrated: 8328019: [lworld] clean up library changes left
 from primitive class support
In-Reply-To: <31-9VlgpIcqpFiURhlFqB7pA9frIfUha7o_XFRthLiI=.2c9da617-1543-43c3-a1f3-b6d52626061c@github.com>
References: <31-9VlgpIcqpFiURhlFqB7pA9frIfUha7o_XFRthLiI=.2c9da617-1543-43c3-a1f3-b6d52626061c@github.com>
Message-ID: <zqlHsgG_MdgPZ17sqsJn_w7FyGMvkOUNaL7236c6iOU=.115410d9-1a55-41ff-b376-3fd3dd58f82a@github.com>

On Tue, 12 Mar 2024 20:09:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Clean up method handle change for JEP 401 and revert some leftover changes.

This pull request has now been integrated.

Changeset: 93f5fc87
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/93f5fc873d8445724eb4e6b34a98f75e6660a027
Stats:     231 lines in 17 files changed: 5 ins; 143 del; 83 mod

8328019: [lworld] clean up library changes left from primitive class support

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

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


From scolebourne at joda.org  Tue Mar 12 20:20:41 2024
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 12 Mar 2024 20:20:41 +0000
Subject: Is operator overloading in the Valhalla plan?
In-Reply-To: <a9bfd3be-7259-4124-b320-2a7a8169a89f@oracle.com>
References: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
 <a9bfd3be-7259-4124-b320-2a7a8169a89f@oracle.com>
Message-ID: <CACzrW9AmVB7iLNJT_FQ20jhMxgGrrH_n7Ps6b7HAiBTehG+bbQ@mail.gmail.com>

On Tue, 12 Mar 2024, 19:29 Brian Goetz, <brian.goetz at oracle.com> wrote:

> Without diving into operator overloading, I think you have this bit
> backwards:
>
> On 3/11/2024 6:38 PM, Stephen Colebourne wrote:
>
> == *will* be widely used as the equals operator
> irrespective of the authors' wishes. Just as it is for Enum and Class
> objects. This will inevitably lead to bug reports where == on two
> different NaN returns false.
>
>
> But, this is not the case; there is no case where float== says any NaNs
> are equal to any other, even themselves.  Float== treats _all_ NaNs as
> unequal, even the same NaN bit pattern, even the same variable (f == f).
>

Not sure why you think my original mail was discussing primitive type float
==. It wasn't. It was discussing the behaviour of java.lang.Float/Double
once converted to a value type.

The anomaly created by the proposed Object== semantics is that a value type
> with a float field may treat the two as Object==, when the component fields
> are not float==, because float== uses neither bitwise nor representational
> equivalence, regardless of NaN bit patterns.
>

Given the current state of Valhalla, I believe that this code always works
and operates in a sensible way except for java.lang.Float/Double wrt odd
NaNs:

  SomeNumericValueType a = loadA();
  SomeNumericValueType b = loadB();
  if (a == b) {
    // do something when equal
  }

At no point does this example refer to == on primitive float/double (where
the language is forever screwed). The key point is that code like that
above will be widely adopted and considered correct. I do not believe you
will convince developers to use a.equals(b) in numeric scenarios like that
above.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240312/4c2ade20/attachment.htm>

From joe.darcy at oracle.com  Tue Mar 12 22:09:16 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 12 Mar 2024 15:09:16 -0700
Subject: Is operator overloading in the Valhalla plan?
In-Reply-To: <a9bfd3be-7259-4124-b320-2a7a8169a89f@oracle.com>
References: <CACzrW9Az22f-sGbLRdkEON3JccYV2TY74T-VNAVNHRx=43YFHg@mail.gmail.com>
 <a9bfd3be-7259-4124-b320-2a7a8169a89f@oracle.com>
Message-ID: <b798d400-b9ce-4a6a-a645-12511a8cea91@oracle.com>

FYI, for some additional context, a discussion was added to 
java.lang.Double a few release ago on the different kinds of 
equivalence-like relationships that are useful to define over 
floating-point values: numerical equality, bit-wise equivalence, and 
representation equivalence.

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/Double.html#equivalenceRelation

HTH,

-Joe

On 3/12/2024 12:29 PM, Brian Goetz wrote:
> Without diving into operator overloading, I think you have this bit 
> backwards:
>
> On 3/11/2024 6:38 PM, Stephen Colebourne wrote:
>> == *will* be widely used as the equals operator
>> irrespective of the authors' wishes. Just as it is for Enum and Class
>> objects. This will inevitably lead to bug reports where == on two
>> different NaN returns false.
>
> But, this is not the case; there is no case where float== says any 
> NaNs are equal to any other, even themselves.? Float== treats _all_ 
> NaNs as unequal, even the same NaN bit pattern, even the same variable 
> (f == f).
>
> The anomaly created by the proposed Object== semantics is that a value 
> type with a float field may treat the two as Object==, when the 
> component fields are not float==, because float== uses neither bitwise 
> nor representational equivalence, regardless of NaN bit patterns.? But 
> we will see such anomalies whether we pick representational or bitwise 
> comparison for values, because float== is already weird.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240312/b340f0f9/attachment.htm>

From fparain at openjdk.org  Thu Mar 14 13:21:19 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 14 Mar 2024 13:21:19 GMT
Subject: [lworld] RFR: 8328010: [lworld] C1 assertion failure in
 LIRAssembler::patching_epilog
Message-ID: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>

Fixes in C1 instance creation code.
Compiler tests updates.

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

Commit messages:
 - C1 fixes in instance creation and tests arguments update

Changes: https://git.openjdk.org/valhalla/pull/1046/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1046&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328010
  Stats: 375 lines in 57 files changed: 73 ins; 19 del; 283 mod
  Patch: https://git.openjdk.org/valhalla/pull/1046.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1046/head:pull/1046

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


From thartmann at openjdk.org  Thu Mar 14 15:05:02 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 14 Mar 2024 15:05:02 GMT
Subject: [lworld] RFR: 8328010: [lworld] C1 assertion failure in
 LIRAssembler::patching_epilog
In-Reply-To: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>
References: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>
Message-ID: <er1yZUlNtUQ07avYmT8EN6O4-dJGqrrD2Hz0ePcTG7o=.b70a3d7e-39da-416d-b7d8-9bea5cdaf2c0@github.com>

On Thu, 14 Mar 2024 13:05:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fixes in C1 instance creation code.
> Compiler tests updates.

That looks good to me. Thanks for fixing!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1046#pullrequestreview-1936980516


From fparain at openjdk.org  Thu Mar 14 16:25:48 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 14 Mar 2024 16:25:48 GMT
Subject: [lworld] RFR: 8328010: [lworld] C1 assertion failure in
 LIRAssembler::patching_epilog
In-Reply-To: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>
References: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>
Message-ID: <sL9dpirPIMY1Ads6lhgIDe2AlX8LKSMRh9DoNiafVIA=.40774c78-d6f3-4d10-9dcc-336953e6484e@github.com>

On Thu, 14 Mar 2024 13:05:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fixes in C1 instance creation code.
> Compiler tests updates.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1046#issuecomment-1997840045


From fparain at openjdk.org  Thu Mar 14 16:25:48 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 14 Mar 2024 16:25:48 GMT
Subject: [lworld] Integrated: 8328010: [lworld] C1 assertion failure in
 LIRAssembler::patching_epilog
In-Reply-To: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>
References: <5lfk42BikWJVrnptRDCd9-xWqHULqb1UAvZH25IjK2M=.6fc495da-7fd8-4cd8-821f-d5997892a91b@github.com>
Message-ID: <DJ3m6vD7pFANpEX-hCfZ-HWeIks9kEvxiUdogaa2Z7c=.31e7afef-8174-4081-860e-98fa6f8acc96@github.com>

On Thu, 14 Mar 2024 13:05:03 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fixes in C1 instance creation code.
> Compiler tests updates.

This pull request has now been integrated.

Changeset: 292622d0
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/292622d0729af768062bf56a3f3e016438659d87
Stats:     375 lines in 57 files changed: 73 ins; 19 del; 283 mod

8328010: [lworld] C1 assertion failure in LIRAssembler::patching_epilog

Reviewed-by: thartmann

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

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


From fparain at openjdk.org  Fri Mar 15 13:11:50 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 15 Mar 2024 13:11:50 GMT
Subject: [lworld] RFR: 8326860 [lworld] Illegal class modifiers in declaration
 of inner class
Message-ID: <Uxc6vsugLJt9Xi5KqG_xGiumoLg2PETBOH4azxzm1W4=.2253339e-01e6-44c7-a64a-635be01d3108@github.com>

Fix setting of ACC_IDENTITY in old inner classes.
Clean up code fixing ACC_IDENTITY in regular classes.
Remove rejection of value enums.
This should fix all the tests failing with "java.lang.ClassFormatError: Illegal class modifiers in declaration of inner class Status (a value class) of class ..."

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

Commit messages:
 - Fix ACC_IDENTITY in old inner classes and allow value enums.

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

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


From fparain at openjdk.org  Fri Mar 15 15:45:59 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 15 Mar 2024 15:45:59 GMT
Subject: [lworld] Integrated: 8326860 [lworld] Illegal class modifiers in
 declaration of inner class
In-Reply-To: <Uxc6vsugLJt9Xi5KqG_xGiumoLg2PETBOH4azxzm1W4=.2253339e-01e6-44c7-a64a-635be01d3108@github.com>
References: <Uxc6vsugLJt9Xi5KqG_xGiumoLg2PETBOH4azxzm1W4=.2253339e-01e6-44c7-a64a-635be01d3108@github.com>
Message-ID: <KpOHrC5YnDLhdSyT7t1_1n48Yf_WmML8DrePMbnsfHc=.52a66a9e-d2ee-40eb-955e-6da098dcf7fc@github.com>

On Fri, 15 Mar 2024 13:05:52 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix setting of ACC_IDENTITY in old inner classes.
> Clean up code fixing ACC_IDENTITY in regular classes.
> Remove rejection of value enums.
> This should fix all the tests failing with "java.lang.ClassFormatError: Illegal class modifiers in declaration of inner class Status (a value class) of class ..."

This pull request has now been integrated.

Changeset: 7113a96a
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7113a96a1f6758d96628917818a07ffc65360bf9
Stats:     22 lines in 1 file changed: 6 ins; 11 del; 5 mod

8326860: [lworld] Illegal class modifiers in declaration of inner class

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

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


From vromero at openjdk.org  Fri Mar 15 15:47:49 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 15 Mar 2024 15:47:49 GMT
Subject: [lworld] RFR: 8327695: [lworld] javac can generate incorrect code in
 inner class' constructors
Message-ID: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>

When dealing with value classes javac, as mandated by the spec, is placing field initializers before any invocation to `super()`. This works just fine most of the time but for cases like:

class JavacBug {
    value class V1 {}

    value class V2 {
        V1 v = new V1();
    }

    void test() {
        V2 v2 = new V2();
    }

    public static void main(String... args) {
        JavacBug jb = new JavacBug();
        jb.test();
    }
}

javac is generating incorrect code for class V2 due to a getfield being generated to read the synthetic field storing the outer this before invoking the constructor for V1. The proposed change is changing the generated bytecode to read the outer this from the mandated parameter javac adds to inner class constructors,

TIA

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

Commit messages:
 - 8327695: [lworld] javac can generate incorrect code in inner class' constructors

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

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


From liach at openjdk.org  Sat Mar 16 22:32:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Mar 2024 22:32:05 GMT
Subject: [lworld] RFR: 8327695: [lworld] javac can generate incorrect code
 in inner class' constructors
In-Reply-To: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
References: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
Message-ID: <X9mBenNEBYjxlukMVbLrD9wl47j_Xtv0WsIWlgNheCo=.1259305a-28b9-4bfb-985a-1d2da591b3af@github.com>

On Fri, 15 Mar 2024 15:40:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> When dealing with value classes javac, as mandated by the spec, is placing field initializers before any invocation to `super()`. This works just fine most of the time but for cases like:
> 
> class JavacBug {
>     value class V1 {}
> 
>     value class V2 {
>         V1 v = new V1();
>     }
> 
>     void test() {
>         V2 v2 = new V2();
>     }
> 
>     public static void main(String... args) {
>         JavacBug jb = new JavacBug();
>         jb.test();
>     }
> }
> 
> javac is generating incorrect code for class V2 due to a getfield being generated to read the synthetic field storing the outer this before invoking the constructor for V1. The proposed change is changing the generated bytecode to read the outer this from the mandated parameter javac adds to inner class constructors,
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2973:

> 2971:                         outerThisSet = Set.of(thisArg);
> 2972:                     } else {
> 2973:                         outerThisSet.add(thisArg);

Is this `java.util.Set`? If yes then `add` probably doesn't work on immutable sets.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1048#discussion_r1526605260


From vromero at openjdk.org  Sat Mar 16 22:32:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 16 Mar 2024 22:32:05 GMT
Subject: [lworld] RFR: 8327695: [lworld] javac can generate incorrect code
 in inner class' constructors
In-Reply-To: <X9mBenNEBYjxlukMVbLrD9wl47j_Xtv0WsIWlgNheCo=.1259305a-28b9-4bfb-985a-1d2da591b3af@github.com>
References: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
 <X9mBenNEBYjxlukMVbLrD9wl47j_Xtv0WsIWlgNheCo=.1259305a-28b9-4bfb-985a-1d2da591b3af@github.com>
Message-ID: <7cSVBCroAwmSkFJiDq-2jtmtdeB2yHu2BqX0ZcQ9dhs=.2f5dc177-6aa3-4f67-9d19-cebc8cc356ce@github.com>

On Fri, 15 Mar 2024 17:20:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When dealing with value classes javac, as mandated by the spec, is placing field initializers before any invocation to `super()`. This works just fine most of the time but for cases like:
>> 
>> class JavacBug {
>>     value class V1 {}
>> 
>>     value class V2 {
>>         V1 v = new V1();
>>     }
>> 
>>     void test() {
>>         V2 v2 = new V2();
>>     }
>> 
>>     public static void main(String... args) {
>>         JavacBug jb = new JavacBug();
>>         jb.test();
>>     }
>> }
>> 
>> javac is generating incorrect code for class V2 due to a getfield being generated to read the synthetic field storing the outer this before invoking the constructor for V1. The proposed change is changing the generated bytecode to read the outer this from the mandated parameter javac adds to inner class constructors,
>> 
>> TIA
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2973:
> 
>> 2971:                         outerThisSet = Set.of(thisArg);
>> 2972:                     } else {
>> 2973:                         outerThisSet.add(thisArg);
> 
> Is this `java.util.Set`? If yes then `add` probably doesn't work on immutable sets.

got it, good catch, will fix thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1048#discussion_r1526622687


From fparain at openjdk.org  Sat Mar 16 22:32:25 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Sat, 16 Mar 2024 22:32:25 GMT
Subject: [lworld] Integrated: 8327637: [lworld]
 runtime/valhalla/inlinetypes/PreloadCircularityTest.java fails with
 --enable-preview
Message-ID: <ydQ0E2-Ayy1sJySWBxnCVWGKk-B2MUwZpQEntcYIPUo=.d71f83ae-2ddd-4e30-b3e7-4f4ed36c14e2@github.com>

Fix test_50 by making output analysis more precise.

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

Commit messages:
 - Fix test_50 by making output analysis more precise

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

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


From fparain at openjdk.org  Sat Mar 16 22:32:30 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Sat, 16 Mar 2024 22:32:30 GMT
Subject: [lworld] Integrated: 8327637: [lworld]
 runtime/valhalla/inlinetypes/PreloadCircularityTest.java fails with
 --enable-preview
In-Reply-To: <ydQ0E2-Ayy1sJySWBxnCVWGKk-B2MUwZpQEntcYIPUo=.d71f83ae-2ddd-4e30-b3e7-4f4ed36c14e2@github.com>
References: <ydQ0E2-Ayy1sJySWBxnCVWGKk-B2MUwZpQEntcYIPUo=.d71f83ae-2ddd-4e30-b3e7-4f4ed36c14e2@github.com>
Message-ID: <EcWiGQn9lk3EliBbY8yrqgX2kPz2C0_NwUBg4D2fHDc=.7274af84-ff79-48f0-be13-092fafc328a8@github.com>

On Fri, 15 Mar 2024 18:04:33 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix test_50 by making output analysis more precise.

This pull request has now been integrated.

Changeset: 9b79f47a
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9b79f47af28ca02f380fd32786a8d3d75d7a1937
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8327637: [lworld] runtime/valhalla/inlinetypes/PreloadCircularityTest.java fails with --enable-preview

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

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


From jbhateja at openjdk.org  Mon Mar 18 07:56:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 18 Mar 2024 07:56:51 GMT
Subject: [lworld] RFR: 8328329: [lworld] Optimize field type checking sequence
 for x86 target.
Message-ID: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>

- For field access bytecodes (getfield / putfield) interpreter perform special handling for flat / null restricted fields.
- Patch replaces existing flag checking sequence with efficient sequence based on 'bt' instruction.

Kindly review and approve.

Best Regards,
Jatin

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

Commit messages:
 - 8328329: [lworld] Optimize field type checking sequence for x86 target.

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

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


From qamai at openjdk.org  Mon Mar 18 09:48:01 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 18 Mar 2024 09:48:01 GMT
Subject: [lworld] RFR: 8328329: [lworld] Optimize field type checking
 sequence for x86 target.
In-Reply-To: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>
References: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>
Message-ID: <udbZ-2KjZUtWgBnUPqeGbafewfC7JQUYw0ciJtCjKOE=.01e111fb-1595-49b7-b748-f59f21aa87a3@github.com>

On Mon, 18 Mar 2024 07:52:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - For field access bytecodes (getfield / putfield) interpreter perform special handling for flat / null restricted fields.
> - Patch replaces existing flag checking sequence with efficient sequence based on 'bt' instruction.
> 
> Kindly review and approve.
> 
> Best Regards,
> Jatin

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 3006:

> 3004:   movl(temp_reg, flags);
> 3005:   btl(temp_reg, ResolvedFieldEntry::is_null_free_inline_type_shift);
> 3006:   jcc(Assembler::carrySet, is_null_free_inline_type);

You also do not need `temp_reg`. Also, I think `testl(flags, 1 << ResolvedFieldEntry::is_null_free_inline_type_shift)` would be better than `btl` since `test` can macro-fuse with `jcc`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1051#discussion_r1528213114


From vromero at openjdk.org  Mon Mar 18 14:22:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Mar 2024 14:22:57 GMT
Subject: [lworld] RFR: 8327695: [lworld] javac can generate incorrect code
 in inner class' constructors [v2]
In-Reply-To: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
References: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
Message-ID: <lfX7xzi2INOes9DE7LwHM7MpKejlOS9DGzbiuAg4sgE=.c2855659-1fd3-4c02-bd5c-e826602c2a9d@github.com>

> When dealing with value classes javac, as mandated by the spec, is placing field initializers before any invocation to `super()`. This works just fine most of the time but for cases like:
> 
> class JavacBug {
>     value class V1 {}
> 
>     value class V2 {
>         V1 v = new V1();
>     }
> 
>     void test() {
>         V2 v2 = new V2();
>     }
> 
>     public static void main(String... args) {
>         JavacBug jb = new JavacBug();
>         jb.test();
>     }
> }
> 
> javac is generating incorrect code for class V2 due to a getfield being generated to read the synthetic field storing the outer this before invoking the constructor for V1. The proposed change is changing the generated bytecode to read the outer this from the mandated parameter javac adds to inner class constructors,
> 
> TIA

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1048/files
  - new: https://git.openjdk.org/valhalla/pull/1048/files/d582b997..7ae7829b

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

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

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


From vromero at openjdk.org  Mon Mar 18 14:22:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 18 Mar 2024 14:22:58 GMT
Subject: [lworld] Integrated: 8327695: [lworld] javac can generate incorrect
 code in inner class' constructors
In-Reply-To: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
References: <EUeL9XWGrr2zSm9x42fPVCzzWLfm1p8oOiLqcxfQxJ4=.8139b342-ccd1-43cc-ada3-70a3a8d7952c@github.com>
Message-ID: <i9gko0LvYfhcC8Hvfc7ODnxHfEZdHfvDhroA9I9wz3g=.e716c1b3-9979-4cd8-9178-b4762fb82944@github.com>

On Fri, 15 Mar 2024 15:40:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> When dealing with value classes javac, as mandated by the spec, is placing field initializers before any invocation to `super()`. This works just fine most of the time but for cases like:
> 
> class JavacBug {
>     value class V1 {}
> 
>     value class V2 {
>         V1 v = new V1();
>     }
> 
>     void test() {
>         V2 v2 = new V2();
>     }
> 
>     public static void main(String... args) {
>         JavacBug jb = new JavacBug();
>         jb.test();
>     }
> }
> 
> javac is generating incorrect code for class V2 due to a getfield being generated to read the synthetic field storing the outer this before invoking the constructor for V1. The proposed change is changing the generated bytecode to read the outer this from the mandated parameter javac adds to inner class constructors,
> 
> TIA

This pull request has now been integrated.

Changeset: 5a130975
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5a13097581a05a9440b4c8e54d52c259057ff47e
Stats:     51 lines in 3 files changed: 51 ins; 0 del; 0 mod

8327695: [lworld] javac can generate incorrect code in inner class' constructors

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

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


From dlsmith at openjdk.org  Mon Mar 18 23:50:27 2024
From: dlsmith at openjdk.org (Dan Smith)
Date: Mon, 18 Mar 2024 23:50:27 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutiable
 comparison of float/double should use raw bits
In-Reply-To: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
References: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
Message-ID: <odkqd5UGnpXCH02eeCcFFFtjyqz6BsWK2tEwRruuaak=.d135684a-c9cc-455c-a928-7cfd1679e664@github.com>

On Thu, 7 Mar 2024 21:56:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.

I'm not the one you want carefully checking the code, but conceptually it looks right to me

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

Marked as reviewed by dlsmith (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1039#pullrequestreview-1944531495


From mchung at openjdk.org  Tue Mar 19 00:08:31 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Mar 2024 00:08:31 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutiable
 comparison of float/double should use raw bits
In-Reply-To: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
References: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
Message-ID: <Y4H4vkDOD2y-WRjPILmXbfXM90aY8EBmmICiaRKZV1o=.5a68324b-db65-4f71-a8e7-7a76cfe35a9a@github.com>

On Thu, 7 Mar 2024 21:56:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.

src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 107:

> 105:                 throw new RuntimeException(e);
> 106:             }
> 107:         }

Suggestion:

        static {
            primitiveSubstitutable.putAll(primitiveEquals); // adopt all the primitive eq methods
            primitiveSubstitutable.put(float.class,
                    findStatic("eqValue", methodType(boolean.class, float.class, float.class)));
            primitiveSubstitutable.put(double.class,
                    findStatic("eqValue", methodType(boolean.class, double.class, double.class)));
        }


Suggest to use existing helper methods and use `MethodType::methodType` for simplicty (avoid `doPrivileged` and loader).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1039#discussion_r1518246901


From jbhateja at openjdk.org  Tue Mar 19 05:34:58 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Mar 2024 05:34:58 GMT
Subject: [lworld] RFR: 8328329: [lworld] Optimize field type checking
 sequence for x86 target. [v2]
In-Reply-To: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>
References: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>
Message-ID: <gOGLpIuLV3j0zToVPctqC1lK2HALdQfvdVA_B6GgF5s=.efebe088-8665-4487-98ef-a1bf0771d7c5@github.com>

> - For field access bytecodes (getfield / putfield) interpreter perform special handling for flat / null restricted fields.
> - Patch replaces existing flag checking sequence with efficient sequence based on 'bt' instruction.
> 
> Kindly review and approve.
> 
> Best Regards,
> Jatin

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

  Refining for macrofusion.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1051/files
  - new: https://git.openjdk.org/valhalla/pull/1051/files/dcb3adf1..fd127e1f

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

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

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


From jbhateja at openjdk.org  Tue Mar 19 05:34:58 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Mar 2024 05:34:58 GMT
Subject: [lworld] Integrated: 8328329: [lworld] Optimize field type checking
 sequence for x86 target.
In-Reply-To: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>
References: <zqeoq789sCHibRutkS9ZgncTMnB3r_eIGa5-PegJO8Q=.23378470-dfb7-4e12-ae3c-b48d6bb38634@github.com>
Message-ID: <SE2_4uaKPJ0ZqnW7cjMRWZbsoUSbcWP-WJEPUmr3oX4=.43358b76-327a-48f2-aa91-cf0138ca1689@github.com>

On Mon, 18 Mar 2024 07:52:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - For field access bytecodes (getfield / putfield) interpreter perform special handling for flat / null restricted fields.
> - Patch replaces existing flag checking sequence with efficient sequence based on 'bt' instruction.
> 
> Kindly review and approve.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: 04c6e039
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/04c6e0395756389707dafb375968bed7a41fb77d
Stats:     13 lines in 2 files changed: 0 ins; 7 del; 6 mod

8328329: [lworld] Optimize field type checking sequence for x86 target.

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

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


From dsimms at openjdk.org  Tue Mar 19 10:27:48 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 19 Mar 2024 10:27:48 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses
Message-ID: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>

* Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
* Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
* Trival fixes to simply remove primitive class tests cases
* `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

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

Commit messages:
 - Misc cleanup
 - JDK tests
 - Lang/IO tests
 - Serviceability tests
 - Runtime tests
 - Merge branch 'lworld' into 8328150
 - Merge branch 'lworld' into 8328150
 - CDS tests
 - Compiler tests

Changes: https://git.openjdk.org/valhalla/pull/1052/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1052&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328150
  Stats: 4216 lines in 117 files changed: 44 ins; 3965 del; 207 mod
  Patch: https://git.openjdk.org/valhalla/pull/1052.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1052/head:pull/1052

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


From rriggs at openjdk.org  Tue Mar 19 14:13:48 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Mar 2024 14:13:48 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutiable
 comparison of float/double should use raw bits [v2]
In-Reply-To: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
References: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
Message-ID: <6ZR5alSdjViHeu5UnrjA6hIvc-MUC-yXCMi1dycO3ug=.82b4144d-1c99-47ce-8263-8db50dd90e1a@github.com>

> Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.

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

  Update src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java
  
  Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1039/files
  - new: https://git.openjdk.org/valhalla/pull/1039/files/116ad483..f4a3d82c

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

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

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


From fparain at openjdk.org  Tue Mar 19 14:57:30 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 19 Mar 2024 14:57:30 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses
In-Reply-To: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
Message-ID: <Jm8sllsoDeiffUZrKOAqqA_LliuiOxD7qwSHb5ias10=.6fdcbb22-70ab-4b1b-aa59-ccfb51d1790b@github.com>

On Tue, 19 Mar 2024 10:23:23 GMT, David Simms <dsimms at openjdk.org> wrote:

> * Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
> * Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
> * Trival fixes to simply remove primitive class tests cases
> * `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

Thank you for this huge cleanup.
Would it make sense to also clean the modules export options?
Many tests use "--add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports java.base/jdk.internal.value=ALL-UNNAMED" and those options have to be copied on build, compile, and run commands.
We could let JTREG add those options itself by just adding this to the JTREG tags:

 * @modules java.base/jdk.internal.vm.annotation
 *          java.base/jdk.internal.classfile
 ```

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

PR Comment: https://git.openjdk.org/valhalla/pull/1052#issuecomment-2007393930


From dsimms at openjdk.org  Tue Mar 19 15:21:36 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 19 Mar 2024 15:21:36 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses
In-Reply-To: <Jm8sllsoDeiffUZrKOAqqA_LliuiOxD7qwSHb5ias10=.6fdcbb22-70ab-4b1b-aa59-ccfb51d1790b@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
 <Jm8sllsoDeiffUZrKOAqqA_LliuiOxD7qwSHb5ias10=.6fdcbb22-70ab-4b1b-aa59-ccfb51d1790b@github.com>
Message-ID: <k5IF9lisqk2nzdeSE6imodgPxhXDTvwfdVI_B0Hy2G4=.30f80168-005c-41c7-95b5-6857118adb39@github.com>

On Tue, 19 Mar 2024 14:52:53 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Thank you for this huge cleanup. Would it make sense to also clean the modules export options? Many tests use "--add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED --add-exports java.base/jdk.internal.value=ALL-UNNAMED" and those options have to be copied on build, compile, and run commands. We could let JTREG add those options itself by just adding this to the JTREG tags:
> 
> ```
>  * @modules java.base/jdk.internal.vm.annotation
>  *          java.base/jdk.internal.classfile
> ```

Totally, good call, let me make another pass

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

PR Comment: https://git.openjdk.org/valhalla/pull/1052#issuecomment-2007472390


From fparain at openjdk.org  Tue Mar 19 15:56:36 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 19 Mar 2024 15:56:36 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses
In-Reply-To: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
Message-ID: <Q59kLSA4TPfdnhyIcg6Y3YagQMfxgPhy9aYNoc5PAXE=.d4165f62-58a5-43f1-8fb7-d1558574ebfc@github.com>

On Tue, 19 Mar 2024 10:23:23 GMT, David Simms <dsimms at openjdk.org> wrote:

> * Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
> * Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
> * Trival fixes to simply remove primitive class tests cases
> * `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

I typed the wrong tags, the correct ones are:

 * @modules java.base/jdk.internal.vm.annotation
 *          java.base/jdk.internal.value

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

PR Comment: https://git.openjdk.org/valhalla/pull/1052#issuecomment-2007556085


From mchung at openjdk.org  Tue Mar 19 15:58:29 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 19 Mar 2024 15:58:29 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutiable
 comparison of float/double should use raw bits [v2]
In-Reply-To: <6ZR5alSdjViHeu5UnrjA6hIvc-MUC-yXCMi1dycO3ug=.82b4144d-1c99-47ce-8263-8db50dd90e1a@github.com>
References: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
 <6ZR5alSdjViHeu5UnrjA6hIvc-MUC-yXCMi1dycO3ug=.82b4144d-1c99-47ce-8263-8db50dd90e1a@github.com>
Message-ID: <-GP_2KdIcEshPhQpZBztUpLl2aAk_QV7spJCt1f_s9Y=.d5fc3de7-971e-4b47-80f7-349548ef3f86@github.com>

On Tue, 19 Mar 2024 14:13:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

Marked as reviewed by mchung (Committer).

src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java line 34:

> 32: import java.lang.reflect.Modifier;
> 33: import java.security.AccessController;
> 34: import java.security.PrivilegedAction;

These imports are unused now.

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

PR Review: https://git.openjdk.org/valhalla/pull/1039#pullrequestreview-1946697183
PR Review Comment: https://git.openjdk.org/valhalla/pull/1039#discussion_r1530664363


From thartmann at openjdk.org  Wed Mar 20 10:37:59 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 20 Mar 2024 10:37:59 GMT
Subject: [lworld] RFR: 8325660: [lworld] Update C2 to support new value
 construction scheme from JEP 401
Message-ID: <EHBBAMAo_XU0d82nWfUZIfSOo3Togt48QVOTVuC_k0M=.3874bb0b-fc91-479e-8b29-c585386a2da6@github.com>

This is a first change to update C2 to support the new value construction scheme from JEP 401. All hotspot/compiler/valhalla tests now pass but there are many known issues and disabled optimizations. Follow-up work will be done with [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106) and is marked with `TODO 8325106` in the code.

For runtime and C1 changes, see [JDK-8326595](https://bugs.openjdk.org/browse/JDK-8326595).

Thanks,
Tobias

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

Commit messages:
 - Removed Integer usages from some tests
 - Fixed TestArrays.java
 - Even more fixes
 - Missing stopped checks
 - More Todos
 - Another TODO
 - Uncommented debug code
 - Workaround for arraycopy intrinsic
 - Removed some dead code in C1
 - Fix for 8328470 and new test
 - ... and 14 more: https://git.openjdk.org/valhalla/compare/292622d0...ce1b1511

Changes: https://git.openjdk.org/valhalla/pull/1049/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1049&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325660
  Stats: 2215 lines in 77 files changed: 609 ins; 436 del; 1170 mod
  Patch: https://git.openjdk.org/valhalla/pull/1049.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1049/head:pull/1049

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


From thartmann at openjdk.org  Wed Mar 20 11:45:35 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 20 Mar 2024 11:45:35 GMT
Subject: [lworld] Integrated: 8325660: [lworld] Update C2 to support new value
 construction scheme from JEP 401
In-Reply-To: <EHBBAMAo_XU0d82nWfUZIfSOo3Togt48QVOTVuC_k0M=.3874bb0b-fc91-479e-8b29-c585386a2da6@github.com>
References: <EHBBAMAo_XU0d82nWfUZIfSOo3Togt48QVOTVuC_k0M=.3874bb0b-fc91-479e-8b29-c585386a2da6@github.com>
Message-ID: <JmMLVeL1iMhrgt1CaU-yD6o7LC9Q9FtY_YprwNp-uDY=.57798212-2a9e-426c-9987-89b249c56646@github.com>

On Fri, 15 Mar 2024 16:01:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This is a first change to update C2 to support the new value construction scheme from JEP 401. All hotspot/compiler/valhalla tests now pass but there are many known issues and disabled optimizations. Follow-up work will be done with [JDK-8325106](https://bugs.openjdk.org/browse/JDK-8325106) and is marked with `TODO 8325106` in the code.
> 
> For runtime and C1 changes, see [JDK-8326595](https://bugs.openjdk.org/browse/JDK-8326595).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: c8731166
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c87311663f926fe63238822234903574cef47211
Stats:     2215 lines in 77 files changed: 609 ins; 436 del; 1170 mod

8325660: [lworld] Update C2 to support new value construction scheme from JEP 401

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

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


From rriggs at openjdk.org  Wed Mar 20 13:29:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Mar 2024 13:29:56 GMT
Subject: [lworld] RFR: 8298659: [lworld] ValueObject isSubstutiable
 comparison of float/double should use raw bits [v3]
In-Reply-To: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
References: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
Message-ID: <gtmzy9YXrA-as-yqChrf4jC6DKMo2ZsAqw8lcZI4uFA=.69a658db-64f7-43e2-ac6f-bf9a3e47b1a0@github.com>

> Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.

Roger Riggs 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 six additional commits since the last revision:

 - Remove unused imports
 - Merge branch 'lworld' into 8298659-substitutable-raw-float-bits
 - Merge branch '8298659-substitutable-raw-float-bits' of https://github.com/RogerRiggs/valhalla into 8298659-substitutable-raw-float-bits
 - Update src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Merge branch 'valhalla-extra-open' into 8298659-substitutable-raw-float-bits
 - 8298659: [lworld] ValueObject isSubstutitable comparison of float/double should use raw bits
   
   Create a separate cache of method pointers for substitutablity test for primitives in ValueObjectMethods.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1039/files
  - new: https://git.openjdk.org/valhalla/pull/1039/files/f4a3d82c..00e74f5d

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

  Stats: 1158 lines in 158 files changed: 362 ins; 312 del; 484 mod
  Patch: https://git.openjdk.org/valhalla/pull/1039.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1039/head:pull/1039

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


From fparain at openjdk.org  Wed Mar 20 17:44:47 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 20 Mar 2024 17:44:47 GMT
Subject: [lworld] Integrated: 8328636: [lworld]
 runtime/clinit/ClassInitBarrier.java fails because of a compilation error
Message-ID: <Enn3o650FRKykZRL894IPnQSVcibfJN5VMDA_1B6mug=.a84c2f85-f074-4293-a6af-18266ba363ec@github.com>

Simple fix enabling preview mode for the whole test and removing the -XX:EnableValhalla flag.

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

Commit messages:
 - Fix enable preview flag

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

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


From fparain at openjdk.org  Wed Mar 20 17:44:47 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 20 Mar 2024 17:44:47 GMT
Subject: [lworld] Integrated: 8328636: [lworld]
 runtime/clinit/ClassInitBarrier.java fails because of a compilation error
In-Reply-To: <Enn3o650FRKykZRL894IPnQSVcibfJN5VMDA_1B6mug=.a84c2f85-f074-4293-a6af-18266ba363ec@github.com>
References: <Enn3o650FRKykZRL894IPnQSVcibfJN5VMDA_1B6mug=.a84c2f85-f074-4293-a6af-18266ba363ec@github.com>
Message-ID: <2fFnV7n4rGimuB1CN5G7_rU6eY3GrIuzIy7tBS2xFr4=.5fb46d9f-cccf-4174-a761-bd923ffb78a1@github.com>

On Wed, 20 Mar 2024 17:39:26 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Simple fix enabling preview mode for the whole test and removing the -XX:EnableValhalla flag.

This pull request has now been integrated.

Changeset: 28e21294
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/28e21294b3e7279c099a74267a3f51388f3125ac
Stats:     15 lines in 1 file changed: 1 ins; 0 del; 14 mod

8328636: [lworld] runtime/clinit/ClassInitBarrier.java fails because of a compilation error

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

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


From dsimms at openjdk.org  Thu Mar 21 10:34:44 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 21 Mar 2024 10:34:44 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses [v2]
In-Reply-To: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
Message-ID: <NnItMDQLB7cQpJT9xEZLpmeWg59HdUTo9EEUVKFVB50=.6068ee0d-72a8-464d-9f8b-c1be01720b39@github.com>

> * Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
> * Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
> * Trival fixes to simply remove primitive class tests cases
> * `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

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

 - Use jtreg modules tag
 - Merge branch 'lworld' into 8328150
 - Misc cleanup
 - JDK tests
 - Lang/IO tests
 - Serviceability tests
 - Runtime tests
 - Merge branch 'lworld' into 8328150
 - Merge branch 'lworld' into 8328150
 - CDS tests
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/28e21294...bda5e97d

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

Changes: https://git.openjdk.org/valhalla/pull/1052/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1052&range=01
  Stats: 4383 lines in 117 files changed: 55 ins; 4073 del; 255 mod
  Patch: https://git.openjdk.org/valhalla/pull/1052.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1052/head:pull/1052

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


From dsimms at openjdk.org  Thu Mar 21 10:57:03 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 21 Mar 2024 10:57:03 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses [v3]
In-Reply-To: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
Message-ID: <-orBIWelWVTExMnuS_t1ZtRyLHNGagsMH1DYU-NacdQ=.feb9d556-44ae-474f-aea8-226a432ec52a@github.com>

> * Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
> * Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
> * Trival fixes to simply remove primitive class tests cases
> * `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

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

  Adjust copyright year

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1052/files
  - new: https://git.openjdk.org/valhalla/pull/1052/files/bda5e97d..616bc2a6

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

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

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


From thartmann at openjdk.org  Thu Mar 21 12:36:03 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 21 Mar 2024 12:36:03 GMT
Subject: [lworld] RFR: 8328682: [lworld] Missing barrier after value object
 construction
Message-ID: <45kwS-Xe9Pgpc12E6EvpNKUT-HFq_j8iKranv2xyHKc=.9684fa74-9742-400e-ba4d-cb4a5bd6cb58@github.com>

Added a missing barrier after value object construction and fixed some unrelated tests.

Thanks,
Tobias

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

Commit messages:
 - 8328682: [lworld] Missing barrier after value object construction

Changes: https://git.openjdk.org/valhalla/pull/1054/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328682
  Stats: 156 lines in 16 files changed: 76 ins; 5 del; 75 mod
  Patch: https://git.openjdk.org/valhalla/pull/1054.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1054/head:pull/1054

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


From thartmann at openjdk.org  Thu Mar 21 13:19:29 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 21 Mar 2024 13:19:29 GMT
Subject: [lworld] Integrated: 8328682: [lworld] Missing barrier after value
 object construction
In-Reply-To: <45kwS-Xe9Pgpc12E6EvpNKUT-HFq_j8iKranv2xyHKc=.9684fa74-9742-400e-ba4d-cb4a5bd6cb58@github.com>
References: <45kwS-Xe9Pgpc12E6EvpNKUT-HFq_j8iKranv2xyHKc=.9684fa74-9742-400e-ba4d-cb4a5bd6cb58@github.com>
Message-ID: <bWVIT6N6WZ5LHI3ngzH2kMvx67-qgIBzA3NokojorFk=.b1a1f691-ff47-4db7-9063-66fc197a0568@github.com>

On Thu, 21 Mar 2024 12:30:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Added a missing barrier after value object construction and fixed some unrelated tests.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 50fcd434
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/50fcd434d0fde1b67f6072ba390fec0e64ed6fa1
Stats:     156 lines in 16 files changed: 76 ins; 5 del; 75 mod

8328682: [lworld] Missing barrier after value object construction

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

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


From thartmann at openjdk.org  Thu Mar 21 13:27:36 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 21 Mar 2024 13:27:36 GMT
Subject: [lworld] RFR: 8328699: [lworld] C2 compilation fails with
 "no reachable node should have no use"
Message-ID: <Uu37kT_K7wvgwcbf0zn9Qk_feE1xPsskuKRWspcdU8M=.5b8921c9-29ad-4781-8194-d4874fd0c723@github.com>

`InlineTypeNode::set_*` methods should use `set_req_X` instead of `set_req` to make sure that an input node becoming dead is processed by IGVN.

Thanks,
Tobias

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

Commit messages:
 - 8328699: [lworld] C2 compilation fails with "no reachable node should have no use"

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

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


From rriggs at openjdk.org  Thu Mar 21 13:42:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Mar 2024 13:42:40 GMT
Subject: [lworld] Integrated: 8298659: [lworld] ValueObject isSubstutiable
 comparison of float/double should use raw bits
In-Reply-To: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
References: <m1MkRmwtuIzL2IzyLgbsVdA7RvkFTcuqEofGb_EaQb4=.aa9655f2-9654-4ee3-b127-6aef172fb245@github.com>
Message-ID: <TPffw3eRjbSzQI-jjnSH4kBfqBFN2mdspKpQ1vbkStA=.ccef05eb-d7c6-451c-b0de-af5424d174ba@github.com>

On Thu, 7 Mar 2024 21:56:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Correct substitutability comparison of float and double using the raw-bits as indicated in JEP 401.

This pull request has now been integrated.

Changeset: 5298ef07
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5298ef0798c6a2032fe49a586bc9d01c1a161189
Stats:     67 lines in 2 files changed: 52 ins; 4 del; 11 mod

8298659: [lworld] ValueObject isSubstutiable comparison of float/double should use raw bits

Reviewed-by: dlsmith, mchung

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

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


From dsimms at openjdk.org  Thu Mar 21 13:49:49 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 21 Mar 2024 13:49:49 GMT
Subject: [lworld] RFR: 8328150: [lworld] Adjust flags to "--enable-preview"
 clear out EnableValhalla and EnablePrimitiveClasses [v4]
In-Reply-To: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
Message-ID: <6RJdScpCj4oPbTn7g8daP7hc7Dger0Cdq40o0S6UdE4=.b86b9b13-97d1-43d1-b02a-691f18d19603@github.com>

> * Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
> * Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
> * Trival fixes to simply remove primitive class tests cases
> * `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

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

 - Merge branch 'lworld' into 8328150
 - Adjust copyright year
 - Use jtreg modules tag
 - Merge branch 'lworld' into 8328150
 - Misc cleanup
 - JDK tests
 - Lang/IO tests
 - Serviceability tests
 - Runtime tests
 - Merge branch 'lworld' into 8328150
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/50fcd434...cf5287ed

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

Changes: https://git.openjdk.org/valhalla/pull/1052/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1052&range=03
  Stats: 4413 lines in 171 files changed: 48 ins; 4056 del; 309 mod
  Patch: https://git.openjdk.org/valhalla/pull/1052.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1052/head:pull/1052

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


From thartmann at openjdk.org  Thu Mar 21 14:13:53 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 21 Mar 2024 14:13:53 GMT
Subject: [lworld] RFR: 8328699: [lworld] C2 compilation fails with
 "no reachable node should have no use" [v2]
In-Reply-To: <Uu37kT_K7wvgwcbf0zn9Qk_feE1xPsskuKRWspcdU8M=.5b8921c9-29ad-4781-8194-d4874fd0c723@github.com>
References: <Uu37kT_K7wvgwcbf0zn9Qk_feE1xPsskuKRWspcdU8M=.5b8921c9-29ad-4781-8194-d4874fd0c723@github.com>
Message-ID: <Scjfo5YCWAx0w8kiXyu217-p4v1aDvN0Nkwc_d0QNsk=.38ae9dc0-d7d3-4e04-9c93-d1611ec1d593@github.com>

> `InlineTypeNode::set_*` methods should use `set_req_X` instead of `set_req` to make sure that an input node becoming dead is processed by IGVN.
> 
> Edit: I just noticed that the barrier part of JDK-8328682 causes some issues so I'm using this change to quickly back it out. Will REDO with JDK-8328704.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with two additional commits since the last revision:

 - Added TODO
 - Backout of 8328682 which causes issues

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1055/files
  - new: https://git.openjdk.org/valhalla/pull/1055/files/1d2e15db..fcc21adb

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

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

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


From thartmann at openjdk.org  Thu Mar 21 14:35:30 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 21 Mar 2024 14:35:30 GMT
Subject: [lworld] Integrated: 8328699: [lworld] C2 compilation fails with
 "no reachable node should have no use"
In-Reply-To: <Uu37kT_K7wvgwcbf0zn9Qk_feE1xPsskuKRWspcdU8M=.5b8921c9-29ad-4781-8194-d4874fd0c723@github.com>
References: <Uu37kT_K7wvgwcbf0zn9Qk_feE1xPsskuKRWspcdU8M=.5b8921c9-29ad-4781-8194-d4874fd0c723@github.com>
Message-ID: <mBuKNSGzILwz_MOLNOb4wZhIbUtii1YI1wRRGLbpSGQ=.5a07305f-90fd-4db7-8e7a-e8fa3f9620ee@github.com>

On Thu, 21 Mar 2024 13:23:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `InlineTypeNode::set_*` methods should use `set_req_X` instead of `set_req` to make sure that an input node becoming dead is processed by IGVN.
> 
> Edit: I just noticed that the barrier part of JDK-8328682 causes some issues so I'm using this change to quickly back it out. Will REDO with JDK-8328704.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: fe2beb5b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fe2beb5b254a56270cb6f06bf5104819055e26c1
Stats:     21 lines in 8 files changed: 4 ins; 0 del; 17 mod

8328699: [lworld] C2 compilation fails with "no reachable node should have no use"

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

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


From fparain at openjdk.org  Thu Mar 21 15:54:40 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 21 Mar 2024 15:54:40 GMT
Subject: [lworld] Integrated: 8328641: [lworld]
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 with java.lang.IncompatibleClassChangeError: value class AME5_B cannot inherit
 from class AME5_A
Message-ID: <wKXnx4rAiQYlN_N9PZLXjzT415ADDvLw02kPVQbdVpA=.04505e57-016f-4f7e-a50a-75def52138dd@github.com>

Make the VM fix the missing ACC_IDENTITY flags even when preview or Valhalla modes are not enabled.

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

Commit messages:
 - Fix missing ACC_IDENTITY even when in non Valhalla mode

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

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


From fparain at openjdk.org  Thu Mar 21 15:54:41 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 21 Mar 2024 15:54:41 GMT
Subject: [lworld] Integrated: 8328641: [lworld]
 runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails
 with java.lang.IncompatibleClassChangeError: value class AME5_B cannot inherit
 from class AME5_A
In-Reply-To: <wKXnx4rAiQYlN_N9PZLXjzT415ADDvLw02kPVQbdVpA=.04505e57-016f-4f7e-a50a-75def52138dd@github.com>
References: <wKXnx4rAiQYlN_N9PZLXjzT415ADDvLw02kPVQbdVpA=.04505e57-016f-4f7e-a50a-75def52138dd@github.com>
Message-ID: <hxoAoo1WteBvzW4kZOMgmFryTTj8xFGu8yOLbHNkSBY=.7d46b2b6-5f18-43f4-8c65-567290b78f9d@github.com>

On Thu, 21 Mar 2024 15:47:06 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Make the VM fix the missing ACC_IDENTITY flags even when preview or Valhalla modes are not enabled.

This pull request has now been integrated.

Changeset: 6f51b962
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6f51b96264cd5530321249aef0a8fc095125b8c0
Stats:     24 lines in 2 files changed: 4 ins; 5 del; 15 mod

8328641: [lworld] runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java fails with java.lang.IncompatibleClassChangeError: value class AME5_B cannot inherit from class AME5_A

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

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


From fparain at openjdk.org  Thu Mar 21 17:58:47 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 21 Mar 2024 17:58:47 GMT
Subject: [lworld] Integrated: 8328715: [lworld]
 runtime/classFileParserBug/NameAndTypeSig.java fails with Wrong
 ClassFormatError exception: Method "<init>" in class nonVoidInitSigCFE (an
 inline class) has illegal signature "()D"
Message-ID: <p8zK9WfAFL0krP06yhh1rC8Ov-pM7ElicvYeTtNc7hc=.2cd2ed40-04d7-4998-8cb4-00fdd69ad2e0@github.com>

Restore the previous behavior of the VM related to ClassFormatError by removing some buggy code.

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

Commit messages:
 - Fix CFE error message

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

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


From fparain at openjdk.org  Thu Mar 21 17:58:47 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 21 Mar 2024 17:58:47 GMT
Subject: [lworld] Integrated: 8328715: [lworld]
 runtime/classFileParserBug/NameAndTypeSig.java fails with Wrong
 ClassFormatError exception: Method "<init>" in class nonVoidInitSigCFE (an
 inline class) has illegal signature "()D"
In-Reply-To: <p8zK9WfAFL0krP06yhh1rC8Ov-pM7ElicvYeTtNc7hc=.2cd2ed40-04d7-4998-8cb4-00fdd69ad2e0@github.com>
References: <p8zK9WfAFL0krP06yhh1rC8Ov-pM7ElicvYeTtNc7hc=.2cd2ed40-04d7-4998-8cb4-00fdd69ad2e0@github.com>
Message-ID: <-mCUQQgUk7qwAxHH-TBHIMp1_CHR6D1ED5bOdOjdlu8=.996945c0-2244-487f-8d3d-cd0d3b6ac44b@github.com>

On Thu, 21 Mar 2024 17:53:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Restore the previous behavior of the VM related to ClassFormatError by removing some buggy code.

This pull request has now been integrated.

Changeset: da9d6fb2
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/da9d6fb2967fc322617443b2df16b3fef9e84d8f
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8328715: [lworld] runtime/classFileParserBug/NameAndTypeSig.java fails with Wrong ClassFormatError exception: Method "<init>" in class nonVoidInitSigCFE (an inline class) has illegal signature "()D"

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

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


From dsimms at openjdk.org  Fri Mar 22 06:33:39 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 22 Mar 2024 06:33:39 GMT
Subject: [lworld] Integrated: 8328150: [lworld] Adjust flags to
 "--enable-preview" clear out EnableValhalla and EnablePrimitiveClasses
In-Reply-To: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
References: <wVLumZnDIUCpFeg-6PhcuvV04Pil5weZK4c_-i3qzyE=.a9f13c32-ad70-4f89-b2f8-c38266401fc3@github.com>
Message-ID: <eel3oIF6xyzeWvywXrL1OiVdPhHXedQ7PxH0goyo4V4=.ccf95fa5-7890-4b03-ab2e-d09c59d1b4a9@github.com>

On Tue, 19 Mar 2024 10:23:23 GMT, David Simms <dsimms at openjdk.org> wrote:

> * Removed all cases of -XX: EnableValhalla and EnablePrimitiveClasses
> * Deleted tests that were dominated by now defunct concepts (withfield, entirely primitives classes etc)
> * Trival fixes to simply remove primitive class tests cases
> * `@ignores` tagged with bug number where tests need non-trival updating to JEP401 concepts

This pull request has now been integrated.

Changeset: bc2ec0ee
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/bc2ec0ee1197645e5e2d258541ed414414b5cec8
Stats:     4412 lines in 171 files changed: 48 ins; 4056 del; 308 mod

8328150: [lworld] Adjust flags to "--enable-preview" clear out EnableValhalla and EnablePrimitiveClasses

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

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


From thartmann at openjdk.org  Fri Mar 22 09:09:07 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Mar 2024 09:09:07 GMT
Subject: [lworld] Integrated: [lworld] Problem listing some more tests that are
 failing in the CI
Message-ID: <EuPAqqUuDWzvVXE-E1goBIWKYUkvG-e25gqdSjZy-HY=.a23c92b2-5999-49c9-a56e-b740012c9dbc@github.com>

More problem listing.

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

Commit messages:
 - [lworld] Problem listing some more tests that are failing in the CI

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

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


From thartmann at openjdk.org  Fri Mar 22 09:09:07 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Mar 2024 09:09:07 GMT
Subject: [lworld] Integrated: [lworld] Problem listing some more tests that are
 failing in the CI
In-Reply-To: <EuPAqqUuDWzvVXE-E1goBIWKYUkvG-e25gqdSjZy-HY=.a23c92b2-5999-49c9-a56e-b740012c9dbc@github.com>
References: <EuPAqqUuDWzvVXE-E1goBIWKYUkvG-e25gqdSjZy-HY=.a23c92b2-5999-49c9-a56e-b740012c9dbc@github.com>
Message-ID: <gN71cRRrHs8jTuqDIpsXHRq4oBErfJTqBspNsUVBK3o=.daec1486-ff39-4ba4-a75b-1c4f8ac99ead@github.com>

On Fri, 22 Mar 2024 09:04:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> More problem listing.

This pull request has now been integrated.

Changeset: 060242e7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/060242e7dddb5ddd7e5186dc2fadc3d36887aa63
Stats:     7 lines in 2 files changed: 6 ins; 0 del; 1 mod

[lworld] Problem listing some more tests that are failing in the CI

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

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


From thartmann at openjdk.org  Fri Mar 22 12:49:53 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Mar 2024 12:49:53 GMT
Subject: [lworld] Integrated: [lworld] Undo problem listing
Message-ID: <jbBO9eXTLIuX0EG4m-ZFnpfazzLGDlI9z3QqWpxUWb4=.724201b6-0b40-4954-9c6a-0d5f8e723e8e@github.com>

Used the wrong problem list.

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

Commit messages:
 - [lworld] Undo problem listing

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

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


From thartmann at openjdk.org  Fri Mar 22 12:49:54 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 22 Mar 2024 12:49:54 GMT
Subject: [lworld] Integrated: [lworld] Undo problem listing
In-Reply-To: <jbBO9eXTLIuX0EG4m-ZFnpfazzLGDlI9z3QqWpxUWb4=.724201b6-0b40-4954-9c6a-0d5f8e723e8e@github.com>
References: <jbBO9eXTLIuX0EG4m-ZFnpfazzLGDlI9z3QqWpxUWb4=.724201b6-0b40-4954-9c6a-0d5f8e723e8e@github.com>
Message-ID: <uEnXdXM-yqFg1KCRMTvAxoYd7R0ccHKKmIYxoYlQSrM=.365a99ec-d478-4cb9-9e12-cc215c87a488@github.com>

On Fri, 22 Mar 2024 12:44:04 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Used the wrong problem list.

This pull request has now been integrated.

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

[lworld] Undo problem listing

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

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


From rriggs at openjdk.org  Fri Mar 22 20:16:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 22 Mar 2024 20:16:51 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures
Message-ID: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>

Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
(The class file format version numbers will need to be updated when re-synching with the mainline).

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

Commit messages:
 - 8328543: [lworld] Library and test updates to use --enable-preview instead of ValhallaFeatures

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

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


From mchung at openjdk.org  Fri Mar 22 20:51:28 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 22 Mar 2024 20:51:28 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <nvq497fcnxLQTZ1GVtFumjDdfgbTL9rxjhJv5NSkmgw=.da560813-5303-4aeb-8b0d-7d9335a7a84c@github.com>

On Fri, 22 Mar 2024 20:12:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

`AccessFlag::IDENTITY` and `STRICT`  are missing `@PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS)`.   Need to do a pass on the new APIs to add `@PreviewFeature` if missing and that may cause additional change.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 188:

> 186:      * In Java SE 8 and above, the JVM treats the {@code ACC_SUPER}
> 187:      * flag as set in every class file (JVMS {@jvms 4.1}).
> 188:      * For class file versions up to but not including Valhalla,

The javadoc should reference to "preview feature" rather than "Valhalla"

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 196:

> 194:             @Override
> 195:             public Set<Location> apply(ClassFileFormatVersion cffv) {
> 196:                 return (cffv.compareTo(ClassFileFormatVersion.RELEASE_22) >= 0)

Shouldn't it check for preview enabled?

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

PR Review: https://git.openjdk.org/valhalla/pull/1060#pullrequestreview-1955764152
PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1536199910
PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1536204830


From rriggs at openjdk.org  Fri Mar 22 22:17:37 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 22 Mar 2024 22:17:37 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures
In-Reply-To: <nvq497fcnxLQTZ1GVtFumjDdfgbTL9rxjhJv5NSkmgw=.da560813-5303-4aeb-8b0d-7d9335a7a84c@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <nvq497fcnxLQTZ1GVtFumjDdfgbTL9rxjhJv5NSkmgw=.da560813-5303-4aeb-8b0d-7d9335a7a84c@github.com>
Message-ID: <_KNQPcMxonPa-CLDKKn_jjPlStiusuv5MeA9v1lB_pE=.7df36a03-d041-4e25-ad55-5500594275e7@github.com>

On Fri, 22 Mar 2024 20:49:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `AccessFlag::IDENTITY` and `STRICT` are missing `@PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS)`. Need to do a pass on the new APIs to add `@PreviewFeature` if missing and that may cause additional change.

Yes for IDENTITY; I don't think the spec for STRICT has settled enough yet to define the behavior as part of JEP 401.

> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 196:
> 
>> 194:             @Override
>> 195:             public Set<Location> apply(ClassFileFormatVersion cffv) {
>> 196:                 return (cffv.compareTo(ClassFileFormatVersion.RELEASE_22) >= 0)
> 
> Shouldn't it check for preview enabled?

The wording of the spec makes it difficult to support SUPER and IDENTITY at the same time flipped on --enable-preview. SUPER is described as being ignored.
It says that 0x0020 means IDENTITY regardless of the class file version number.
The repo hasn't yet sync'd with the mainline changes for jdk23. When that happens, SUPER can be meaningful only for 22 and ignored for 23 and IDENTITY can hold that bit position.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1060#issuecomment-2016010068
PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1536271528


From rriggs at openjdk.org  Fri Mar 22 22:28:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 22 Mar 2024 22:28:55 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v2]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <_SQUQlEKPl0F2gCd-EEJ_3qMbReWvbJuHdahVHzehpk=.6a6ccd66-90f3-4ad6-a60c-8f71159070d4@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

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

  Add PreviewFeature annotation to AccessFlag.IDENTITY.
  Update module-info.java to allow jfr to use IDENTITY in writing classes.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/0dc31d92..dde005e5

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

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

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


From vromero at openjdk.org  Sat Mar 23 13:03:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 23 Mar 2024 13:03:58 GMT
Subject: [lworld] Integrated: 8328839: [lworld] javac allows super constructor
 invocations before all fields have been initialized
Message-ID: <EtX-VyJPL7E6zrWrhVL37B2THbxyCR77fqsJDBMKyUk=.5f8f6bab-eb10-4df1-ab33-5896a148e881@github.com>

this code is being accepted by javac:

value class V {
    int i;

    V() {
        super();
        i = 1;
    }
}

it should be rejected. Also, with value records, the implicit super call always ends up before the field stores. Reported by Tobias

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

Commit messages:
 - 8328839: [lworld] javac allows super constructor invocations before all fields have been initialized

Changes: https://git.openjdk.org/valhalla/pull/1061/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1061&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328839
  Stats: 206 lines in 8 files changed: 130 ins; 44 del; 32 mod
  Patch: https://git.openjdk.org/valhalla/pull/1061.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1061/head:pull/1061

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


From vromero at openjdk.org  Sat Mar 23 13:03:59 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 23 Mar 2024 13:03:59 GMT
Subject: [lworld] Integrated: 8328839: [lworld] javac allows super constructor
 invocations before all fields have been initialized
In-Reply-To: <EtX-VyJPL7E6zrWrhVL37B2THbxyCR77fqsJDBMKyUk=.5f8f6bab-eb10-4df1-ab33-5896a148e881@github.com>
References: <EtX-VyJPL7E6zrWrhVL37B2THbxyCR77fqsJDBMKyUk=.5f8f6bab-eb10-4df1-ab33-5896a148e881@github.com>
Message-ID: <-lmGzvS4okNY6vcQannhG0kDQAq-k7Q0DfPHVabA2NM=.4ca432f4-1854-433b-93cf-1c1be7b389af@github.com>

On Sat, 23 Mar 2024 12:57:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this code is being accepted by javac:
> 
> value class V {
>     int i;
> 
>     V() {
>         super();
>         i = 1;
>     }
> }
> 
> it should be rejected. Also, with value records, the implicit super call always ends up before the field stores. Reported by Tobias

This pull request has now been integrated.

Changeset: f8931fd9
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f8931fd95193ccd5b31a6a880acfd5b523e27363
Stats:     206 lines in 8 files changed: 130 ins; 44 del; 32 mod

8328839: [lworld] javac allows super constructor invocations before all fields have been initialized

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

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


From thartmann at openjdk.org  Mon Mar 25 13:31:58 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Mar 2024 13:31:58 GMT
Subject: [lworld] RFR: 8328704: [REDO] [lworld] Missing barrier after value
 object construction
Message-ID: <h8sRJbW8FNIz8ep9SSzXF-GRaLkeJYxN_zWe0bjK_XE=.1be3c1a1-c55f-471e-b01e-013b4e6cdd1e@github.com>

Added a missing barrier after value object construction.

Thanks,
Tobias

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

Commit messages:
 - Removed ToDos
 - Removed ToDos
 - 8328704: [REDO] [lworld] Missing barrier after value object construction

Changes: https://git.openjdk.org/valhalla/pull/1062/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328704
  Stats: 59 lines in 8 files changed: 42 ins; 14 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1062.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1062/head:pull/1062

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


From thartmann at openjdk.org  Mon Mar 25 13:54:41 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 25 Mar 2024 13:54:41 GMT
Subject: [lworld] Integrated: 8328704: [REDO] [lworld] Missing barrier after
 value object construction
In-Reply-To: <h8sRJbW8FNIz8ep9SSzXF-GRaLkeJYxN_zWe0bjK_XE=.1be3c1a1-c55f-471e-b01e-013b4e6cdd1e@github.com>
References: <h8sRJbW8FNIz8ep9SSzXF-GRaLkeJYxN_zWe0bjK_XE=.1be3c1a1-c55f-471e-b01e-013b4e6cdd1e@github.com>
Message-ID: <Vlb1ffnc1QZaB4-_v9YKqnhbyMy46q7xbtOLLtboKCE=.40cac555-9ef9-4620-a0fc-f328d37a9bea@github.com>

On Mon, 25 Mar 2024 13:27:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Added a missing barrier after value object construction.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: a226fb4b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a226fb4bff53a715acc83ef56187d5e174c10ed0
Stats:     59 lines in 8 files changed: 42 ins; 14 del; 3 mod

8328704: [REDO] [lworld] Missing barrier after value object construction

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

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


From iklam at openjdk.org  Tue Mar 26 15:55:42 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 26 Mar 2024 15:55:42 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with --enable-preview
 patched value classes
Message-ID: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>

[1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.

[2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.

[3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.

[4] Tests with all CDS tests and tiers 1-4.

[5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

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

Commit messages:
 - 8304168: [lworld] CDS tests fail with --enable-preview patched value classes

Changes: https://git.openjdk.org/valhalla/pull/1063/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304168
  Stats: 252 lines in 25 files changed: 149 ins; 23 del; 80 mod
  Patch: https://git.openjdk.org/valhalla/pull/1063.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1063/head:pull/1063

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


From mchung at openjdk.org  Tue Mar 26 16:58:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 26 Mar 2024 16:58:45 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes
In-Reply-To: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
Message-ID: <NaQDjZFEjFSGLoVqSZWgoS6PzEb1ZZNawNbkl31BTfQ=.08c226a1-eeed-40d1-a98d-aceef0009c01@github.com>

On Tue, 26 Mar 2024 15:51:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
> 
> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
> 
> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
> 
> [4] Tests with all CDS tests and tiers 1-4.
> 
> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

This approach is reasonable and simplest to add a new CDS archive which adds a small percentage to the image size.

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

Marked as reviewed by mchung (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1063#pullrequestreview-1961136254


From rriggs at openjdk.org  Tue Mar 26 18:45:32 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 26 Mar 2024 18:45:32 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes
In-Reply-To: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
Message-ID: <HOvNHNEqZrG-UkF4adMAE7NsX0qupFYApFZEMlfzr-k=.b87f996e-281a-4842-9214-ef878f51b3c1@github.com>

On Tue, 26 Mar 2024 15:51:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
> 
> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
> 
> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
> 
> [4] Tests with all CDS tests and tiers 1-4.
> 
> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

Can we drop `EnableValhalla`; I believe we're trying to remove that and use only --enable-preview.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1063#issuecomment-2021213392


From iklam at openjdk.org  Tue Mar 26 18:54:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 26 Mar 2024 18:54:39 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes
In-Reply-To: <HOvNHNEqZrG-UkF4adMAE7NsX0qupFYApFZEMlfzr-k=.b87f996e-281a-4842-9214-ef878f51b3c1@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
 <HOvNHNEqZrG-UkF4adMAE7NsX0qupFYApFZEMlfzr-k=.b87f996e-281a-4842-9214-ef878f51b3c1@github.com>
Message-ID: <qcDjUJZSW7DBFwi7m0LICovPoSXNf5ZbHxU5sl7uwnI=.85696169-df39-4a9a-ad56-e57c1c4172dc@github.com>

On Tue, 26 Mar 2024 18:42:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Can we drop `EnableValhalla`; I believe we're trying to remove that and use only --enable-preview.

There's existing code in arguments.cpp that checks `if (enable_preview() && EnableValhalla)`. I think we can clean that up in a separate PR.

https://github.com/openjdk/valhalla/blob/a226fb4bff53a715acc83ef56187d5e174c10ed0/src/hotspot/share/runtime/arguments.cpp#L2195-L2201

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

PR Comment: https://git.openjdk.org/valhalla/pull/1063#issuecomment-2021234249


From rriggs at openjdk.org  Wed Mar 27 01:51:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Mar 2024 01:51:55 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v3]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <pDzD2mpmjqtPDsFvtw4Jfw-OAbmXm2wdJ7bpGg8LQdY=.196f1310-09ea-4a6d-ac28-9140df98ad97@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

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

  Corrected code and tests to use --enable-preview when refering to ACC_IDENTITY

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/dde005e5..6085d5ef

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

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

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


From dsimms at openjdk.org  Wed Mar 27 09:59:33 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 27 Mar 2024 09:59:33 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes
In-Reply-To: <qcDjUJZSW7DBFwi7m0LICovPoSXNf5ZbHxU5sl7uwnI=.85696169-df39-4a9a-ad56-e57c1c4172dc@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
 <HOvNHNEqZrG-UkF4adMAE7NsX0qupFYApFZEMlfzr-k=.b87f996e-281a-4842-9214-ef878f51b3c1@github.com>
 <qcDjUJZSW7DBFwi7m0LICovPoSXNf5ZbHxU5sl7uwnI=.85696169-df39-4a9a-ad56-e57c1c4172dc@github.com>
Message-ID: <fr7OF07M2wlC5V3ErOrQgH5kbGaKl7-LNc8gnyrDHMY=.3692c365-f98c-41d7-8229-71bada1c2c78@github.com>

On Tue, 26 Mar 2024 18:52:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Can we drop `EnableValhalla`; I believe we're trying to remove that and use only --enable-preview.

We said within the VM implementation to continue using `EnableValhalla` to easily demarcate Valhalla until we prepare for preview. Outside the VM, i.e. test invocations etc, yeah we are using `--enable-preview`

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

PR Comment: https://git.openjdk.org/valhalla/pull/1063#issuecomment-2022354385


From fparain at openjdk.org  Wed Mar 27 15:49:39 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 27 Mar 2024 15:49:39 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes
In-Reply-To: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
Message-ID: <0i2CpWbAic9LxfoXB8kVCLrhv0DfZ-AoE-Vp9UZbTBs=.5cf8b8d7-8450-48c7-a6b7-3d9b858f7801@github.com>

On Tue, 26 Mar 2024 15:51:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
> 
> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
> 
> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
> 
> [4] Tests with all CDS tests and tiers 1-4.
> 
> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

src/hotspot/share/cds/cdsConfig.cpp line 51:

> 49: bool CDSConfig::is_dumping_heap() {
> 50:   if (is_valhalla_preview()) {
> 51:     // Not working yet -- e.g., HeapShared::ooo_hash() needs to be implemented for value oops

HeapShared::ooo_hash() -> HeapShared::oop_hash()

src/hotspot/share/cds/filemap.cpp line 2474:

> 2472:     }
> 2473:   }
> 2474: 

Another VM option, `InlineFieldMaxFlatSize`, can influence the field layout, and by consequence, the validity of the `InstanceKlass` from the archive. It is probably needed to encode the value of `InlineFieldMaxFlatSize` in the archive to be able to check against the current VM options. We can decide to completely reject the archive if `InlineFieldMaxFlatSize` options don't match, or we can have a per class approach, as most classes won't have flat fields, and only reject them with a field layout not compliant with the current flag value.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1063#discussion_r1541375017
PR Review Comment: https://git.openjdk.org/valhalla/pull/1063#discussion_r1541374564


From mchung at openjdk.org  Wed Mar 27 16:38:38 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 16:38:38 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v3]
In-Reply-To: <pDzD2mpmjqtPDsFvtw4Jfw-OAbmXm2wdJ7bpGg8LQdY=.196f1310-09ea-4a6d-ac28-9140df98ad97@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <pDzD2mpmjqtPDsFvtw4Jfw-OAbmXm2wdJ7bpGg8LQdY=.196f1310-09ea-4a6d-ac28-9140df98ad97@github.com>
Message-ID: <kqHrBUwln_992nfm9zrzoVOYdZgvQX6r5N7iei2-eEA=.5aae1f33-1f08-43b9-af2f-c20cb0cc6dc2@github.com>

On Wed, 27 Mar 2024 01:51:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
>> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
>> (The class file format version numbers will need to be updated when re-synching with the mainline).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected code and tests to use --enable-preview when refering to ACC_IDENTITY

Minor point: as you avoid dependency to `ACC_IDENTITY` in JVM CI, I wonder if you should do the same in JFR.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 191:

> 189:      * In Java SE 8 and above, the JVM treats the {@code ACC_SUPER}
> 190:      * flag as set in every class file (JVMS {@jvms 4.1}).
> 191:      * For class file versions up to but not including PreviewFeature VALUE_OBJECTS,

Suggestion:

     * If preview feature is enabled, 
     * the {@code 0x0020} access flag bit is {@linkplain #IDENTITY IDENTITY access flag}.

src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotModifiers.java line 56:

> 54: 
> 55:     public static int jvmClassModifiers() {
> 56:         return PUBLIC | FINAL | INTERFACE | ABSTRACT | ANNOTATION | ENUM | SYNTHETIC | 0x0020; // ACC_IDENTITY temp constant to avoid preview dependency

Add `0x0020` only if preview is enabled.

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

Marked as reviewed by mchung (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1060#pullrequestreview-1958297604
PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1541433993
PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1541442515


From iklam at openjdk.org  Wed Mar 27 17:11:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 27 Mar 2024 17:11:55 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes [v2]
In-Reply-To: <0i2CpWbAic9LxfoXB8kVCLrhv0DfZ-AoE-Vp9UZbTBs=.5cf8b8d7-8450-48c7-a6b7-3d9b858f7801@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
 <0i2CpWbAic9LxfoXB8kVCLrhv0DfZ-AoE-Vp9UZbTBs=.5cf8b8d7-8450-48c7-a6b7-3d9b858f7801@github.com>
Message-ID: <Dp80i5_YaqE1tiNyMIoKCPeNGlPBdWhP_enlpklr-nE=.b540483b-8a49-4876-a298-746b2daf5247@github.com>

On Wed, 27 Mar 2024 15:46:48 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo
>
> src/hotspot/share/cds/cdsConfig.cpp line 51:
> 
>> 49: bool CDSConfig::is_dumping_heap() {
>> 50:   if (is_valhalla_preview()) {
>> 51:     // Not working yet -- e.g., HeapShared::ooo_hash() needs to be implemented for value oops
> 
> HeapShared::ooo_hash() -> HeapShared::oop_hash()

Fixed.

> src/hotspot/share/cds/filemap.cpp line 2474:
> 
>> 2472:     }
>> 2473:   }
>> 2474: 
> 
> Another VM option, `InlineFieldMaxFlatSize`, can influence the field layout, and by consequence, the validity of the `InstanceKlass` from the archive. It is probably needed to encode the value of `InlineFieldMaxFlatSize` in the archive to be able to check against the current VM options. We can decide to completely reject the archive if `InlineFieldMaxFlatSize` options don't match, or we can have a per class approach, as most classes won't have flat fields, and only reject classes with a field layout not compliant with the current flag value.

We have such a check already (see [JDK-8272290](https://bugs.openjdk.org/browse/JDK-8272290)]. We currently reject the whole archive when the following flags don't match:

  - EnableValhalla
  - FlatArrayElementMaxOops
  - FlatArrayElementMaxSize
  - InlineFieldMaxFlatSize
  - InlineTypePassFieldsAsArgs
  - InlineTypeReturnedAsFields

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1063#discussion_r1541510977
PR Review Comment: https://git.openjdk.org/valhalla/pull/1063#discussion_r1541511007


From iklam at openjdk.org  Wed Mar 27 17:11:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 27 Mar 2024 17:11:55 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes [v2]
In-Reply-To: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
Message-ID: <Z2Qqe-mhgII9F4uDjHqTSGOe_zZXITzCzWrIFNW5fDs=.fecb32c7-de0d-48b4-aff6-8337f32a9663@github.com>

> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
> 
> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
> 
> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
> 
> [4] Tests with all CDS tests and tiers 1-4.
> 
> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1063/files
  - new: https://git.openjdk.org/valhalla/pull/1063/files/11c6d680..622eda67

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

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

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


From mchung at openjdk.org  Wed Mar 27 17:13:01 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 17:13:01 GMT
Subject: [lworld] RFR: 8329205: [lworld] Add jdk.internal.value.CheckedType API
Message-ID: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>

This PR adds `jdk.internal.value.CheckedType` and other internal APIs for null-restricted value type and array support.   Also rename `Unsafe::isFlattenedArray` to `Unsafe::isFlatArray`.

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

Commit messages:
 - 8329205: [lworld] Add jdk.internal.value.CheckedType API

Changes: https://git.openjdk.org/valhalla/pull/1065/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1065&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329205
  Stats: 853 lines in 32 files changed: 535 ins; 133 del; 185 mod
  Patch: https://git.openjdk.org/valhalla/pull/1065.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1065/head:pull/1065

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


From rriggs at openjdk.org  Wed Mar 27 17:19:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Mar 2024 17:19:27 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v3]
In-Reply-To: <kqHrBUwln_992nfm9zrzoVOYdZgvQX6r5N7iei2-eEA=.5aae1f33-1f08-43b9-af2f-c20cb0cc6dc2@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <pDzD2mpmjqtPDsFvtw4Jfw-OAbmXm2wdJ7bpGg8LQdY=.196f1310-09ea-4a6d-ac28-9140df98ad97@github.com>
 <kqHrBUwln_992nfm9zrzoVOYdZgvQX6r5N7iei2-eEA=.5aae1f33-1f08-43b9-af2f-c20cb0cc6dc2@github.com>
Message-ID: <6sOaeqGpdyjsRD2DgKvr4HsqpdNG8XnUEqObGY9H7mI=.8c997950-de74-41dd-9537-f2443e69b75a@github.com>

On Wed, 27 Mar 2024 16:35:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Minor point: as you avoid dependency to `ACC_IDENTITY` in JVM CI, I wonder if you should do the same in JFR.

jfr already has a module import of java in mainline so its just extending the existing use of preview features.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1060#issuecomment-2023348627


From rriggs at openjdk.org  Wed Mar 27 17:29:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Mar 2024 17:29:43 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v4]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <nC180Hnkz--I54z9BxF-mGZDJWVuMZ9JrmE350MgnwE=.36d6a787-7557-44ff-9642-9957f0895bfc@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

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

  condition on enable preview

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/6085d5ef..bd5886a1

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

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

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


From rriggs at openjdk.org  Wed Mar 27 17:35:48 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 27 Mar 2024 17:35:48 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v5]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <XotpQOMCtk2lBF0YTmGf-KIOr42LcqWd1oUdPBktl4s=.e378674d-a83d-428a-9b98-17cc48da7c5c@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

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

 - remove extraneous text
 - Update src/java.base/share/classes/java/lang/reflect/AccessFlag.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/bd5886a1..cc7ac497

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

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

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


From vromero at openjdk.org  Wed Mar 27 18:13:36 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 27 Mar 2024 18:13:36 GMT
Subject: [lworld] Integrated: 8329106: [lworld] adding support for value
 classes in javap, plus test refactorings
Message-ID: <YVJJFUG03IbAWQFsLSiep3cI8c90g9XiQWww_0THVKg=.d5d588f8-8fac-4329-bde0-e4fb91796f2e@github.com>

adding support in javap to show if a class is a value class, plus some test clean-up and refactorings

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

Commit messages:
 - 8329106: [lworld] adding support for value classes in javap, plus test refactorings

Changes: https://git.openjdk.org/valhalla/pull/1066/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329106
  Stats: 1495 lines in 11 files changed: 71 ins; 1409 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/1066.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1066/head:pull/1066

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


From vromero at openjdk.org  Wed Mar 27 18:13:36 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 27 Mar 2024 18:13:36 GMT
Subject: [lworld] Integrated: 8329106: [lworld] adding support for value
 classes in javap, plus test refactorings
In-Reply-To: <YVJJFUG03IbAWQFsLSiep3cI8c90g9XiQWww_0THVKg=.d5d588f8-8fac-4329-bde0-e4fb91796f2e@github.com>
References: <YVJJFUG03IbAWQFsLSiep3cI8c90g9XiQWww_0THVKg=.d5d588f8-8fac-4329-bde0-e4fb91796f2e@github.com>
Message-ID: <eRSp8tnOCNvt7_7Rlojsk4feMk6q0qYGsr9CqZwaq0g=.facb6542-fe74-44ee-9133-bea02fc26c57@github.com>

On Wed, 27 Mar 2024 18:05:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> adding support in javap to show if a class is a value class, plus some test clean-up and refactorings

This pull request has now been integrated.

Changeset: f0df074b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f0df074bf7bd7f818742b2603915de6a74533ba6
Stats:     1495 lines in 11 files changed: 71 ins; 1409 del; 15 mod

8329106: [lworld] adding support for value classes in javap, plus test refactorings

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

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


From mchung at openjdk.org  Wed Mar 27 18:48:13 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 18:48:13 GMT
Subject: [lworld] RFR: 8329205: [lworld] Add jdk.internal.value.CheckedType
 API [v2]
In-Reply-To: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>
References: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>
Message-ID: <4VujbcpPk55J04ZQxRDe0dU6PtTdVjj-Cc-8eI7J0xc=.799a314f-85dd-4a5f-b7ea-9e68ddcb2c02@github.com>

> This PR adds `jdk.internal.value.CheckedType` and other internal APIs for null-restricted value type and array support.   Also rename `Unsafe::isFlattenedArray` to `Unsafe::isFlatArray`.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  misc clean up

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1065/files
  - new: https://git.openjdk.org/valhalla/pull/1065/files/90296ee1..b052b2d3

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

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

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


From mchung at openjdk.org  Wed Mar 27 20:09:48 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 20:09:48 GMT
Subject: [lworld] Integrated: 8329205: [lworld] Add
 jdk.internal.value.CheckedType API
In-Reply-To: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>
References: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>
Message-ID: <x_9aBGbqdU0IBXOacvnk5YJVB6JvLvGqaL-ezmrNNAQ=.75a3a660-c183-4c16-8ca0-67419dd4abcc@github.com>

On Wed, 27 Mar 2024 17:07:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This PR adds `jdk.internal.value.CheckedType` and other internal APIs for null-restricted value type and array support.   Also rename `Unsafe::isFlattenedArray` to `Unsafe::isFlatArray`.

This pull request has now been integrated.

Changeset: 0888af6e
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0888af6eb813699af1c2d7a81460ad7be3a87087
Stats:     867 lines in 33 files changed: 535 ins; 139 del; 193 mod

8329205: [lworld] Add jdk.internal.value.CheckedType API

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

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


From mchung at openjdk.org  Wed Mar 27 20:27:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 20:27:45 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v5]
In-Reply-To: <XotpQOMCtk2lBF0YTmGf-KIOr42LcqWd1oUdPBktl4s=.e378674d-a83d-428a-9b98-17cc48da7c5c@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <XotpQOMCtk2lBF0YTmGf-KIOr42LcqWd1oUdPBktl4s=.e378674d-a83d-428a-9b98-17cc48da7c5c@github.com>
Message-ID: <9ztfNlP_oI2gf6jXYZ9mgKpGRDB0SqhZGX6-N_QEtLw=.e175ccd0-89c0-4a26-be00-4769bbd00889@github.com>

On Wed, 27 Mar 2024 17:35:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
>> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
>> (The class file format version numbers will need to be updated when re-synching with the mainline).
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove extraneous text
>  - Update src/java.base/share/classes/java/lang/reflect/AccessFlag.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java line 30:

> 28:  * @modules java.base/jdk.internal.misc
> 29:  * @enablePreview
> 30:  * @run main/othervm --enable-preview BasicAccessFlagTest

`@enablePreview` should always add `--enable-preview` to test execution.  If you want to test with preview enabled and disabled, it can't use `@enablePreview`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1541983852


From liach at openjdk.org  Wed Mar 27 21:34:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 27 Mar 2024 21:34:42 GMT
Subject: [lworld] RFR: 8329205: [lworld] Add jdk.internal.value.CheckedType
 API [v2]
In-Reply-To: <4VujbcpPk55J04ZQxRDe0dU6PtTdVjj-Cc-8eI7J0xc=.799a314f-85dd-4a5f-b7ea-9e68ddcb2c02@github.com>
References: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>
 <4VujbcpPk55J04ZQxRDe0dU6PtTdVjj-Cc-8eI7J0xc=.799a314f-85dd-4a5f-b7ea-9e68ddcb2c02@github.com>
Message-ID: <u4fnOGd0Gh7F5pIU_E_WSxRsCDEEZD57ruxMtrJ0Bu0=.b9fe95d6-22bd-46db-9044-4a927b04b84a@github.com>

On Wed, 27 Mar 2024 18:48:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR adds `jdk.internal.value.CheckedType` and other internal APIs for null-restricted value type and array support.   Also rename `Unsafe::isFlattenedArray` to `Unsafe::isFlatArray`.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   misc clean up

Sorry for a late comment, but should we add some handling to checked types to explicitly reject passing primitives? Currently primitives doesn't appear in checked types' code paths but other developers might accidentally abuse it in the future.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1065#issuecomment-2024027057


From mchung at openjdk.org  Wed Mar 27 22:11:48 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 27 Mar 2024 22:11:48 GMT
Subject: [lworld] RFR: 8329205: [lworld] Add jdk.internal.value.CheckedType
 API [v2]
In-Reply-To: <4VujbcpPk55J04ZQxRDe0dU6PtTdVjj-Cc-8eI7J0xc=.799a314f-85dd-4a5f-b7ea-9e68ddcb2c02@github.com>
References: <LyphWH8g6CZgaivtacD4NZwP8extlQNfN8KjubxuWDw=.7f5f191d-3d40-4bd4-84f8-fead566de0f3@github.com>
 <4VujbcpPk55J04ZQxRDe0dU6PtTdVjj-Cc-8eI7J0xc=.799a314f-85dd-4a5f-b7ea-9e68ddcb2c02@github.com>
Message-ID: <soi2qlj5YunMONiG-wuLh0yu5GIkDqQ-LzUEz8G5YIY=.ccdfe7d3-6f3f-487e-b1c5-856a006b7165@github.com>

On Wed, 27 Mar 2024 18:48:13 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This PR adds `jdk.internal.value.CheckedType` and other internal APIs for null-restricted value type and array support.   Also rename `Unsafe::isFlattenedArray` to `Unsafe::isFlatArray`.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   misc clean up

Yes, agree.   The API needs additional argument checking and will update it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1065#issuecomment-2024074862


From thartmann at openjdk.org  Thu Mar 28 07:41:51 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 28 Mar 2024 07:41:51 GMT
Subject: [lworld] RFR: 8329196: [lworld] More fixes to value object
 construction in C2
Message-ID: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>

Follow-up from [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660). We can't rely on `GraphKit::replace_in_map` to reliably replace an InlineTypeNode that is initialized in the constructor in the caller map because there can be data flow merges. Instead, we need to explicitly update the node in the exit map. I added corresponding regression tests.

I also noticed that we are extensively cloning InlineTypeNodes during parsing, which often leads to an explosion of redundant nodes that then need to be removed. I added `InlineTypeNode::clone_if_required` to mitigate this, this can probably be further improved (I added corresponding ToDo's).

There are still issues with deoptimization from the constructor (`-XX:+DeoptimizeALot`). I'll address these in another fix.

I also disabled an IR rule in `TestZGCBarrierElision`. The issue will be fixed by [JDK-8329234](https://bugs.openjdk.org/browse/JDK-8329234).

Thanks,
Tobias

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

Commit messages:
 - Disabled IR verification due to JDK-8329234
 - Merge branch 'lworld' into JDK-8329196
 - More fixes, refactoring
 - First prototype

Changes: https://git.openjdk.org/valhalla/pull/1064/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329196
  Stats: 172 lines in 13 files changed: 124 ins; 10 del; 38 mod
  Patch: https://git.openjdk.org/valhalla/pull/1064.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1064/head:pull/1064

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


From rriggs at openjdk.org  Thu Mar 28 14:11:58 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 28 Mar 2024 14:11:58 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v6]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

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

  Remove extr enable preview and test code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/cc7ac497..98860d94

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

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

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


From thartmann at openjdk.org  Thu Mar 28 14:50:56 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 28 Mar 2024 14:50:56 GMT
Subject: [lworld] RFR: 8329196: [lworld] More fixes to value object
 construction in C2 [v2]
In-Reply-To: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
References: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
Message-ID: <xQdM08zw9UNk9_TfTXD1TODdRxImxGG22l_PnEyEsZs=.bb6972f0-ceb9-47f5-b420-f0fb0e60e630@github.com>

> Follow-up from [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660). We can't rely on `GraphKit::replace_in_map` to reliably replace an InlineTypeNode that is initialized in the constructor in the caller map because there can be data flow merges. Instead, we need to explicitly update the node in the exit map. I added corresponding regression tests.
> 
> I also noticed that we are extensively cloning InlineTypeNodes during parsing, which often leads to an explosion of redundant nodes that then need to be removed. I added `InlineTypeNode::clone_if_required` to mitigate this, this can probably be further improved (I added corresponding ToDo's).
> 
> There are still issues with deoptimization from the constructor (`-XX:+DeoptimizeALot`). I'll address these in another fix.
> 
> I also disabled an IR rule in `TestZGCBarrierElision`. The issue will be fixed by [JDK-8329234](https://bugs.openjdk.org/browse/JDK-8329234).
> 
> Thanks,
> Tobias

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

  Handling abstract value class constructors with arguments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1064/files
  - new: https://git.openjdk.org/valhalla/pull/1064/files/f2481f62..d12ce386

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

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

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


From thartmann at openjdk.org  Thu Mar 28 16:14:55 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 28 Mar 2024 16:14:55 GMT
Subject: [lworld] RFR: 8329196: [lworld] More fixes to value object
 construction in C2 [v2]
In-Reply-To: <xQdM08zw9UNk9_TfTXD1TODdRxImxGG22l_PnEyEsZs=.bb6972f0-ceb9-47f5-b420-f0fb0e60e630@github.com>
References: <z8WM0mJjAwBUAw8t-8NrHIQvieYciSi9OP25E2X_Zjg=.79a5ed19-4d5e-4d22-963a-8879d00f62fd@github.com>
 <xQdM08zw9UNk9_TfTXD1TODdRxImxGG22l_PnEyEsZs=.bb6972f0-ceb9-47f5-b420-f0fb0e60e630@github.com>
Message-ID: <i5LL8cgzda8TQdmq9ATcKy8XlSCPKduxzJkvqaQMfrI=.a47bcc0b-47e1-435f-b15b-af6b53c3f166@github.com>

On Thu, 28 Mar 2024 14:50:56 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Follow-up from [JDK-8325660](https://bugs.openjdk.org/browse/JDK-8325660). We can't rely on `GraphKit::replace_in_map` to reliably replace an InlineTypeNode that is initialized in the constructor in the caller map because there can be data flow merges. Instead, we need to explicitly update the node in the exit map. I added corresponding regression tests.
>> 
>> I also noticed that we are extensively cloning InlineTypeNodes during parsing, which often leads to an explosion of redundant nodes that then need to be removed. I added `InlineTypeNode::clone_if_required` to mitigate this, this can probably be further improved (I added corresponding ToDo's).
>> 
>> There are still issues with deoptimization from the constructor (`-XX:+DeoptimizeALot`). I'll address these in another fix.
>> 
>> I also disabled an IR rule in `TestZGCBarrierElision`. The issue will be fixed by [JDK-8329234](https://bugs.openjdk.org/browse/JDK-8329234).
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handling abstract value class constructors with arguments

Found more issues when there are deeply nested constructors, i.e., calls from one constructor to another. Will continue to work on this after the easter break.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1064#issuecomment-2025592430


From mchung at openjdk.org  Thu Mar 28 16:24:48 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 28 Mar 2024 16:24:48 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v6]
In-Reply-To: <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>
Message-ID: <AlnW54RrYAkwmM73jCcIAIJzarWJLpBad3SRGrjLp74=.5261c819-7b9b-4a78-9707-b4770a7be366@github.com>

On Thu, 28 Mar 2024 14:11:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
>> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
>> (The class file format version numbers will need to be updated when re-synching with the mainline).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extr enable preview and test code

test/jdk/java/lang/reflect/AccessFlag/ClassAccessFlagTest.java line 29:

> 27:  * @summary Test expected AccessFlag's on classes.
> 28:  * @modules java.base/jdk.internal.misc
> 29:  * @enablePreview

Should drop `@enablePreview`.  Same as `test/jdk/java/lang/reflect/AccessFlag/BasicAccessFlagTest.java`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1543259724


From liach at openjdk.org  Thu Mar 28 17:23:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 28 Mar 2024 17:23:43 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v6]
In-Reply-To: <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>
Message-ID: <0tFCT5l7QRM-X9PKo3lf0YDWQcnI7kLISmj4iV2A-AY=.399b6c8e-1e2e-44af-a7f3-f9320c353084@github.com>

On Thu, 28 Mar 2024 14:11:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
>> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
>> (The class file format version numbers will need to be updated when re-synching with the mainline).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extr enable preview and test code

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 364:

> 362:                public Set<Location> apply(ClassFileFormatVersion cffv) {
> 363:                    return (cffv.compareTo(ClassFileFormatVersion.RELEASE_2)  >= 0 &&
> 364:                            cffv.compareTo(ClassFileFormatVersion.RELEASE_16) <= 0) ?

I believe we still want to keep the strict field modifier for value class fields.

test/jdk/java/lang/reflect/AccessFlag/VersionedLocationsTest.java line 274:

> 272:                 Set.of(Location.METHOD) :
> 273:                         (cffv.compareTo(ClassFileFormatVersion.RELEASE_22) >= 0)
> 274:                                 ? Set.of(Location.FIELD) : Set.of();

Same remark

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1543350802
PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1543353968


From rriggs at openjdk.org  Thu Mar 28 19:10:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 28 Mar 2024 19:10:41 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v6]
In-Reply-To: <0tFCT5l7QRM-X9PKo3lf0YDWQcnI7kLISmj4iV2A-AY=.399b6c8e-1e2e-44af-a7f3-f9320c353084@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
 <6Y93H65-Wl6C3nB9wlHjFJi9c7GSdioustvjhVpvONY=.2ceb5d8e-73ce-4a39-b43a-dbee3c049331@github.com>
 <0tFCT5l7QRM-X9PKo3lf0YDWQcnI7kLISmj4iV2A-AY=.399b6c8e-1e2e-44af-a7f3-f9320c353084@github.com>
Message-ID: <umzqRNnFmBiB0inOVOAc-fMLxacyduPQdvGqs155ff4=.73cafde7-c892-48d7-adf5-0f92ba466fe6@github.com>

On Thu, 28 Mar 2024 17:19:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove extr enable preview and test code
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 364:
> 
>> 362:                public Set<Location> apply(ClassFileFormatVersion cffv) {
>> 363:                    return (cffv.compareTo(ClassFileFormatVersion.RELEASE_2)  >= 0 &&
>> 364:                            cffv.compareTo(ClassFileFormatVersion.RELEASE_16) <= 0) ?
> 
> I believe we still want to keep the strict field modifier for value class fields.

I dropped it because its not in JEP401 and the feature has not settled yet nor which spec its covered in.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1060#discussion_r1543503085


From rriggs at openjdk.org  Thu Mar 28 20:14:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 28 Mar 2024 20:14:00 GMT
Subject: [lworld] RFR: 8328543: [lworld] Library and test updates to use
 --enable-preview instead of ValhallaFeatures [v7]
In-Reply-To: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
References: <gnVMSDi4JayPFO79HRVaCsE_mc4rjkBd68V32ecGhiA=.e2c894ca-6af8-493d-aa9f-1ad4c92c1203@github.com>
Message-ID: <_9ZgKwZOXn0leo2Ul4UpE0w6OjlQeLX5Un1LdeXj7wk=.e6d76ae2-01c7-487f-a8d4-a50de8786afa@github.com>

> Update AccessFlag and tests to JEP 401 and use of --enable-preview instead of ValhallaFeatures.
> Minor formatting change to java.lang.Character to allow it to be a value class with --enable-preview.
> (The class file format version numbers will need to be updated when re-synching with the mainline).

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

  Preview and non-preview tests cannot be supported by a single test due to compilation of value classes.
  Moved preview support for access flags to a new test (ClassAccessFlagPreviewTest) to be run only with --enable-preview.
  Reverted all changes to ClassAccessFlagTest and will only run when not --enable-preview.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1060/files
  - new: https://git.openjdk.org/valhalla/pull/1060/files/98860d94..c3fb4d85

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

  Stats: 68 lines in 2 files changed: 8 ins; 42 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/1060.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1060/head:pull/1060

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


From vromero at openjdk.org  Fri Mar 29 16:31:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Mar 2024 16:31:57 GMT
Subject: [lworld] Integrated: 8329327: [lworld] refactoring ignored tests
Message-ID: <3kpWUKXhgESaLpjgIy8-u-dCEUaFVzT3TGGpbHvU7vk=.3c14b565-cb11-4097-8947-49a47ca0dd6e@github.com>

some regression tests had been ignored due to verifier errors as the VM was adapting to the latest changes in the class file for JEP 401. Those tests need to be re-enabled and in some cases adapted to the latest JLS for JEP 401

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

Commit messages:
 - 8329327: [lworld] refactoring ignored tests

Changes: https://git.openjdk.org/valhalla/pull/1067/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1067&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329327
  Stats: 903 lines in 10 files changed: 12 ins; 863 del; 28 mod
  Patch: https://git.openjdk.org/valhalla/pull/1067.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1067/head:pull/1067

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


From vromero at openjdk.org  Fri Mar 29 16:31:57 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Mar 2024 16:31:57 GMT
Subject: [lworld] Integrated: 8329327: [lworld] refactoring ignored tests
In-Reply-To: <3kpWUKXhgESaLpjgIy8-u-dCEUaFVzT3TGGpbHvU7vk=.3c14b565-cb11-4097-8947-49a47ca0dd6e@github.com>
References: <3kpWUKXhgESaLpjgIy8-u-dCEUaFVzT3TGGpbHvU7vk=.3c14b565-cb11-4097-8947-49a47ca0dd6e@github.com>
Message-ID: <UxCurSs_U5LOiA3aeAKu6jaJlaMY8T9Jjen-JFM5SSk=.617d57d1-064e-44b4-9358-c7bb364afc43@github.com>

On Fri, 29 Mar 2024 16:26:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> some regression tests had been ignored due to verifier errors as the VM was adapting to the latest changes in the class file for JEP 401. Those tests need to be re-enabled and in some cases adapted to the latest JLS for JEP 401

This pull request has now been integrated.

Changeset: 6f919269
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6f919269c9034750c418222cb3bf292585014aa7
Stats:     903 lines in 10 files changed: 12 ins; 863 del; 28 mod

8329327: [lworld] refactoring ignored tests

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

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


From fparain at openjdk.org  Fri Mar 29 18:36:47 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 29 Mar 2024 18:36:47 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes [v2]
In-Reply-To: <Z2Qqe-mhgII9F4uDjHqTSGOe_zZXITzCzWrIFNW5fDs=.fecb32c7-de0d-48b4-aff6-8337f32a9663@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
 <Z2Qqe-mhgII9F4uDjHqTSGOe_zZXITzCzWrIFNW5fDs=.fecb32c7-de0d-48b4-aff6-8337f32a9663@github.com>
Message-ID: <UEJYlNsYooFA_gSFHk4IptzYwj6IlzUNeYc3Q42dnjg=.09745497-09a9-4def-9c3d-f48c976a0e4f@github.com>

On Wed, 27 Mar 2024 17:11:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
>> 
>> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
>> 
>> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
>> 
>> [4] Tests with all CDS tests and tiers 1-4.
>> 
>> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo

Marked as reviewed by fparain (Committer).

Looks good to me, thank you for fixing CDS.

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

PR Review: https://git.openjdk.org/valhalla/pull/1063#pullrequestreview-1969321336
PR Comment: https://git.openjdk.org/valhalla/pull/1063#issuecomment-2027585386


From vromero at openjdk.org  Fri Mar 29 21:41:05 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Mar 2024 21:41:05 GMT
Subject: [lworld] RFR: 8329345: [lworld] type of expression in a synchronized
 statement can be an abstract value class
Message-ID: <qd9f9SXBFUj9oSNeCqOwnCn9QMIlXfBa0ol7vdYCa_Y=.f967e2bf-c819-4799-94e4-b66248327a6c@github.com>

14.19 The synchronized Statement of the JLS for 401 [1] states:


SynchronizedStatement:
    synchronized ( Expression ) Block

The type of Expression must be a reference type, and must not be a final value class type, or a type variable or intersection type bounded by a final value class type, or a compile-time error occurs.

javac is not allowing value classes even if they are abstract, javac should be in sync with the latest spec

[1] https://cr.openjdk.org/~dlsmith/jep401/jep401-20240222/specs/value-objects-jls.html

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

Commit messages:
 - 8329345: [lworld] type of expression in a synchronized statement can be an abstract value class

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

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


From vromero at openjdk.org  Fri Mar 29 21:51:48 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 29 Mar 2024 21:51:48 GMT
Subject: [lworld] Integrated: 8329345: [lworld] type of expression in a
 synchronized statement can be an abstract value class
In-Reply-To: <qd9f9SXBFUj9oSNeCqOwnCn9QMIlXfBa0ol7vdYCa_Y=.f967e2bf-c819-4799-94e4-b66248327a6c@github.com>
References: <qd9f9SXBFUj9oSNeCqOwnCn9QMIlXfBa0ol7vdYCa_Y=.f967e2bf-c819-4799-94e4-b66248327a6c@github.com>
Message-ID: <oW7T36O_5-8EGaVqElxYVxM5slczUnW1CBSotIk2RvE=.59a08ad1-372e-4366-a11c-6eba4ec10455@github.com>

On Fri, 29 Mar 2024 21:36:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> 14.19 The synchronized Statement of the JLS for 401 [1] states:
> 
> 
> SynchronizedStatement:
>     synchronized ( Expression ) Block
> 
> The type of Expression must be a reference type, and must not be a final value class type, or a type variable or intersection type bounded by a final value class type, or a compile-time error occurs.
> 
> javac is not allowing value classes even if they are abstract, javac should be in sync with the latest spec
> 
> [1] https://cr.openjdk.org/~dlsmith/jep401/jep401-20240222/specs/value-objects-jls.html

This pull request has now been integrated.

Changeset: ef6bdcc2
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ef6bdcc2f3726ec738dedabb5423aa44c4bc7e4e
Stats:     4 lines in 2 files changed: 2 ins; 0 del; 2 mod

8329345: [lworld] type of expression in a synchronized statement can be an abstract value class

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

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


From iklam at openjdk.org  Sat Mar 30 04:38:08 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 30 Mar 2024 04:38:08 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes [v3]
In-Reply-To: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
Message-ID: <WCCXu1bOrySIpTQp0rTeVh0BT3FLy0iRBNRDt_UyxqE=.dd18de93-aa8c-493e-bf3e-df107d4db255@github.com>

> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
> 
> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
> 
> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
> 
> [4] Tests with all CDS tests and tiers 1-4.
> 
> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

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

 - Merge branch 'lworld' into 8304168-cds-tests-fail-with-enable-preview-patched-value-classes
 - fixed typo
 - 8304168: [lworld] CDS tests fail with --enable-preview patched value classes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1063/files
  - new: https://git.openjdk.org/valhalla/pull/1063/files/622eda67..5c09e817

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

  Stats: 3269 lines in 55 files changed: 620 ins; 2411 del; 238 mod
  Patch: https://git.openjdk.org/valhalla/pull/1063.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1063/head:pull/1063

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


From iklam at openjdk.org  Sun Mar 31 01:37:43 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 31 Mar 2024 01:37:43 GMT
Subject: [lworld] RFR: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes [v3]
In-Reply-To: <NaQDjZFEjFSGLoVqSZWgoS6PzEb1ZZNawNbkl31BTfQ=.08c226a1-eeed-40d1-a98d-aceef0009c01@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
 <NaQDjZFEjFSGLoVqSZWgoS6PzEb1ZZNawNbkl31BTfQ=.08c226a1-eeed-40d1-a98d-aceef0009c01@github.com>
Message-ID: <QVqgUbSxMA1691X1NhsqipA_21b1DMClS1N_7pFrFeo=.7bcf29ec-9439-4060-80ec-0874d0b992bd@github.com>

On Tue, 26 Mar 2024 16:55:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into 8304168-cds-tests-fail-with-enable-preview-patched-value-classes
>>  - fixed typo
>>  - 8304168: [lworld] CDS tests fail with --enable-preview patched value classes
>
> This approach is reasonable and simplest to add a new CDS archive which adds a small percentage to the image size.

Thanks @mlchung @fparain for the review.
I tested again with tiers 1-4 and no new failures.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1063#issuecomment-2028521269


From iklam at openjdk.org  Sun Mar 31 01:37:44 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 31 Mar 2024 01:37:44 GMT
Subject: [lworld] Integrated: 8304168: [lworld] CDS tests fail with
 --enable-preview patched value classes
In-Reply-To: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
References: <mS7NX_oY6b0OTxWfTA2hOAwnHNmw5uvJGw2CBsUdaK0=.aff1316b-a47c-47d9-b424-2aba12d87771@github.com>
Message-ID: <iF-bOa_z_lndFYhS9OI9KS8hltNAIbVkV5VD_O6wK6Q=.173ccf62-be54-42d1-8c34-c32a32094377@github.com>

On Tue, 26 Mar 2024 15:51:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [1] Allow `--enable-preview -XX:+EnableValhalla` to be specified when dumping a CDS archive. This allows only the patch modules that are used for the value classes. The user is still forbidden from specifying --patch-module when dumping the CDS archive.
> 
> [2] If a CDS archive was created with `--enable-preview -XX:+EnableValhalla`, then it must also be specified at run time, or else the CDS archive will be ignored.
> 
> [3] Fixed a few bugs with value types. E.g., some metadata objects need to be placed in R/W region.
> 
> [4] Tests with all CDS tests and tiers 1-4.
> 
> [5] Modify Image.gmk to be able to generate default CDS archives for `--enable-preview -XX:+EnableValhalla`, but this is not yet enabled as some non-CDS tests will fail. See [JDK-8329108](https://bugs.openjdk.org/browse/JDK-8329108)

This pull request has now been integrated.

Changeset: 7ea9a235
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7ea9a235e8bbc7787d55d6f1723bee15e711b7ad
Stats:     252 lines in 25 files changed: 149 ins; 23 del; 80 mod

8304168: [lworld] CDS tests fail with --enable-preview patched value classes

Reviewed-by: mchung, fparain

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

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