From dsimms at openjdk.org  Tue Oct  1 07:07:35 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 1 Oct 2024 07:07:35 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <FOHF3_nDQw9ABV0MzGdTt8rjzt5tapa3GELZ_PHkfBU=.04582658-3899-429f-a432-85297155ced3@github.com>

Merge jdk-24+1

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

Commit messages:
 - Version flicks
 - Merge tag 'jdk-24+1' into lworld_merge_jdk_24_1
 - 8026127: Deflater/Inflater documentation incomplete/misleading
 - 8333456: CompactNumberFormat integer parsing fails when string has no suffix
 - 8333743: Change .jcheck/conf branches property to match valid branches
 - 8330182: Start of release updates for JDK 24

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

Changes: https://git.openjdk.org/valhalla/pull/1261/files
  Stats: 2348 lines in 64 files changed: 2141 ins; 66 del; 141 mod
  Patch: https://git.openjdk.org/valhalla/pull/1261.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1261/head:pull/1261

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

From rgiulietti at openjdk.org  Tue Oct  1 08:20:24 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 1 Oct 2024 08:20:24 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16 [v2]
In-Reply-To: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
Message-ID: <dxjOo5mIBd_xeyD77aUaklXrgzBpj7KBHA0c23tzhj0=.8cc288e0-a05d-47ed-8e49-ad43bb6c975b@github.com>

> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.

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

  Revert back experimental remnant of valueOf(String).

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1260/files
  - new: https://git.openjdk.org/valhalla/pull/1260/files/18f09e6c..9b8a57b5

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

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

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

From dsimms at openjdk.org  Tue Oct  1 11:02:08 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 1 Oct 2024 11:02:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <FOHF3_nDQw9ABV0MzGdTt8rjzt5tapa3GELZ_PHkfBU=.04582658-3899-429f-a432-85297155ced3@github.com>
References: <FOHF3_nDQw9ABV0MzGdTt8rjzt5tapa3GELZ_PHkfBU=.04582658-3899-429f-a432-85297155ced3@github.com>
Message-ID: <PMnPKOL1UYh_mZLqibFPVmrtJDUi07c1zXMPvWINcmU=.0f3c0210-faf6-4321-acd8-438ca1835265@github.com>

On Tue, 1 Oct 2024 07:00:41 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-24+1

This pull request has now been integrated.

Changeset: 1ee74c5c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1ee74c5c3ecaca3a6afbf6110430fe459d818cba
Stats:     2348 lines in 64 files changed: 2141 ins; 66 del; 141 mod

Merge jdk

Merge jdk-24+1

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

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

From vromero at openjdk.org  Tue Oct  1 13:22:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 1 Oct 2024 13:22:26 GMT
Subject: [lworld] Integrated: 8341061: [lworld] final field initialization bug
 with instance block initializers
Message-ID: <5-1RLl1KhhfjXbmet9K3bQk02nPbaDUdkDwB39kl3lM=.a7a4b9c9-6198-4acd-8ba2-d55dec20d2c3@github.com>

javac is allowing final fields of a value class to be assigned in an instance initialization block. But those are executed after the `super()` invocation, so code like:

value class V {
    int f;
    {
        f = 1;
    }
}

should be rejected as `f` would be initialized after the implicit `super` invocation

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

Commit messages:
 - 8341061: [lworld] final field initialization bug with instance block initializers

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

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

From vromero at openjdk.org  Tue Oct  1 13:22:26 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 1 Oct 2024 13:22:26 GMT
Subject: [lworld] Integrated: 8341061: [lworld] final field initialization bug
 with instance block initializers
In-Reply-To: <5-1RLl1KhhfjXbmet9K3bQk02nPbaDUdkDwB39kl3lM=.a7a4b9c9-6198-4acd-8ba2-d55dec20d2c3@github.com>
References: <5-1RLl1KhhfjXbmet9K3bQk02nPbaDUdkDwB39kl3lM=.a7a4b9c9-6198-4acd-8ba2-d55dec20d2c3@github.com>
Message-ID: <-CdaneO88cbvCo5Y03wihY5FeNRlUwsqn007HhWdpZA=.85284409-22c5-4ff5-9358-6ede072d510e@github.com>

On Tue, 1 Oct 2024 13:14:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is allowing final fields of a value class to be assigned in an instance initialization block. But those are executed after the `super()` invocation, so code like:
> 
> value class V {
>     int f;
>     {
>         f = 1;
>     }
> }
> 
> should be rejected as `f` would be initialized after the implicit `super` invocation

This pull request has now been integrated.

Changeset: 1c354b82
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1c354b826b7407ea786b67832bd101cf1a278381
Stats:     26 lines in 3 files changed: 14 ins; 1 del; 11 mod

8341061: [lworld] final field initialization bug with instance block initializers

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

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

From darcy at openjdk.org  Tue Oct  1 19:24:50 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 1 Oct 2024 19:24:50 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16 [v2]
In-Reply-To: <dxjOo5mIBd_xeyD77aUaklXrgzBpj7KBHA0c23tzhj0=.8cc288e0-a05d-47ed-8e49-ad43bb6c975b@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
 <dxjOo5mIBd_xeyD77aUaklXrgzBpj7KBHA0c23tzhj0=.8cc288e0-a05d-47ed-8e49-ad43bb6c975b@github.com>
Message-ID: <RCGi87jh6RMB3UvfBNDcPN78_ruNL55TSspgDhsmHqw=.a4f2a104-75d5-4dec-b361-5ccd9b37ca48@github.com>

On Tue, 1 Oct 2024 08:20:24 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert back experimental remnant of valueOf(String).

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

> 212:      * @param   f16   the {@code Float16} to be converted.
> 213:      * @return a string representation of the argument.
> 214:      * @see java.lang.Float#toString(float)

Please also fix/adjust the implSpec portions of the method's javadoc.

src/java.base/share/classes/jdk/internal/math/Float16ToDecimal.java line 124:

> 122: 
> 123:     /**
> 124:      * Returns a string representation of the {@code float}

Nit: "float argument" -> "Float16 argument"

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1260#discussion_r1783371489
PR Review Comment: https://git.openjdk.org/valhalla/pull/1260#discussion_r1783373836

From vromero at openjdk.org  Wed Oct  2 18:59:23 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Oct 2024 18:59:23 GMT
Subject: [lworld] Integrated: 8340984: [lworld] instance variable initializer
 erroneously allows to refer to instance variables, methods, this,
 or super
Message-ID: <UbrTlt0oAUksE-mAmzNAUYtpz25MP5ffKaLAMCGZSss=.679cefbc-72a8-48d9-976d-92371bdb29da@github.com>

environment for variable initializers were not aware of being in a constructor prologue and thus javac is failing to issue errors for incorrect programs

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

Commit messages:
 - 8340984: [lworld] instance variable initializer erroneously allows to refer to instance variables, methods, this, or super

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

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

From vromero at openjdk.org  Wed Oct  2 18:59:24 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 2 Oct 2024 18:59:24 GMT
Subject: [lworld] Integrated: 8340984: [lworld] instance variable initializer
 erroneously allows to refer to instance variables, methods, this,
 or super
In-Reply-To: <UbrTlt0oAUksE-mAmzNAUYtpz25MP5ffKaLAMCGZSss=.679cefbc-72a8-48d9-976d-92371bdb29da@github.com>
References: <UbrTlt0oAUksE-mAmzNAUYtpz25MP5ffKaLAMCGZSss=.679cefbc-72a8-48d9-976d-92371bdb29da@github.com>
Message-ID: <T001pDKv8TFTJY97dVwEU_TwLC8QID4ycasA33dGL1I=.271cd830-a8a7-4c7c-9a18-22d52c4c14e6@github.com>

On Wed, 2 Oct 2024 18:54:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> environment for variable initializers were not aware of being in a constructor prologue and thus javac is failing to issue errors for incorrect programs

This pull request has now been integrated.

Changeset: 640d7897
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/640d7897200799911c917ed08ee55d916fe96eb2
Stats:     94 lines in 4 files changed: 50 ins; 41 del; 3 mod

8340984: [lworld] instance variable initializer erroneously allows to refer to instance variables, methods, this, or super

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

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

From vromero at openjdk.org  Thu Oct  3 02:58:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Oct 2024 02:58:30 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v5]
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <9gLKoUadggy13l44uDUR3Fmiw8Fy2vY1-ZQj7Jpqvrw=.f52a3251-b721-4bde-8e95-b482e7711730@github.com>

> javac is not generating null checks for runtime execution for method invocations and array writes

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

  refactoring

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1251/files
  - new: https://git.openjdk.org/valhalla/pull/1251/files/b9173d8f..6390b492

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

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

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

From vromero at openjdk.org  Thu Oct  3 03:22:10 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Oct 2024 03:22:10 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v6]
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <bsfYttX-q6SVCSaqzMIbaTrNqar_G_lH0Pw5VM9t4oI=.d482ffe7-d739-4e0a-a2da-0c0e4bf24919@github.com>

> javac is not generating null checks for runtime execution for method invocations and array writes

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

  additional refactoring

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1251/files
  - new: https://git.openjdk.org/valhalla/pull/1251/files/6390b492..a23c3630

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

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

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

From vromero at openjdk.org  Thu Oct  3 03:26:28 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Oct 2024 03:26:28 GMT
Subject: RFR: 8340125: [lw5] null checks are not being generated for method
 invocations and array writes [v7]
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <a9JVenPGmysXkaU6e_i4pCSGjBMzRJKtc0m5uEpBdBg=.67396dc8-0464-4ba2-893a-c90842d9ccc4@github.com>

> javac is not generating null checks for runtime execution for method invocations and array writes

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

  refactoring

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1251/files
  - new: https://git.openjdk.org/valhalla/pull/1251/files/a23c3630..334ec9bc

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

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

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

From vromero at openjdk.org  Thu Oct  3 03:58:49 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 3 Oct 2024 03:58:49 GMT
Subject: Integrated: 8340125: [lw5] null checks are not being generated for
 method invocations and array writes
In-Reply-To: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
References: <t4iFWeTxDmjeTw-EmwlptrUkGzbzDJO3qqUfFxnBAuc=.ace1cc5f-9c76-4de4-9e86-5daaa4a3b179@github.com>
Message-ID: <aQ3j6kz04H1KF2g5VaVn3n7OfExF1nD6jDuZPAFnmng=.8e8f04d3-1aa0-42b8-a3e0-61bce8c0d3eb@github.com>

On Tue, 24 Sep 2024 21:13:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is not generating null checks for runtime execution for method invocations and array writes

This pull request has now been integrated.

Changeset: ff277645
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ff2776455fd90ec4c7d744007c0f93b948e977d8
Stats:     336 lines in 6 files changed: 284 ins; 24 del; 28 mod

8340125: [lw5] null checks are not being generated for method invocations and array writes

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

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

From vromero at openjdk.org  Fri Oct  4 01:59:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Oct 2024 01:59:31 GMT
Subject: [lworld] RFR: 8341182: [lworld] test CantAnnotateScoping.java
 fails after merge, due to experimental code for anonymous value classes
In-Reply-To: <3UfipUXfIy6FR6GjOfB21TSY3sIHg2KSNMdNXVAScAE=.7bc3a0b8-6960-42dd-a3e4-44675f42d769@github.com>
References: <3UfipUXfIy6FR6GjOfB21TSY3sIHg2KSNMdNXVAScAE=.7bc3a0b8-6960-42dd-a3e4-44675f42d769@github.com>
Message-ID: <vTM2wtV2YNO8X5A3ye3Hvc2Cxic1pltj4Jcp9D3MQxo=.09c5419c-ff5c-4d60-965b-704bebee10f5@github.com>

On Fri, 4 Oct 2024 01:52:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> there was experimental code in lworld to allow anonymous value classes, after removing this code the test passed again

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2567:

> 2565:      */
> 2566:     JCExpression creator(int newpos, List<JCExpression> typeArgs) {
> 2567:         final JCModifiers mods = modifiersOpt();

this code was here to allow programs like:


Object o = new value Comparable<>() {
    @Override
    public int compareTo(Object o) {
        return 0;
    }
};


modifiersOpt() interprets all annotations as declaration annotations, even type annotations, this produced a different golden file for the test

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1264#discussion_r1787018616

From vromero at openjdk.org  Fri Oct  4 02:04:48 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Oct 2024 02:04:48 GMT
Subject: [lworld] Integrated: 8341182: [lworld] test CantAnnotateScoping.java
 fails after merge,
 due to experimental code for anonymous value classes
In-Reply-To: <3UfipUXfIy6FR6GjOfB21TSY3sIHg2KSNMdNXVAScAE=.7bc3a0b8-6960-42dd-a3e4-44675f42d769@github.com>
References: <3UfipUXfIy6FR6GjOfB21TSY3sIHg2KSNMdNXVAScAE=.7bc3a0b8-6960-42dd-a3e4-44675f42d769@github.com>
Message-ID: <S5sdILTb_3HXOWvzMpnjcm_c3oov37toTdY6fNkmBtc=.ca75dcd1-5579-4118-ab3b-2bfc5104bf82@github.com>

On Fri, 4 Oct 2024 01:52:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> there was experimental code in lworld to allow anonymous value classes, after removing this code the test passed again

This pull request has now been integrated.

Changeset: 4a37d360
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4a37d3608f9d7a13d2704c9323a8d383c8977f4e
Stats:     52 lines in 3 files changed: 1 ins; 44 del; 7 mod

8341182: [lworld] test CantAnnotateScoping.java fails after merge, due to experimental code for anonymous value classes

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

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

From vromero at openjdk.org  Fri Oct  4 01:59:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Oct 2024 01:59:31 GMT
Subject: [lworld] RFR: 8341182: [lworld] test CantAnnotateScoping.java fails
 after merge, due to experimental code for anonymous value classes
Message-ID: <3UfipUXfIy6FR6GjOfB21TSY3sIHg2KSNMdNXVAScAE=.7bc3a0b8-6960-42dd-a3e4-44675f42d769@github.com>

there was experimental code in lworld to allow anonymous value classes, after removing this code the test passed again

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

Commit messages:
 - 8341182: [lworld] test CantAnnotateScoping.java fails after merge, due to experimental code for anonymous value classes

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

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

From rgiulietti at openjdk.org  Fri Oct  4 14:47:25 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 14:47:25 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16 [v3]
In-Reply-To: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
Message-ID: <G-GgsSO5gxhnfvElSRfwlLd9-yV6tU-nv86HscUneWw=.a4fdfedf-7e36-4334-9ba8-1e5ec56f382e@github.com>

> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.

Raffaello Giulietti 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/1260/files
  - new: https://git.openjdk.org/valhalla/pull/1260/files/9b8a57b5..f2dc5685

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

  Stats: 150 lines in 5 files changed: 126 ins; 2 del; 22 mod
  Patch: https://git.openjdk.org/valhalla/pull/1260.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1260/head:pull/1260

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

From rgiulietti at openjdk.org  Fri Oct  4 15:48:05 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 15:48:05 GMT
Subject: [lworld+fp16] RFR: 8341368: Refactor to use nextUp/nextDown and scalb
 in Float16 impl. and tests
Message-ID: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>

Make use of `Float16.nextUp()`, `Float16.nextDown()`, `Float16.scalb()` in tests and code.

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

Commit messages:
 - 8341368: Refactor to use nextUp/nextDown and scalb in Float16 impl. and tests

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

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

From vromero at openjdk.org  Fri Oct  4 15:48:18 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Oct 2024 15:48:18 GMT
Subject: [lworld] RFR: 8341180: [lworld] Some classfile tests failing on
 LoadableDescriptorsAttribute after merge jdk-23+26 and jdk-23+27
Message-ID: <6v4aQrRwEj_oHUFfBzRLOycQV1IflLpDZd9KaHzl2Oc=.6e09116d-75ba-4287-aecf-cac649e6058f@github.com>

class `jdk.internal.classfile.impl.verifier.ParserVerifier` is failing with an assertion error as it doesn't know about `LoadableDescriptorsAttribute` which is specific to valhalla

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

Commit messages:
 - adding copyright year
 - 8341180: [lworld] Some classfile tests failing on LoadableDescriptorsAttribute after merge jdk-23+26 and jdk-23+27

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

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

From vromero at openjdk.org  Fri Oct  4 16:03:51 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 4 Oct 2024 16:03:51 GMT
Subject: [lworld] Integrated: 8341180: [lworld] Some classfile tests failing on
 LoadableDescriptorsAttribute after merge jdk-23+26 and jdk-23+27
In-Reply-To: <6v4aQrRwEj_oHUFfBzRLOycQV1IflLpDZd9KaHzl2Oc=.6e09116d-75ba-4287-aecf-cac649e6058f@github.com>
References: <6v4aQrRwEj_oHUFfBzRLOycQV1IflLpDZd9KaHzl2Oc=.6e09116d-75ba-4287-aecf-cac649e6058f@github.com>
Message-ID: <8Fh6H896Vy00TsIXI8b1ObpZfXcUfKNJxqvf1q5vMNI=.d5543fb5-fcc5-410b-8203-a6de62d20e7f@github.com>

On Fri, 4 Oct 2024 15:43:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> class `jdk.internal.classfile.impl.verifier.ParserVerifier` is failing with an assertion error as it doesn't know about `LoadableDescriptorsAttribute` which is specific to valhalla

This pull request has now been integrated.

Changeset: 6f8c3fc2
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6f8c3fc278597203ce66fa3f743099d9786e57f9
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8341180: [lworld] Some classfile tests failing on LoadableDescriptorsAttribute after merge jdk-23+26 and jdk-23+27

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

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

From darcy at openjdk.org  Fri Oct  4 17:07:52 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 4 Oct 2024 17:07:52 GMT
Subject: [lworld+fp16] RFR: 8341368: Refactor to use nextUp/nextDown and
 scalb in Float16 impl. and tests
In-Reply-To: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>
References: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>
Message-ID: <WTQPOlePPYj92Zl_HxuJdVKOTMdCCfIELB4MwEyGSjk=.33929796-6c5d-458c-86f5-e8f8cca2d63c@github.com>

On Fri, 4 Oct 2024 15:42:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of `Float16.nextUp()`, `Float16.nextDown()`, `Float16.scalb()` in tests and code.

Marked as reviewed by darcy (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1265#pullrequestreview-2348595138

From duke at openjdk.org  Fri Oct  4 22:52:50 2024
From: duke at openjdk.org (duke)
Date: Fri, 4 Oct 2024 22:52:50 GMT
Subject: [lworld+fp16] RFR: 8341368: Refactor to use nextUp/nextDown and
 scalb in Float16 impl. and tests
In-Reply-To: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>
References: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>
Message-ID: <NqI4rAZ51jaXv232paBQimXTdbscPWwxDIgBJy0mwzM=.30da7e27-7f46-43f6-8aa2-13dceb65e864@github.com>

On Fri, 4 Oct 2024 15:42:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of `Float16.nextUp()`, `Float16.nextDown()`, `Float16.scalb()` in tests and code.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1265#issuecomment-2394763326

From rgiulietti at openjdk.org  Fri Oct  4 23:56:48 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 4 Oct 2024 23:56:48 GMT
Subject: [lworld+fp16] Integrated: 8341368: Refactor to use nextUp/nextDown and
 scalb in Float16 impl. and tests
In-Reply-To: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>
References: <JJ2qegBXhmwrLd4fkd3AT9EHXi0dWJTGe7b2_S9xYjU=.da20df9d-b8eb-41ca-b888-53be080dd1b3@github.com>
Message-ID: <dUs073qm056_wlx7F5bpZRF1G7yk0Fbk6N3J-ML541U=.24a54ffd-64ac-4031-93fc-f02904be757e@github.com>

On Fri, 4 Oct 2024 15:42:19 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Make use of `Float16.nextUp()`, `Float16.nextDown()`, `Float16.scalb()` in tests and code.

This pull request has now been integrated.

Changeset: dd5d236f
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dd5d236ffcbe173e20135658df4f554a22dca77f
Stats:     27 lines in 2 files changed: 0 ins; 16 del; 11 mod

8341368: Refactor to use nextUp/nextDown and scalb in Float16 impl. and tests

Reviewed-by: darcy

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

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

From dsimms at openjdk.org  Mon Oct  7 09:04:44 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 7 Oct 2024 09:04:44 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <HgdL0vQl0RMDKUIwa3y8jO7_WSNyJieoTBEX5gWcqSY=.6b744df9-476e-418d-a843-39084e0bf493@github.com>

Merge tag 'jdk-24+2' into lworld_merge_jdk_24_2
Added tag jdk-24+2 for changeset 301bd708

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

Commit messages:
 - Merge tag 'jdk-24+2' into lworld_merge_jdk_24_2
 - 8311110: multichar warning in WinAccessBridge.cpp
 - 8322064: Remove expired flags in JDK 24
 - 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump
 - 8209092: Remove outdated wording from RC5ParameterSpec
 - 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup
 - 8332139: SymbolTableHash::Node allocations allocates twice the required memory
 - 8319457: Update jpackage to support WiX v4 and v5 on Windows
 - 8321308: AArch64: Fix matching predication for cbz/cbnz
 - 8333382: [s390x] Enhance popcnt Instruction to use Z15 facilities
 - ... and 64 more: https://git.openjdk.org/valhalla/compare/6f8c3fc2...b344243c

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

Changes: https://git.openjdk.org/valhalla/pull/1267/files
  Stats: 18904 lines in 550 files changed: 9828 ins; 7486 del; 1590 mod
  Patch: https://git.openjdk.org/valhalla/pull/1267.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1267/head:pull/1267

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

From dsimms at openjdk.org  Mon Oct  7 11:16:48 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 7 Oct 2024 11:16:48 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <HgdL0vQl0RMDKUIwa3y8jO7_WSNyJieoTBEX5gWcqSY=.6b744df9-476e-418d-a843-39084e0bf493@github.com>
References: <HgdL0vQl0RMDKUIwa3y8jO7_WSNyJieoTBEX5gWcqSY=.6b744df9-476e-418d-a843-39084e0bf493@github.com>
Message-ID: <oXz2m1DAI10rXmMEdST1T3lrBOZvA7hghqClohhJ3Jk=.1a3c3fce-be6b-4dfb-b46e-dca829759719@github.com>

On Mon, 7 Oct 2024 08:58:18 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-24+2' into lworld_merge_jdk_24_2
> Added tag jdk-24+2 for changeset 301bd708

This pull request has now been integrated.

Changeset: b2e26916
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b2e26916bbfc8b6fc604f3cd3d2bd2deb85d7e43
Stats:     18904 lines in 550 files changed: 9828 ins; 7486 del; 1590 mod

Merge jdk

Merge jdk-24+2

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

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

From rgiulietti at openjdk.org  Mon Oct  7 13:27:06 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 7 Oct 2024 13:27:06 GMT
Subject: [lworld+fp16] RFR: 8341639: Add float16ToShortBits(), signum(),
 copySign() to Float16
Message-ID: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>

These common operations are currently lacking for Float16, and should be added.

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

Commit messages:
 - 8341639: Add float16ToShortBits(), signum(), copySign() to Float16

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

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

From darcy at openjdk.org  Mon Oct  7 16:29:53 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 7 Oct 2024 16:29:53 GMT
Subject: [lworld+fp16] RFR: 8341639: Add float16ToShortBits(), signum(),
 copySign() to Float16
In-Reply-To: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>
References: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>
Message-ID: <ZYr9qqo7VhfmFwmcLGRBWtAY4Z3cNFCXews338I0EkI=.ed201efa-f607-4b4d-95a9-60c8a4f3971c@github.com>

On Mon, 7 Oct 2024 13:21:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> These common operations are currently lacking for Float16, and should be added.

New API looks fine.

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

Marked as reviewed by darcy (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1268#pullrequestreview-2352434021

From duke at openjdk.org  Mon Oct  7 17:01:49 2024
From: duke at openjdk.org (duke)
Date: Mon, 7 Oct 2024 17:01:49 GMT
Subject: [lworld+fp16] RFR: 8341639: Add float16ToShortBits(), signum(),
 copySign() to Float16
In-Reply-To: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>
References: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>
Message-ID: <cRM7IWckj1Ej8ohsHw0cJ98MYMAWX9xuhMAmm61XpU0=.f66cc6af-c84c-48c8-99b5-db2c7dff52f2@github.com>

On Mon, 7 Oct 2024 13:21:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> These common operations are currently lacking for Float16, and should be added.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1268#issuecomment-2397446741

From rgiulietti at openjdk.org  Mon Oct  7 17:08:50 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 7 Oct 2024 17:08:50 GMT
Subject: [lworld+fp16] Integrated: 8341639: Add float16ToShortBits(), signum(),
 copySign() to Float16
In-Reply-To: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>
References: <JYIscRH6-v_GPHSTXabrw4vQemypT8OYDzm7j3qsIVk=.b94ce194-2974-4c93-a46b-8fe28a7c2780@github.com>
Message-ID: <_bqWlYtsZs0VrZNO7nFR85jdEItlPRDniS7p6zEZ1V8=.149db430-3c48-4ee3-a24d-b7561c51a4d0@github.com>

On Mon, 7 Oct 2024 13:21:13 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> These common operations are currently lacking for Float16, and should be added.

This pull request has now been integrated.

Changeset: 2e1ced6d
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2e1ced6d6fcb3f8b37ccd0be5e3c05eb7fcfc6be
Stats:     178 lines in 3 files changed: 174 ins; 3 del; 1 mod

8341639: Add float16ToShortBits(), signum(), copySign() to Float16

Reviewed-by: darcy

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

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

From vromero at openjdk.org  Mon Oct  7 17:49:56 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Oct 2024 17:49:56 GMT
Subject: [lworld] Integrated: 8341657: [lworld] some valhalla tests are failing
 after fix for JDK-8341182
Message-ID: <KaHSf7j1aqBiHhpzOndDKGlipZ2jXcxNhSauIBJ3C-E=.fa72f50f-5e36-4362-be13-b4a433a88d80@github.com>

removing anonymous classes related code and tests

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

Commit messages:
 - 8341657: [lworld] some valhalla tests are failing after fix for JDK-8341182

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

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

From vromero at openjdk.org  Mon Oct  7 17:49:56 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 7 Oct 2024 17:49:56 GMT
Subject: [lworld] Integrated: 8341657: [lworld] some valhalla tests are failing
 after fix for JDK-8341182
In-Reply-To: <KaHSf7j1aqBiHhpzOndDKGlipZ2jXcxNhSauIBJ3C-E=.fa72f50f-5e36-4362-be13-b4a433a88d80@github.com>
References: <KaHSf7j1aqBiHhpzOndDKGlipZ2jXcxNhSauIBJ3C-E=.fa72f50f-5e36-4362-be13-b4a433a88d80@github.com>
Message-ID: <qg040527Uj-DD-NDMq54XYqNaLsBIJMlUosldPZfXEg=.59091168-82c1-46a6-b7f6-385d80579911@github.com>

On Mon, 7 Oct 2024 17:44:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> removing anonymous classes related code and tests

This pull request has now been integrated.

Changeset: 9553af79
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9553af79f04e872dbcde96f0db4c5d09b5e4b295
Stats:     19 lines in 1 file changed: 0 ins; 19 del; 0 mod

8341657: [lworld] some valhalla tests are failing after fix for JDK-8341182

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

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

From rriggs at openjdk.org  Tue Oct  8 19:34:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 8 Oct 2024 19:34:00 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v2]
In-Reply-To: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
Message-ID: <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>

> Serialization and deerialization of value classes. 
> For java.base value classes migrated from identity classes:
>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>   - Must have a constructor or static factory method:
>     - annotated with jdk.internal.value.DeserializeConstrucctor
>     - constructor parameters must match order and types of serializable fields of the class
>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>   - Migrated value classes are serialized using the same format/fields as the identity class
> 
> Non-migrated value classes throw InvalidClassException
> 
> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
> 
> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'lworld' into 8340409-simple-value-deserialize
 - Merge branch 'lworld' into 8340409-simple-value-deserialize
 - 8340409: [lworld] Simple serialization and deserialization of core migrated classes
   
   Serialization and deerialization of value classes.
   For java.base value classes being migrated from identity classes:
     - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
     - Must have a constructor or static factory method:
       - annotated with jdk.internal.value.DeserializeConstrucctor
       - constructor parameters must match order and types of serializable fields of the class
     - Value class must not have superclass with fields; only Object or abstract w/o fields
     - Uses same technique as for Records to extract and concat values from stream to invoke constructor
     - Migrated value classes are serialized using the same format/fields as the identity class
   
   Non-migrated value classes throw InvalidClassException
   
   Along the way, refactored code to break out different modes of deserialization:
   full custom deserialization with custom data, default deserialization only,
   externalizable, no local class, record, and then added mode to deserialize a value class.
   
   Updates to value class tests and added a combo test to check many combinations
   of value and identity classes with different parameters.

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

Changes: https://git.openjdk.org/valhalla/pull/1248/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1248&range=01
  Stats: 3169 lines in 21 files changed: 2584 ins; 423 del; 162 mod
  Patch: https://git.openjdk.org/valhalla/pull/1248.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1248/head:pull/1248

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

From vklang at openjdk.org  Tue Oct  8 21:20:11 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Oct 2024 21:20:11 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v2]
In-Reply-To: <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
 <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>
Message-ID: <RUUSOD2KE652fk9GRTgJEf-OKinPyNRec18dMFmgJW0=.f6f4f924-7b59-4249-9700-dbaec54841a8@github.com>

On Tue, 8 Oct 2024 19:34:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Serialization and deerialization of value classes. 
>> For java.base value classes migrated from identity classes:
>>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>>   - Must have a constructor or static factory method:
>>     - annotated with jdk.internal.value.DeserializeConstrucctor
>>     - constructor parameters must match order and types of serializable fields of the class
>>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>>   - Migrated value classes are serialized using the same format/fields as the identity class
>> 
>> Non-migrated value classes throw InvalidClassException
>> 
>> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
>> 
>> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'lworld' into 8340409-simple-value-deserialize
>  - Merge branch 'lworld' into 8340409-simple-value-deserialize
>  - 8340409: [lworld] Simple serialization and deserialization of core migrated classes
>    
>    Serialization and deerialization of value classes.
>    For java.base value classes being migrated from identity classes:
>      - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>      - Must have a constructor or static factory method:
>        - annotated with jdk.internal.value.DeserializeConstrucctor
>        - constructor parameters must match order and types of serializable fields of the class
>      - Value class must not have superclass with fields; only Object or abstract w/o fields
>      - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>      - Migrated value classes are serialized using the same format/fields as the identity class
>    
>    Non-migrated value classes throw InvalidClassException
>    
>    Along the way, refactored code to break out different modes of deserialization:
>    full custom deserialization with custom data, default deserialization only,
>    externalizable, no local class, record, and then added mode to deserialize a value class.
>    
>    Updates to value class tests and added a combo test to check many combinations
>    of value and identity classes with different parameters.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 1591:

> 1589:                         return null;
> 1590:                     }})
> 1591:                 .filter(m -> matchFactoryParamTypes(clazz, m, fields))

`m` can be null here, so `matchFactoryParamTypes` needs to check that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1248#discussion_r1792519912

From vklang at openjdk.org  Tue Oct  8 21:23:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Oct 2024 21:23:16 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v2]
In-Reply-To: <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
 <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>
Message-ID: <L6Podc7d02bx739f-K9ZIKSx_geDM6qaFCuCrd4wWpg=.ae587d26-30a1-4022-a33c-49f62c3e9e97@github.com>

On Tue, 8 Oct 2024 19:34:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Serialization and deerialization of value classes. 
>> For java.base value classes migrated from identity classes:
>>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>>   - Must have a constructor or static factory method:
>>     - annotated with jdk.internal.value.DeserializeConstrucctor
>>     - constructor parameters must match order and types of serializable fields of the class
>>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>>   - Migrated value classes are serialized using the same format/fields as the identity class
>> 
>> Non-migrated value classes throw InvalidClassException
>> 
>> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
>> 
>> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'lworld' into 8340409-simple-value-deserialize
>  - Merge branch 'lworld' into 8340409-simple-value-deserialize
>  - 8340409: [lworld] Simple serialization and deserialization of core migrated classes
>    
>    Serialization and deerialization of value classes.
>    For java.base value classes being migrated from identity classes:
>      - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>      - Must have a constructor or static factory method:
>        - annotated with jdk.internal.value.DeserializeConstrucctor
>        - constructor parameters must match order and types of serializable fields of the class
>      - Value class must not have superclass with fields; only Object or abstract w/o fields
>      - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>      - Migrated value classes are serialized using the same format/fields as the identity class
>    
>    Non-migrated value classes throw InvalidClassException
>    
>    Along the way, refactored code to break out different modes of deserialization:
>    full custom deserialization with custom data, default deserialization only,
>    externalizable, no local class, record, and then added mode to deserialize a value class.
>    
>    Updates to value class tests and added a combo test to check many combinations
>    of value and identity classes with different parameters.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 1894:

> 1892: 
> 1893:         int argIndex = 0;
> 1894:         for (int i = 0; i < clFields.length; i++) {

Suggestion:

        for (int i = 0, argIndex = 0; i < clFields.length; i++) {

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1248#discussion_r1792525148

From amenkov at openjdk.org  Wed Oct  9 00:44:07 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 9 Oct 2024 00:44:07 GMT
Subject: [lworld] RFR: 8341802: Add test coverage for JVMTI function with value
 classes
Message-ID: <XbHDBK9sEsLQXFhBShbM3K_95tuW8tGXowkhMIk1po0=.d8a33fc2-9bbd-4155-952b-30824f75d49b@github.com>

Added sanity tests for JVMTI sunctions

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

Commit messages:
 - JVMTI sanity tests

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

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

From amenkov at openjdk.org  Wed Oct  9 01:14:28 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 9 Oct 2024 01:14:28 GMT
Subject: [lworld] Integrated: 8341802: Add test coverage for JVMTI function
 with value classes
In-Reply-To: <XbHDBK9sEsLQXFhBShbM3K_95tuW8tGXowkhMIk1po0=.d8a33fc2-9bbd-4155-952b-30824f75d49b@github.com>
References: <XbHDBK9sEsLQXFhBShbM3K_95tuW8tGXowkhMIk1po0=.d8a33fc2-9bbd-4155-952b-30824f75d49b@github.com>
Message-ID: <DFrrvPrMF8r6lGUJxuMeY3T9_EhYvh6LmWkgPU-L1qc=.5e5435d8-de84-412e-acf1-60be9da00262@github.com>

On Wed, 9 Oct 2024 00:38:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Added sanity tests for JVMTI sunctions

This pull request has now been integrated.

Changeset: 1a935cb8
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1a935cb893d3af9a5cb24f85c3ab2fe7b7fa7d17
Stats:     959 lines in 10 files changed: 959 ins; 0 del; 0 mod

8341802: Add test coverage for JVMTI function with value classes

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

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

From chagedorn at openjdk.org  Wed Oct  9 12:41:52 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 9 Oct 2024 12:41:52 GMT
Subject: [lworld] RFR: 8315003: [lworld] C2: Implement full support for
 JDK-8287061 and JDK-8316991
Message-ID: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>

This patch makes the improved allocation merge at EA work with inline types.

Before this patch, the assumption was that we do **not** have non-scalarized inline types at safepoints which EA is going to scalarize (and if we do, then there is a missed opportunity which can be considered a bug). We should have pushed all `InlineTypeNodes` down through phis in order to have them scalarized before EA.

This, however, changes with the improved allocation merge RFEs that have been merged into Valhalla ([JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) and [JDK-8316991](https://bugs.openjdk.org/browse/JDK-8316991)). We could now the following graph as found in the test case:

![image](https://github.com/user-attachments/assets/4e5174d3-9a52-4c43-8dcd-b6a119438ca0)

Here, `272 Phi` merges the non-value type allocation `238 CheckCastPP` with the value type allocation `217 InlineType`. Before the improved allocation merge RFEs, we would not be able to remove the allocations. But now, we can do it at EA: We create a special `SafePointScalarMergeNode` which in case has `SafePointScalarObjectNodes` as inputs for the merged allocations. Additionally, each field of the merged allocations are added to the safepoint, which also includes the value type field `v2` of `V`:

![image](https://github.com/user-attachments/assets/eb8e7012-262d-492f-ae30-a3962f5ae931)

We should not have safepoint uses for `InlineType` and thus now replace them with `SafePointScalarObjectNodes` as well (newly done with this patch). As a result, we have the following graph after EA:

![image](https://github.com/user-attachments/assets/0cf521c4-dee1-4cb7-bb7c-3479b459ed34)

Note that the safepoint node inputs for fields are well-defined to keep track of which field belong to each of the `SafePointScalarObjectNodes` of the `SafePointScalarMergeNode`.


### Additional Code Changes
- There was a bug in mainline with the new allocation merge implementation that is already fixed in mainline but not integrated in Valhalla, yet: [JDK-8335220](https://bugs.openjdk.org/browse/JDK-8335220). I cherry-picked these changes (L589-605 in escape.cpp).
- I added assertion code to verify that when we are going to scalar replace an inline type allocation that is an input into a phi at EA, we would not have been able to push the `InlineTypeNode` down (which should have been done earlier if possible).
- Re-enabled uncommented tests and removed problem-listed `AllocationMergesTests.java` that had been added with the allocation merge RFE.

### Future Work
There is currently an open bug for the allocation merges ([JDK-8335977](https://bugs.openjdk.org/browse/JDK-8335977)) which has been found by extending `AllocationMergesTests.java` with various deoptimization points and checking for correct values (similar to what we do in `TestValueConstruction.java`). Once this bug is fixed in mainline (it should extend this test and add these deoptimization checks), we should extend `AllocationMergesTests.java` and add tests for value types as well. I filed [JDK-8341856](https://bugs.openjdk.org/browse/JDK-8341856) to keep track of that.

Thanks,
Christian

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

Commit messages:
 - 8315003: [lworld] C2: Implement full support for JDK-8287061 and JDK-8316991

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

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

From chagedorn at openjdk.org  Wed Oct  9 12:41:52 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 9 Oct 2024 12:41:52 GMT
Subject: [lworld] RFR: 8315003: [lworld] C2: Implement full support for
 JDK-8287061 and JDK-8316991
In-Reply-To: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
References: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
Message-ID: <017FvNKAcrMwhH15mhfhx9egn9gXtHcB7qC8qTszymQ=.0fe0549b-1b8b-493a-a01a-807324596ed9@github.com>

On Wed, 9 Oct 2024 12:27:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch makes the improved allocation merge at EA work with inline types.
> 
> Before this patch, the assumption was that we do **not** have non-scalarized inline types at safepoints which EA is going to scalarize (and if we do, then there is a missed opportunity which can be considered a bug). We should have pushed all `InlineTypeNodes` down through phis in order to have them scalarized before EA.
> 
> This, however, changes with the improved allocation merge RFEs that have been merged into Valhalla ([JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) and [JDK-8316991](https://bugs.openjdk.org/browse/JDK-8316991)). We could now the following graph as found in the test case:
> 
> ![image](https://github.com/user-attachments/assets/4e5174d3-9a52-4c43-8dcd-b6a119438ca0)
> 
> Here, `272 Phi` merges the non-value type allocation `238 CheckCastPP` with the value type allocation `217 InlineType`. Before the improved allocation merge RFEs, we would not be able to remove the allocations. But now, we can do it at EA: We create a special `SafePointScalarMergeNode` which in case has `SafePointScalarObjectNodes` as inputs for the merged allocations. Additionally, each field of the merged allocations are added to the safepoint, which also includes the value type field `v2` of `V`:
> 
> ![image](https://github.com/user-attachments/assets/eb8e7012-262d-492f-ae30-a3962f5ae931)
> 
> We should not have safepoint uses for `InlineType` and thus now replace them with `SafePointScalarObjectNodes` as well (newly done with this patch). As a result, we have the following graph after EA:
> 
> ![image](https://github.com/user-attachments/assets/0cf521c4-dee1-4cb7-bb7c-3479b459ed34)
> 
> Note that the safepoint node inputs for fields are well-defined to keep track of which field belong to each of the `SafePointScalarObjectNodes` of the `SafePointScalarMergeNode`.
> 
> 
> ### Additional Code Changes
> - There was a bug in mainline with the new allocation merge implementation that is already fixed in mainline but not integrated in Valhalla, yet: [JDK-8335220](https://bugs.openjdk.org/browse/JDK-8335220). I cherry-picked these changes (L589-605 in escape.cpp).
> - I added assertion code to verify that when we are going to scalar replace an inline type allocation that is an input into a phi at EA, we would not have been able to push the `InlineTypeNode` down (which should have been done earlier if possible).
> - Re-enabled uncommented tests and removed problem-listed `AllocationMergesTests.java` that had been added with ...

src/hotspot/share/opto/escape.cpp line 605:

> 603:             }
> 604: #endif
> 605:             return false;

cherry-picked mainline fix

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1271#discussion_r1793431648

From dsimms at openjdk.org  Wed Oct  9 14:06:01 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 9 Oct 2024 14:06:01 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>

Merge jdk-24+3

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

Commit messages:
 - Classfile API changes
 - Adjust testing for generational zgc
 - Merge tag 'jdk-24+3' into lworld_merge_jdk_24_3
 - 8334026: Provide a diagnostic PrintMemoryMapAtExit switch on Linux
 - 8334164: The fix for JDK-8322811 should use _filename.is_set() rather than strcmp()
 - 8334544: C2: wrong control assigned in PhaseIdealLoop::clone_assertion_predicate_for_unswitched_loops()
 - 8334239: Introduce macro for ubsan method/function exclusions
 - 8332717: ZGC: Division by zero in heuristics
 - 8333754: Add a Test against ECDSA and ECDH NIST Test vector
 - 8334570: Problem list gc/TestAlwaysPreTouchBehavior.java
 - ... and 63 more: https://git.openjdk.org/valhalla/compare/b2e26916...e5350bbc

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

Changes: https://git.openjdk.org/valhalla/pull/1272/files
  Stats: 17812 lines in 324 files changed: 13875 ins; 2188 del; 1749 mod
  Patch: https://git.openjdk.org/valhalla/pull/1272.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1272/head:pull/1272

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

From rriggs at openjdk.org  Wed Oct  9 18:17:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Oct 2024 18:17:34 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v3]
In-Reply-To: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
Message-ID: <VEv3pB1F23scq6GGs8ksQEcxdGZNNUkUaWPNrvZjlVs=.013fd302-559a-4d7d-9594-857d4d4f5d7e@github.com>

> Serialization and deerialization of value classes. 
> For java.base value classes migrated from identity classes:
>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>   - Must have a constructor or static factory method:
>     - annotated with jdk.internal.value.DeserializeConstrucctor
>     - constructor parameters must match order and types of serializable fields of the class
>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>   - Migrated value classes are serialized using the same format/fields as the identity class
> 
> Non-migrated value classes throw InvalidClassException
> 
> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
> 
> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.

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

  From review comments.
  Tidy up unreachable IllegalAccessException after setAccessible; throw InternalError.
  Move declaration of local into for loop header.
  Cleanup TRACE Property parsing.
  Improve test output readability.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1248/files
  - new: https://git.openjdk.org/valhalla/pull/1248/files/df2b4ef8..9ec46a99

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

  Stats: 18 lines in 3 files changed: 7 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1248.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1248/head:pull/1248

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

From rriggs at openjdk.org  Wed Oct  9 18:17:36 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 9 Oct 2024 18:17:36 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v2]
In-Reply-To: <RUUSOD2KE652fk9GRTgJEf-OKinPyNRec18dMFmgJW0=.f6f4f924-7b59-4249-9700-dbaec54841a8@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
 <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>
 <RUUSOD2KE652fk9GRTgJEf-OKinPyNRec18dMFmgJW0=.f6f4f924-7b59-4249-9700-dbaec54841a8@github.com>
Message-ID: <WwiQyXRnUC7idWJF-4X5N0O76lbgTHAENbjUoUsLHeo=.8d368b2f-5d99-456d-a276-7903513cc8ab@github.com>

On Tue, 8 Oct 2024 21:17:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge branch 'lworld' into 8340409-simple-value-deserialize
>>  - Merge branch 'lworld' into 8340409-simple-value-deserialize
>>  - 8340409: [lworld] Simple serialization and deserialization of core migrated classes
>>    
>>    Serialization and deerialization of value classes.
>>    For java.base value classes being migrated from identity classes:
>>      - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>>      - Must have a constructor or static factory method:
>>        - annotated with jdk.internal.value.DeserializeConstrucctor
>>        - constructor parameters must match order and types of serializable fields of the class
>>      - Value class must not have superclass with fields; only Object or abstract w/o fields
>>      - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>>      - Migrated value classes are serialized using the same format/fields as the identity class
>>    
>>    Non-migrated value classes throw InvalidClassException
>>    
>>    Along the way, refactored code to break out different modes of deserialization:
>>    full custom deserialization with custom data, default deserialization only,
>>    externalizable, no local class, record, and then added mode to deserialize a value class.
>>    
>>    Updates to value class tests and added a combo test to check many combinations
>>    of value and identity classes with different parameters.
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 1591:
> 
>> 1589:                         return null;
>> 1590:                     }})
>> 1591:                 .filter(m -> matchFactoryParamTypes(clazz, m, fields))
> 
> `m` can be null here, so `matchFactoryParamTypes` needs to check that.

After setAccessible IAE should never happen; change to throw InternalError.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1248#discussion_r1793954848

From vklang at openjdk.org  Wed Oct  9 21:22:24 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 9 Oct 2024 21:22:24 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v2]
In-Reply-To: <WwiQyXRnUC7idWJF-4X5N0O76lbgTHAENbjUoUsLHeo=.8d368b2f-5d99-456d-a276-7903513cc8ab@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
 <tsp2u0wT4TnnILqCiNBfjAcnEkfOScnvQgbEKf5sEAk=.186e3d8e-1232-4690-aade-155e4a192609@github.com>
 <RUUSOD2KE652fk9GRTgJEf-OKinPyNRec18dMFmgJW0=.f6f4f924-7b59-4249-9700-dbaec54841a8@github.com>
 <WwiQyXRnUC7idWJF-4X5N0O76lbgTHAENbjUoUsLHeo=.8d368b2f-5d99-456d-a276-7903513cc8ab@github.com>
Message-ID: <q5J56mfF2gxgFmHCy7BR17LkBc-9fmUm4Z1VKDoqkgk=.ba5e2920-405f-430c-ba40-db7e9292b77a@github.com>

On Wed, 9 Oct 2024 18:14:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 1591:
>> 
>>> 1589:                         return null;
>>> 1590:                     }})
>>> 1591:                 .filter(m -> matchFactoryParamTypes(clazz, m, fields))
>> 
>> `m` can be null here, so `matchFactoryParamTypes` needs to check that.
>
> After setAccessible IAE should never happen; change to throw InternalError.

Yeah, sounds good. ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1248#discussion_r1794243082

From thartmann at openjdk.org  Thu Oct 10 07:42:37 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 10 Oct 2024 07:42:37 GMT
Subject: [lworld] RFR: 8315003: [lworld] C2: Implement full support for
 JDK-8287061 and JDK-8316991
In-Reply-To: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
References: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
Message-ID: <wDGcgNnKniPzifLbi6XGtub06mkkjApMsKq63CpJdew=.30228f9d-0bb8-4dda-a087-fa8afc28da53@github.com>

On Wed, 9 Oct 2024 12:27:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch makes the improved allocation merge at EA work with inline types.
> 
> Before this patch, the assumption was that we do **not** have non-scalarized inline types at safepoints which EA is going to scalarize (and if we do, then there is a missed opportunity which can be considered a bug). We should have pushed all `InlineTypeNodes` down through phis in order to have them scalarized before EA.
> 
> This, however, changes with the improved allocation merge RFEs that have been merged into Valhalla ([JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) and [JDK-8316991](https://bugs.openjdk.org/browse/JDK-8316991)). We could now the following graph as found in the test case:
> 
> ![image](https://github.com/user-attachments/assets/4e5174d3-9a52-4c43-8dcd-b6a119438ca0)
> 
> Here, `272 Phi` merges the non-value type allocation `238 CheckCastPP` with the value type allocation `217 InlineType`. Before the improved allocation merge RFEs, we would not be able to remove the allocations. But now, we can do it at EA: We create a special `SafePointScalarMergeNode` which in case has `SafePointScalarObjectNodes` as inputs for the merged allocations. Additionally, each field of the merged allocations are added to the safepoint, which also includes the value type field `v2` of `V`:
> 
> ![image](https://github.com/user-attachments/assets/eb8e7012-262d-492f-ae30-a3962f5ae931)
> 
> We should not have safepoint uses for `InlineType` and thus now replace them with `SafePointScalarObjectNodes` as well (newly done with this patch). As a result, we have the following graph after EA:
> 
> ![image](https://github.com/user-attachments/assets/0cf521c4-dee1-4cb7-bb7c-3479b459ed34)
> 
> Note that the safepoint node inputs for fields are well-defined to keep track of which field belong to each of the `SafePointScalarObjectNodes` of the `SafePointScalarMergeNode`.
> 
> 
> ### Additional Code Changes
> - There was a bug in mainline with the new allocation merge implementation that is already fixed in mainline but not integrated in Valhalla, yet: [JDK-8335220](https://bugs.openjdk.org/browse/JDK-8335220). I cherry-picked these changes (L589-605 in escape.cpp).
> - I added assertion code to verify that when we are going to scalar replace an inline type allocation that is an input into a phi at EA, we would not have been able to push the `InlineTypeNode` down (which should have been done earlier if possible).
> - Re-enabled uncommented tests and removed problem-listed `AllocationMergesTests.java` that had been added with ...

Great work, Christian. The detailed description in the PR is useful for future reference. Looks good to me.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java line 27:

> 25:  * @test
> 26:  * @bug 8315003
> 27:  * @summary Test that removing allocation merges of non-value and value types at EA is working properly.

Suggestion:

 * @summary Test that removing allocation merges of non-value and value object at EA is working properly.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1271#pullrequestreview-2359326158
PR Review Comment: https://git.openjdk.org/valhalla/pull/1271#discussion_r1794865200

From chagedorn at openjdk.org  Thu Oct 10 08:06:40 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Oct 2024 08:06:40 GMT
Subject: [lworld] RFR: 8315003: [lworld] C2: Implement full support for
 JDK-8287061 and JDK-8316991 [v2]
In-Reply-To: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
References: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
Message-ID: <NcCkE6GnhhOwcnhs5qzi6QSU5tJeYwIWLiXAqha_iMo=.5c53a22d-ca10-45c8-96bc-8b0fb85f4303@github.com>

> This patch makes the improved allocation merge at EA work with inline types.
> 
> Before this patch, the assumption was that we do **not** have non-scalarized inline types at safepoints which EA is going to scalarize (and if we do, then there is a missed opportunity which can be considered a bug). We should have pushed all `InlineTypeNodes` down through phis in order to have them scalarized before EA.
> 
> This, however, changes with the improved allocation merge RFEs that have been merged into Valhalla ([JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) and [JDK-8316991](https://bugs.openjdk.org/browse/JDK-8316991)). We could now the following graph as found in the test case:
> 
> ![image](https://github.com/user-attachments/assets/4e5174d3-9a52-4c43-8dcd-b6a119438ca0)
> 
> Here, `272 Phi` merges the non-value type allocation `238 CheckCastPP` with the value type allocation `217 InlineType`. Before the improved allocation merge RFEs, we would not be able to remove the allocations. But now, we can do it at EA: We create a special `SafePointScalarMergeNode` which in case has `SafePointScalarObjectNodes` as inputs for the merged allocations. Additionally, each field of the merged allocations are added to the safepoint, which also includes the value type field `v2` of `V`:
> 
> ![image](https://github.com/user-attachments/assets/eb8e7012-262d-492f-ae30-a3962f5ae931)
> 
> We should not have safepoint uses for `InlineType` and thus now replace them with `SafePointScalarObjectNodes` as well (newly done with this patch). As a result, we have the following graph after EA:
> 
> ![image](https://github.com/user-attachments/assets/0cf521c4-dee1-4cb7-bb7c-3479b459ed34)
> 
> Note that the safepoint node inputs for fields are well-defined to keep track of which field belong to each of the `SafePointScalarObjectNodes` of the `SafePointScalarMergeNode`.
> 
> 
> ### Additional Code Changes
> - There was a bug in mainline with the new allocation merge implementation that is already fixed in mainline but not integrated in Valhalla, yet: [JDK-8335220](https://bugs.openjdk.org/browse/JDK-8335220). I cherry-picked these changes (L589-605 in escape.cpp).
> - I added assertion code to verify that when we are going to scalar replace an inline type allocation that is an input into a phi at EA, we would not have been able to push the `InlineTypeNode` down (which should have been done earlier if possible).
> - Re-enabled uncommented tests and removed problem-listed `AllocationMergesTests.java` that had been added with ...

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

  Update test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAllocationMergeAndFolding.java
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1271/files
  - new: https://git.openjdk.org/valhalla/pull/1271/files/b21dcca4..781e4e4d

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

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

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

From chagedorn at openjdk.org  Thu Oct 10 08:06:40 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Oct 2024 08:06:40 GMT
Subject: [lworld] RFR: 8315003: [lworld] C2: Implement full support for
 JDK-8287061 and JDK-8316991
In-Reply-To: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
References: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
Message-ID: <EpbwUHpcd0gB6WNu3V7IxMYJgk5U2hymn-4AIPXW-aA=.d0a9c85b-cbb1-4cbd-b35f-822d267a14b4@github.com>

On Wed, 9 Oct 2024 12:27:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch makes the improved allocation merge at EA work with inline types.
> 
> Before this patch, the assumption was that we do **not** have non-scalarized inline types at safepoints which EA is going to scalarize (and if we do, then there is a missed opportunity which can be considered a bug). We should have pushed all `InlineTypeNodes` down through phis in order to have them scalarized before EA.
> 
> This, however, changes with the improved allocation merge RFEs that have been merged into Valhalla ([JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) and [JDK-8316991](https://bugs.openjdk.org/browse/JDK-8316991)). We could now the following graph as found in the test case:
> 
> ![image](https://github.com/user-attachments/assets/4e5174d3-9a52-4c43-8dcd-b6a119438ca0)
> 
> Here, `272 Phi` merges the non-value type allocation `238 CheckCastPP` with the value type allocation `217 InlineType`. Before the improved allocation merge RFEs, we would not be able to remove the allocations. But now, we can do it at EA: We create a special `SafePointScalarMergeNode` which in case has `SafePointScalarObjectNodes` as inputs for the merged allocations. Additionally, each field of the merged allocations are added to the safepoint, which also includes the value type field `v2` of `V`:
> 
> ![image](https://github.com/user-attachments/assets/eb8e7012-262d-492f-ae30-a3962f5ae931)
> 
> We should not have safepoint uses for `InlineType` and thus now replace them with `SafePointScalarObjectNodes` as well (newly done with this patch). As a result, we have the following graph after EA:
> 
> ![image](https://github.com/user-attachments/assets/0cf521c4-dee1-4cb7-bb7c-3479b459ed34)
> 
> Note that the safepoint node inputs for fields are well-defined to keep track of which field belong to each of the `SafePointScalarObjectNodes` of the `SafePointScalarMergeNode`.
> 
> 
> ### Additional Code Changes
> - There was a bug in mainline with the new allocation merge implementation that is already fixed in mainline but not integrated in Valhalla, yet: [JDK-8335220](https://bugs.openjdk.org/browse/JDK-8335220). I cherry-picked these changes (L589-605 in escape.cpp).
> - I added assertion code to verify that when we are going to scalar replace an inline type allocation that is an input into a phi at EA, we would not have been able to push the `InlineTypeNode` down (which should have been done earlier if possible).
> - Re-enabled uncommented tests and removed problem-listed `AllocationMergesTests.java` that had been added with ...

Thanks Tobias for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1271#issuecomment-2404371729

From chagedorn at openjdk.org  Thu Oct 10 08:13:26 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 10 Oct 2024 08:13:26 GMT
Subject: [lworld] Integrated: 8315003: [lworld] C2: Implement full support for
 JDK-8287061 and JDK-8316991
In-Reply-To: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
References: <-7O-N5R7atweS8TFtK9aMGiBi1b9rE_Y7FnsGBFrwiw=.2d82a40e-3be6-4cc8-b8be-dd1c43fe5dac@github.com>
Message-ID: <Aw1jHhvBsZmrvAr7wxhSOYpiWaKWgmDRUc6lQ3z19Rg=.88c38475-0f14-42d9-ab34-31d76a38c636@github.com>

On Wed, 9 Oct 2024 12:27:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch makes the improved allocation merge at EA work with inline types.
> 
> Before this patch, the assumption was that we do **not** have non-scalarized inline types at safepoints which EA is going to scalarize (and if we do, then there is a missed opportunity which can be considered a bug). We should have pushed all `InlineTypeNodes` down through phis in order to have them scalarized before EA.
> 
> This, however, changes with the improved allocation merge RFEs that have been merged into Valhalla ([JDK-8287061](https://bugs.openjdk.org/browse/JDK-8287061) and [JDK-8316991](https://bugs.openjdk.org/browse/JDK-8316991)). We could now the following graph as found in the test case:
> 
> ![image](https://github.com/user-attachments/assets/4e5174d3-9a52-4c43-8dcd-b6a119438ca0)
> 
> Here, `272 Phi` merges the non-value type allocation `238 CheckCastPP` with the value type allocation `217 InlineType`. Before the improved allocation merge RFEs, we would not be able to remove the allocations. But now, we can do it at EA: We create a special `SafePointScalarMergeNode` which in case has `SafePointScalarObjectNodes` as inputs for the merged allocations. Additionally, each field of the merged allocations are added to the safepoint, which also includes the value type field `v2` of `V`:
> 
> ![image](https://github.com/user-attachments/assets/eb8e7012-262d-492f-ae30-a3962f5ae931)
> 
> We should not have safepoint uses for `InlineType` and thus now replace them with `SafePointScalarObjectNodes` as well (newly done with this patch). As a result, we have the following graph after EA:
> 
> ![image](https://github.com/user-attachments/assets/0cf521c4-dee1-4cb7-bb7c-3479b459ed34)
> 
> Note that the safepoint node inputs for fields are well-defined to keep track of which field belong to each of the `SafePointScalarObjectNodes` of the `SafePointScalarMergeNode`.
> 
> 
> ### Additional Code Changes
> - There was a bug in mainline with the new allocation merge implementation that is already fixed in mainline but not integrated in Valhalla, yet: [JDK-8335220](https://bugs.openjdk.org/browse/JDK-8335220). I cherry-picked these changes (L589-605 in escape.cpp).
> - I added assertion code to verify that when we are going to scalar replace an inline type allocation that is an input into a phi at EA, we would not have been able to push the `InlineTypeNode` down (which should have been done earlier if possible).
> - Re-enabled uncommented tests and removed problem-listed `AllocationMergesTests.java` that had been added with ...

This pull request has now been integrated.

Changeset: 0ae00ea8
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ae00ea810a3e682e513e18984e4f44cbdfee0ff
Stats:     155 lines in 7 files changed: 134 ins; 11 del; 10 mod

8315003: [lworld] C2: Implement full support for JDK-8287061 and JDK-8316991

Reviewed-by: thartmann

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

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

From jespersm at openjdk.org  Thu Oct 10 15:40:00 2024
From: jespersm at openjdk.org (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 10 Oct 2024 15:40:00 GMT
Subject: [lworld] RFR: 8341061 [lworld]: Mark and fail compilation in
 non-discardable values are discarded
Message-ID: <PHIuzsNyJfeXIJ3Emg38JIrCm-m_0ujEmGb9VNUqbog=.45280b73-e077-44fe-846e-8a18afcddbf9@github.com>

... as per https://bugs.openjdk.org/browse/JDK-8199429

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

Commit messages:
 - Merge branch 'openjdk:lworld' into 8341061-lworld-non-discardable-values
 - 8341061: [lworld] value type (re)constructors expressions should not be discardable

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

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

From jespersm at openjdk.org  Thu Oct 10 16:14:23 2024
From: jespersm at openjdk.org (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 10 Oct 2024 16:14:23 GMT
Subject: [lworld] RFR: 8341061 [lworld]: Mark and fail compilation in
 non-discardable values are discarded
In-Reply-To: <PHIuzsNyJfeXIJ3Emg38JIrCm-m_0ujEmGb9VNUqbog=.45280b73-e077-44fe-846e-8a18afcddbf9@github.com>
References: <PHIuzsNyJfeXIJ3Emg38JIrCm-m_0ujEmGb9VNUqbog=.45280b73-e077-44fe-846e-8a18afcddbf9@github.com>
Message-ID: <JcObEm8-UttOVDLcmYihTULkmd-UniZN0UUvEIlW8xY=.5d61e260-239c-4c7d-afdc-48dd808474fc@github.com>

On Thu, 10 Oct 2024 15:31:56 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> ... as per https://bugs.openjdk.org/browse/JDK-8199429

Mismatched JBS number. I'll open a different one with all the right references.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1273#issuecomment-2405530045

From jespersm at openjdk.org  Thu Oct 10 16:14:23 2024
From: jespersm at openjdk.org (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 10 Oct 2024 16:14:23 GMT
Subject: [lworld] Withdrawn: 8341061 [lworld]: Mark and fail compilation in
 non-discardable values are discarded
In-Reply-To: <PHIuzsNyJfeXIJ3Emg38JIrCm-m_0ujEmGb9VNUqbog=.45280b73-e077-44fe-846e-8a18afcddbf9@github.com>
References: <PHIuzsNyJfeXIJ3Emg38JIrCm-m_0ujEmGb9VNUqbog=.45280b73-e077-44fe-846e-8a18afcddbf9@github.com>
Message-ID: <XoOzmHUplFIMbyoDt8iR1mFGi5c5RzvyPE1_61D8s8c=.8949866e-3a3f-4be5-8d55-ad4c8fcb97fe@github.com>

On Thu, 10 Oct 2024 15:31:56 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> ... as per https://bugs.openjdk.org/browse/JDK-8199429

This pull request has been closed without being integrated.

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

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

From jespersm at openjdk.org  Thu Oct 10 16:26:39 2024
From: jespersm at openjdk.org (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 10 Oct 2024 16:26:39 GMT
Subject: [lworld] RFR: 8199429: [lworld] value type (re)constructors
 expressions should not =?UTF-8?B?4oCm?=
Message-ID: <cl2ovFgy6fLr8n8DWLyc15aIYy6xigKfWy42p83qhoc=.7e077dca-f681-48d6-9496-ddbb523a0ade@github.com>

?be discardable as per https://bugs.openjdk.org/browse/JDK-8199429 .

This is a first stab at it, only with the manual marking on a method, and without the loading of the annotation in ClassReader.

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

Commit messages:
 - 8199429: [lworld] value type (re)constructors expressions should not be discardable

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

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

From jespersm at openjdk.org  Thu Oct 10 17:01:25 2024
From: jespersm at openjdk.org (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 10 Oct 2024 17:01:25 GMT
Subject: [lworld] RFR: 8199429: [lworld] value type (re)constructors
 expressions value type should not be discardable [v2]
In-Reply-To: <cl2ovFgy6fLr8n8DWLyc15aIYy6xigKfWy42p83qhoc=.7e077dca-f681-48d6-9496-ddbb523a0ade@github.com>
References: <cl2ovFgy6fLr8n8DWLyc15aIYy6xigKfWy42p83qhoc=.7e077dca-f681-48d6-9496-ddbb523a0ade@github.com>
Message-ID: <N9xC-F3t1X83F540bt6rQboLh5IYiibQMDsaJVdusNc=.afb46ad6-f057-47d0-b367-935ab59a59f1@github.com>

> ?be discardable as per https://bugs.openjdk.org/browse/JDK-8199429 .
> 
> This is a first stab at it, only with the manual marking on a method, and without the loading of the annotation in ClassReader.

Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:

  8199429: [lworld] Add error example for CheckExamples test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1274/files
  - new: https://git.openjdk.org/valhalla/pull/1274/files/793f07d4..c2130bd2

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

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

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

From liach at openjdk.org  Thu Oct 10 22:13:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 10 Oct 2024 22:13:17 GMT
Subject: [lworld] RFR: 8199429: [lworld] value type (re)constructors
 expressions value type should not be discardable [v2]
In-Reply-To: <N9xC-F3t1X83F540bt6rQboLh5IYiibQMDsaJVdusNc=.afb46ad6-f057-47d0-b367-935ab59a59f1@github.com>
References: <cl2ovFgy6fLr8n8DWLyc15aIYy6xigKfWy42p83qhoc=.7e077dca-f681-48d6-9496-ddbb523a0ade@github.com>
 <N9xC-F3t1X83F540bt6rQboLh5IYiibQMDsaJVdusNc=.afb46ad6-f057-47d0-b367-935ab59a59f1@github.com>
Message-ID: <L67YynhjYmp3rVBlxKjkawD9TDMB_a-s6B73ziAJBdA=.74597b8a-c5aa-4551-aba8-e32eacaedfad@github.com>

On Thu, 10 Oct 2024 17:01:25 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

>> ?be discardable as per https://bugs.openjdk.org/browse/JDK-8199429 .
>> 
>> This is a first stab at it, only with the manual marking on a method, and without the loading of the annotation in ClassReader.
>
> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8199429: [lworld] Add error example for CheckExamples test

I think the "reconstrcutor" proposal is out-of-date; the latest approach would be "deconstructors" https://github.com/openjdk/amber/pull/94 and "Derived record creation" https://openjdk.org/jeps/468

For `@MustUse`: in the "CheckReturnValue at Google" presentation in [JVMLS 2024](https://openjdk.org/projects/mlvm/jvmlangsummit/agenda.html), Google finds that the pattern is simple: All builder/fluent methods can have return values ignored by default, and all other methods should have return values "must use" by default. Only a tiny fraction of the methods can have their return value ignored, like `List.add`.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1274#issuecomment-2406128892

From jespersm at openjdk.org  Thu Oct 10 23:42:26 2024
From: jespersm at openjdk.org (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Thu, 10 Oct 2024 23:42:26 GMT
Subject: [lworld] RFR: 8199429: [lworld] value type (re)constructors
 expressions value type should not be discardable [v2]
In-Reply-To: <L67YynhjYmp3rVBlxKjkawD9TDMB_a-s6B73ziAJBdA=.74597b8a-c5aa-4551-aba8-e32eacaedfad@github.com>
References: <cl2ovFgy6fLr8n8DWLyc15aIYy6xigKfWy42p83qhoc=.7e077dca-f681-48d6-9496-ddbb523a0ade@github.com>
 <N9xC-F3t1X83F540bt6rQboLh5IYiibQMDsaJVdusNc=.afb46ad6-f057-47d0-b367-935ab59a59f1@github.com>
 <L67YynhjYmp3rVBlxKjkawD9TDMB_a-s6B73ziAJBdA=.74597b8a-c5aa-4551-aba8-e32eacaedfad@github.com>
Message-ID: <SnOBvRbSyE2pGbVOl9zVDOw73BhHeY7HZJJ9Y0nK7S8=.5dc9bd35-8589-4811-9022-b2f626b30c66@github.com>

On Thu, 10 Oct 2024 22:10:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jesper Steen M?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8199429: [lworld] Add error example for CheckExamples test
>
> I think the "reconstrcutor" proposal is out-of-date; the latest approach would be "deconstructors" https://github.com/openjdk/amber/pull/94 and "Derived record creation" https://openjdk.org/jeps/468
> 
> For `@MustUse`: in the "CheckReturnValue at Google" presentation in [JVMLS 2024](https://openjdk.org/projects/mlvm/jvmlangsummit/agenda.html), Google finds that the pattern is simple: All builder/fluent methods can have return values ignored by default, and all other methods should have return values "must use" by default. Only a tiny fraction of the methods can have their return value ignored, like `List.add`.

Thanks for the feedback, @liach 

Re. reconstructors: Good point, the case of an JCExpressionStatement "p with { y = 0}" is of course easy to flag as an error, (just from structure alone, like x+1 in the original motivation).

As for the annotation: I could not find the Google presentation on YT, but I guess that what you're saying is that the annotation would make sense for any and all methods which return a computed value without causing any mutations or side-effects. Since values are immutable, only side effects need consideration, so the bar is a lot lower (and enforceable in practice, since we don't want to break people code, even nonsensical parts).

So in the [example](https://github.com/openjdk/valhalla/blob/c2130bd2c1a8e21cb6d547c84d335fdd12325d67/test/langtools/tools/javac/valhalla/must_use/MustUseValueTest.java#L31-L34) given in the PR, the method `next()` could be automatically annotated as `@MustUse` because we know that the entire method call _will be useless_ if the value is not put to good use.
If, however, the method's control flow was ever to leave the method (even by throwing an exception) or a value was assigned to any field (on some referenced object, obviously not on the value), the `@MustUse` annotation could not be set automatically.

As for identity objects, I'm guessing that developers in the future could use `@MustUse` on methods where the only sane usage is to use the returned value, such as in the builder pattern as you mention, to alert their callers of the intent, since we can't apply the same rules as with the value types.

Or am I overthinking this? ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1274#issuecomment-2406231106

From dsimms at openjdk.org  Fri Oct 11 08:59:44 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 11 Oct 2024 08:59:44 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>
References: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>
Message-ID: <vqLJbA6e_c8rkm9rbpjpA2fkFgx3YlsJg2L_UR_Lt5Y=.951ed599-53e2-45eb-af5c-deddc5216d37@github.com>

> Merge jdk-24+3

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

  Remerge 8333805

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1272/files
  - new: https://git.openjdk.org/valhalla/pull/1272/files/e5350bbc..9ff07c03

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

  Stats: 77 lines in 1 file changed: 32 ins; 27 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/1272.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1272/head:pull/1272

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

From dsimms at openjdk.org  Fri Oct 11 09:30:58 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 11 Oct 2024 09:30:58 GMT
Subject: [lworld] RFR: Merge jdk [v3]
In-Reply-To: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>
References: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>
Message-ID: <x-2nugDRwr5PhI1xrLoYguLOyUrdzDid6_rb_gYesak=.751dcabf-765e-4702-9931-83049be2a825@github.com>

> Merge jdk-24+3

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

  Adjust testing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1272/files
  - new: https://git.openjdk.org/valhalla/pull/1272/files/9ff07c03..6eb0d927

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

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

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

From dsimms at openjdk.org  Fri Oct 11 13:10:35 2024
From: dsimms at openjdk.org (David Simms)
Date: Fri, 11 Oct 2024 13:10:35 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>
References: <q1YQvQbLHlrBwF7OMj6Q02SG4orUaGIcKjScjmYzl10=.3dfd1f84-7b89-43a9-b6a4-f4338da4239d@github.com>
Message-ID: <IiahsA5GGrrsApQgszf9QMu6wtYyQk5t52amQiP_4uQ=.e033bad2-934e-4f88-89fa-2231c6a135d0@github.com>

On Wed, 9 Oct 2024 14:00:51 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-24+3

This pull request has now been integrated.

Changeset: d8a2bfa8
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d8a2bfa8b2abe2ad13298412a9313429aba8f350
Stats:     17901 lines in 325 files changed: 13920 ins; 2215 del; 1766 mod

Merge jdk

Merge jdk-24+3

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

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

From dsimms at openjdk.org  Mon Oct 14 09:26:00 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Oct 2024 09:26:00 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <7pNbZFSHT6F9NryYe5yl16tNCNzvzd_c9xOKvj1jEhM=.f519748c-e80d-4690-bbb1-2ed1bc08f90b@github.com>

Merge tag 'jdk-24+4' into lworld_merge_jdk_24_4
Added tag jdk-24+4 for changeset 46b817b7

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

Commit messages:
 - Merge tag 'jdk-24+4' into lworld_merge_jdk_24_4
 - 8333363: ubsan: instanceKlass.cpp: runtime error: member call on null pointer of type 'struct AnnotationArray'
 - 8332014: since-checker - Fix @ since tags in jdk.jshell
 - 8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal
 - 8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed
 - 8334779: Test compiler/c1/CanonicalizeArrayLength.java is timing out
 - 8328536: javac - crash on unknown type referenced in yield statement
 - 8334670: SSLSocketOutputRecord buffer miscalculation
 - 8334769: Shenandoah: Move CodeCache_lock close to its use in ShenandoahConcurrentNMethodIterator
 - 8331411: Shenandoah: Reconsider spinning duration in ShenandoahLock
 - ... and 81 more: https://git.openjdk.org/valhalla/compare/d8a2bfa8...6245d149

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

Changes: https://git.openjdk.org/valhalla/pull/1276/files
  Stats: 12888 lines in 361 files changed: 6375 ins; 5084 del; 1429 mod
  Patch: https://git.openjdk.org/valhalla/pull/1276.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1276/head:pull/1276

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

From dsimms at openjdk.org  Mon Oct 14 13:11:42 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Oct 2024 13:11:42 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <7pNbZFSHT6F9NryYe5yl16tNCNzvzd_c9xOKvj1jEhM=.f519748c-e80d-4690-bbb1-2ed1bc08f90b@github.com>
References: <7pNbZFSHT6F9NryYe5yl16tNCNzvzd_c9xOKvj1jEhM=.f519748c-e80d-4690-bbb1-2ed1bc08f90b@github.com>
Message-ID: <fA7tRaMn3fOOMB-w9IRqx99IGdJ7bVdDRWkZ2Ao-mgU=.c8b617dc-84f8-4c96-835e-c851ef78056c@github.com>

> Merge tag 'jdk-24+4' into lworld_merge_jdk_24_4
> Added tag jdk-24+4 for changeset 46b817b7

David Simms has updated the pull request incrementally with 151 additional commits since the last revision:

 - Merge tag 'jdk-24+6' into lworld_merge_jdk_24_4
   
   Added tag jdk-24+6 for changeset b363de8c
 - 8335946: DTrace code snippets should be generated when DTrace flags are enabled
   
   Reviewed-by: coleenp, dholmes
 - 8335743: jhsdb jstack cannot print some information on the waiting thread
   
   Reviewed-by: dholmes, cjplummer, kevinw
 - 8335935: Chained builders not sending transformed models to next transforms
   
   Reviewed-by: asotona
 - 8334481: [JVMCI] add LINK_TO_NATIVE to MethodHandleAccessProvider.IntrinsicMethod
   
   Reviewed-by: dnsimon
 - 8335637: Add explicit non-null return value expectations to Object.toString()
   
   Reviewed-by: jpai, alanb, smarks, prappo
 - 8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665
   
   Reviewed-by: dholmes, stuefe, coleenp, shade
 - 8331725: ubsan: pc may not always be the entry point for a VtableStub
   
   Reviewed-by: kvn, mbaesken
 - 8313909: [JVMCI] assert(cp->tag_at(index).is_unresolved_klass()) in lookupKlassInPool
   
   Reviewed-by: yzheng, never
 - 8336012: Fix usages of jtreg-reserved properties
   
   Reviewed-by: jjg
 - ... and 141 more: https://git.openjdk.org/valhalla/compare/6245d149...3b89477b

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1276/files
  - new: https://git.openjdk.org/valhalla/pull/1276/files/6245d149..3b89477b

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

  Stats: 17838 lines in 661 files changed: 11501 ins; 3603 del; 2734 mod
  Patch: https://git.openjdk.org/valhalla/pull/1276.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1276/head:pull/1276

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

From dsimms at openjdk.org  Mon Oct 14 14:11:38 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Oct 2024 14:11:38 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <7pNbZFSHT6F9NryYe5yl16tNCNzvzd_c9xOKvj1jEhM=.f519748c-e80d-4690-bbb1-2ed1bc08f90b@github.com>
References: <7pNbZFSHT6F9NryYe5yl16tNCNzvzd_c9xOKvj1jEhM=.f519748c-e80d-4690-bbb1-2ed1bc08f90b@github.com>
Message-ID: <PF5sTm1QRbEhDXRuTE2yHV_-d2fI-ZJw-Cu6bFfMsrE=.1ea930e8-39f3-44f8-a6c0-f64818ee7b95@github.com>

On Mon, 14 Oct 2024 09:20:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-24+4' into lworld_merge_jdk_24_4
> Added tag jdk-24+4 for changeset 46b817b7

This pull request has now been integrated.

Changeset: b613b567
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b613b567b826dcd8c3c0d78ad8f271cf0fbb5dd8
Stats:     30677 lines in 981 files changed: 17856 ins; 8667 del; 4154 mod

Merge jdk

Merge jdk-24+4
Merge jdk-24+5
Merge jdk-24+6

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

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

From dsimms at openjdk.org  Mon Oct 14 14:56:40 2024
From: dsimms at openjdk.org (David Simms)
Date: Mon, 14 Oct 2024 14:56:40 GMT
Subject: [lworld] RFR: 8342033: [lworld] Rename ClassDescImpl back to
 ReferenceClassDescImpl
Message-ID: <FkzRgVWDMJtmWac3j1x7HaEb0oefklTZF3wCMZwRXOA=.c2ed68b3-7776-458d-84dd-842fa2182f90@github.com>

ClassDescImpl -> ReferenceClassDescImpl

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

Commit messages:
 - 8342033: [lworld] Rename ClassDescImpl back to ReferenceClassDescImpl

Changes: https://git.openjdk.org/valhalla/pull/1277/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1277&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342033
  Stats: 377 lines in 13 files changed: 135 ins; 135 del; 107 mod
  Patch: https://git.openjdk.org/valhalla/pull/1277.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1277/head:pull/1277

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

From liach at openjdk.org  Mon Oct 14 15:07:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 14 Oct 2024 15:07:28 GMT
Subject: [lworld] RFR: 8342033: [lworld] Rename ClassDescImpl back to
 ReferenceClassDescImpl
In-Reply-To: <FkzRgVWDMJtmWac3j1x7HaEb0oefklTZF3wCMZwRXOA=.c2ed68b3-7776-458d-84dd-842fa2182f90@github.com>
References: <FkzRgVWDMJtmWac3j1x7HaEb0oefklTZF3wCMZwRXOA=.c2ed68b3-7776-458d-84dd-842fa2182f90@github.com>
Message-ID: <E05oZ9YDOntaLq6YzOGqnVtEf0B9TeUhS6-0nSAElyU=.189e97dc-3dfc-4d25-a9aa-7c1d71ee4bbc@github.com>

On Mon, 14 Oct 2024 14:51:43 GMT, David Simms <dsimms at openjdk.org> wrote:

> ClassDescImpl -> ReferenceClassDescImpl

Will reduce the merge overhead from master in the future.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1277#pullrequestreview-2366944874

From dsimms at openjdk.org  Tue Oct 15 05:13:28 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Oct 2024 05:13:28 GMT
Subject: [lworld] Integrated: 8342033: [lworld] Rename ClassDescImpl back to
 ReferenceClassDescImpl
In-Reply-To: <FkzRgVWDMJtmWac3j1x7HaEb0oefklTZF3wCMZwRXOA=.c2ed68b3-7776-458d-84dd-842fa2182f90@github.com>
References: <FkzRgVWDMJtmWac3j1x7HaEb0oefklTZF3wCMZwRXOA=.c2ed68b3-7776-458d-84dd-842fa2182f90@github.com>
Message-ID: <y6CmGSbNrcAWdJdA5jIisG9Q2dGBMC5OXqvF1nSsE9s=.28c60c94-e717-44d0-8af0-43f845de0f5a@github.com>

On Mon, 14 Oct 2024 14:51:43 GMT, David Simms <dsimms at openjdk.org> wrote:

> ClassDescImpl -> ReferenceClassDescImpl

This pull request has now been integrated.

Changeset: a59ca590
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a59ca590eec3ede39d5651688f9f22307082c2f5
Stats:     377 lines in 13 files changed: 135 ins; 135 del; 107 mod

8342033: [lworld] Rename ClassDescImpl back to ReferenceClassDescImpl

Reviewed-by: liach

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

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

From dsimms at openjdk.org  Tue Oct 15 08:19:08 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Oct 2024 08:19:08 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <aegelwK5HT--ak60q0tK5FJndwLIkiQAv1t5BFzb2Ik=.c4447c4e-67ba-48d0-a70e-bc3f61e9f623@github.com>

Merge jdk-24+7
Merge jdk-24+8
Merge jdk-24+9

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

Commit messages:
 - Merge tag 'jdk-24+9' into lworld_merge_jdk_24_7
 - 8337027: Parallel: Obsolete BaseFootPrintEstimate
 - 8324345: Stack overflow during C2 compilation when splitting memory phi
 - 8331090: Run Ideal_minmax before de-canonicalizing CMoves
 - 8337421: RISC-V: client VM build failure after JDK-8335191
 - 8337523: Fix -Wzero-as-null-pointer-constant warnings in jvmci code
 - 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code
 - 8336635: Add IR test for Reference.refersTo intrinsic
 - 8336242: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found (again)
 - 8336912: G1: Undefined behavior for G1ConfidencePercent=0
 - ... and 224 more: https://git.openjdk.org/valhalla/compare/a59ca590...ea380af7

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

Changes: https://git.openjdk.org/valhalla/pull/1278/files
  Stats: 24015 lines in 793 files changed: 14516 ins; 6394 del; 3105 mod
  Patch: https://git.openjdk.org/valhalla/pull/1278.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1278/head:pull/1278

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

From dsimms at openjdk.org  Tue Oct 15 14:00:21 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Oct 2024 14:00:21 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <aegelwK5HT--ak60q0tK5FJndwLIkiQAv1t5BFzb2Ik=.c4447c4e-67ba-48d0-a70e-bc3f61e9f623@github.com>
References: <aegelwK5HT--ak60q0tK5FJndwLIkiQAv1t5BFzb2Ik=.c4447c4e-67ba-48d0-a70e-bc3f61e9f623@github.com>
Message-ID: <KeZG_Q2rNTQZGVflA8lCPhgAVg3uqZqmCH9RvDRjeBs=.9dab618d-c656-4850-a472-5c235eeab95f@github.com>

> Merge jdk-24+7
> Merge jdk-24+8
> Merge jdk-24+9

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

  Adjust testing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1278/files
  - new: https://git.openjdk.org/valhalla/pull/1278/files/ea380af7..4c189b57

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

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

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

From dsimms at openjdk.org  Tue Oct 15 14:00:22 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Oct 2024 14:00:22 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <aegelwK5HT--ak60q0tK5FJndwLIkiQAv1t5BFzb2Ik=.c4447c4e-67ba-48d0-a70e-bc3f61e9f623@github.com>
References: <aegelwK5HT--ak60q0tK5FJndwLIkiQAv1t5BFzb2Ik=.c4447c4e-67ba-48d0-a70e-bc3f61e9f623@github.com>
Message-ID: <Er99xCCodgzUf-_53L2GZFac3p1kd0bsRI8uBn4LiTI=.70346400-967b-4178-8409-7c8fd3167577@github.com>

On Tue, 15 Oct 2024 08:13:35 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-24+7
> Merge jdk-24+8
> Merge jdk-24+9

This pull request has now been integrated.

Changeset: ab79443c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ab79443c11d7b3aabdd27caa3c0d0056fc5167e9
Stats:     24020 lines in 794 files changed: 14520 ins; 6394 del; 3106 mod

Merge jdk

Merge jdk-24+7
Merge jdk-24+8
Merge jdk-24+9

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

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

From dsimms at openjdk.org  Wed Oct 16 12:34:26 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 16 Oct 2024 12:34:26 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <lluWKYxidgpTy-6FWpabXaECdrDs6Ch4pjbbHXSif4o=.573a7ed7-fb3e-4901-b577-235b1b387f2f@github.com>

Merge jdk-24+10
Merge jdk-24+11
Merge jdk-24+12

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

Commit messages:
 - Merge tag 'jdk-24+12' into lworld_merge_jdk_24_10
 - 8334357: Use NonInterleavingLogStream for report_metadata_oome
 - 8333265: De-duplicate method references in java.util.stream.FindOps
 - 8338146: Improve Exchanger performance with VirtualThreads
 - 8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier
 - 8338677: Improve startup of memory access var handles by simplifying combinator chains
 - 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor
 - 8338490: Serial: Move Generation::print_on to subclasses
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations
 - 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode
 - ... and 212 more: https://git.openjdk.org/valhalla/compare/ab79443c...4bdd4867

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

Changes: https://git.openjdk.org/valhalla/pull/1279/files
  Stats: 31039 lines in 933 files changed: 16301 ins; 10108 del; 4630 mod
  Patch: https://git.openjdk.org/valhalla/pull/1279.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1279/head:pull/1279

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

From dsimms at openjdk.org  Wed Oct 16 14:12:42 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 16 Oct 2024 14:12:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <lluWKYxidgpTy-6FWpabXaECdrDs6Ch4pjbbHXSif4o=.573a7ed7-fb3e-4901-b577-235b1b387f2f@github.com>
References: <lluWKYxidgpTy-6FWpabXaECdrDs6Ch4pjbbHXSif4o=.573a7ed7-fb3e-4901-b577-235b1b387f2f@github.com>
Message-ID: <KxP1iPXV7_yel2CD1OzlcGStutbgZ4WdLTwAhdMTElg=.18049839-c024-4eb0-96d8-e3a1c911ebe3@github.com>

On Wed, 16 Oct 2024 12:27:52 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-24+10
> Merge jdk-24+11
> Merge jdk-24+12

This pull request has now been integrated.

Changeset: a995dd30
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a995dd30548984f4be81ab9b55979a72793badbd
Stats:     31039 lines in 933 files changed: 16301 ins; 10108 del; 4630 mod

Merge jdk

Merge jdk-24+10
Merge jdk-24+11
Merge jdk-24+12

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

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

From jesper at selskabet.org  Wed Oct 16 16:34:23 2024
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Wed, 16 Oct 2024 18:34:23 +0200
Subject: Picked up JDK-8199429
Message-ID: <B32F1AA3-2F57-4306-92C7-40842AB2C4C0@selskabet.org>

Hi list

Emboldened by talks at Deoxx in Antwerp, I?ve picked up the valhalla repo again, and contributed towards fixing JDK-8199429 <https://bugs.openjdk.org/browse/JDK-8199429>. There?s a WIP pull request, but I?ll need some guidance wrt. the finer points of what we want to achieve.

And anyway: Is work on this particular ticket helpful for the progress for Valhall (I chose it as it was unassigned and had a fix version ?repo-valhalla?)

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

From dsimms at openjdk.org  Thu Oct 17 03:46:13 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 17 Oct 2024 03:46:13 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <4-lS5T4cYjtceiiaC7ofEaXZh2n9sxYpUwdi_i6zbGs=.74b8b5e4-d62b-4a35-b550-0aa608df878b@github.com>

Merge tag 'jdk-24+13' into lworld_merge_jdk_24_13
Added tag jdk-24+13 for changeset ff59532d

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

Commit messages:
 - Merge tag 'jdk-24+13' into lworld_merge_jdk_24_13
 - 8338678: Erroneous parameterized type represented as <any>
 - 8324859: Improve error recovery
 - 8327381: Refactor type-improving transformations in BoolNode::Ideal to BoolNode::Value
 - 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property
 - 8335120: assert(!target->can_be_statically_bound() || target == cha_monomorphic_target) failed
 - 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource
 - 8338888: SystemDictionary::class_name_symbol has incorrect length check
 - 8339126: JNI exception pending in Inflater.c
 - 8258483: [TESTBUG] gtest CollectorPolicy.young_scaled_initial_ergo_vm fails if heap is too small
 - ... and 63 more: https://git.openjdk.org/valhalla/compare/a995dd30...01e95697

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

Changes: https://git.openjdk.org/valhalla/pull/1281/files
  Stats: 8132 lines in 332 files changed: 6479 ins; 716 del; 937 mod
  Patch: https://git.openjdk.org/valhalla/pull/1281.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1281/head:pull/1281

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

From dsimms at openjdk.org  Thu Oct 17 07:04:09 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 17 Oct 2024 07:04:09 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <4-lS5T4cYjtceiiaC7ofEaXZh2n9sxYpUwdi_i6zbGs=.74b8b5e4-d62b-4a35-b550-0aa608df878b@github.com>
References: <4-lS5T4cYjtceiiaC7ofEaXZh2n9sxYpUwdi_i6zbGs=.74b8b5e4-d62b-4a35-b550-0aa608df878b@github.com>
Message-ID: <BqdNpIiPgid0r1UFcsR3xxYV_SwWsjmnjSrXLil-rXE=.16f26695-8a17-4937-9271-80986de5ff18@github.com>

> Merge tag 'jdk-24+13' into lworld_merge_jdk_24_13
> Added tag jdk-24+13 for changeset ff59532d

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

  Adjust testing

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1281/files
  - new: https://git.openjdk.org/valhalla/pull/1281/files/01e95697..63399922

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

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

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

From dsimms at openjdk.org  Thu Oct 17 07:04:10 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 17 Oct 2024 07:04:10 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <4-lS5T4cYjtceiiaC7ofEaXZh2n9sxYpUwdi_i6zbGs=.74b8b5e4-d62b-4a35-b550-0aa608df878b@github.com>
References: <4-lS5T4cYjtceiiaC7ofEaXZh2n9sxYpUwdi_i6zbGs=.74b8b5e4-d62b-4a35-b550-0aa608df878b@github.com>
Message-ID: <y8jHpGeWC_dTcYUo4pzeUvfglr0RAuHE1PlAVQtONsU=.31429798-212d-4f0a-a09a-1fd04afd9a28@github.com>

On Thu, 17 Oct 2024 03:40:31 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-24+13' into lworld_merge_jdk_24_13
> Added tag jdk-24+13 for changeset ff59532d

This pull request has now been integrated.

Changeset: 9d28ca00
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9d28ca00bc9f31cba07af1e4071b5901ffabfc53
Stats:     8134 lines in 333 files changed: 6481 ins; 716 del; 937 mod

Merge jdk

Merge jdk-24+13

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

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

From dsimms at openjdk.org  Sat Oct 19 12:00:00 2024
From: dsimms at openjdk.org (David Simms)
Date: Sat, 19 Oct 2024 12:00:00 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <7AjezCVsB6LZjhZj-Goj495S-k23OwO-YsfcN3waOt4=.54eaafe1-92b1-49eb-a237-75f088872d8b@github.com>

Merge jdk-24+14

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

Commit messages:
 - classfile API naming changes
 - Merge tag 'jdk-24+14' into lworld_merge_jdk_24_14
 - 8332461: ubsan : dependencies.cpp:906:3: runtime error: load of value 4294967295, which is not a valid value for type 'DepType'
 - 8339316: Test runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java fails after  JDK-8338257
 - 8338937: Optimize the string concatenation of ClassDesc
 - 8338530: CDS warning Skipping java/lang/invoke/BoundMethodHandle$Species_LLLL
 - 8339233: Test javax/swing/JButton/SwingButtonResizeTestWithOpenGL.java#id failed: Button renderings are different after window resize
 - 8338924: C1: assert(0 <= i && i < _len) failed: illegal index 5 for length 5
 - 8339492: StackMapDecoder::writeFrames makes lots of allocations
 - 8332901: Select{Current,New}ItemTest.java for Choice don't open popup on macOS
 - ... and 66 more: https://git.openjdk.org/valhalla/compare/9d28ca00...67ae79b7

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

Changes: https://git.openjdk.org/valhalla/pull/1282/files
  Stats: 8892 lines in 396 files changed: 4952 ins; 1710 del; 2230 mod
  Patch: https://git.openjdk.org/valhalla/pull/1282.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1282/head:pull/1282

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

From dsimms at openjdk.org  Sat Oct 19 16:46:26 2024
From: dsimms at openjdk.org (David Simms)
Date: Sat, 19 Oct 2024 16:46:26 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <7AjezCVsB6LZjhZj-Goj495S-k23OwO-YsfcN3waOt4=.54eaafe1-92b1-49eb-a237-75f088872d8b@github.com>
References: <7AjezCVsB6LZjhZj-Goj495S-k23OwO-YsfcN3waOt4=.54eaafe1-92b1-49eb-a237-75f088872d8b@github.com>
Message-ID: <Ag8mCxn_gUnW1s-IWEBIAUiBKoM7-eqw8-PmzF6yILQ=.36624bfa-1a13-426d-b372-29cb4208d38f@github.com>

On Sat, 19 Oct 2024 09:21:16 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-24+14

This pull request has now been integrated.

Changeset: 88b2b86e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/88b2b86ee294aca51083b2e85b3f002a7baeac1c
Stats:     8892 lines in 396 files changed: 4952 ins; 1710 del; 2230 mod

Merge jdk

Merge jdk-24+14

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

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

From darcy at openjdk.org  Mon Oct 21 19:46:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 21 Oct 2024 19:46:37 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16 [v3]
In-Reply-To: <G-GgsSO5gxhnfvElSRfwlLd9-yV6tU-nv86HscUneWw=.a4fdfedf-7e36-4334-9ba8-1e5ec56f382e@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
 <G-GgsSO5gxhnfvElSRfwlLd9-yV6tU-nv86HscUneWw=.a4fdfedf-7e36-4334-9ba8-1e5ec56f382e@github.com>
Message-ID: <PYxAhnZt73Bm_xgC-9bWkYzboQvIGFDhLq3fgMxFcKk=.4842300f-0f76-430b-82a0-a0dd4812d726@github.com>

On Fri, 4 Oct 2024 14:47:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments.

Looks fine.


For future work, having a single copy of the floating-point value -> toString text somewhere and then having it referenced by Double::toString(double), Float::toString(float), Float16::toString(Float16) might be a better structure for the docs.

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

Marked as reviewed by darcy (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1260#pullrequestreview-2383163775

From duke at openjdk.org  Tue Oct 22 12:02:55 2024
From: duke at openjdk.org (duke)
Date: Tue, 22 Oct 2024 12:02:55 GMT
Subject: [lworld+fp16] RFR: 8341245: Add 'shortest length' toString() to
 Float16 [v3]
In-Reply-To: <G-GgsSO5gxhnfvElSRfwlLd9-yV6tU-nv86HscUneWw=.a4fdfedf-7e36-4334-9ba8-1e5ec56f382e@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
 <G-GgsSO5gxhnfvElSRfwlLd9-yV6tU-nv86HscUneWw=.a4fdfedf-7e36-4334-9ba8-1e5ec56f382e@github.com>
Message-ID: <UGFgdwKwJqJImVCqzTTnVvERn-nJfb2ODkQudolMW7Q=.7969c93c-5788-4ba5-9cd2-519d9aa4b807@github.com>

On Fri, 4 Oct 2024 14:47:25 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1260#issuecomment-2429086991

From rgiulietti at openjdk.org  Tue Oct 22 15:08:26 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 22 Oct 2024 15:08:26 GMT
Subject: [lworld+fp16] Integrated: 8341245: Add 'shortest length' toString() to
 Float16
In-Reply-To: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
References: <C14adNAT2M0ZTj2PWgvqi-kfY1ysmF6NR68-9YBteL4=.9d5a5e95-5df2-4408-b4f6-2a840c7b07ea@github.com>
Message-ID: <VwCxxZBtWZHvgC5YaTkzGkivvZV23DPdwgiyN75Axc8=.ec9eb7e6-0a63-47d3-af0e-cf751983e1c5@github.com>

On Mon, 30 Sep 2024 15:48:12 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `Float16.toString()` with the same 'shortest length' properties as of `[Double|Float].toString()`.

This pull request has now been integrated.

Changeset: a24a240b
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
Committer: Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a24a240bd0a2ebe2a8f17094a31f259976544f44
Stats:     816 lines in 5 files changed: 799 ins; 2 del; 15 mod

8341245: Add 'shortest length' toString() to Float16

Reviewed-by: darcy

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

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

From rriggs at openjdk.org  Tue Oct 22 15:37:35 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Oct 2024 15:37:35 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v3]
In-Reply-To: <VEv3pB1F23scq6GGs8ksQEcxdGZNNUkUaWPNrvZjlVs=.013fd302-559a-4d7d-9594-857d4d4f5d7e@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
 <VEv3pB1F23scq6GGs8ksQEcxdGZNNUkUaWPNrvZjlVs=.013fd302-559a-4d7d-9594-857d4d4f5d7e@github.com>
Message-ID: <6M2GuP1-NpIY8PGMdPJYSl09e8oqMrEfat6fuR1e0hA=.c20fdba0-10c0-4fd8-9052-ce6ccede282f@github.com>

On Wed, 9 Oct 2024 18:17:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Serialization and deerialization of value classes. 
>> For java.base value classes migrated from identity classes:
>>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>>   - Must have a constructor or static factory method:
>>     - annotated with jdk.internal.value.DeserializeConstrucctor
>>     - constructor parameters must match order and types of serializable fields of the class
>>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>>   - Migrated value classes are serialized using the same format/fields as the identity class
>> 
>> Non-migrated value classes throw InvalidClassException
>> 
>> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
>> 
>> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   From review comments.
>   Tidy up unreachable IllegalAccessException after setAccessible; throw InternalError.
>   Move declaration of local into for loop header.
>   Cleanup TRACE Property parsing.
>   Improve test output readability.

Are there any more review comments; I'd like to get this integrated.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1248#issuecomment-2429615623

From rriggs at openjdk.org  Tue Oct 22 17:13:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Oct 2024 17:13:16 GMT
Subject: [lworld] RFR: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes [v4]
In-Reply-To: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
Message-ID: <j0rMbAz-AHPzVPfkT-XoUYWfysyeWjj2tVTF2NwZNSo=.25d8c364-6488-4e3d-b528-6bae09a65ca2@github.com>

> Serialization and deerialization of value classes. 
> For java.base value classes migrated from identity classes:
>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>   - Must have a constructor or static factory method:
>     - annotated with jdk.internal.value.DeserializeConstrucctor
>     - constructor parameters must match order and types of serializable fields of the class
>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>   - Migrated value classes are serialized using the same format/fields as the identity class
> 
> Non-migrated value classes throw InvalidClassException
> 
> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
> 
> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.

Roger Riggs 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
 - From review comments.
   Tidy up unreachable IllegalAccessException after setAccessible; throw InternalError.
   Move declaration of local into for loop header.
   Cleanup TRACE Property parsing.
   Improve test output readability.
 - Merge branch 'lworld' into 8340409-simple-value-deserialize
 - Merge branch 'lworld' into 8340409-simple-value-deserialize
 - 8340409: [lworld] Simple serialization and deserialization of core migrated classes
   
   Serialization and deerialization of value classes.
   For java.base value classes being migrated from identity classes:
     - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
     - Must have a constructor or static factory method:
       - annotated with jdk.internal.value.DeserializeConstrucctor
       - constructor parameters must match order and types of serializable fields of the class
     - Value class must not have superclass with fields; only Object or abstract w/o fields
     - Uses same technique as for Records to extract and concat values from stream to invoke constructor
     - Migrated value classes are serialized using the same format/fields as the identity class
   
   Non-migrated value classes throw InvalidClassException
   
   Along the way, refactored code to break out different modes of deserialization:
   full custom deserialization with custom data, default deserialization only,
   externalizable, no local class, record, and then added mode to deserialize a value class.
   
   Updates to value class tests and added a combo test to check many combinations
   of value and identity classes with different parameters.

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

Changes: https://git.openjdk.org/valhalla/pull/1248/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1248&range=03
  Stats: 3174 lines in 21 files changed: 2588 ins; 423 del; 163 mod
  Patch: https://git.openjdk.org/valhalla/pull/1248.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1248/head:pull/1248

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

From rriggs at openjdk.org  Tue Oct 22 19:52:45 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 22 Oct 2024 19:52:45 GMT
Subject: [lworld] RFR: 8342276: [lworld] Apply LIBRARY.properties to stabiliize
 --enable-preview for tests
Message-ID: <uvVCpWifIK-4lz9FDSKgj7vOJ2tSsYIHtGboixTuM0s=.c4c9e9b4-836e-499a-a24c-db62b5c2330c@github.com>

Create LIBRARY.properties files to set the value of `enablePreview` for sensitive test library roots.

The top level test library is set with `enablePreview = false` so that when compiled they will be able to be used with or without enablePreview.

Individual tests that use preview features and test library files that use preview features will need to be compiled based on the settings in each test.

Some tests are modified to remove explicit building or compilation and fall back to implicit compiles with the prevailing enablePreview setting.

There are other test library roots that declare `enablePreview = true` appropriate to their uses.

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

Commit messages:
 - Remove unnecessary @enablePreview tags
 - Cleanup LIBRARY.properties files to fix remaining test issues
 - 8342276: [lworld] Apply LIBRARY.properties to stabiliize --enable-preview for tests

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

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

From fparain at openjdk.org  Wed Oct 23 12:16:25 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 23 Oct 2024 12:16:25 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic and
 nullable flattening
Message-ID: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>

Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
The patch includes the generation of two new flat fields layouts: atomic and nullable.
The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.

There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.

Fred

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

Commit messages:
 - Fix paths on Windows
 - Merge remote-tracking branch 'upstream/lworld' into nullable_flat_2
 - Fixes from initial reviews
 - Add support for oops embedded in nullable flat fields
 - Implementation of new fields layouts with interpreter support

Changes: https://git.openjdk.org/valhalla/pull/1275/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1275&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341757
  Stats: 2011 lines in 72 files changed: 960 ins; 498 del; 553 mod
  Patch: https://git.openjdk.org/valhalla/pull/1275.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1275/head:pull/1275

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

From coleenp at openjdk.org  Wed Oct 23 12:16:26 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 12:16:26 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
Message-ID: <6QjthIB3OU6ABWW26VgQfR7gjV23Sc3Hyy6gtdIPDho=.000c4671-f8f9-4bd4-b5a0-2360043f654f@github.com>

On Fri, 11 Oct 2024 13:45:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
> The patch includes the generation of two new flat fields layouts: atomic and nullable.
> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
> 
> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
> 
> Fred

This is sort of a surface review of all but the actual field layout part (the meat of the change) until I ran out of steam.

src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.cpp line 155:

> 153:   // "short-cuts" to be made from asm. What there is, appears to have the same
> 154:   // cost in C++, so just "call_VM_leaf" for now rather than maintain hundreds
> 155:   // of hand-rolled instructions...

Never apologize for not writing assembly!

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

> 519:   } else {
> 520:     assert(array->klass()->is_flatArray_klass(), "should not be called");
> 521:     array->value_copy_to_index(value, index, LayoutKind::PAYLOAD); // Non atomic is currently the only layout supported by flt arrays

s/flt/flat/

src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 55:

> 53: //
> 54: 
> 55: #define MAX_ATOMIC_OP_SIZE sizeof(jlong)

We've been avoiding Java types where possible (not consistently).  Can you change to uint64_t?

src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 348:

> 346: 
> 347:   int null_marker_offset() const { return _null_marker_offset; }
> 348:   bool is_empty_inline_class() const { return _is_empty_inline_class; }

Nit, it would look nice if you lined up {'s here, as we do in other places that are functions like this.

src/hotspot/share/gc/shared/barrierSetRuntime.cpp line 38:

> 36: 
> 37: JRT_LEAF(void, BarrierSetRuntime::value_copy2(void* src, void* dst, InlineLayoutInfo* li))
> 38:   HeapAccess<>::value_copy(src, dst, li->klass(), li->kind());

This can't be an overload because it's called from macro assembler?  maybe value_copy_with_layout ? That's not too long...
Or are you going to remove the first when the compiler and unsafe support is implemented. This is fine then.

src/hotspot/share/interpreter/interpreterRuntime.cpp line 283:

> 281:       InlineLayoutInfo* li = klass->inline_layout_info_adr(index);
> 282:       li->set_klass(InlineKlass::cast(field_k));
> 283:       li->set_kind(LayoutKind::REFERENCE);

Do you always set these together?  Might be good to have one function like fill_in() that fills both values in.

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

> 83:   *((int*)adr_atomic_size_in_bytes()) = -1;
> 84:   *((int*)adr_nullable_size_in_bytes()) = -1;
> 85:   *((int*)adr_null_marker_offset()) = -1;

hm don't know what this is.

src/hotspot/share/oops/instanceKlass.hpp line 191:

> 189:   static ByteSize klass_offset() { return in_ByteSize(offset_of(InlineLayoutInfo, _klass)); }
> 190:   static ByteSize null_marker_offset_offset() { return in_ByteSize(offset_of(InlineLayoutInfo, _null_marker_offset)); }
> 191: 

Should this be in inlineKlass.hpp ?  Is that included here?  It seems better there and then #include that.
Edit: it is complicated though isn't it?  Maybe it is better here but I don't like extra classes in header files, especially this one since it's sort of key.  Maybe it's better in its own header file?

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

PR Review: https://git.openjdk.org/valhalla/pull/1275#pullrequestreview-2378835003
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806936155
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806937058
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806940480
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806942549
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806954345
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806965794
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806970340
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1806974674

From heidinga at openjdk.org  Wed Oct 23 12:16:28 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
Message-ID: <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>

On Fri, 11 Oct 2024 13:45:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
> The patch includes the generation of two new flat fields layouts: atomic and nullable.
> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
> 
> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
> 
> Fred

General question - does the Valhalla CDS support need to be updated to handle the Klass pointers in InlineLayoutInfo when this is merged?

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

> 519:   } else {
> 520:     assert(array->klass()->is_flatArray_klass(), "should not be called");
> 521:     array->value_copy_to_index(value, index, LayoutKind::PAYLOAD); // Non atomic is currently the only layout supported by flt arrays

Suggestion:

    array->value_copy_to_index(value, index, LayoutKind::PAYLOAD); // Non atomic is currently the only layout supported by flat arrays

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

> 1564:     _temp_field_info->adr_at(idx)->set_index(idx);
> 1565:     _static_oop_count++;
> 1566:     // Inject static ".reset" field

I think we should rename this field to be something like `null_examplar` or `null_reset`.  
Suggestion:

    // Inject static ".null_examplar" field.  This is the same as the `.default field but will never have its null-channel set to non-zero.

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 723:

> 721:   _field_info(field_info),
> 722:   _info(info),
> 723:   // _inline_type_field_klasses(inline_type_field_klasses),

Remove?

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 933:

> 931:         // Presence of a must_be_atomic field must revert the _must_be_atomic flag of the holder to true
> 932:         if (vk->must_be_atomic()) {
> 933:           _must_be_atomic = true;

Is this something we want to log so it's clear why a `@LooselyConsistent` class is forced to be atomic?

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1119:

> 1117: 
> 1118:   // Determining if the value class is naturally atomic:
> 1119:   if ((!_layout->super_has_fields() && _declared_non_static_fields_count <= 1 && !_has_non_naturally_atomic_fields)

Suggestion:

  if ((!_layout->super_has_fields() && _declared_non_static_fields_count == 1 && !_has_non_naturally_atomic_fields)


Should the check be `==1` rather than `<=1`?  We don't support empty values (we inject a field)

src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1197:

> 1195:     // to shift all fields in the raw layout, but this operation is possible only if the class
> 1196:     // doesn't have inherited fields (offsets of inherited fields cannot be changed). If a
> 1197:     // field shift is needed but not possible, atomic layouts are disabled.

Suggestion:

    // field shift is needed but not possible, all atomic layouts are disabled and only reference and loosely consistent are supported.

src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 67:

> 65:     FLAT,                  // flat field
> 66:     INHERITED,             // field(s) inherited from super classes
> 67:     NULL_MARKER            // stores the null marker for a flat field

Does this mean we only allocate a `NULL_MARKER` for non-abstract value classes?  I think that makes sense but confirmation would be good.  This may affect future opts for sealed hierarchies as the null channel may be in different places for each class.

src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 290:

> 288:   GrowableArray<FieldInfo>* _field_info;
> 289:   FieldLayoutInfo* _info;
> 290:   // Array<InlineKlass*>* _inline_type_field_klasses;

Remove?

src/hotspot/share/classfile/javaClasses.cpp line 3785:

> 3783: 
> 3784: #define BOXING_FIELDS_DO(macro) \
> 3785:   macro(_value_offset,      byteKlass, "value", byte_signature, false); \

Is this a Valhalla change?  I'm not sure I understand this change

src/hotspot/share/interpreter/interpreterRuntime.cpp line 317:

> 315: 
> 316:   InlineLayoutInfo* layout_info = holder->inline_layout_info_adr(entry->field_index());
> 317:   InlineKlass* field_vklass = layout_info->klass();

Why `vklass`?  Valhalla Klass?

src/hotspot/share/oops/inlineKlass.hpp line 200:

> 198:     return static_cast<const InlineKlass*>(k);
> 199:   }
> 200:   // static InlineKlass* cast(Klass* k);

Suggestion:

src/hotspot/share/oops/instanceKlass.cpp line 183:

> 181:   if (_loadable_descriptors == nullptr) return false;
> 182:   for (int i = 0; i < _loadable_descriptors->length(); i++) {
> 183:         // Symbol* class_name = _constants->klass_at_noresolve(_loadable_descriptors->at(i));

Suggestion:

src/hotspot/share/oops/instanceKlass.cpp line 1374:

> 1372:                 CLEAR_PENDING_EXCEPTION;
> 1373:             }
> 1374:             THROW_OOP(e());

If I understand this code correctly, an OutOfMemoryError here will make the class unusable, which is a bit surprising.  Is it possible to instead disable all layouts except the REFERENCE if an OOM is thrown here?

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

PR Review: https://git.openjdk.org/valhalla/pull/1275#pullrequestreview-2372924439
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1803376234
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808893029
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808915598
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808965782
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808975301
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808982551
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808904155
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808905176
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808990396
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1808996534
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809006518
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809008647
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1810852592

From fparain at openjdk.org  Wed Oct 23 12:16:28 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
Message-ID: <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>

On Mon, 21 Oct 2024 15:11:50 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

> General question - does the Valhalla CDS support need to be updated to handle the Klass pointers in InlineLayoutInfo when this is merged?

The InstanceKlass' metaspace_pointers_do() method has been updated to process the _inline_layout_info_array, and the InlineLayoutInfo class has its own metaspace_pointers_do() method to process its _klass pointer. Did I miss something?

> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 933:
> 
>> 931:         // Presence of a must_be_atomic field must revert the _must_be_atomic flag of the holder to true
>> 932:         if (vk->must_be_atomic()) {
>> 933:           _must_be_atomic = true;
> 
> Is this something we want to log so it's clear why a `@LooselyConsistent` class is forced to be atomic?

So far, we have avoided logging individual layout decisions. Only the final result is available as a diagnostic feature. If we start with this one, we could have many other decisions to add to the logging.

> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1119:
> 
>> 1117: 
>> 1118:   // Determining if the value class is naturally atomic:
>> 1119:   if ((!_layout->super_has_fields() && _declared_non_static_fields_count <= 1 && !_has_non_naturally_atomic_fields)
> 
> Suggestion:
> 
>   if ((!_layout->super_has_fields() && _declared_non_static_fields_count == 1 && !_has_non_naturally_atomic_fields)
> 
> 
> Should the check be `==1` rather than `<=1`?  We don't support empty values (we inject a field)

Empty abstract values have no instance fields. The ".empty" field is only added to concrete value classes.

> src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 67:
> 
>> 65:     FLAT,                  // flat field
>> 66:     INHERITED,             // field(s) inherited from super classes
>> 67:     NULL_MARKER            // stores the null marker for a flat field
> 
> Does this mean we only allocate a `NULL_MARKER` for non-abstract value classes?  I think that makes sense but confirmation would be good.  This may affect future opts for sealed hierarchies as the null channel may be in different places for each class.

Correct. The null-marker is only added to concrete value classes. In fact, all the flat layouts are computed only for non-abstract value classes. If this is going to be an issue in the future, we should discuss another design before pushing those changes.

> src/hotspot/share/classfile/javaClasses.cpp line 3785:
> 
>> 3783: 
>> 3784: #define BOXING_FIELDS_DO(macro) \
>> 3785:   macro(_value_offset,      byteKlass, "value", byte_signature, false); \
> 
> Is this a Valhalla change?  I'm not sure I understand this change

JavaClasses::check_offsets() verifies the offset of the boxing classes. The code used to handle two offsets, one taken rom j.l.Integer and used for Byte, Char, Short, Int and Float, and another one taken from j.l.Long for Long and Double. If you think of an object with compress class pointer, the first group has its field aligned on a 32bits boundary, and the second group has a field aligned on a 64bits boundary. The addition of ATOMIC_NULLABLE_FLAT layout changes of the layout of j.l.Integer and j.l.Float which now must have their field aligned on a 64bits boundary to be copiable atomically with their null marker. The new code now uses the j.l.Byte class as a reference for Byte, Char and Short, and has special cases to handle j.l.Integer and j.l.Float.

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 317:
> 
>> 315: 
>> 316:   InlineLayoutInfo* layout_info = holder->inline_layout_info_adr(entry->field_index());
>> 317:   InlineKlass* field_vklass = layout_info->klass();
> 
> Why `vklass`?  Valhalla Klass?

Value Klass. InstanceKlass pointers are often named ik, but now those two letters can be interpreted as either InstanceKlass or InlineKlass. So, I often use vk or vklass to designate a pointer to an InlineKlass.

> src/hotspot/share/oops/instanceKlass.cpp line 1374:
> 
>> 1372:                 CLEAR_PENDING_EXCEPTION;
>> 1373:             }
>> 1374:             THROW_OOP(e());
> 
> If I understand this code correctly, an OutOfMemoryError here will make the class unusable, which is a bit surprising.  Is it possible to instead disable all layouts except the REFERENCE if an OOM is thrown here?

Only the NULLABLE_ATOMIC_FLAT layout would need to be disabled. But if an OOM is thrown at this stage (class initialization), does it really worth the effort to try to recover the class? It is unlikely the application will be able to allocate an instance of this class anyway.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1275#issuecomment-2429399611
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809251379
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809253832
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809262373
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809282536
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809363690
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1810874464

From heidinga at openjdk.org  Wed Oct 23 12:16:28 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
 <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>
Message-ID: <ALRuMCy3iU4ZrcXAFO5Q6Mi5xqepUjszomaYWS3WbYE=.b59f2f39-2dea-4aa5-ab9e-9995af709450@github.com>

On Tue, 22 Oct 2024 14:10:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> > General question - does the Valhalla CDS support need to be updated to handle the Klass pointers in InlineLayoutInfo when this is merged?
> 
> The InstanceKlass' metaspace_pointers_do() method has been updated to process the _inline_layout_info_array, and the InlineLayoutInfo class has its own metaspace_pointers_do() method to process its _klass pointer. Did I miss something?

No, I missed `it->push(&_inline_layout_info_array, MetaspaceClosure::_writable);` in the instanceKlass.  Thanks for confirming

>> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 933:
>> 
>>> 931:         // Presence of a must_be_atomic field must revert the _must_be_atomic flag of the holder to true
>>> 932:         if (vk->must_be_atomic()) {
>>> 933:           _must_be_atomic = true;
>> 
>> Is this something we want to log so it's clear why a `@LooselyConsistent` class is forced to be atomic?
>
> So far, we have avoided logging individual layout decisions. Only the final result is available as a diagnostic feature. If we start with this one, we could have many other decisions to add to the logging.

Fair enough.  This comment can be resolved.

>> src/hotspot/share/classfile/fieldLayoutBuilder.cpp line 1119:
>> 
>>> 1117: 
>>> 1118:   // Determining if the value class is naturally atomic:
>>> 1119:   if ((!_layout->super_has_fields() && _declared_non_static_fields_count <= 1 && !_has_non_naturally_atomic_fields)
>> 
>> Suggestion:
>> 
>>   if ((!_layout->super_has_fields() && _declared_non_static_fields_count == 1 && !_has_non_naturally_atomic_fields)
>> 
>> 
>> Should the check be `==1` rather than `<=1`?  We don't support empty values (we inject a field)
>
> Empty abstract values have no instance fields. The ".empty" field is only added to concrete value classes.

Thanks for confirming.  This can be resolved,

>> src/hotspot/share/classfile/fieldLayoutBuilder.hpp line 67:
>> 
>>> 65:     FLAT,                  // flat field
>>> 66:     INHERITED,             // field(s) inherited from super classes
>>> 67:     NULL_MARKER            // stores the null marker for a flat field
>> 
>> Does this mean we only allocate a `NULL_MARKER` for non-abstract value classes?  I think that makes sense but confirmation would be good.  This may affect future opts for sealed hierarchies as the null channel may be in different places for each class.
>
> Correct. The null-marker is only added to concrete value classes. In fact, all the flat layouts are computed only for non-abstract value classes. If this is going to be an issue in the future, we should discuss another design before pushing those changes.

We have hypothesized that sealed hierarchies may be a target for future flattening optimizations as users will target the sealed type (typically an interface) for use as fields in their classes with a limited number (sometimes one!) of implementations.

These kinds of optimizations will require additional book-keeping for tracking the null marker, determining the klass of the value, and maybe additional info.  I don't think we want to delay this work for those future optimizations.... we can figure them out under a future RFE

>> src/hotspot/share/classfile/javaClasses.cpp line 3785:
>> 
>>> 3783: 
>>> 3784: #define BOXING_FIELDS_DO(macro) \
>>> 3785:   macro(_value_offset,      byteKlass, "value", byte_signature, false); \
>> 
>> Is this a Valhalla change?  I'm not sure I understand this change
>
> JavaClasses::check_offsets() verifies the offset of the boxing classes. The code used to handle two offsets, one taken rom j.l.Integer and used for Byte, Char, Short, Int and Float, and another one taken from j.l.Long for Long and Double. If you think of an object with compress class pointer, the first group has its field aligned on a 32bits boundary, and the second group has a field aligned on a 64bits boundary. The addition of ATOMIC_NULLABLE_FLAT layout changes of the layout of j.l.Integer and j.l.Float which now must have their field aligned on a 64bits boundary to be copiable atomically with their null marker. The new code now uses the j.l.Byte class as a reference for Byte, Char and Short, and has special cases to handle j.l.Integer and j.l.Float.

Sorry, I may be slow today but I would expect j.l.Byte and j.l.Short/Char to have different field layouts - given a 12byte header, the `value` field of j.l.Byte can start at the first free byte.  Using hand-hacked versions of the print fields output:

 @0 RESERVED 12/-
 @12 REGULAR 1/1 "value" B

and the `value` field of a j.l.Short needs additional alignment:

 @0 RESERVED 12/-
 @12 PADDING 4/1
 @16 REGULAR 2/2 "value" S


What am I missing?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1275#issuecomment-2429471876
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809271732
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809292409
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809270848
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809324644

From coleenp at openjdk.org  Wed Oct 23 12:16:28 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
Message-ID: <SVGnShJ2RAivS9MT49CenpOqRQnb8-AvifDcWsqZMN4=.b8270c04-b154-40ef-9643-839feedb27bb@github.com>

On Mon, 21 Oct 2024 14:04:21 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
>> The patch includes the generation of two new flat fields layouts: atomic and nullable.
>> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
>> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
>> 
>> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
>> 
>> Fred
>
> src/hotspot/share/classfile/classFileParser.cpp line 1566:
> 
>> 1564:     _temp_field_info->adr_at(idx)->set_index(idx);
>> 1565:     _static_oop_count++;
>> 1566:     // Inject static ".reset" field
> 
> I think we should rename this field to be something like `null_examplar` or `null_reset`.  
> Suggestion:
> 
>     // Inject static ".null_examplar" field.  This is the same as the `.default field but will never have its null-channel set to non-zero.

null_exemplar I like that!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809361337

From fparain at openjdk.org  Wed Oct 23 12:16:28 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <ALRuMCy3iU4ZrcXAFO5Q6Mi5xqepUjszomaYWS3WbYE=.b59f2f39-2dea-4aa5-ab9e-9995af709450@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
 <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>
 <ALRuMCy3iU4ZrcXAFO5Q6Mi5xqepUjszomaYWS3WbYE=.b59f2f39-2dea-4aa5-ab9e-9995af709450@github.com>
Message-ID: <36F5eKNAyW9XRPYgtfLfltOqFlVoajuWtDN_-MCIzLw=.e300024b-aa4f-4156-8a8a-b1b4716da8fc@github.com>

On Mon, 21 Oct 2024 18:43:41 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> JavaClasses::check_offsets() verifies the offset of the boxing classes. The code used to handle two offsets, one taken rom j.l.Integer and used for Byte, Char, Short, Int and Float, and another one taken from j.l.Long for Long and Double. If you think of an object with compress class pointer, the first group has its field aligned on a 32bits boundary, and the second group has a field aligned on a 64bits boundary. The addition of ATOMIC_NULLABLE_FLAT layout changes of the layout of j.l.Integer and j.l.Float which now must have their field aligned on a 64bits boundary to be copiable atomically with their null marker. The new code now uses the j.l.Byte class as a reference for Byte, Char and Short, and has special cases to handle j.l.Integer and j.l.Float.
>
> Sorry, I may be slow today but I would expect j.l.Byte and j.l.Short/Char to have different field layouts - given a 12byte header, the `value` field of j.l.Byte can start at the first free byte.  Using hand-hacked versions of the print fields output:
> 
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 "value" B
> 
> and the `value` field of a j.l.Short needs additional alignment:
> 
>  @0 RESERVED 12/-
>  @12 PADDING 4/1
>  @16 REGULAR 2/2 "value" S
> 
> 
> What am I missing?

I don't know why, but we don't have the same layouts.
Here's the ones I have without support for NULLABLE_ATOMIC_FLAT:


Layout of class java/lang/Byte at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
Instance fields:
 @0 RESERVED 12/-
 @12 REGULAR 1/1 "value" B



Layout of class java/lang/Short at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
Instance fields:
 @0 RESERVED 12/-
 @12 REGULAR 2/2 "value" S



Layout of class java/lang/Integer at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
Instance fields:
 @0 RESERVED 12/-
 @12 REGULAR 4/4 "value" I


And the layouts of the same classes with NULLABLE_ATOMIC_FLAT enabled:


Layout of class java/lang/Byte at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
Instance fields:
 @0 RESERVED 12/-
 @12 REGULAR 1/1 "value" B
 @13 NULL_MARKER 1/1



Layout of class java/lang/Short at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
Instance fields:
 @0 RESERVED 12/-
 @12 REGULAR 2/2 "value" S
 @14 NULL_MARKER 1/1



Layout of class java/lang/Integer at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
Instance fields:
 @0 RESERVED 12/-
 @12 PADDING 4/1
 @16 REGULAR 4/4 "value" I
 @20 NULL_MARKER 1/1

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809537292

From heidinga at openjdk.org  Wed Oct 23 12:16:28 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <36F5eKNAyW9XRPYgtfLfltOqFlVoajuWtDN_-MCIzLw=.e300024b-aa4f-4156-8a8a-b1b4716da8fc@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
 <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>
 <ALRuMCy3iU4ZrcXAFO5Q6Mi5xqepUjszomaYWS3WbYE=.b59f2f39-2dea-4aa5-ab9e-9995af709450@github.com>
 <36F5eKNAyW9XRPYgtfLfltOqFlVoajuWtDN_-MCIzLw=.e300024b-aa4f-4156-8a8a-b1b4716da8fc@github.com>
Message-ID: <dagnF-h2qjjCa430IixIji0U5Mzvqyd4V6cMtyNhIH4=.ac357f6a-f932-49ce-9a3f-5b2b779ef47c@github.com>

On Mon, 21 Oct 2024 21:07:05 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Sorry, I may be slow today but I would expect j.l.Byte and j.l.Short/Char to have different field layouts - given a 12byte header, the `value` field of j.l.Byte can start at the first free byte.  Using hand-hacked versions of the print fields output:
>> 
>>  @0 RESERVED 12/-
>>  @12 REGULAR 1/1 "value" B
>> 
>> and the `value` field of a j.l.Short needs additional alignment:
>> 
>>  @0 RESERVED 12/-
>>  @12 PADDING 4/1
>>  @16 REGULAR 2/2 "value" S
>> 
>> 
>> What am I missing?
>
> I don't know why, but we don't have the same layouts.
> Here's the ones I have without support for NULLABLE_ATOMIC_FLAT:
> 
> 
> Layout of class java/lang/Byte at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 "value" B
> 
> 
> 
> Layout of class java/lang/Short at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 2/2 "value" S
> 
> 
> 
> Layout of class java/lang/Integer at 0x7eae3c1357a0 extends java/lang/Number at 0x7eae3c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 4/4 "value" I
> 
> 
> And the layouts of the same classes with NULLABLE_ATOMIC_FLAT enabled:
> 
> 
> Layout of class java/lang/Byte at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 1/1 "value" B
>  @13 NULL_MARKER 1/1
> 
> 
> 
> Layout of class java/lang/Short at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 REGULAR 2/2 "value" S
>  @14 NULL_MARKER 1/1
> 
> 
> 
> Layout of class java/lang/Integer at 0x7bd87c1357a0 extends java/lang/Number at 0x7bd87c1357a0
> Instance fields:
>  @0 RESERVED 12/-
>  @12 PADDING 4/1
>  @16 REGULAR 4/4 "value" I
>  @20 NULL_MARKER 1/1

Thanks Fred.  I think I get it now.  With the pre-valhalla layouts, the j.l.Integer takes 32 bits for the payload so it can start at `@12` and have the correct alignment.  In the Valhalla case, we need the 4bytes of padding to get the 64 bit payload (32 bit int + null marker) aligned correctly to be read atomically.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1810675469

From fparain at openjdk.org  Wed Oct 23 12:16:28 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 23 Oct 2024 12:16:28 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <6QjthIB3OU6ABWW26VgQfR7gjV23Sc3Hyy6gtdIPDho=.000c4671-f8f9-4bd4-b5a0-2360043f654f@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <6QjthIB3OU6ABWW26VgQfR7gjV23Sc3Hyy6gtdIPDho=.000c4671-f8f9-4bd4-b5a0-2360043f654f@github.com>
Message-ID: <csY0B-MN1uELELkjBWuaMWrYbnlszUW9hD0IodLCFM4=.a438ea27-1de9-4b86-9fe7-c22f992ed7f4@github.com>

On Fri, 18 Oct 2024 19:48:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
>> The patch includes the generation of two new flat fields layouts: atomic and nullable.
>> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
>> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
>> 
>> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
>> 
>> Fred
>
> src/hotspot/share/gc/shared/barrierSetRuntime.cpp line 38:
> 
>> 36: 
>> 37: JRT_LEAF(void, BarrierSetRuntime::value_copy2(void* src, void* dst, InlineLayoutInfo* li))
>> 38:   HeapAccess<>::value_copy(src, dst, li->klass(), li->kind());
> 
> This can't be an overload because it's called from macro assembler?  maybe value_copy_with_layout ? That's not too long...
> Or are you going to remove the first when the compiler and unsafe support is implemented. This is fine then.

This is temporary. The original value_copy() method is still there because of arrays. Once arrays have been updated to support the new flat layouts, value_copy() will be removed, and value_copy2() will be renamed value_copy().

> src/hotspot/share/interpreter/interpreterRuntime.cpp line 283:
> 
>> 281:       InlineLayoutInfo* li = klass->inline_layout_info_adr(index);
>> 282:       li->set_klass(InlineKlass::cast(field_k));
>> 283:       li->set_kind(LayoutKind::REFERENCE);
> 
> Do you always set these together?  Might be good to have one function like fill_in() that fills both values in.

Not always. For instance fields, the class of those fields is usually known while parsing the class file (LoadableDescriptors attribute, @NullRestricted annotation), but the layout kind is only known after the field layout computation (post-processing of the parsed stream).

> src/hotspot/share/oops/inlineKlass.cpp line 85:
> 
>> 83:   *((int*)adr_atomic_size_in_bytes()) = -1;
>> 84:   *((int*)adr_nullable_size_in_bytes()) = -1;
>> 85:   *((int*)adr_null_marker_offset()) = -1;
> 
> hm don't know what this is.

Initialization of various fields for layout support in the InlineKlassFixedBlock. In the next patch, they are rewritten using setter methods.

> src/hotspot/share/oops/instanceKlass.hpp line 191:
> 
>> 189:   static ByteSize klass_offset() { return in_ByteSize(offset_of(InlineLayoutInfo, _klass)); }
>> 190:   static ByteSize null_marker_offset_offset() { return in_ByteSize(offset_of(InlineLayoutInfo, _null_marker_offset)); }
>> 191: 
> 
> Should this be in inlineKlass.hpp ?  Is that included here?  It seems better there and then #include that.
> Edit: it is complicated though isn't it?  Maybe it is better here but I don't like extra classes in header files, especially this one since it's sort of key.  Maybe it's better in its own header file?

The InlineLayoutInfo array is a side data structure associated with InstanceKlass instances (any class with value fields needs this array, and this includes identity classes and abstract classes). This is why it is declared here, like the OopMapBlock. It could be declared in its own header file, but this would add a new file for just 30 lines of code.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809286465
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809358529
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809468512
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1809481070

From rriggs at openjdk.org  Wed Oct 23 13:37:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Oct 2024 13:37:16 GMT
Subject: [lworld] RFR: 8342276: [lworld] Apply LIBRARY.properties to
 stabiliize --enable-preview for tests [v2]
In-Reply-To: <uvVCpWifIK-4lz9FDSKgj7vOJ2tSsYIHtGboixTuM0s=.c4c9e9b4-836e-499a-a24c-db62b5c2330c@github.com>
References: <uvVCpWifIK-4lz9FDSKgj7vOJ2tSsYIHtGboixTuM0s=.c4c9e9b4-836e-499a-a24c-db62b5c2330c@github.com>
Message-ID: <I1IT8HUVyVLTSXuuHt0_jTOxDsJPLrIXdpbAv4U_Tis=.b745ecf2-e81a-4874-a51f-701ad4393140@github.com>

> Create LIBRARY.properties files to set the value of `enablePreview` for sensitive test library roots.
> 
> The top level test library is set with `enablePreview = false` so that when compiled they will be able to be used with or without enablePreview.
> 
> Individual tests that use preview features and test library files that use preview features will need to be compiled based on the settings in each test.
> 
> Some tests are modified to remove explicit building or compilation and fall back to implicit compiles with the prevailing enablePreview setting.
> 
> There are other test library roots that declare `enablePreview = true` appropriate to their uses.

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

 - change jib-profiles.js to use jtreg 7.5
   and remove unnecessary test/langtools/tools/javac/lib/LIBRARY.properties
 - Merge branch 'lworld' into 8342276-fix-library-preview
 - Remove unnecessary @enablePreview tags
 - Cleanup LIBRARY.properties files to fix remaining test issues
 - 8342276: [lworld] Apply LIBRARY.properties to stabiliize --enable-preview for tests
   Create LIBRARY.properties files to set the value of `enablePreview` for sensitive test library roots.
   
   The top level test library is set with `enablePreview = false` so that
   when compiled they will be able to be used with or without enablePreview.
   
   Individual tests that use preview features and test library files that use
   preview features will need to be compiled based on the settings in each test.
   
   Some tests are modified to remove explicit building or compilation and
   fall back to implicit compiles with the prevaining enablePreview setting.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1280/files
  - new: https://git.openjdk.org/valhalla/pull/1280/files/c5b384e9..05a0dfda

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

  Stats: 47844 lines in 1517 files changed: 27602 ins; 12490 del; 7752 mod
  Patch: https://git.openjdk.org/valhalla/pull/1280.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1280/head:pull/1280

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

From rriggs at openjdk.org  Wed Oct 23 14:10:35 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 23 Oct 2024 14:10:35 GMT
Subject: [lworld] Integrated: 8342276: [lworld] Apply LIBRARY.properties to
 stabiliize --enable-preview for tests
In-Reply-To: <uvVCpWifIK-4lz9FDSKgj7vOJ2tSsYIHtGboixTuM0s=.c4c9e9b4-836e-499a-a24c-db62b5c2330c@github.com>
References: <uvVCpWifIK-4lz9FDSKgj7vOJ2tSsYIHtGboixTuM0s=.c4c9e9b4-836e-499a-a24c-db62b5c2330c@github.com>
Message-ID: <5ga82FxdERqFsTRYTLERO9k6m4MZpvb2mLWTJN2E9ss=.239e5a40-1341-4a13-90c2-96e45fe0730c@github.com>

On Wed, 16 Oct 2024 13:26:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create LIBRARY.properties files to set the value of `enablePreview` for sensitive test library roots.
> 
> The top level test library is set with `enablePreview = false` so that when compiled they will be able to be used with or without enablePreview.
> 
> Individual tests that use preview features and test library files that use preview features will need to be compiled based on the settings in each test.
> 
> Some tests are modified to remove explicit building or compilation and fall back to implicit compiles with the prevailing enablePreview setting.
> 
> There are other test library roots that declare `enablePreview = true` appropriate to their uses.

This pull request has now been integrated.

Changeset: 72472c42
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/72472c42e03676b45a556254132c91ab3c2b974b
Stats:     24 lines in 21 files changed: 6 ins; 10 del; 8 mod

8342276: [lworld] Apply LIBRARY.properties to stabiliize --enable-preview for tests

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

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

From bkilambi at openjdk.org  Wed Oct 23 14:12:56 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 23 Oct 2024 14:12:56 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion routines
Message-ID: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>

This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions.

Performance numbers on aarch64 machine with SVE support :

Benchmark                         (vectorDim)   Gain
Float16OpsBenchmark.fp16ToDouble  1024          18.23
Float16OpsBenchmark.fp16ToInt     1024          1.93
Float16OpsBenchmark.fp16ToLong    1024          3.95

The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic).

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

Commit messages:
 - 8341414: Add support for FP16 conversion routines

Changes: https://git.openjdk.org/valhalla/pull/1283/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1283&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341414
  Stats: 1323 lines in 32 files changed: 596 ins; 2 del; 725 mod
  Patch: https://git.openjdk.org/valhalla/pull/1283.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1283/head:pull/1283

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

From rriggs at openjdk.org  Thu Oct 24 14:51:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 24 Oct 2024 14:51:38 GMT
Subject: [lworld] Integrated: 8340409: [lworld] Simple serialization and
 deserialization of core migrated classes
In-Reply-To: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
References: <fMvQxd7AAuRwNcavgBFy3EmW3CkyYgUssxb1tsYaQn0=.4f32d2f3-cde4-463a-9313-8274f1477952@github.com>
Message-ID: <VGX8_Y7CVnrf3mIm3PMkuzo3GUxTi-Q7f0pFUVsK8Bs=.1caf7a98-5ae0-4e42-8057-05de6bab36a8@github.com>

On Wed, 18 Sep 2024 20:31:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Serialization and deerialization of value classes. 
> For java.base value classes migrated from identity classes:
>   - Must be annotated with jdk.internal.MigratedValueClass (in tests too)
>   - Must have a constructor or static factory method:
>     - annotated with jdk.internal.value.DeserializeConstrucctor
>     - constructor parameters must match order and types of serializable fields of the class
>   - Value class must not have superclass with fields; only Object or abstract w/o fields
>   - Uses same technique as for Records to extract and concat values from stream to invoke constructor
>   - Migrated value classes are serialized using the same format/fields as the identity class
> 
> Non-migrated value classes throw InvalidClassException
> 
> Along the way, refactored code to break out different modes of deserialization: full custom deserialization with custom data, default deserialization only, externalizable, no local class, record, and then added mode to deserialize a value class.
> 
> Updates to value class tests and added a combo test to check many combinations of value and identity classes with different parameters.

This pull request has now been integrated.

Changeset: e02c628f
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e02c628f867d564bd3ddf644ec2fcc465c75b8f3
Stats:     3174 lines in 21 files changed: 2588 ins; 423 del; 163 mod

8340409: [lworld] Simple serialization and deserialization of core migrated classes

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

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

From fparain at openjdk.org  Fri Oct 25 13:29:54 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 25 Oct 2024 13:29:54 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v2]
In-Reply-To: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
Message-ID: <OI-M4Xd33aDjTipmzDe1aRYD4TuVkYSJb8QUVG6OKxw=.2babb0fd-2e3c-4ef7-a972-6e09625570ef@github.com>

> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
> The patch includes the generation of two new flat fields layouts: atomic and nullable.
> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
> 
> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
> 
> Fred

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

  Fix bugs in aarch64 get_default_value_oop() method

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1275/files
  - new: https://git.openjdk.org/valhalla/pull/1275/files/ceaa7c8a..0eacc549

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

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

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

From jbhateja at openjdk.org  Mon Oct 28 12:30:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Oct 2024 12:30:25 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion
 routines
In-Reply-To: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
References: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
Message-ID: <hHzEfLV_AFGfdala4duuztQ5iigpdwgrOld1efMjCes=.3de8be53-56c6-425c-b51e-f3a1b6aa8f3d@github.com>

On Wed, 23 Oct 2024 14:07:52 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions.
> 
> Performance numbers on aarch64 machine with SVE support :
> 
> 
> Benchmark                         (vectorDim)   Gain
> Float16OpsBenchmark.fp16ToDouble  1024          18.23
> Float16OpsBenchmark.fp16ToInt     1024          1.93
> Float16OpsBenchmark.fp16ToLong    1024          3.95
> 
> 
> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic).

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

> 641:     @IntrinsicCandidate
> 642:     public int intValue() {
> 643:         return (int)floatValue();

Should it be handled trough Idealization xform ?

ConvHF2F + ConvF2I => ConvHF2I

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

> 651:      */
> 652:     @Override
> 653:     @IntrinsicCandidate

Should this be handled trough Idealization xform ?

ConvHF2F + ConvF2L => ConvHF2L

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

> 684:     @IntrinsicCandidate
> 685:     public double doubleValue() {
> 686:         return (double)floatValue();

Should it be handled trough Idealization step ?

ConvHF2F + ConvF2D => ConvHF2D

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1818966378
PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1818966022
PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1818968514

From jbhateja at openjdk.org  Mon Oct 28 12:30:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Oct 2024 12:30:25 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion
 routines
In-Reply-To: <hHzEfLV_AFGfdala4duuztQ5iigpdwgrOld1efMjCes=.3de8be53-56c6-425c-b51e-f3a1b6aa8f3d@github.com>
References: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
 <hHzEfLV_AFGfdala4duuztQ5iigpdwgrOld1efMjCes=.3de8be53-56c6-425c-b51e-f3a1b6aa8f3d@github.com>
Message-ID: <QRZYJliG6SdpTGnQSkCMwybXP-VIann7sOxjxXf2LH8=.c45c6cba-b663-412f-9298-fb6f496e2405@github.com>

On Mon, 28 Oct 2024 12:22:43 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions.
>> 
>> Performance numbers on aarch64 machine with SVE support :
>> 
>> 
>> Benchmark                         (vectorDim)   Gain
>> Float16OpsBenchmark.fp16ToDouble  1024          18.23
>> Float16OpsBenchmark.fp16ToInt     1024          1.93
>> Float16OpsBenchmark.fp16ToLong    1024          3.95
>> 
>> 
>> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic).
>
> src/java.base/share/classes/java/lang/Float16.java line 643:
> 
>> 641:     @IntrinsicCandidate
>> 642:     public int intValue() {
>> 643:         return (int)floatValue();
> 
> Should it be handled trough Idealization xform ?
> 
> ConvHF2F + ConvF2I => ConvHF2I

Matcher pattern may also suffice, but the problem will if ConvHF2F has multiple users.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1818971252

From jbhateja at openjdk.org  Mon Oct 28 12:30:25 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 28 Oct 2024 12:30:25 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion
 routines
In-Reply-To: <QRZYJliG6SdpTGnQSkCMwybXP-VIann7sOxjxXf2LH8=.c45c6cba-b663-412f-9298-fb6f496e2405@github.com>
References: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
 <hHzEfLV_AFGfdala4duuztQ5iigpdwgrOld1efMjCes=.3de8be53-56c6-425c-b51e-f3a1b6aa8f3d@github.com>
 <QRZYJliG6SdpTGnQSkCMwybXP-VIann7sOxjxXf2LH8=.c45c6cba-b663-412f-9298-fb6f496e2405@github.com>
Message-ID: <4W6Yrjjsxqq5aTRn9GkPoPx33IbJ5ugG-coMlLB1aeI=.0ce1ab1e-5722-4c3d-a646-54377b2b1dfc@github.com>

On Mon, 28 Oct 2024 12:25:56 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Float16.java line 643:
>> 
>>> 641:     @IntrinsicCandidate
>>> 642:     public int intValue() {
>>> 643:         return (int)floatValue();
>> 
>> Should it be handled trough Idealization xform ?
>> 
>> ConvHF2F + ConvF2I => ConvHF2I
>
> Matcher pattern may also suffice, but the problem will if ConvHF2F has multiple users.

If you check JDK mainline Float16 C2 compiler support PR, John has suggested us to go with pattern matching, I have added more details to that draft PR.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1818972524

From bkilambi at openjdk.org  Mon Oct 28 16:56:06 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 28 Oct 2024 16:56:06 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion
 routines
In-Reply-To: <4W6Yrjjsxqq5aTRn9GkPoPx33IbJ5ugG-coMlLB1aeI=.0ce1ab1e-5722-4c3d-a646-54377b2b1dfc@github.com>
References: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
 <hHzEfLV_AFGfdala4duuztQ5iigpdwgrOld1efMjCes=.3de8be53-56c6-425c-b51e-f3a1b6aa8f3d@github.com>
 <QRZYJliG6SdpTGnQSkCMwybXP-VIann7sOxjxXf2LH8=.c45c6cba-b663-412f-9298-fb6f496e2405@github.com>
 <4W6Yrjjsxqq5aTRn9GkPoPx33IbJ5ugG-coMlLB1aeI=.0ce1ab1e-5722-4c3d-a646-54377b2b1dfc@github.com>
Message-ID: <MXMxJDtZTtcDUSiQ0B0Oelp2OdrRb4jD5eJLUUvTtac=.8545cbe0-3527-40c0-ad7a-e5aa559537d1@github.com>

On Mon, 28 Oct 2024 12:26:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Matcher pattern may also suffice, but the problem will if ConvHF2F has multiple users.
>
> If you check JDK mainline Float16 C2 compiler support PR, John has suggested us to go with pattern matching, I have added more details to that draft PR.

Hi Jatin, thanks for the review comments. I did go through the comments on your draft PR earlier but I wasn't sure if we would be following their comments on the Valhalla branch as yet but I do agree with him about having too many intrinsics being an overkill. I'll remove the `@IntrinsicCandidate` here and add the code to do pattern matching in the mid-end.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1283#discussion_r1819417019

From dsimms at openjdk.org  Tue Oct 29 11:38:06 2024
From: dsimms at openjdk.org (David Simms)
Date: Tue, 29 Oct 2024 11:38:06 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <0PbQ1igqYQ0bG91JOYUGSSk4MwGFXS0P2vc_-o9M_xQ=.bb8dd8e6-3aad-4e83-9462-33bcae392d74@github.com>

Merge tag 'jdk-24+15' into lworld_merge_jdk_24_15
Added tag jdk-24+15 for changeset 3c40afa5

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

Commit messages:
 - Merge tag 'jdk-24+15' into lworld_merge_jdk_24_15
 - 8334165: Remove serialVersionUID compatibility logic from JMX
 - 8339733: C2: some nodes can have incorrect control after do_range_check()
 - 8339731: java.desktop/share/classes/javax/swing/text/html/default.css typo in margin settings
 - 8339159: api/java_rmi/Naming/Rebind.html crashes with SEGV from UTF8::quoted_ascii_length call
 - 8339835: Replace usages of -mx and -ms in some client-libs tests
 - 8339834: Replace usages of -mx and -ms in some tests
 - 8339678: Update runtime/condy tests to be executed with VM flags
 - 8299419: Thread.sleep(millis) may throw OOME
 - 8335362: [Windows] Stack pointer increment in _cont_thaw stub can cause program to terminate with exit code 0xc0000005
 - ... and 81 more: https://git.openjdk.org/valhalla/compare/e02c628f...97fa6405

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

Changes: https://git.openjdk.org/valhalla/pull/1284/files
  Stats: 14022 lines in 431 files changed: 7303 ins; 4692 del; 2027 mod
  Patch: https://git.openjdk.org/valhalla/pull/1284.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1284/head:pull/1284

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

From dsimms at openjdk.org  Wed Oct 30 07:26:33 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 30 Oct 2024 07:26:33 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <0PbQ1igqYQ0bG91JOYUGSSk4MwGFXS0P2vc_-o9M_xQ=.bb8dd8e6-3aad-4e83-9462-33bcae392d74@github.com>
References: <0PbQ1igqYQ0bG91JOYUGSSk4MwGFXS0P2vc_-o9M_xQ=.bb8dd8e6-3aad-4e83-9462-33bcae392d74@github.com>
Message-ID: <DUNYWmFe12sabCH8kXK-FdfZY8oewlvM6jJsxmbmu9c=.17ba3a89-676f-4628-a7eb-d8c714053f3b@github.com>

On Tue, 29 Oct 2024 11:32:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-24+15' into lworld_merge_jdk_24_15
> Added tag jdk-24+15 for changeset 3c40afa5

This pull request has now been integrated.

Changeset: 68e1861a
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/68e1861a5ef0c88047a4224446943a6bc1b685df
Stats:     14022 lines in 431 files changed: 7303 ins; 4692 del; 2027 mod

Merge jdk

Merge jdk-24+15

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

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

From heidinga at openjdk.org  Wed Oct 30 15:48:34 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 30 Oct 2024 15:48:34 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v2]
In-Reply-To: <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <NSJXD97q094Rirqj-b2j8vDhMF71WKnjGZ9JRE8RsEM=.cc2594c3-8408-44a3-8809-b50bd6b07ccb@github.com>
 <V1tCV8iuWpZkTIROl-kmVEyj7TP1WraKnArx9uhBrYc=.efd6155d-9618-41d9-8f7f-0f19ff2d855b@github.com>
Message-ID: <vD-MKuL9LGXe_iTqTcY2hnJ2dTsHf1po32QNOlHZZVU=.77e53635-37c5-4e13-afb6-6c1c336157e5@github.com>

On Tue, 22 Oct 2024 14:45:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 1374:
>> 
>>> 1372:                 CLEAR_PENDING_EXCEPTION;
>>> 1373:             }
>>> 1374:             THROW_OOP(e());
>> 
>> If I understand this code correctly, an OutOfMemoryError here will make the class unusable, which is a bit surprising.  Is it possible to instead disable all layouts except the REFERENCE if an OOM is thrown here?
>
> Only the NULLABLE_ATOMIC_FLAT layout would need to be disabled. But if an OOM is thrown at this stage (class initialization), does it really worth the effort to try to recover the class? It is unlikely the application will be able to allocate an instance of this class anyway.

I'm OK with leaving the code as is - an OOM thrown during class initialization would poison the class anyways.  This is just one more case of that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1822904166

From jatin.bhateja at intel.com  Wed Oct 30 16:28:25 2024
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Wed, 30 Oct 2024 16:28:25 +0000
Subject: New Valhalla Committer: Bhavana Kilambi
Message-ID: <PH8PR11MB796763F85B24F456F9F7F63FE8542@PH8PR11MB7967.namprd11.prod.outlook.com>

I hereby nominate Bhavana Kilambi(OpenJDK name: bkilambi)[1] to Valhalla Committer.



Bhavana is an author in JDK Project. She authored 17 bug fixes and enhancements to C2 Compiler encompassing AARCH64 Float16 backend support, mid-end transformations, and optimized inline expansions [2].



In the context of the Valhalla Project, Bhawana has contributed 4 patches on lworld+fp16 branch optimizing various Float16 operations notably [3][4][5][6].



Going forward she will be helping us in productizing the VectorAPI-Valhalla prototype on the lworld+vector branch.



Votes are due by 2024-11-13 at 17:00 PST.



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



For Lazy Consensus voting instructions, see [8].



Best regards,

Jatin Bhateja



[1] https://openjdk.org/census#bkilambi

[2] https://github.com/openjdk/jdk/commits/master?author=bkilambi at openjdk.org

[3] https://github.com/openjdk/valhalla/commit/9005a9a309e615780e87e49673ca9f9ea4831137

[4] https://github.com/openjdk/valhalla/commit/ce32e8c9bb2e99b20d088b88819feac9da6125f5

[5] https://github.com/openjdk/valhalla/commit/2e21e366969e1f02db46a684046812d00fa3eb52

[6] https://github.com/openjdk/valhalla/commit/3f42a1c9b9fc806e79e56ff794a745749feb823e

[7] https://openjdk.org/census#valhalla
[8] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20241030/2199d01e/attachment.htm>

From jatin.bhateja at intel.com  Wed Oct 30 16:29:25 2024
From: jatin.bhateja at intel.com (Bhateja, Jatin)
Date: Wed, 30 Oct 2024 16:29:25 +0000
Subject: New Valhalla Committer: Bhavana Kilambi
In-Reply-To: <PH8PR11MB796763F85B24F456F9F7F63FE8542@PH8PR11MB7967.namprd11.prod.outlook.com>
References: <PH8PR11MB796763F85B24F456F9F7F63FE8542@PH8PR11MB7967.namprd11.prod.outlook.com>
Message-ID: <PH8PR11MB7967991DB795FA7F0298BC05E8542@PH8PR11MB7967.namprd11.prod.outlook.com>

Vote: yes

Best Regards,
Jatin

From: Bhateja, Jatin
Sent: Wednesday, October 30, 2024 9:58 PM
To: valhalla-dev at openjdk.org
Cc: Bhavana Kilambi <Bhavana.Kilambi at arm.com>
Subject: New Valhalla Committer: Bhavana Kilambi


I hereby nominate Bhavana Kilambi(OpenJDK name: bkilambi)[1] to Valhalla Committer.



Bhavana is an author in JDK Project. She authored 17 bug fixes and enhancements to C2 Compiler encompassing AARCH64 Float16 backend support, mid-end transformations, and optimized inline expansions [2].



In the context of the Valhalla Project, Bhawana has contributed 4 patches on lworld+fp16 branch optimizing various Float16 operations notably [3][4][5][6].



Going forward she will be helping us in productizing the VectorAPI-Valhalla prototype on the lworld+vector branch.



Votes are due by 2024-11-13 at 17:00 PST.



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



For Lazy Consensus voting instructions, see [8].



Best regards,

Jatin Bhateja



[1] https://openjdk.org/census#bkilambi

[2] https://github.com/openjdk/jdk/commits/master?author=bkilambi at openjdk.org

[3] https://github.com/openjdk/valhalla/commit/9005a9a309e615780e87e49673ca9f9ea4831137

[4] https://github.com/openjdk/valhalla/commit/ce32e8c9bb2e99b20d088b88819feac9da6125f5

[5] https://github.com/openjdk/valhalla/commit/2e21e366969e1f02db46a684046812d00fa3eb52

[6] https://github.com/openjdk/valhalla/commit/3f42a1c9b9fc806e79e56ff794a745749feb823e

[7] https://openjdk.org/census#valhalla
[8] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20241030/7b07d6de/attachment-0001.htm>

From dsimms at openjdk.org  Wed Oct 30 16:40:24 2024
From: dsimms at openjdk.org (David Simms)
Date: Wed, 30 Oct 2024 16:40:24 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v2]
In-Reply-To: <OI-M4Xd33aDjTipmzDe1aRYD4TuVkYSJb8QUVG6OKxw=.2babb0fd-2e3c-4ef7-a972-6e09625570ef@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <OI-M4Xd33aDjTipmzDe1aRYD4TuVkYSJb8QUVG6OKxw=.2babb0fd-2e3c-4ef7-a972-6e09625570ef@github.com>
Message-ID: <Dc6WbgykcxdOLKJCEwUCyejy0Ieaon-d4qYsxUM-lKQ=.de492c66-a2b9-467b-9bfc-06fd892b657e@github.com>

On Fri, 25 Oct 2024 13:29:54 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
>> The patch includes the generation of two new flat fields layouts: atomic and nullable.
>> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
>> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
>> 
>> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bugs in aarch64 get_default_value_oop() method

That's a lot of work, good job !

src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp line 54:

> 52:                           Register src, Register dst, Register value_klass);
> 53:   virtual void flat_field_copy(MacroAssembler* masm, DecoratorSet decorators,
> 54:                           Register src, Register dst, Register inline_layout_info);

Does new flat_field_copy eventually replace value_copy ? Yes, this checks out (re-read the PR comments)

src/hotspot/share/gc/shared/barrierSetRuntime.hpp line 41:

> 39:   // Template interpreter...
> 40:   static void value_copy(void* src, void* dst, InlineKlass* md);
> 41:   static void value_copy2(void* src, void* dst, InlineLayoutInfo* layout_info);

Are there not better names (e.g _ilo) than 2 ? Or is this temp naming ?

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1275#pullrequestreview-2405526038
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1822984684
PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1822978081

From heidinga at openjdk.org  Wed Oct 30 16:47:48 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 30 Oct 2024 16:47:48 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v2]
In-Reply-To: <OI-M4Xd33aDjTipmzDe1aRYD4TuVkYSJb8QUVG6OKxw=.2babb0fd-2e3c-4ef7-a972-6e09625570ef@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <OI-M4Xd33aDjTipmzDe1aRYD4TuVkYSJb8QUVG6OKxw=.2babb0fd-2e3c-4ef7-a972-6e09625570ef@github.com>
Message-ID: <V2dZM-8JgnxpfE4ObfduesiaAJZAoe4Z2DG3ZH8L8HQ=.3e6f6d48-5eed-49aa-91fe-36da1de2f79e@github.com>

On Fri, 25 Oct 2024 13:29:54 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
>> The patch includes the generation of two new flat fields layouts: atomic and nullable.
>> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
>> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
>> 
>> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bugs in aarch64 get_default_value_oop() method

All my comments have been addressed

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1275#pullrequestreview-2405603953

From fparain at openjdk.org  Wed Oct 30 18:07:00 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Oct 2024 18:07:00 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v2]
In-Reply-To: <Dc6WbgykcxdOLKJCEwUCyejy0Ieaon-d4qYsxUM-lKQ=.de492c66-a2b9-467b-9bfc-06fd892b657e@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <OI-M4Xd33aDjTipmzDe1aRYD4TuVkYSJb8QUVG6OKxw=.2babb0fd-2e3c-4ef7-a972-6e09625570ef@github.com>
 <Dc6WbgykcxdOLKJCEwUCyejy0Ieaon-d4qYsxUM-lKQ=.de492c66-a2b9-467b-9bfc-06fd892b657e@github.com>
Message-ID: <huHhRWr0AtUr9ylPPPboCbSUU_VMWjXYcJyReadY9j0=.33262b34-7523-43ae-bde1-efbd46710adf@github.com>

On Wed, 30 Oct 2024 16:19:41 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 bugs in aarch64 get_default_value_oop() method
>
> src/hotspot/share/gc/shared/barrierSetRuntime.hpp line 41:
> 
>> 39:   // Template interpreter...
>> 40:   static void value_copy(void* src, void* dst, InlineKlass* md);
>> 41:   static void value_copy2(void* src, void* dst, InlineLayoutInfo* layout_info);
> 
> Are there not better names (e.g _ilo) than 2 ? Or is this temp naming ?

This is a temporary naming, once flat arrays have been updated, we can remove the old value_copy() method, and reuse the name for the new method.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1275#discussion_r1823144798

From fparain at openjdk.org  Wed Oct 30 18:06:57 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Oct 2024 18:06:57 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v3]
In-Reply-To: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
Message-ID: <h64gYMP3WwYW9GOWD6PESL-2WKxU1Ks7UHa7BbMxXKY=.a542e897-7083-40c3-92ed-ed09cca0e67a@github.com>

> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
> The patch includes the generation of two new flat fields layouts: atomic and nullable.
> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
> 
> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
> 
> 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 eight commits:

 - Remove unused field
 - Merge remote-tracking branch 'upstream/lworld' into nullable_flat_2
 - Fix bugs in aarch64 get_default_value_oop() method
 - Fix paths on Windows
 - Merge remote-tracking branch 'upstream/lworld' into nullable_flat_2
 - Fixes from initial reviews
 - Add support for oops embedded in nullable flat fields
 - Implementation of new fields layouts with interpreter support

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

Changes: https://git.openjdk.org/valhalla/pull/1275/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1275&range=02
  Stats: 1902 lines in 72 files changed: 960 ins; 393 del; 549 mod
  Patch: https://git.openjdk.org/valhalla/pull/1275.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1275/head:pull/1275

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

From fparain at openjdk.org  Wed Oct 30 18:19:31 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Oct 2024 18:19:31 GMT
Subject: [lworld] RFR: 8341757: Field layout computation allowing atomic
 and nullable flattening [v3]
In-Reply-To: <h64gYMP3WwYW9GOWD6PESL-2WKxU1Ks7UHa7BbMxXKY=.a542e897-7083-40c3-92ed-ed09cca0e67a@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
 <h64gYMP3WwYW9GOWD6PESL-2WKxU1Ks7UHa7BbMxXKY=.a542e897-7083-40c3-92ed-ed09cca0e67a@github.com>
Message-ID: <KW5Wsv-yRXjcS4QCpudN3gMjXksZG3HwqDNjqsYCRrA=.e918b38c-d0e8-4345-bbf5-bd9fed118a5f@github.com>

On Wed, 30 Oct 2024 18:06:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
>> The patch includes the generation of two new flat fields layouts: atomic and nullable.
>> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
>> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
>> 
>> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
>> 
>> 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 eight commits:
> 
>  - Remove unused field
>  - Merge remote-tracking branch 'upstream/lworld' into nullable_flat_2
>  - Fix bugs in aarch64 get_default_value_oop() method
>  - Fix paths on Windows
>  - Merge remote-tracking branch 'upstream/lworld' into nullable_flat_2
>  - Fixes from initial reviews
>  - Add support for oops embedded in nullable flat fields
>  - Implementation of new fields layouts with interpreter support

Coleen, Dan, MrSimms, 
Thank you for your reviews of this huge patch.

Fred

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

PR Comment: https://git.openjdk.org/valhalla/pull/1275#issuecomment-2447985658

From fparain at openjdk.org  Wed Oct 30 18:19:31 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Oct 2024 18:19:31 GMT
Subject: [lworld] Integrated: 8341757: Field layout computation allowing atomic
 and nullable flattening
In-Reply-To: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
References: <AUX2hiNBVFbXRR4UYZ4PHuCDZKdLWZNxwNJBLSPK2cU=.3cc7e035-debf-4308-aa38-4ffdbe143a3a@github.com>
Message-ID: <BR4s7fxtzC62XZ9XNjyfaBnWtKB8hei6NJOd8GQUfGE=.96ecaff7-cd4a-4f7d-9ff1-2c0980f1ae97@github.com>

On Fri, 11 Oct 2024 13:45:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Initial implementation of fields layouts in order to support heap flattening with JEP 401 model.
> The patch includes the generation of two new flat fields layouts: atomic and nullable.
> The patch also includes the support in the interpreter (through the access API) to access the new layouts while respecting the new semantic (on x86_64 and aarch64).
> Some areas do not support the new layouts yet, like JITs, Unsafe and arrays.
> 
> There's no automatic tests yet, but considering the impact those new layouts will have on the JVM, the priority was to make this code available to all developers as soon as possible. Automatic tests will be added in a following CR.
> 
> Fred

This pull request has now been integrated.

Changeset: d420fbdf
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d420fbdf4abadde0421e20f38ccc74aa3618a465
Stats:     1902 lines in 72 files changed: 960 ins; 393 del; 549 mod

8341757: Field layout computation allowing atomic and nullable flattening

Reviewed-by: heidinga, dsimms

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

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

From fparain at openjdk.org  Wed Oct 30 21:48:06 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 30 Oct 2024 21:48:06 GMT
Subject: [lworld] RFR: 8331503: [lworld] Tearing issues in the interpreter when
 using the Access API
Message-ID: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>

Fix the way the interpreter is copying value payloads to prevent primitive fields tearing.

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

Commit messages:
 - Merge remote-tracking branch 'upstream/lworld' into value_copy
 - Prevent tearing of primitive fields during value copying (interpreter)

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

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

From dsimms at openjdk.org  Thu Oct 31 09:21:37 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 31 Oct 2024 09:21:37 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <OcCRfKkJmHbjm094BWQydazEfz0jKjswtpKcxKl5q0Q=.6a082b69-b588-4cd3-b7b6-5dd63a9ccbef@github.com>

Merge jdk-24+16

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

Commit messages:
 - Problem list 8343346
 - Merge branch 'lworld' into lworld_merge_jdk_24_16
 - Additional test in JDK-8340272 blew up build-microbenchmark target with oom
 - Renaming for JDK-8339849
 - Merge tag 'jdk-24+16' into lworld_merge_jdk_24_16
 - 8340276: Test java/lang/management/ThreadMXBean/Locks.java failed with NullPointerException
 - 8286851: Deprecate for removal several of the undocumented java launcher options
 - 8339416: [s390x] Provide implementation for resolve_global_jobject
 - 8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java
 - 8340360: Update -mx to -Xmx in UnninstallUIMemoryLeaks test
 - ... and 83 more: https://git.openjdk.org/valhalla/compare/d420fbdf...1f46f25d

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

Changes: https://git.openjdk.org/valhalla/pull/1286/files
  Stats: 148249 lines in 613 files changed: 143232 ins; 2023 del; 2994 mod
  Patch: https://git.openjdk.org/valhalla/pull/1286.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1286/head:pull/1286

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

From dsimms at openjdk.org  Thu Oct 31 10:00:58 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 31 Oct 2024 10:00:58 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <OcCRfKkJmHbjm094BWQydazEfz0jKjswtpKcxKl5q0Q=.6a082b69-b588-4cd3-b7b6-5dd63a9ccbef@github.com>
References: <OcCRfKkJmHbjm094BWQydazEfz0jKjswtpKcxKl5q0Q=.6a082b69-b588-4cd3-b7b6-5dd63a9ccbef@github.com>
Message-ID: <OeNqhfQnOHp6B9Ua1x42i7hGkILS0-Xt4fkbhPolhaA=.8e4b3761-aa97-416d-ab2d-9d29e6a9c38e@github.com>

On Thu, 31 Oct 2024 09:13:25 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-24+16

This pull request has now been integrated.

Changeset: aa67ec83
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/aa67ec8353f4f072b4fcdbbab911fb7294281266
Stats:     148249 lines in 613 files changed: 143232 ins; 2023 del; 2994 mod

Merge jdk

Merge jdk-24+16

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

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

From thartmann at openjdk.org  Thu Oct 31 11:10:22 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 11:10:22 GMT
Subject: [lworld] Integrated: 8343346: [lworld] IR matching need updating after
 merging JDK-8339849
Message-ID: <r-4IGLoiWqOB8uGik0hIM84MDO0plbjejbzZM8vIMiY=.e1d74839-7dd5-4873-9494-801edc4c741a@github.com>

Adjusted the Valhalla specific IR rules to [JDK-8339849](https://bugs.openjdk.org/browse/JDK-8339849).

Thanks,
Tobias

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

Commit messages:
 - 8343346: [lworld] IR matching need updating after merging JDK-8339849

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

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

From thartmann at openjdk.org  Thu Oct 31 11:10:23 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 11:10:23 GMT
Subject: [lworld] Integrated: 8343346: [lworld] IR matching need updating after
 merging JDK-8339849
In-Reply-To: <r-4IGLoiWqOB8uGik0hIM84MDO0plbjejbzZM8vIMiY=.e1d74839-7dd5-4873-9494-801edc4c741a@github.com>
References: <r-4IGLoiWqOB8uGik0hIM84MDO0plbjejbzZM8vIMiY=.e1d74839-7dd5-4873-9494-801edc4c741a@github.com>
Message-ID: <ufsCjOo8_Pt4cCgSrrnDDEWOuiBQsKYjVi8UF1DgmlA=.6cb25461-9eb0-4f7a-b06a-5331e8ff07c9@github.com>

On Thu, 31 Oct 2024 11:05:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Adjusted the Valhalla specific IR rules to [JDK-8339849](https://bugs.openjdk.org/browse/JDK-8339849).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 695bb4a7
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/695bb4a7075d90374d0124212cf9a8887451a2ee
Stats:     10 lines in 2 files changed: 0 ins; 5 del; 5 mod

8343346: [lworld] IR matching need updating after merging JDK-8339849

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

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

From thartmann at openjdk.org  Thu Oct 31 12:01:24 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 12:01:24 GMT
Subject: [lworld] RFR: 8342064: [lworld] IR mismatch errors in Valhalla testing
 after merging jdk-24+4
Message-ID: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>

@chhagedorn found that this is actually a mainline bug and reported [JDK-8342156](https://bugs.openjdk.org/browse/JDK-8342156). Let's cherry pick the fix to un-problem lists our tests.

Thanks,
Tobias

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

Commit messages:
 - 8342064: [lworld] IR mismatch errors in Valhalla testing after merging jdk-24+4

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

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

From chagedorn at openjdk.org  Thu Oct 31 12:31:49 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 31 Oct 2024 12:31:49 GMT
Subject: [lworld] RFR: 8342064: [lworld] IR mismatch errors in Valhalla
 testing after merging jdk-24+4
In-Reply-To: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>
References: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>
Message-ID: <LfRumNmGVjGFyanyqvomnrYN34apBpl7Vxr0JQLs01U=.7be478b5-fdd7-4ec6-bfe4-d978a4a35f9a@github.com>

On Thu, 31 Oct 2024 11:55:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> @chhagedorn found that this is actually a mainline bug and reported [JDK-8342156](https://bugs.openjdk.org/browse/JDK-8342156). Let's cherry pick the fix to un-problem lists our tests.
> 
> Thanks,
> Tobias

Looks good, thanks Tobias for taking care of that!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1288#pullrequestreview-2407801305

From thartmann at openjdk.org  Thu Oct 31 12:42:36 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 12:42:36 GMT
Subject: [lworld] RFR: 8342064: [lworld] IR mismatch errors in Valhalla
 testing after merging jdk-24+4
In-Reply-To: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>
References: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>
Message-ID: <ne1xRDw48aoQuetr5RsCV02LyE3Z2GpGFO6lYVpjhp8=.3c8d9817-bc24-4938-bb82-f0b70a0c97dd@github.com>

On Thu, 31 Oct 2024 11:55:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> @chhagedorn found that this is actually a mainline bug and reported [JDK-8342156](https://bugs.openjdk.org/browse/JDK-8342156). Let's cherry pick the fix to un-problem lists our tests.
> 
> Thanks,
> Tobias

Thanks Christian. I'm running testing before integration.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1288#issuecomment-2449751380

From thartmann at openjdk.org  Thu Oct 31 13:02:03 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 13:02:03 GMT
Subject: [lworld] Integrated: 8342064: [lworld] IR mismatch errors in Valhalla
 testing after merging jdk-24+4
In-Reply-To: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>
References: <xnF1mJhaXmaOkEWKIdkPeK_v6_LAkTkDRzBRxWDkBdY=.759db95a-3c4a-4a5a-bfbc-dbe10034a80d@github.com>
Message-ID: <aLQKQN2GugEMHelRiPPTqCN7REnFgkw7R_wOGfI9lXo=.8bb00587-9c1c-4b47-9a6f-3da3a010712f@github.com>

On Thu, 31 Oct 2024 11:55:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> @chhagedorn found that this is actually a mainline bug and reported [JDK-8342156](https://bugs.openjdk.org/browse/JDK-8342156). Let's cherry pick the fix to un-problem lists our tests.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: b61feb09
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b61feb096024d7fc32cca0a03bdc6ef7667844ff
Stats:     58 lines in 3 files changed: 51 ins; 4 del; 3 mod

8342064: [lworld] IR mismatch errors in Valhalla testing after merging jdk-24+4

Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
Reviewed-by: chagedorn

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

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

From thartmann at openjdk.org  Thu Oct 31 13:06:02 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 13:06:02 GMT
Subject: [lworld] RFR: 8341949: [lworld]
 compiler/valhalla/inlinetypes/TestMethodHandles.java broken after merging
 jdk-24+3
Message-ID: <ChLf6-Xj2KR9W9HLZmtg7AjFBkV136g0TrFugEIwR88=.1da7b931-1982-4328-a0bb-96138e88f77c@github.com>

Force inlining of LambdaForm methods to ensure that the IR always looks as expected.

Thanks,
Tobias

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

Commit messages:
 - 8341949: [lworld] compiler/valhalla/inlinetypes/TestMethodHandles.java broken after merging jdk-24+3

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

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

From bkilambi at openjdk.org  Thu Oct 31 13:50:40 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 31 Oct 2024 13:50:40 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion
 routines [v2]
In-Reply-To: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
References: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
Message-ID: <OpRWh_HM6FueQNgNjHI2XbtdNFIMZp_CPzjLLLTkoQM=.f5f2f93b-503b-4556-a4bf-12bb814e3eed@github.com>

> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions.
> 
> Performance numbers on aarch64 machine with SVE support :
> 
> 
> Benchmark                         (vectorDim)   Gain
> Float16OpsBenchmark.fp16ToDouble  1024          18.23
> Float16OpsBenchmark.fp16ToInt     1024          1.93
> Float16OpsBenchmark.fp16ToLong    1024          3.95
> 
> 
> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic).

Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:

  Remove intrinsification of conversion methods in Float16

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1283/files
  - new: https://git.openjdk.org/valhalla/pull/1283/files/fe9e31ce..0809cedc

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

  Stats: 307 lines in 10 files changed: 188 ins; 110 del; 9 mod
  Patch: https://git.openjdk.org/valhalla/pull/1283.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1283/head:pull/1283

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

From bkilambi at openjdk.org  Thu Oct 31 13:53:43 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 31 Oct 2024 13:53:43 GMT
Subject: [lworld+fp16] RFR: 8341414: Add support for FP16 conversion
 routines
In-Reply-To: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
References: <MM4XZX234Og5S8t-6heS--p5Ff7MDYL8MtbzyQtvrac=.36689526-b493-4b5e-a8fb-1543b0a19394@github.com>
Message-ID: <DcCoLWlbKza5Z5lufz5q_l_6duswpY9dkjFbp5NJUN8=.962d5298-5040-4f41-b2b2-51552b333506@github.com>

On Wed, 23 Oct 2024 14:07:52 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for FP16 conversion routines to int/long/double and also the aarch64 backend support. This patch implements both scalar and vector versions for these conversions.
> 
> Performance numbers on aarch64 machine with SVE support :
> 
> 
> Benchmark                         (vectorDim)   Gain
> Float16OpsBenchmark.fp16ToDouble  1024          18.23
> Float16OpsBenchmark.fp16ToInt     1024          1.93
> Float16OpsBenchmark.fp16ToLong    1024          3.95
> 
> 
> The Gain column is the ratio between thrpt of this patch and the thrpt with the intrinsics disabled (which generates FP32 arithmetic).

Hi @jatin-bhateja , I have uploaded a patch addressing your comments. Please review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1283#issuecomment-2449892299

From dsimms at openjdk.org  Thu Oct 31 13:56:35 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 31 Oct 2024 13:56:35 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <c5NaVIZ2Umg6gTauUBrpWiVpb_-dwS7ip6N_J5l2f84=.7580651d-3c43-4f47-a473-b9d335d7197d@github.com>

Merge jdk-24+17 and jdk-24+18

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

Commit messages:
 - Merge tag 'jdk-24+18' into lworld_merge_jdk_24_17
 - 8341148: Open source several Choice related tests
 - Merge commit '0b467e902d591ae9feeec1669918d1588987cd1c' into lworld_merge_jdk_24_17
 - 8334060: Implementation of Late Barrier Expansion for G1
 - Merge commit 'c6e7e551928c04b74775b5d4c03eb31232aeb2c9' into lworld_merge_jdk_24_17
 - 8341091: CDS: Segmented roots array misses roots
 - 8341239: Open source closed frame tests # 3
 - 8341191: Open source few more AWT FileDialog tests
 - 8341177: Opensource few List and a Window test
 - 8309841: Jarsigner should print a warning if an entry is removed
 - ... and 202 more: https://git.openjdk.org/valhalla/compare/aa67ec83...0730016c

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

Changes: https://git.openjdk.org/valhalla/pull/1290/files
  Stats: 43388 lines in 803 files changed: 34332 ins; 5162 del; 3894 mod
  Patch: https://git.openjdk.org/valhalla/pull/1290.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1290/head:pull/1290

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

From thartmann at openjdk.org  Thu Oct 31 14:29:38 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 14:29:38 GMT
Subject: [lworld] Integrated: 8341949: [lworld]
 compiler/valhalla/inlinetypes/TestMethodHandles.java broken after merging
 jdk-24+3
In-Reply-To: <ChLf6-Xj2KR9W9HLZmtg7AjFBkV136g0TrFugEIwR88=.1da7b931-1982-4328-a0bb-96138e88f77c@github.com>
References: <ChLf6-Xj2KR9W9HLZmtg7AjFBkV136g0TrFugEIwR88=.1da7b931-1982-4328-a0bb-96138e88f77c@github.com>
Message-ID: <jVA6ZCAjB3H5v2icIdF831XQb0GdzRDLalcfiacYcto=.cc63dac1-d328-436b-8d3c-7c6d6096e037@github.com>

On Thu, 31 Oct 2024 13:01:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Force inlining of LambdaForm methods to ensure that the IR always looks as expected.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: ab079490
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ab07949066d3f2e7f89a6a136bcc431951b68736
Stats:     3 lines in 2 files changed: 1 ins; 2 del; 0 mod

8341949: [lworld] compiler/valhalla/inlinetypes/TestMethodHandles.java broken after merging jdk-24+3

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

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

From thartmann at openjdk.org  Thu Oct 31 14:37:16 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 14:37:16 GMT
Subject: [lworld] Integrated: [lworld] Remove InlineOops.java from problem list
 after JDK-8313607 got fixed
Message-ID: <ka-gM23N1QVUV1toNlgZacZ2Fej11cO8NFjlOfhtP48=.76cf0f0a-eb82-4c0b-ae58-bdd47341a05b@github.com>

[JDK-8313607](https://bugs.openjdk.org/browse/JDK-8313607) was fixed but the test is still problem listed. Let's fix that.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Remove InlineOops.java from problem list after JDK-8313607 got fixed

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

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

From thartmann at openjdk.org  Thu Oct 31 14:37:16 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 31 Oct 2024 14:37:16 GMT
Subject: [lworld] Integrated: [lworld] Remove InlineOops.java from problem list
 after JDK-8313607 got fixed
In-Reply-To: <ka-gM23N1QVUV1toNlgZacZ2Fej11cO8NFjlOfhtP48=.76cf0f0a-eb82-4c0b-ae58-bdd47341a05b@github.com>
References: <ka-gM23N1QVUV1toNlgZacZ2Fej11cO8NFjlOfhtP48=.76cf0f0a-eb82-4c0b-ae58-bdd47341a05b@github.com>
Message-ID: <WWRAEkguX1UqHDtzDkmJXqOoe-9eNhgObxbL8AxUf8k=.2ef239aa-765d-4f1e-a5ed-ae9fb45f59ab@github.com>

On Thu, 31 Oct 2024 14:32:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8313607](https://bugs.openjdk.org/browse/JDK-8313607) was fixed but the test is still problem listed. Let's fix that.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

[lworld] Remove InlineOops.java from problem list after JDK-8313607 got fixed

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

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

From dsimms at openjdk.org  Thu Oct 31 15:14:42 2024
From: dsimms at openjdk.org (David Simms)
Date: Thu, 31 Oct 2024 15:14:42 GMT
Subject: [lworld] RFR: 8331503: [lworld] Tearing issues in the interpreter
 when using the Access API
In-Reply-To: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>
References: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>
Message-ID: <B0O-fAlLjmVqhtHVAMCr-4E4AGrThQX5RHUMMU4TdlM=.a47a3454-2999-40a3-8b7a-bac220b11a44@github.com>

On Tue, 29 Oct 2024 14:58:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix the way the interpreter is copying value payloads to prevent primitive fields tearing.

Nice, fixes the departure from 64-bit alignment

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1285#pullrequestreview-2408256582

From fparain at openjdk.org  Thu Oct 31 16:46:43 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 31 Oct 2024 16:46:43 GMT
Subject: [lworld] RFR: 8331503: [lworld] Tearing issues in the interpreter
 when using the Access API
In-Reply-To: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>
References: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>
Message-ID: <kZzWmYFm1rVU6VxZJX-ER20yAKX-kIkHYZEAXYo6c8k=.de795248-1c32-41e2-98a7-4a9574a72382@github.com>

On Tue, 29 Oct 2024 14:58:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix the way the interpreter is copying value payloads to prevent primitive fields tearing.

Thank you for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1285#issuecomment-2450342928

From fparain at openjdk.org  Thu Oct 31 16:46:44 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 31 Oct 2024 16:46:44 GMT
Subject: [lworld] Integrated: 8331503: [lworld] Tearing issues in the
 interpreter when using the Access API
In-Reply-To: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>
References: <bB1lPiTozCPA7yd45KRoL2wrQIEDBVulggT27hJiO7I=.da030e3c-60bd-4770-832d-ad3520c271bb@github.com>
Message-ID: <tGpJMqB5-8b8ySyFu--MS9Lr0IVkNiQVIFTuifaaVbM=.a8f26469-045d-4fab-8f24-c684c8794b46@github.com>

On Tue, 29 Oct 2024 14:58:12 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix the way the interpreter is copying value payloads to prevent primitive fields tearing.

This pull request has now been integrated.

Changeset: 178289b9
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/178289b98566e38f50056d4c92407e594f480443
Stats:     152 lines in 6 files changed: 150 ins; 0 del; 2 mod

8331503: [lworld] Tearing issues in the interpreter when using the Access API

Reviewed-by: dsimms

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

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

From amenkov at openjdk.org  Thu Oct 31 19:36:21 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 31 Oct 2024 19:36:21 GMT
Subject: [lworld] RFR: 8343408: TestJNIIsSameObject should be run on all
 platforms
Message-ID: <9_D1i8qlamLc1KWUykmJkogQVzMVI6Cd2C58Ut1F4_Y=.01032837-f2e3-4f8e-ba96-4a85e579261a@github.com>

The fix drops the test requirements to run it on all platforms

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

Commit messages:
 - fix

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

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

From amenkov at openjdk.org  Thu Oct 31 23:54:46 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 31 Oct 2024 23:54:46 GMT
Subject: [lworld] Integrated: 8343408: TestJNIIsSameObject should be run on all
 platforms
In-Reply-To: <9_D1i8qlamLc1KWUykmJkogQVzMVI6Cd2C58Ut1F4_Y=.01032837-f2e3-4f8e-ba96-4a85e579261a@github.com>
References: <9_D1i8qlamLc1KWUykmJkogQVzMVI6Cd2C58Ut1F4_Y=.01032837-f2e3-4f8e-ba96-4a85e579261a@github.com>
Message-ID: <_TeWKzitYPDN-p7A6QuiJhwZZ48rcWEuPjElG-ZQu2M=.bf31354e-374d-4a3a-adc1-b928619dd805@github.com>

On Thu, 31 Oct 2024 19:31:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix drops the test requirements to run it on all platforms

This pull request has now been integrated.

Changeset: 3f01207a
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3f01207a03c37dcb5e32c26a1dced21dacf6e80d
Stats:     6 lines in 2 files changed: 0 ins; 6 del; 0 mod

8343408: TestJNIIsSameObject should be run on all platforms

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

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