From duke at openjdk.org  Sun Feb  2 08:11:03 2025
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Sun, 2 Feb 2025 08:11:03 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update
In-Reply-To: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
Message-ID: <U06l-RqzIjvXAr1vxBHQezZQ25d5RaVokAtaOLRc-cU=.eb3a8a75-b8fb-4895-9109-95666bbe1bc1@github.com>

On Fri, 31 Jan 2025 20:17:48 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This patch is mostly about VM flags update and internal renaming.
> 
> Renaming a few symbols to make them consistent with previous code cleanup:
>   - data_for_oop() -> payload_address()
>   - first_field_offset() -> payload_offset()
>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>   
> VM flags controlling flattening:
>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>   
> Example:
>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
> 
> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
> 
> Feel free to propose new names for those flags if you think they are not explicit enough.
> 
> Thank you,
> 
> Fred

src/hotspot/share/oops/layoutKind.hpp line 1:

> 1: /*

LayoudKind - typo

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1345#discussion_r1938233148

From rriggs at openjdk.org  Mon Feb  3 03:14:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 3 Feb 2025 03:14:15 GMT
Subject: [lworld] RFR: 8348904: [lworld] Remove concept of default value
 object and zeroInstance [v2]
In-Reply-To: <ZHZ-nwNYtywqlCWy_8m1MVIi85Nsk9Nka_N5-tq2kPQ=.eebccf5b-dcc7-445f-9dcf-9cea906db656@github.com>
References: <ZHZ-nwNYtywqlCWy_8m1MVIi85Nsk9Nka_N5-tq2kPQ=.eebccf5b-dcc7-445f-9dcf-9cea906db656@github.com>
Message-ID: <yp3gVQFduATcwR8EXnwVNiv6eHLRn4IhfeJ6KePqvKU=.c619a790-270a-4a62-8109-e230db303ab6@github.com>

> Remove support for the default value object and zeroInstance, no longer included in the spec.
> In related tests, test cases were removed if no longer applicable or replaced by a hand created zero/null object.

Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:

 - Remove debug println
 - Merge branch 'xx-broken-default-value-object' into 8348904-remove-default-value-object
   Remove vestigal remains of zeroInstance in DirectMethodHandle.makePreparedFieldLambdaForm.
 - 8348904: [lworld] Remove concept of default value object and zeroInstance
   Remove support for the default object and zeroInstance, no longer included in the spec.
   In related tests, test cases were removed if no longer applicable or
   replaced by a hand created zero/null object.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1346/files
  - new: https://git.openjdk.org/valhalla/pull/1346/files/7952b01e..483ec26f

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

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

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

From liach at openjdk.org  Mon Feb  3 04:45:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 3 Feb 2025 04:45:01 GMT
Subject: [lworld] RFR: 8348904: [lworld] Remove concept of default value
 object and zeroInstance [v2]
In-Reply-To: <yp3gVQFduATcwR8EXnwVNiv6eHLRn4IhfeJ6KePqvKU=.c619a790-270a-4a62-8109-e230db303ab6@github.com>
References: <ZHZ-nwNYtywqlCWy_8m1MVIi85Nsk9Nka_N5-tq2kPQ=.eebccf5b-dcc7-445f-9dcf-9cea906db656@github.com>
 <yp3gVQFduATcwR8EXnwVNiv6eHLRn4IhfeJ6KePqvKU=.c619a790-270a-4a62-8109-e230db303ab6@github.com>
Message-ID: <b8BYRZbPLL6hKuSVp6Vg2svkX-hyRrnOUQ_kv-iiX6A=.8afe5176-b2f4-48d4-b87e-3c7bfde1726e@github.com>

On Mon, 3 Feb 2025 03:14:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Remove support for the default value object and zeroInstance, no longer included in the spec.
>> In related tests, test cases were removed if no longer applicable or replaced by a hand created zero/null object.
>
> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove debug println
>  - Merge branch 'xx-broken-default-value-object' into 8348904-remove-default-value-object
>    Remove vestigal remains of zeroInstance in DirectMethodHandle.makePreparedFieldLambdaForm.
>  - 8348904: [lworld] Remove concept of default value object and zeroInstance
>    Remove support for the default object and zeroInstance, no longer included in the spec.
>    In related tests, test cases were removed if no longer applicable or
>    replaced by a hand created zero/null object.

We can clean up the implicitly constructable concept from the VM and arrays later.

src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2:

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

Thanks for this update; thought we don't update headers in valhalla.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1346#pullrequestreview-2588878007
PR Review Comment: https://git.openjdk.org/valhalla/pull/1346#discussion_r1938752926

From dsimms at openjdk.org  Mon Feb  3 09:37:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 3 Feb 2025 09:37:37 GMT
Subject: [lworld] Integrated: Problem Listing 250203
Message-ID: <K99Y6SIqvG3iggIPbxRqUlw-lf0sjq_uTU85VDeqnMo=.74f41fb8-8452-41ef-a4e2-cbd68b7c7959@github.com>

Problem list known failures

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

Commit messages:
 - Problem Listing 250203

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

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

From dsimms at openjdk.org  Mon Feb  3 09:37:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 3 Feb 2025 09:37:37 GMT
Subject: [lworld] Integrated: Problem Listing 250203
In-Reply-To: <K99Y6SIqvG3iggIPbxRqUlw-lf0sjq_uTU85VDeqnMo=.74f41fb8-8452-41ef-a4e2-cbd68b7c7959@github.com>
References: <K99Y6SIqvG3iggIPbxRqUlw-lf0sjq_uTU85VDeqnMo=.74f41fb8-8452-41ef-a4e2-cbd68b7c7959@github.com>
Message-ID: <uTQ2GLjypGqF7nSZRPfwCoEseCT2TcomqZ6G3EsztT4=.02386ba3-5773-46d7-bc6a-e3be718025a6@github.com>

On Mon, 3 Feb 2025 09:32:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem list known failures

This pull request has now been integrated.

Changeset: 67fe7319
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/67fe7319fb6c4af5f1ee7cb9838ae76b1199714c
Stats:     4 lines in 2 files changed: 3 ins; 0 del; 1 mod

Problem Listing 250203

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

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

From jbhateja at openjdk.org  Mon Feb  3 11:25:03 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 3 Feb 2025 11:25:03 GMT
Subject: [lworld+fp16] RFR: 8345053: Add support for FP16 valueOf routines
 [v2]
In-Reply-To: <1iteJZNvJrsydropaIEAl8ZYuXRd0cK34JAQ-FWzV2o=.53139579-3812-4cc1-b5f3-b26c284d36a2@github.com>
References: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
 <1iteJZNvJrsydropaIEAl8ZYuXRd0cK34JAQ-FWzV2o=.53139579-3812-4cc1-b5f3-b26c284d36a2@github.com>
Message-ID: <YOnIScLnWuSykZHEqEhv5FV7UFCDQ6eBs65Nb7-UGlw=.82bb1b25-7c6a-4ec8-b0fd-de07d9d6b041@github.com>

On Fri, 24 Jan 2025 13:45:42 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for Float16.valueOf() routines - conversions from int/long/double to half float.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new microbenchmarks for valueOf() routines

src/hotspot/share/opto/convertnode.cpp line 204:

> 202: 
> 203: //------------------------------Identity---------------------------------------
> 204: // Half-Float's can be converted to doubles with no loss of bits.  Hence

Suggestion:

// Half-Float's can be converted to doubles with no loss of precision.  Hence

src/hotspot/share/opto/vectornode.cpp line 1450:

> 1448:     case Op_VectorCastD2HF: return new VectorCastD2HFNode(n1, vt);
> 1449:     case Op_VectorCastL2HF: return new VectorCastL2HFNode(n1, vt);
> 1450: 

We can optimize creating new vector IR once mainline patch gets integrated as I have added an explicit ideal type for HalfFloats, thus existing D2X, I2X and L2X IR can be used and we can perform a type based checks in matcher.

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

> 389: 
> 390:     @IntrinsicCandidate
> 391:     private static short longToFloat16(long value) {

Offlate there have been some concerns around keeping java side changes to a minimum,  doing boxing on the compiler side involves additional work, please refer to my changes on mainline
https://github.com/openjdk/jdk/pull/22754/commits/692de9c03fb6344f9602617f0bed75c28c409ed0#diff-1929ace9ae6df116e2fa2a718ed3924d9dae9a2daea454ca9a78177c21477aa3R8641

But, for now, this looks ok, we can fine-tune going forward once we reach a stage of JDK mainline integration.

test/hotspot/jtreg/compiler/c2/irTests/ConvD2HFTransformationTests.java line 61:

> 59:         failOn = {IRNode.CONV_D2HF, IRNode.CONV_I2D},
> 60:         applyIfCPUFeatureAnd = {"fphp", "true", "asimdhp", "true"})
> 61:     // Test Ideal transformation of ConvD2HF node : pattern ConvI2D -> ConvD2HF is optimized to ConvI2HF

Fix indentation

test/hotspot/jtreg/compiler/c2/irTests/ConvD2HFTransformationTests.java line 81:

> 79:     @IR(failOn = {IRNode.CONV_D2HF, IRNode.CONV_HF2D},
> 80:         applyIfCPUFeatureAnd = {"fphp", "true", "asimdhp", "true"})
> 81:     // Test Identity transformation of ConvD2HF node : pattern - ConvHF2D -> ConvD2HF is optimized away

Fix indentation

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1332#discussion_r1939069295
PR Review Comment: https://git.openjdk.org/valhalla/pull/1332#discussion_r1939184818
PR Review Comment: https://git.openjdk.org/valhalla/pull/1332#discussion_r1939037593
PR Review Comment: https://git.openjdk.org/valhalla/pull/1332#discussion_r1939211938
PR Review Comment: https://git.openjdk.org/valhalla/pull/1332#discussion_r1939212313

From dsimms at openjdk.org  Mon Feb  3 13:59:35 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 3 Feb 2025 13:59:35 GMT
Subject: [lworld] Integrated: Problem listing, mistakes were made
Message-ID: <KtWw8gWMK5389UpWHWHzHX4o4LbaaHpUo__kVEP0UcA=.33986c49-2558-468c-bad8-0e52b9d6a756@github.com>

Fix correct path and platform

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

Commit messages:
 - Merge branch 'lworld' into ProblemListing_250203_2
 - Problem listing, mistakes were made

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

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

From dsimms at openjdk.org  Mon Feb  3 13:59:35 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 3 Feb 2025 13:59:35 GMT
Subject: [lworld] Integrated: Problem listing, mistakes were made
In-Reply-To: <KtWw8gWMK5389UpWHWHzHX4o4LbaaHpUo__kVEP0UcA=.33986c49-2558-468c-bad8-0e52b9d6a756@github.com>
References: <KtWw8gWMK5389UpWHWHzHX4o4LbaaHpUo__kVEP0UcA=.33986c49-2558-468c-bad8-0e52b9d6a756@github.com>
Message-ID: <nqj4jA8vzhINtelUAI_DdfP06JZO2U0FHg4wy1kBSUM=.16ecbe2e-9798-4021-8133-8f6818fb3840@github.com>

On Mon, 3 Feb 2025 13:52:33 GMT, David Simms <dsimms at openjdk.org> wrote:

> Fix correct path and platform

This pull request has now been integrated.

Changeset: aa89d878
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/aa89d8784fa3f6164745bc991d00e06ba6a11cff
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

Problem listing, mistakes were made

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

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

From thartmann at openjdk.org  Mon Feb  3 15:59:07 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Feb 2025 15:59:07 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v2]
In-Reply-To: <4igjSsNMyGt5txjgecpejhTZgQx-NUtpQ9sykdRZxWY=.86567fa0-78d4-458d-a488-99e053e66ffc@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
 <4igjSsNMyGt5txjgecpejhTZgQx-NUtpQ9sykdRZxWY=.86567fa0-78d4-458d-a488-99e053e66ffc@github.com>
Message-ID: <kcbr7LXHt1iOQcTT4VyVtoqU96CfYGnTm5ksnKp-7Ow=.1d63e44f-dd52-4bf9-aba6-02ec037f7ccb@github.com>

On Mon, 3 Feb 2025 14:00:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch is mostly about VM flags update and internal renaming.
>> 
>> Renaming a few symbols to make them consistent with previous code cleanup:
>>   - data_for_oop() -> payload_address()
>>   - first_field_offset() -> payload_offset()
>>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>>   
>> VM flags controlling flattening:
>>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>>   
>> Example:
>>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
>> 
>> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
>> 
>> Feel free to propose new names for those flags if you think they are not explicit enough.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

test/hotspot/jtreg/runtime/valhalla/inlinetypes/field_layout/TestLayoutFlags.java line 106:

> 104:  public class TestLayoutFlags {
> 105: 
> 106:    static class TestRunner {

Just a quick drive-by comment: Java code should use 4-whitespace indentation. Same for other files.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1345#discussion_r1939632983

From bkilambi at openjdk.org  Mon Feb  3 16:23:42 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 3 Feb 2025 16:23:42 GMT
Subject: [lworld+fp16] RFR: 8345053: Add support for FP16 valueOf routines
 [v3]
In-Reply-To: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
References: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
Message-ID: <WYWtpggVyVJgqiWrONDGIl44SDOiv4G6tNl7vzay0S4=.1cc1ee30-e80f-4a38-ab4c-2ed079941797@github.com>

> This patch adds intrinsic support for Float16.valueOf() routines - conversions from int/long/double to half float.

Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1332/files
  - new: https://git.openjdk.org/valhalla/pull/1332/files/f7b98148..eeb2afe8

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

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

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

From bkilambi at openjdk.org  Mon Feb  3 16:23:44 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Mon, 3 Feb 2025 16:23:44 GMT
Subject: [lworld+fp16] RFR: 8345053: Add support for FP16 valueOf routines
 [v2]
In-Reply-To: <YOnIScLnWuSykZHEqEhv5FV7UFCDQ6eBs65Nb7-UGlw=.82bb1b25-7c6a-4ec8-b0fd-de07d9d6b041@github.com>
References: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
 <1iteJZNvJrsydropaIEAl8ZYuXRd0cK34JAQ-FWzV2o=.53139579-3812-4cc1-b5f3-b26c284d36a2@github.com>
 <YOnIScLnWuSykZHEqEhv5FV7UFCDQ6eBs65Nb7-UGlw=.82bb1b25-7c6a-4ec8-b0fd-de07d9d6b041@github.com>
Message-ID: <NfwPZYTIw_wXbVhgrOhDEOcRa6ISGyEnoUA_Zc3KJwc=.c3e31966-006f-4917-83ff-ccee5c40c171@github.com>

On Mon, 3 Feb 2025 09:16:10 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add new microbenchmarks for valueOf() routines
>
> src/java.base/share/classes/java/lang/Float16.java line 391:
> 
>> 389: 
>> 390:     @IntrinsicCandidate
>> 391:     private static short longToFloat16(long value) {
> 
> Offlate there have been some concerns around keeping java side changes to a minimum,  doing boxing on the compiler side involves additional work, please refer to my changes on mainline
> https://github.com/openjdk/jdk/pull/22754/commits/692de9c03fb6344f9602617f0bed75c28c409ed0#diff-1929ace9ae6df116e2fa2a718ed3924d9dae9a2daea454ca9a78177c21477aa3R8641
> 
> But, for now, this looks ok, we can fine-tune going forward once we reach a stage of JDK mainline integration.

Got it, thank you!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1332#discussion_r1939672291

From fparain at openjdk.org  Mon Feb  3 17:09:42 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 3 Feb 2025 17:09:42 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v3]
In-Reply-To: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
Message-ID: <xlOQ-z3QR0xV5lROYBWK98rSR0YQUbF8vhNP_LbEQmw=.78b52ef4-e4b4-4a78-bb02-e5658fd24ef9@github.com>

> This patch is mostly about VM flags update and internal renaming.
> 
> Renaming a few symbols to make them consistent with previous code cleanup:
>   - data_for_oop() -> payload_address()
>   - first_field_offset() -> payload_offset()
>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>   
> VM flags controlling flattening:
>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>   
> Example:
>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
> 
> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
> 
> Feel free to propose new names for those flags if you think they are not explicit enough.
> 
> Thank you,
> 
> Fred

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

  Fix identation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1345/files
  - new: https://git.openjdk.org/valhalla/pull/1345/files/ee8a2fd0..c8ca53a8

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

  Stats: 249 lines in 1 file changed: 73 ins; 73 del; 103 mod
  Patch: https://git.openjdk.org/valhalla/pull/1345.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1345/head:pull/1345

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

From vromero at openjdk.org  Mon Feb  3 22:42:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 3 Feb 2025 22:42:07 GMT
Subject: [lworld] Integrated: 8349260: [lworld] minimal support for @Strict,
 follow-up of JDK-8349073
Message-ID: <WH9Ndf2CKtVYWhmSXNlTOOv7VynRU0Xod8GLHhRKTik=.df9a11d3-4854-4d2c-8bc6-caaac3c33795@github.com>

additional support for @Strict anno

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

Commit messages:
 - 8349260: [lworld] minimal support for @Strict, follow-up

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

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

From vromero at openjdk.org  Mon Feb  3 22:42:07 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 3 Feb 2025 22:42:07 GMT
Subject: [lworld] Integrated: 8349260: [lworld] minimal support for @Strict,
 follow-up of JDK-8349073
In-Reply-To: <WH9Ndf2CKtVYWhmSXNlTOOv7VynRU0Xod8GLHhRKTik=.df9a11d3-4854-4d2c-8bc6-caaac3c33795@github.com>
References: <WH9Ndf2CKtVYWhmSXNlTOOv7VynRU0Xod8GLHhRKTik=.df9a11d3-4854-4d2c-8bc6-caaac3c33795@github.com>
Message-ID: <S0ZViLDfrv80Vmw6yX5iDeqeJluewRyjLHzAy8Hb53U=.a39b8f75-a487-421b-bf6b-3541784019fa@github.com>

On Mon, 3 Feb 2025 22:34:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> additional support for @Strict anno

This pull request has now been integrated.

Changeset: bf9ddbe7
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/bf9ddbe7b7597f06301fae9f12d0dbb2bceaac47
Stats:     50 lines in 4 files changed: 47 ins; 0 del; 3 mod

8349260: [lworld] minimal support for @Strict, follow-up of JDK-8349073

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

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

From dsimms at openjdk.org  Tue Feb  4 13:17:03 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 4 Feb 2025 13:17:03 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <JcRtenQgDSZMxK_FocJ678qCRC1vefcyuj-nfxRV8mI=.c2850abf-a118-4ab9-97f1-388ff4c276ba@github.com>

Merge jdk-25+1

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

Commit messages:
 - Move to version 25 (CFV:69)
 - Merge tag 'jdk-25+1' into lworld_merge_jdk_25_1
 - 8342444: Shenandoah: Uncommit regions from a separate, STS aware thread
 - 8344665: Refactor PartialArrayState allocation for reuse
 - 8342979: Start of release updates for JDK 25

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

Changes: https://git.openjdk.org/valhalla/pull/1350/files
  Stats: 7036 lines in 131 files changed: 6650 ins; 151 del; 235 mod
  Patch: https://git.openjdk.org/valhalla/pull/1350.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1350/head:pull/1350

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

From dsimms at openjdk.org  Tue Feb  4 13:17:03 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 4 Feb 2025 13:17:03 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <JcRtenQgDSZMxK_FocJ678qCRC1vefcyuj-nfxRV8mI=.c2850abf-a118-4ab9-97f1-388ff4c276ba@github.com>
References: <JcRtenQgDSZMxK_FocJ678qCRC1vefcyuj-nfxRV8mI=.c2850abf-a118-4ab9-97f1-388ff4c276ba@github.com>
Message-ID: <TouPXpiIoE1jjUxQQkyfROkCVXcA4GL6ePkVM6h8uu4=.0d446a47-21a9-4e7c-96aa-25d396bd7a35@github.com>

On Tue, 4 Feb 2025 13:09:31 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+1

This pull request has now been integrated.

Changeset: 43bee78c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/43bee78c8155e5d219a079ce89abd3e0b2196fd5
Stats:     7036 lines in 131 files changed: 6650 ins; 151 del; 235 mod

Merge jdk

Merge jdk-25+1

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

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

From dsimms at openjdk.org  Tue Feb  4 14:26:31 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 4 Feb 2025 14:26:31 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <MoITBLtMZjE5twURkyKPx5CP0n_Mogvb-Uveg-IDq1k=.eed0d2d5-006a-44ac-97ba-7c22cf4de866@github.com>

Merge tag 'jdk-25+2' into lworld_merge_jdk_25_2
Added tag jdk-25+2 for changeset ceb4366e

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

Commit messages:
 - Merge tag 'jdk-25+2' into lworld_merge_jdk_25_2
 - 8345955: Deprecate the UseOprofile flag with a view to removing the legacy oprofile support in the VM
 - 8345876: Update nativeAddAtIndex comment to match the code
 - 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation
 - 8345423: Shenandoah: Parallelize concurrent cleanup
 - 8346039: [BACKOUT] - [C1] LIR Operations with one input should be implemented as LIR_Op1
 - 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
 - 8345797: Update copyright year to 2024 for client-libs in files where it was missed
 - 8345799: Update copyright year to 2024 for core-libs in files where it was missed
 - 8345683: Remove special flags for files compiled for static libraries
 - ... and 80 more: https://git.openjdk.org/valhalla/compare/43bee78c...2322faa0

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

Changes: https://git.openjdk.org/valhalla/pull/1351/files
  Stats: 14263 lines in 2533 files changed: 7631 ins; 2313 del; 4319 mod
  Patch: https://git.openjdk.org/valhalla/pull/1351.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1351/head:pull/1351

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

From rriggs at openjdk.org  Tue Feb  4 17:13:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 17:13:42 GMT
Subject: [lworld] RFR: 8348904: [lworld] Remove concept of default value
 object and zeroInstance [v2]
In-Reply-To: <b8BYRZbPLL6hKuSVp6Vg2svkX-hyRrnOUQ_kv-iiX6A=.8afe5176-b2f4-48d4-b87e-3c7bfde1726e@github.com>
References: <ZHZ-nwNYtywqlCWy_8m1MVIi85Nsk9Nka_N5-tq2kPQ=.eebccf5b-dcc7-445f-9dcf-9cea906db656@github.com>
 <yp3gVQFduATcwR8EXnwVNiv6eHLRn4IhfeJ6KePqvKU=.c619a790-270a-4a62-8109-e230db303ab6@github.com>
 <b8BYRZbPLL6hKuSVp6Vg2svkX-hyRrnOUQ_kv-iiX6A=.8afe5176-b2f4-48d4-b87e-3c7bfde1726e@github.com>
Message-ID: <K7wPhJoOzqGSSFHxKlqULwH8ZuMOX85yaE70dXM0MYs=.cdb1868c-5683-4096-9bcd-1c021e557e4a@github.com>

On Mon, 3 Feb 2025 04:23:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove debug println
>>  - Merge branch 'xx-broken-default-value-object' into 8348904-remove-default-value-object
>>    Remove vestigal remains of zeroInstance in DirectMethodHandle.makePreparedFieldLambdaForm.
>>  - 8348904: [lworld] Remove concept of default value object and zeroInstance
>>    Remove support for the default object and zeroInstance, no longer included in the spec.
>>    In related tests, test cases were removed if no longer applicable or
>>    replaced by a hand created zero/null object.
>
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Thanks for this update; thought we don't update headers in valhalla.

For OpenJDK projects, copyrights are updated. Do it now, you won't have to do it later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1346#discussion_r1941572968

From rriggs at openjdk.org  Tue Feb  4 17:13:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 17:13:43 GMT
Subject: [lworld] Integrated: 8348904: [lworld] Remove concept of default value
 object and zeroInstance
In-Reply-To: <ZHZ-nwNYtywqlCWy_8m1MVIi85Nsk9Nka_N5-tq2kPQ=.eebccf5b-dcc7-445f-9dcf-9cea906db656@github.com>
References: <ZHZ-nwNYtywqlCWy_8m1MVIi85Nsk9Nka_N5-tq2kPQ=.eebccf5b-dcc7-445f-9dcf-9cea906db656@github.com>
Message-ID: <AJKiNxxLdHZeowAbcSf1ggeawRLnXiswXrAisoqXa9g=.32784f2a-2430-4db6-8667-8e5aa170f043@github.com>

On Fri, 31 Jan 2025 20:26:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove support for the default value object and zeroInstance, no longer included in the spec.
> In related tests, test cases were removed if no longer applicable or replaced by a hand created zero/null object.

This pull request has now been integrated.

Changeset: 38041d75
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/38041d7572e853348691af5b384a08f245e2354d
Stats:     109 lines in 13 files changed: 4 ins; 69 del; 36 mod

8348904: [lworld] Remove concept of default value object and zeroInstance

Reviewed-by: liach

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

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

From liach at openjdk.org  Tue Feb  4 17:19:24 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 4 Feb 2025 17:19:24 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v3]
In-Reply-To: <xT6C9izbpmme3XhYVopaBcZ804Ig5DYtNonEAmUKRHY=.e75452f1-7fac-4702-abcd-358746b0cee3@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
 <xT6C9izbpmme3XhYVopaBcZ804Ig5DYtNonEAmUKRHY=.e75452f1-7fac-4702-abcd-358746b0cee3@github.com>
Message-ID: <URm-waIZWdkIaMyIYzOPd5iMhRn-NR-sRSgsyb73Im4=.913adeeb-a08f-49f6-aeba-39b2d7a0360d@github.com>

On Mon, 13 Jan 2025 22:09:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
>> Simplified WeakHashMap javadoc updates for IdentityException. 
>> Added note to System.identityHashCode to include value objects.
>> Added to class javadoc for IdentityHashMap for value objects.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception
>  - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException
>    Add APINote and javadoc for IdentityException where it will be useful to know.
>    Updated Objects.hasIdentity to return true for non-null reference to identity class; else false
>    Added Objects.isValueObject to return true for non-null reference to value class; else false
>    Updated tests for value objects.

Does this intend to wait for openjdk/jdk#23395 or will it migrate from HTML after the taglet is available?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1327#issuecomment-2634595576

From fparain at openjdk.org  Tue Feb  4 19:04:04 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Feb 2025 19:04:04 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v4]
In-Reply-To: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
Message-ID: <qyX9kHvfgA6CVPliWgmK90BhL1lukeD8_uXkRJK7fYE=.0074c47f-d5c1-46ec-89d1-fc437a4576af@github.com>

> This patch is mostly about VM flags update and internal renaming.
> 
> Renaming a few symbols to make them consistent with previous code cleanup:
>   - data_for_oop() -> payload_address()
>   - first_field_offset() -> payload_offset()
>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>   
> VM flags controlling flattening:
>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>   
> Example:
>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
> 
> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
> 
> Feel free to propose new names for those flags if you think they are not explicit enough.
> 
> Thank you,
> 
> 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 six commits:

 - Change flags names for more consistency
 - Merge remote-tracking branch 'upstream/lworld' into renaming
 - Fix identation
 - Fix typo
 - Merge remote-tracking branch 'upstream/lworld' into renaming
 - Renaming and VM flags cleanup

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

Changes: https://git.openjdk.org/valhalla/pull/1345/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1345&range=03
  Stats: 680 lines in 96 files changed: 324 ins; 20 del; 336 mod
  Patch: https://git.openjdk.org/valhalla/pull/1345.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1345/head:pull/1345

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

From fparain at openjdk.org  Tue Feb  4 19:06:24 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Feb 2025 19:06:24 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v3]
In-Reply-To: <xlOQ-z3QR0xV5lROYBWK98rSR0YQUbF8vhNP_LbEQmw=.78b52ef4-e4b4-4a78-bb02-e5658fd24ef9@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
 <xlOQ-z3QR0xV5lROYBWK98rSR0YQUbF8vhNP_LbEQmw=.78b52ef4-e4b4-4a78-bb02-e5658fd24ef9@github.com>
Message-ID: <vRnTKg7VDoRQXIIVqm9YURN_eK2cevYbatdKiXymhWI=.52a35005-4a17-4a51-a666-b4efb446bc73@github.com>

On Mon, 3 Feb 2025 17:09:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch is mostly about VM flags update and internal renaming.
>> 
>> Renaming a few symbols to make them consistent with previous code cleanup:
>>   - data_for_oop() -> payload_address()
>>   - first_field_offset() -> payload_offset()
>>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>>   
>> VM flags controlling flattening:
>>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>>   
>> Example:
>>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
>> 
>> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
>> 
>> Feel free to propose new names for those flags if you think they are not explicit enough.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix identation

After a discussion with Tobias, we agreed on a more consistent scheme for flags names:
  - UseFlatArray -> UseArrayFlattening
  - UseFlatField -> UseFieldFlattening
  - NonAtomicValueFlattening -> UseNonAtomicValueFlattening
  - AtomicValueFlattening -> UseAtomicValueFlattening
  - NullableValueFlattening -> UseNullableValueFlattening

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

PR Comment: https://git.openjdk.org/valhalla/pull/1345#issuecomment-2634822741

From rriggs at openjdk.org  Tue Feb  4 20:43:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 20:43:30 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v3]
In-Reply-To: <xT6C9izbpmme3XhYVopaBcZ804Ig5DYtNonEAmUKRHY=.e75452f1-7fac-4702-abcd-358746b0cee3@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
 <xT6C9izbpmme3XhYVopaBcZ804Ig5DYtNonEAmUKRHY=.e75452f1-7fac-4702-abcd-358746b0cee3@github.com>
Message-ID: <mUUV8BLGjUQTyBbnGzS0faxfZ4k1aK3SKJW8v1mU-UQ=.7bc4009e-5914-4eae-88dc-62d39bc141ef@github.com>

On Mon, 13 Jan 2025 22:09:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
>> Simplified WeakHashMap javadoc updates for IdentityException. 
>> Added note to System.identityHashCode to include value objects.
>> Added to class javadoc for IdentityHashMap for value objects.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception
>  - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException
>    Add APINote and javadoc for IdentityException where it will be useful to know.
>    Updated Objects.hasIdentity to return true for non-null reference to identity class; else false
>    Added Objects.isValueObject to return true for non-null reference to value class; else false
>    Updated tests for value objects.

I've been trying out the various incarnations of the javadoc support to see how they work, but that can be a separate PR when it settles.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1327#issuecomment-2635022869

From rriggs at openjdk.org  Tue Feb  4 20:59:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 20:59:39 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v4]
In-Reply-To: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
Message-ID: <OcGqhM0HrS8vAuoa3hIAkHeTwpYA6Fq8wCm7tMfRwvc=.294a8e59-df3b-4b6e-beca-1a874831681d@github.com>

> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
> Simplified WeakHashMap javadoc updates for IdentityException. 
> Added note to System.identityHashCode to include value objects.
> Added to class javadoc for IdentityHashMap for value objects.

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

  Expand javadoc reference to Reference

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1327/files
  - new: https://git.openjdk.org/valhalla/pull/1327/files/850923bd..d450add4

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

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

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

From thartmann at openjdk.org  Wed Feb  5 06:50:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 5 Feb 2025 06:50:29 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v4]
In-Reply-To: <qyX9kHvfgA6CVPliWgmK90BhL1lukeD8_uXkRJK7fYE=.0074c47f-d5c1-46ec-89d1-fc437a4576af@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
 <qyX9kHvfgA6CVPliWgmK90BhL1lukeD8_uXkRJK7fYE=.0074c47f-d5c1-46ec-89d1-fc437a4576af@github.com>
Message-ID: <jxIMNovTNEJzYZVPWwEQb71cyqCsU_MmHxjrm7ZP8Ig=.a42132d2-3977-4fed-b8b1-eb0eddec2916@github.com>

On Tue, 4 Feb 2025 19:04:04 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch is mostly about VM flags update and internal renaming.
>> 
>> Renaming a few symbols to make them consistent with previous code cleanup:
>>   - data_for_oop() -> payload_address()
>>   - first_field_offset() -> payload_offset()
>>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>>   
>> VM flags controlling flattening:
>>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>>   
>> Example:
>>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
>> 
>> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
>> 
>> Feel free to propose new names for those flags if you think they are not explicit enough.
>> 
>> Thank you,
>> 
>> 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 six commits:
> 
>  - Change flags names for more consistency
>  - Merge remote-tracking branch 'upstream/lworld' into renaming
>  - Fix identation
>  - Fix typo
>  - Merge remote-tracking branch 'upstream/lworld' into renaming
>  - Renaming and VM flags cleanup

src/hotspot/share/runtime/globals.hpp line 814:

> 812:           "Allow the VM to flatten value fields")                           \
> 813:                                                                             \
> 814:   product(bool, UseNonUseAtomicValueFlattening, true,                       \

There's something off here :)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1345#discussion_r1942327794

From jbhateja at openjdk.org  Wed Feb  5 10:04:23 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 5 Feb 2025 10:04:23 GMT
Subject: [lworld+fp16] RFR: 8345053: Add support for FP16 valueOf routines
 [v3]
In-Reply-To: <WYWtpggVyVJgqiWrONDGIl44SDOiv4G6tNl7vzay0S4=.1cc1ee30-e80f-4a38-ab4c-2ed079941797@github.com>
References: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
 <WYWtpggVyVJgqiWrONDGIl44SDOiv4G6tNl7vzay0S4=.1cc1ee30-e80f-4a38-ab4c-2ed079941797@github.com>
Message-ID: <CaIPm_BdO9I0tA3kLPCIL6CEBltt0ENx6Uh7RDJgpdo=.e523a0e6-0046-4868-b06d-76b748e0ea03@github.com>

On Mon, 3 Feb 2025 16:23:42 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> This patch adds intrinsic support for Float16.valueOf() routines - conversions from int/long/double to half float.
>
> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks @Bhavana-Kilambi, after scalar Float16 support patch gets integrated into mainline, we will need a little fine-tuning around vector IR, before that a merge is required from mainline (mainline->lworld->lworld+fp16)

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

Marked as reviewed by jbhateja (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1332#pullrequestreview-2595185362

From bkilambi at openjdk.org  Wed Feb  5 10:16:28 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 5 Feb 2025 10:16:28 GMT
Subject: [lworld+fp16] RFR: 8345053: Add support for FP16 valueOf routines
In-Reply-To: <vN0ymD-a9BPcdz9RZqE5vhUaLd2wSe37U4qubYAErIg=.3713b9c2-3de4-4598-8001-fb521e52f127@github.com>
References: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
 <HP8sdDC4niQG7-4_ktTgBWDSA-ksOpryRW6aqlk6sCU=.5472365c-f62a-461d-9f52-755abd76f568@github.com>
 <vN0ymD-a9BPcdz9RZqE5vhUaLd2wSe37U4qubYAErIg=.3713b9c2-3de4-4598-8001-fb521e52f127@github.com>
Message-ID: <qdfILgCswjoXN85qS6I59plLoqjLeKYwgNrN66RsVaQ=.c083da6f-50d8-40cd-ab9a-f1ad3398b892@github.com>

On Wed, 22 Jan 2025 11:56:48 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi @jatin-bhateja , could you please review this PR? Thanks!
>
> Hi @Bhavana-Kilambi , Kindly extend [test/micro/org/openjdk/bench/java/lang/Float16OpsBenchmark.java](test/micro/org/openjdk/bench/java/lang/Float16OpsBenchmark.java) to cover newly intrinsified operations and share the results with and without changes.

Sure @jatin-bhateja , would be happy to do vector related changes after we merge the mainline branch here. Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1332#issuecomment-2636298521

From bkilambi at openjdk.org  Wed Feb  5 10:19:31 2025
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 5 Feb 2025 10:19:31 GMT
Subject: [lworld+fp16] Integrated: 8345053: Add support for FP16 valueOf
 routines
In-Reply-To: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
References: <q9gJQPoGk7kRz3gBgsxBsf-hsyjKlEbKVg-oTreoL2o=.54c87ac6-3d22-46f3-ae6c-b4427e56fb46@github.com>
Message-ID: <NgQqB4vMZvLHY2X2_Thaf5TGwVJ5h7J-Ht0XurqCmjk=.28aa0bfe-645c-4cca-930a-f44367e58559@github.com>

On Fri, 17 Jan 2025 17:47:20 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> This patch adds intrinsic support for Float16.valueOf() routines - conversions from int/long/double to half float.

This pull request has now been integrated.

Changeset: 0ed65b9a
Author:    Bhavana Kilambi <bkilambi at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ed65b9a63405e950c411835120f0f36e326aaaa
Stats:     1342 lines in 28 files changed: 642 ins; 2 del; 698 mod

8345053: Add support for FP16 valueOf routines

Reviewed-by: jbhateja

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

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

From dsimms at openjdk.org  Wed Feb  5 14:46:54 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 5 Feb 2025 14:46:54 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <MoITBLtMZjE5twURkyKPx5CP0n_Mogvb-Uveg-IDq1k=.eed0d2d5-006a-44ac-97ba-7c22cf4de866@github.com>
References: <MoITBLtMZjE5twURkyKPx5CP0n_Mogvb-Uveg-IDq1k=.eed0d2d5-006a-44ac-97ba-7c22cf4de866@github.com>
Message-ID: <Gbh1x0RI1zq6bNPp54bnl3x68Ah2K-sojPg85o6j3A0=.0519b224-e8ee-4bb0-a506-5edd9dc31e47@github.com>

> Merge tag 'jdk-25+2' into lworld_merge_jdk_25_2
> Added tag jdk-25+2 for changeset ceb4366e

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 92 commits:

 - Merge branch 'lworld' into lworld_merge_jdk_25_2
 - Re-enable preview for tests with LoadableDescriptors dependencies (e.g. RebuildingTransformation)
 - Merge tag 'jdk-25+2' into lworld_merge_jdk_25_2
   
   Added tag jdk-25+2 for changeset ceb4366e
 - 8345955: Deprecate the UseOprofile flag with a view to removing the legacy oprofile support in the VM
   
   Reviewed-by: iklam, shade
 - 8345876: Update nativeAddAtIndex comment to match the code
   
   Reviewed-by: azvegint, aivanov, psadhukhan, kizune
 - 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation
   
   Reviewed-by: psandoz, jbhateja, epeter
 - 8345423: Shenandoah: Parallelize concurrent cleanup
   
   Reviewed-by: ysr, kdnilsen, wkemper
 - 8346039: [BACKOUT] - [C1] LIR Operations with one input should be implemented as LIR_Op1
   
   Reviewed-by: kvn, mdoerr
 - 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
   
   Reviewed-by: ihse
 - 8345797: Update copyright year to 2024 for client-libs in files where it was missed
   
   Reviewed-by: psadhukhan
 - ... and 82 more: https://git.openjdk.org/valhalla/compare/38041d75...e6b93179

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

Changes: https://git.openjdk.org/valhalla/pull/1351/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1351&range=01
  Stats: 14269 lines in 2536 files changed: 7639 ins; 2312 del; 4318 mod
  Patch: https://git.openjdk.org/valhalla/pull/1351.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1351/head:pull/1351

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

From dsimms at openjdk.org  Wed Feb  5 14:46:57 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 5 Feb 2025 14:46:57 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <MoITBLtMZjE5twURkyKPx5CP0n_Mogvb-Uveg-IDq1k=.eed0d2d5-006a-44ac-97ba-7c22cf4de866@github.com>
References: <MoITBLtMZjE5twURkyKPx5CP0n_Mogvb-Uveg-IDq1k=.eed0d2d5-006a-44ac-97ba-7c22cf4de866@github.com>
Message-ID: <GmULPbT5z3kFx6qG8pniAZfs7qYL3JoxXzhNIZ-AV7I=.83855cab-30c9-4d29-999f-920d8538be31@github.com>

On Tue, 4 Feb 2025 14:19:56 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+2' into lworld_merge_jdk_25_2
> Added tag jdk-25+2 for changeset ceb4366e

This pull request has now been integrated.

Changeset: 02cdf7d5
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/02cdf7d5c46ca7ff37e44e4e78bb4549f801536b
Stats:     14269 lines in 2536 files changed: 7639 ins; 2312 del; 4318 mod

Merge jdk

Merge jdk-25+2

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

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

From dsimms at openjdk.org  Thu Feb  6 08:36:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 6 Feb 2025 08:36:37 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <KSLXsEuH7c4xPDnLQ7Dzrxdt4hdPnExMi6Nx7xdcC7U=.5719315d-75c1-4730-9703-0b8cbf3ed502@github.com>
References: <KSLXsEuH7c4xPDnLQ7Dzrxdt4hdPnExMi6Nx7xdcC7U=.5719315d-75c1-4730-9703-0b8cbf3ed502@github.com>
Message-ID: <A3TsnJGNdeuQAZUYbrhYndMs5aW1vJX4YZH-Wxt0mi4=.35a0434a-601a-438f-99ae-04bacefc8841@github.com>

On Thu, 6 Feb 2025 08:24:15 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+3

This pull request has now been integrated.

Changeset: dc0ec550
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dc0ec550dd324e6b27fffa49483ac229d5cc1da8
Stats:     14328 lines in 942 files changed: 9671 ins; 2403 del; 2254 mod

Merge jdk

Merge jdk-25+3

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

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

From dsimms at openjdk.org  Thu Feb  6 08:30:19 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 6 Feb 2025 08:30:19 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <KSLXsEuH7c4xPDnLQ7Dzrxdt4hdPnExMi6Nx7xdcC7U=.5719315d-75c1-4730-9703-0b8cbf3ed502@github.com>

Merge jdk-25+3

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

Commit messages:
 - Missing lint categories (partial fix for 8345263)
 - Merge tag 'jdk-25+3' into lworld_merge_jdk_25_3
 - 8346463: Add test coverage for deploying the default provider as a module
 - 8346306: Unattached thread can cause crash during VM exit if it calls wait_if_vm_exited
 - 8340401: DcmdMBeanPermissionsTest.java and SystemDumpMapTest.java fail with assert(_stack_base != nullptr) failed: Sanity check
 - 8346475: RISC-V: Small improvement for MacroAssembler::ctzc_bit
 - 8346016: Problemlist vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_a in virtual thread mode
 - 8346132: fallbacklinker.c failed compilation due to unused variable
 - 8346570: SM cleanup of tests for Beans and Serialization
 - 8346532: XXXVector::rearrangeTemplate misses null check
 - ... and 85 more: https://git.openjdk.org/valhalla/compare/02cdf7d5...691951f9

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

Changes: https://git.openjdk.org/valhalla/pull/1352/files
  Stats: 14328 lines in 942 files changed: 9671 ins; 2403 del; 2254 mod
  Patch: https://git.openjdk.org/valhalla/pull/1352.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1352/head:pull/1352

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

From dsimms at openjdk.org  Thu Feb  6 14:05:19 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 6 Feb 2025 14:05:19 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <fBFGdJE0cTB7WzRzkjbIQqVj5-Z3XyvA55SpOBV8vUk=.1903ac2f-3490-4f52-85f8-94471426a665@github.com>

Merge jdk-25+4
Merge jdk-25+5

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

Commit messages:
 - Merge tag 'jdk-25+5' into lworld_merge_jdk_25_4
 - 8346671: java/nio/file/Files/probeContentType/Basic.java fails on Windows 2025
 - 8346998: Test nsk/jvmti/ResourceExhausted/resexhausted003 fails with java.lang.OutOfMemoryError when CDS is off
 - 8347147: [REDO] AccessFlags can be u2 in metadata
 - 8346310: Duplicate !HAS_PENDING_EXCEPTION check in DynamicArchive::dump_at_exit
 - 8166983: Remove old/legacy unused tzdata files
 - 8346099: JFR: Query for 'jfr view' can't handle wildcard with multiple event types
 - 8346047: JFR: Incorrect percentile value in 'jfr view'
 - 8345580: Remove const from Node::_idx which is modified
 - 8346872: tools/jpackage/windows/WinLongPathTest.java fails
 - ... and 86 more: https://git.openjdk.org/valhalla/compare/dc0ec550...efc32187

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

Changes: https://git.openjdk.org/valhalla/pull/1353/files
  Stats: 20952 lines in 363 files changed: 8545 ins; 10895 del; 1512 mod
  Patch: https://git.openjdk.org/valhalla/pull/1353.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1353/head:pull/1353

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

From fparain at openjdk.org  Thu Feb  6 14:18:11 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 6 Feb 2025 14:18:11 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v5]
In-Reply-To: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
Message-ID: <DDcRiar7EIad4RDYfeEA2stBwp02JPI7qwj5nzN1tow=.390de7c3-e3ea-4dd8-b183-642f904d5b76@github.com>

> This patch is mostly about VM flags update and internal renaming.
> 
> Renaming a few symbols to make them consistent with previous code cleanup:
>   - data_for_oop() -> payload_address()
>   - first_field_offset() -> payload_offset()
>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>   
> VM flags controlling flattening:
>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>   
> Example:
>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
> 
> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
> 
> Feel free to propose new names for those flags if you think they are not explicit enough.
> 
> Thank you,
> 
> Fred

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

  Fix flag name typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1345/files
  - new: https://git.openjdk.org/valhalla/pull/1345/files/cc2eab84..74b55a39

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

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

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

From fparain at openjdk.org  Thu Feb  6 14:18:12 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 6 Feb 2025 14:18:12 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v4]
In-Reply-To: <jxIMNovTNEJzYZVPWwEQb71cyqCsU_MmHxjrm7ZP8Ig=.a42132d2-3977-4fed-b8b1-eb0eddec2916@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
 <qyX9kHvfgA6CVPliWgmK90BhL1lukeD8_uXkRJK7fYE=.0074c47f-d5c1-46ec-89d1-fc437a4576af@github.com>
 <jxIMNovTNEJzYZVPWwEQb71cyqCsU_MmHxjrm7ZP8Ig=.a42132d2-3977-4fed-b8b1-eb0eddec2916@github.com>
Message-ID: <BghCrXbHbdvgQIUB7ktjmHgI7BvSgPewtCg3wX2ruXg=.4b52c3a8-62f8-40d3-b50c-72d17c1de832@github.com>

On Wed, 5 Feb 2025 06:47:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Change flags names for more consistency
>>  - Merge remote-tracking branch 'upstream/lworld' into renaming
>>  - Fix identation
>>  - Fix typo
>>  - Merge remote-tracking branch 'upstream/lworld' into renaming
>>  - Renaming and VM flags cleanup
>
> src/hotspot/share/runtime/globals.hpp line 814:
> 
>> 812:           "Allow the VM to flatten value fields")                           \
>> 813:                                                                             \
>> 814:   product(bool, UseNonUseAtomicValueFlattening, true,                       \
> 
> There's something off here :)

Definitively off.
Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1345#discussion_r1944801573

From amenkov at openjdk.org  Fri Feb  7 00:17:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Feb 2025 00:17:57 GMT
Subject: [lworld] RFR: 8348743: [lworld] GetObjectHashCode crashes with
 ShouldNotReachHere()
Message-ID: <8frpW26VEjktzf8wThn3GjIK21OsWQdl2VMUzkjXKh4=.e5c58711-c0c7-47f2-a93b-4c9e158f0ff9@github.com>

The change fixes GetObjectHashCode JVMTI function.
Hashcode is the same for all instances of a value class - similar to fix for heap walking functions ([JDK-8310655](https://bugs.openjdk.org/browse/JDK-8310655)). The solution is far from perfect, but it's better than crash

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

Commit messages:
 - fix

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

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

From dsimms at openjdk.org  Fri Feb  7 05:47:07 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 7 Feb 2025 05:47:07 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <fBFGdJE0cTB7WzRzkjbIQqVj5-Z3XyvA55SpOBV8vUk=.1903ac2f-3490-4f52-85f8-94471426a665@github.com>
References: <fBFGdJE0cTB7WzRzkjbIQqVj5-Z3XyvA55SpOBV8vUk=.1903ac2f-3490-4f52-85f8-94471426a665@github.com>
Message-ID: <g_7nKY-9yANIk316xpa58B-W43vG51Z1KCshQZtcBf8=.4dc50efe-71a0-4231-ae7f-3bc1de0c5343@github.com>

> Merge jdk-25+4
> Merge jdk-25+5

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

  Valhalla code for 8347147, u2 AccessFlags

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1353/files
  - new: https://git.openjdk.org/valhalla/pull/1353/files/efc32187..d86e6d94

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

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

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

From dsimms at openjdk.org  Fri Feb  7 05:56:25 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 7 Feb 2025 05:56:25 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <fBFGdJE0cTB7WzRzkjbIQqVj5-Z3XyvA55SpOBV8vUk=.1903ac2f-3490-4f52-85f8-94471426a665@github.com>
References: <fBFGdJE0cTB7WzRzkjbIQqVj5-Z3XyvA55SpOBV8vUk=.1903ac2f-3490-4f52-85f8-94471426a665@github.com>
Message-ID: <IPr7JZsATvCY7HjLK5umnbtYR534zNh4gRkug_Xxc4A=.4ffb668d-f02a-476d-a309-d1a1e7d0b80d@github.com>

On Thu, 6 Feb 2025 13:59:22 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+4
> Merge jdk-25+5

This pull request has now been integrated.

Changeset: 5ca8cb12
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5ca8cb126536c70ab9e0943958b1d641018945a6
Stats:     20954 lines in 365 files changed: 8545 ins; 10895 del; 1514 mod

Merge jdk

Merge jdk-25+4 and jdk-25+5

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

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

From dsimms at openjdk.org  Fri Feb  7 06:13:38 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 7 Feb 2025 06:13:38 GMT
Subject: [lworld] Integrated: Adjust testing 250207
Message-ID: <ORWeueHtKDy9CJocAt3dX_UaOnv1l7Nyb9huH5sjAr8=.4f2a9a54-f08d-4823-885b-49600ec6705e@github.com>

Problem listing

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

Commit messages:
 - Adjust testing 250207

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

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

From dsimms at openjdk.org  Fri Feb  7 06:13:38 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 7 Feb 2025 06:13:38 GMT
Subject: [lworld] Integrated: Adjust testing 250207
In-Reply-To: <ORWeueHtKDy9CJocAt3dX_UaOnv1l7Nyb9huH5sjAr8=.4f2a9a54-f08d-4823-885b-49600ec6705e@github.com>
References: <ORWeueHtKDy9CJocAt3dX_UaOnv1l7Nyb9huH5sjAr8=.4f2a9a54-f08d-4823-885b-49600ec6705e@github.com>
Message-ID: <90qymejAyZmvfa09_2LJHh1krJFUHIhPtqcK77XdVl0=.343736d7-0ec5-4d54-91a8-2ffae3e8fb80@github.com>

On Fri, 7 Feb 2025 06:08:33 GMT, David Simms <dsimms at openjdk.org> wrote:

> Problem listing

This pull request has now been integrated.

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

Adjust testing 250207

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

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

From thartmann at openjdk.org  Fri Feb  7 14:48:28 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Feb 2025 14:48:28 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v5]
In-Reply-To: <DDcRiar7EIad4RDYfeEA2stBwp02JPI7qwj5nzN1tow=.390de7c3-e3ea-4dd8-b183-642f904d5b76@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
 <DDcRiar7EIad4RDYfeEA2stBwp02JPI7qwj5nzN1tow=.390de7c3-e3ea-4dd8-b183-642f904d5b76@github.com>
Message-ID: <xQauxCwuNRnpgCYOOMhJQc169i80oeYRsntpdmLlRrs=.fd02a424-fd35-4965-b95b-6c8ca392962c@github.com>

On Thu, 6 Feb 2025 14:18:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch is mostly about VM flags update and internal renaming.
>> 
>> Renaming a few symbols to make them consistent with previous code cleanup:
>>   - data_for_oop() -> payload_address()
>>   - first_field_offset() -> payload_offset()
>>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>>   
>> VM flags controlling flattening:
>>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>>   
>> Example:
>>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
>> 
>> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
>> 
>> Feel free to propose new names for those flags if you think they are not explicit enough.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix flag name typo

Looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1345#pullrequestreview-2601932984

From chagedorn at openjdk.org  Fri Feb  7 16:29:52 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 7 Feb 2025 16:29:52 GMT
Subject: [lworld] RFR: 8348962: [lworld]
 compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in
 PhaseMacroExpand::expand_arraycopy_node
Message-ID: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>

When we call `clone()` on an array, we are calling the `Object::clone()` instrinsic with an array class receiver. For that, we call `inline_native_clone()`. When additionally running with `-XX:-ReduceInitialCardMarks`, `CardTableBarrierSetC2::array_copy_requires_gc_barriers()` will return true. As a result, we mark the newly created `ArrayCopyNode` for the cloning as `CloneOopArray`:

https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5631-L5632

The destination type of `ArrayCopyNode` is known to be some kind of array since we called `Object::clone()` on an array. Therefore, when expanding the node during macro expansion, the destination type will always be an array type and consequently, `top_dest` will be nun-null in `PhaseMacroExpand::expand_arraycopy_node()`: 

https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360

However, with reflection, we can still directly call `Object::clone()` on an array without C2 knowing that it's an array. This is done in the failing test when calling `TestObjectArrayClone::testCloneObjectWithMethodHandle()`:

https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java#L192-L194

`clone` is the `Object::clone()` method and `obj` is a `String[]` but passed in as an `Object` to the method. As a result, C2 just knows that the destination type is `Object`. Therefore, `top_dest` will be null here (i.e. not an array type):

https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360

Later, we check whether the destination is a flat array:
https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1382

Since `top_dest` is null, we crash with a segfault.

The solution is to just check whether `top_dest` is non-null. Note that in this case, we do not need a membar. When it turns out that the array behind `Object` is flat during runtime, we will go to the slow path and make a call to `clone()`:

https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5611-L5613

I added the failing flag combination to the existing test which covers this bug.

Thanks,
Christian

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

Commit messages:
 - 8348962: [lworld] compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in PhaseMacroExpand::expand_arraycopy_node

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

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

From fparain at openjdk.org  Fri Feb  7 18:19:11 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 7 Feb 2025 18:19:11 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v6]
In-Reply-To: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
Message-ID: <BPTI9kNqDSWSahLwL3s4ZeY9aXCkVVPyvmpB2aQJr1g=.0a8b4458-83d5-4872-83b7-dc528b7ecc1e@github.com>

> This patch is mostly about VM flags update and internal renaming.
> 
> Renaming a few symbols to make them consistent with previous code cleanup:
>   - data_for_oop() -> payload_address()
>   - first_field_offset() -> payload_offset()
>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>   
> VM flags controlling flattening:
>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>   
> Example:
>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
> 
> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
> 
> Feel free to propose new names for those flags if you think they are not explicit enough.
> 
> Thank you,
> 
> 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:

 - Merge remote-tracking branch 'upstream/lworld' into renaming
 - Fix flag name typo
 - Change flags names for more consistency
 - Merge remote-tracking branch 'upstream/lworld' into renaming
 - Fix identation
 - Fix typo
 - Merge remote-tracking branch 'upstream/lworld' into renaming
 - Renaming and VM flags cleanup

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

Changes: https://git.openjdk.org/valhalla/pull/1345/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1345&range=05
  Stats: 680 lines in 96 files changed: 324 ins; 20 del; 336 mod
  Patch: https://git.openjdk.org/valhalla/pull/1345.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1345/head:pull/1345

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

From fparain at openjdk.org  Fri Feb  7 18:19:12 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 7 Feb 2025 18:19:12 GMT
Subject: [lworld] RFR: 8349162: [lworld] VM Flags controlling flattening
 need an update [v5]
In-Reply-To: <DDcRiar7EIad4RDYfeEA2stBwp02JPI7qwj5nzN1tow=.390de7c3-e3ea-4dd8-b183-642f904d5b76@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
 <DDcRiar7EIad4RDYfeEA2stBwp02JPI7qwj5nzN1tow=.390de7c3-e3ea-4dd8-b183-642f904d5b76@github.com>
Message-ID: <F1_rKotZTAZwCIVsEFHct61xBF7xCpPsattSjTF5d-Q=.3ade2d4a-1eee-4e5f-9449-e7aad80d315c@github.com>

On Thu, 6 Feb 2025 14:18:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This patch is mostly about VM flags update and internal renaming.
>> 
>> Renaming a few symbols to make them consistent with previous code cleanup:
>>   - data_for_oop() -> payload_address()
>>   - first_field_offset() -> payload_offset()
>>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>>   
>> VM flags controlling flattening:
>>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>>   
>> Example:
>>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
>> 
>> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
>> 
>> Feel free to propose new names for those flags if you think they are not explicit enough.
>> 
>> Thank you,
>> 
>> Fred
>
> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix flag name typo

Thank you for the reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1345#issuecomment-2643670413

From fparain at openjdk.org  Fri Feb  7 18:19:13 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 7 Feb 2025 18:19:13 GMT
Subject: [lworld] Integrated: 8349162: [lworld] VM Flags controlling flattening
 need an update
In-Reply-To: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
References: <NXrroBJncf2UIptR7jmhdYXba8njN4l1pCihdiOUYGU=.939a318c-eee7-4ce9-8644-d03b6c135aef@github.com>
Message-ID: <0bl55otye7icxanPFunqKYS8nihB19ZOWpE2oXjM4AQ=.dbd7e41a-f265-47c7-9b45-2f146230124e@github.com>

On Fri, 31 Jan 2025 20:17:48 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This patch is mostly about VM flags update and internal renaming.
> 
> Renaming a few symbols to make them consistent with previous code cleanup:
>   - data_for_oop() -> payload_address()
>   - first_field_offset() -> payload_offset()
>   - LayoutKind::PAYLOAD -> LayoutKind::BUFFERED (it is only used to describe layout in buffered values, and it makes it an adjective like the other LayoutKind values)
>   
> VM flags controlling flattening:
>   - size based VM flags are removed:  FlatArrayElementMaxSize, InlineFieldMaxFlatSize. For now, FlatArrayElementMaxOops is still present because some compiler tests rely on it, but it will be removed eventually
>   - InlineArrayAtomicAccess has been removed, use AlwaysAtomicAccesses instead
>   - new VM flags to control the generation of the new layouts: NonAtomicValueFlattening, AtomicValueFlattening, NullableValueFlattening. Note that that those flags control the generation of the layouts, not the way they are used (see flags below)
>   - new VM flags to control use of flat layouts: UseFlatField, UseFlatArray
>   
> Example:
>   To enable flattening of nullable fields, the flag combination is -XX:+NullableValueFlattening -XX:+UseFlatField
> 
> The new VM flags controlling flattening are flags for testing or troubleshooting (they should probably be turned into DIAGNOSTIC flags before preview). They are not designed for performance tuning.
> 
> Feel free to propose new names for those flags if you think they are not explicit enough.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 9786bf33
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9786bf33b14cea79499c88f1d33626a5fbc0c1a5
Stats:     680 lines in 96 files changed: 324 ins; 20 del; 336 mod

8349162: [lworld] VM Flags controlling flattening need an update

Reviewed-by: thartmann

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

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

From amenkov at openjdk.org  Fri Feb  7 23:54:28 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Feb 2025 23:54:28 GMT
Subject: [lworld] Integrated: 8348743: [lworld] GetObjectHashCode crashes with
 ShouldNotReachHere()
In-Reply-To: <8frpW26VEjktzf8wThn3GjIK21OsWQdl2VMUzkjXKh4=.e5c58711-c0c7-47f2-a93b-4c9e158f0ff9@github.com>
References: <8frpW26VEjktzf8wThn3GjIK21OsWQdl2VMUzkjXKh4=.e5c58711-c0c7-47f2-a93b-4c9e158f0ff9@github.com>
Message-ID: <PU_NNocjyJqQrddf46MtC26NKNCAnoAEQELNaKTvtyY=.f9a999b5-541f-4483-a80b-f1b6fd36cc65@github.com>

On Fri, 7 Feb 2025 00:12:19 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes GetObjectHashCode JVMTI function.
> Hashcode is the same for all instances of a value class - similar to fix for heap walking functions ([JDK-8310655](https://bugs.openjdk.org/browse/JDK-8310655)). The solution is far from perfect, but it's better than crash

This pull request has now been integrated.

Changeset: 92472fd8
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/92472fd8258e3519bf6169643524ccca9169b6e6
Stats:     147 lines in 3 files changed: 144 ins; 0 del; 3 mod

8348743: [lworld] GetObjectHashCode crashes with ShouldNotReachHere()

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

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

From duke at openjdk.org  Sun Feb  9 16:14:16 2025
From: duke at openjdk.org (duke)
Date: Sun, 9 Feb 2025 16:14:16 GMT
Subject: [valhalla-docs] Withdrawn: Add Brian Goetz presentation from July 2024
In-Reply-To: <zVCFhDZHLe1uJfRQ0s93w4ADI_B7jPudLU4TQ2MhDSo=.56e628db-89d0-4c0e-bcc8-929befa62230@github.com>
References: <zVCFhDZHLe1uJfRQ0s93w4ADI_B7jPudLU4TQ2MhDSo=.56e628db-89d0-4c0e-bcc8-929befa62230@github.com>
Message-ID: <sy1rKtTJfXG-cplt146XyjriUqrmtRjvUyLUfT5Lsi4=.6850cd2e-b8d0-4159-8941-b21739cbfe8b@github.com>

On Mon, 2 Dec 2024 10:04:04 GMT, Andrew Byrd <duke at openjdk.org> wrote:

> Looking into the present state of project Valhalla, I found a very good presentation from July of 2024 at https://inside.java/tag/valhalla that was not listed on the page at https://openjdk.org/projects/valhalla/ but seems to fit well alongside the other presentations listed there.
> 
> I updated the page to include this presentation from Brian Goetz. I also sorted the presentations in reverse chronological order, as some of the information in this 2024 presentation seems to supersede previous ones.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/valhalla-docs/pull/13

From thartmann at openjdk.org  Mon Feb 10 06:32:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 10 Feb 2025 06:32:25 GMT
Subject: [lworld] RFR: 8348962: [lworld]
 compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in
 PhaseMacroExpand::expand_arraycopy_node
In-Reply-To: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
References: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
Message-ID: <5tuGXK9RKORNqu6YIl5PyBZ5sJRvDD1FZ-MVOtHyPQM=.fa2c66aa-8eb9-4ac9-841d-f906a4f207f7@github.com>

On Fri, 7 Feb 2025 16:25:36 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When we call `clone()` on an array, we are calling the `Object::clone()` instrinsic with an array class receiver. For that, we call `inline_native_clone()`. When additionally running with `-XX:-ReduceInitialCardMarks`, `CardTableBarrierSetC2::array_copy_requires_gc_barriers()` will return true. As a result, we mark the newly created `ArrayCopyNode` for the cloning as `CloneOopArray`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5631-L5632
> 
> The destination type of `ArrayCopyNode` is known to be some kind of array since we called `Object::clone()` on an array. Therefore, when expanding the node during macro expansion, the destination type will always be an array type and consequently, `top_dest` will be nun-null in `PhaseMacroExpand::expand_arraycopy_node()`: 
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
> 
> However, with reflection, we can still directly call `Object::clone()` on an array without C2 knowing that it's an array. This is done in the failing test when calling `TestObjectArrayClone::testCloneObjectWithMethodHandle()`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java#L192-L194
> 
> `clone` is the `Object::clone()` method and `obj` is a `String[]` but passed in as an `Object` to the method. As a result, C2 just knows that the destination type is `Object`. Therefore, `top_dest` will be null here (i.e. not an array type):
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
> 
> Later, we check whether the destination is a flat array:
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1382
> 
> Since `top_dest` is null, we crash with a segfault.
> 
> The solution is to just check whether `top_dest` is non-null. Note that in this case, we do not need a membar. When it turns out that the array behind `Object` is flat during runtime, we will go to the slow path and make a call to `clone()`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5611-L5613
> 
> I added the failing flag combination to the existing test which covers this bug.
> 
> Thanks,
> Christian

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1356#pullrequestreview-2604797317

From chagedorn at openjdk.org  Mon Feb 10 09:35:56 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 10 Feb 2025 09:35:56 GMT
Subject: [lworld] RFR: 8348962: [lworld]
 compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in
 PhaseMacroExpand::expand_arraycopy_node [v2]
In-Reply-To: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
References: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
Message-ID: <KfoCRiVPG6cTfy_qG1q5T2vpbfRmrkEE_5QlVDSW6yk=.7ea74365-b755-468f-b47d-e5151ae0eb5f@github.com>

> When we call `clone()` on an array, we are calling the `Object::clone()` instrinsic with an array class receiver. For that, we call `inline_native_clone()`. When additionally running with `-XX:-ReduceInitialCardMarks`, `CardTableBarrierSetC2::array_copy_requires_gc_barriers()` will return true. As a result, we mark the newly created `ArrayCopyNode` for the cloning as `CloneOopArray`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5631-L5632
> 
> The destination type of `ArrayCopyNode` is known to be some kind of array since we called `Object::clone()` on an array. Therefore, when expanding the node during macro expansion, the destination type will always be an array type and consequently, `top_dest` will be nun-null in `PhaseMacroExpand::expand_arraycopy_node()`: 
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
> 
> However, with reflection, we can still directly call `Object::clone()` on an array without C2 knowing that it's an array. This is done in the failing test when calling `TestObjectArrayClone::testCloneObjectWithMethodHandle()`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java#L192-L194
> 
> `clone` is the `Object::clone()` method and `obj` is a `String[]` but passed in as an `Object` to the method. As a result, C2 just knows that the destination type is `Object`. Therefore, `top_dest` will be null here (i.e. not an array type):
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
> 
> Later, we check whether the destination is a flat array:
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1382
> 
> Since `top_dest` is null, we crash with a segfault.
> 
> The solution is to just check whether `top_dest` is non-null. Note that in this case, we do not need a membar. When it turns out that the array behind `Object` is flat during runtime, we will go to the slow path and make a call to `clone()`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5611-L5613
> 
> I added the failing flag combination to the existing test which covers this bug.
> 
> Thanks,
> Christian

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

  update

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1356/files
  - new: https://git.openjdk.org/valhalla/pull/1356/files/f76d220f..f18be3fe

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

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

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

From thartmann at openjdk.org  Mon Feb 10 11:47:26 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 10 Feb 2025 11:47:26 GMT
Subject: [lworld] RFR: 8348962: [lworld]
 compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in
 PhaseMacroExpand::expand_arraycopy_node [v2]
In-Reply-To: <KfoCRiVPG6cTfy_qG1q5T2vpbfRmrkEE_5QlVDSW6yk=.7ea74365-b755-468f-b47d-e5151ae0eb5f@github.com>
References: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
 <KfoCRiVPG6cTfy_qG1q5T2vpbfRmrkEE_5QlVDSW6yk=.7ea74365-b755-468f-b47d-e5151ae0eb5f@github.com>
Message-ID: <GFJLoBpRGoPLl6YRfzUPoy3OY3W9UYDFLMuH2SxlZ-0=.fc3568e6-0ced-492d-91ed-f3247cd7b6b6@github.com>

On Mon, 10 Feb 2025 09:35:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When we call `clone()` on an array, we are calling the `Object::clone()` instrinsic with an array object receiver. For that, we call `inline_native_clone()`. When additionally running with `-XX:-ReduceInitialCardMarks`, `CardTableBarrierSetC2::array_copy_requires_gc_barriers()` will return true. As a result, we mark the newly created `ArrayCopyNode` for the cloning as `CloneOopArray`:
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5631-L5632
>> 
>> The destination type of `ArrayCopyNode` is known to be some kind of array since we called `Object::clone()` on an array. Therefore, when expanding the node during macro expansion, the destination type will always be an array type and consequently, `top_dest` will be nun-null in `PhaseMacroExpand::expand_arraycopy_node()`: 
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
>> 
>> However, with reflection, we can still directly call `Object::clone()` on an array without C2 knowing that it's an array. This is done in the failing test when calling `TestObjectArrayClone::testCloneObjectWithMethodHandle()`:
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java#L192-L194
>> 
>> `clone` is the `Object::clone()` method and `obj` is a `String[]` but passed in as an `Object` to the method. As a result, C2 just knows that the destination type is `Object`. Therefore, `top_dest` will be null here (i.e. not an array type):
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
>> 
>> Later, we check whether the destination is a flat array:
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1382
>> 
>> Since `top_dest` is null, we crash with a segfault.
>> 
>> The solution is to just check whether `top_dest` is non-null. Note that in this case, we do not need a membar. When it turns out that the array behind `Object` is flat during runtime, we will go to the slow path and make a call to `clone()`:
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5611-L5613
>> 
>> I added the failing flag combination to the existing test which covers this bug.
>> 
>> Tha...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Embarrassing that I didn't spot that :) Looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1356#pullrequestreview-2605512134

From chagedorn at openjdk.org  Mon Feb 10 11:47:26 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 10 Feb 2025 11:47:26 GMT
Subject: [lworld] RFR: 8348962: [lworld]
 compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in
 PhaseMacroExpand::expand_arraycopy_node [v2]
In-Reply-To: <KfoCRiVPG6cTfy_qG1q5T2vpbfRmrkEE_5QlVDSW6yk=.7ea74365-b755-468f-b47d-e5151ae0eb5f@github.com>
References: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
 <KfoCRiVPG6cTfy_qG1q5T2vpbfRmrkEE_5QlVDSW6yk=.7ea74365-b755-468f-b47d-e5151ae0eb5f@github.com>
Message-ID: <_qY28Y2CUAfLoiVAs7N33YYsa6g2f7yCP5N2qXBpnkQ=.f1695bdb-b46f-4797-8b93-80ff88595662@github.com>

On Mon, 10 Feb 2025 09:35:56 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> When we call `clone()` on an array, we are calling the `Object::clone()` instrinsic with an array object receiver. For that, we call `inline_native_clone()`. When additionally running with `-XX:-ReduceInitialCardMarks`, `CardTableBarrierSetC2::array_copy_requires_gc_barriers()` will return true. As a result, we mark the newly created `ArrayCopyNode` for the cloning as `CloneOopArray`:
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5631-L5632
>> 
>> The destination type of `ArrayCopyNode` is known to be some kind of array since we called `Object::clone()` on an array. Therefore, when expanding the node during macro expansion, the destination type will always be an array type and consequently, `top_dest` will be nun-null in `PhaseMacroExpand::expand_arraycopy_node()`: 
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
>> 
>> However, with reflection, we can still directly call `Object::clone()` on an array without C2 knowing that it's an array. This is done in the failing test when calling `TestObjectArrayClone::testCloneObjectWithMethodHandle()`:
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java#L192-L194
>> 
>> `clone` is the `Object::clone()` method and `obj` is a `String[]` but passed in as an `Object` to the method. As a result, C2 just knows that the destination type is `Object`. Therefore, `top_dest` will be null here (i.e. not an array type):
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
>> 
>> Later, we check whether the destination is a flat array:
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1382
>> 
>> Since `top_dest` is null, we crash with a segfault.
>> 
>> The solution is to just check whether `top_dest` is non-null. Note that in this case, we do not need a membar. When it turns out that the array behind `Object` is flat during runtime, we will go to the slow path and make a call to `clone()`:
>> 
>> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5611-L5613
>> 
>> I added the failing flag combination to the existing test which covers this bug.
>> 
>> Tha...
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Thanks Tobias for your review! Same for me, I've stared at the code and could not spot it right away :-)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1356#issuecomment-2647746970

From chagedorn at openjdk.org  Mon Feb 10 11:47:26 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 10 Feb 2025 11:47:26 GMT
Subject: [lworld] Integrated: 8348962: [lworld]
 compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in
 PhaseMacroExpand::expand_arraycopy_node
In-Reply-To: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
References: <UWs5TFzTSUO-UGk0OTrkio5RJDGoUGXNARN4j8LSHMo=.371c2961-dbfd-4f20-ba3d-892cd50cc239@github.com>
Message-ID: <HvwtEJH2IKgtkHE-a91PBC1hUH94KnJ6crKuY9RBseg=.7927e012-7576-4638-8e43-68db26eb789c@github.com>

On Fri, 7 Feb 2025 16:25:36 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When we call `clone()` on an array, we are calling the `Object::clone()` instrinsic with an array object receiver. For that, we call `inline_native_clone()`. When additionally running with `-XX:-ReduceInitialCardMarks`, `CardTableBarrierSetC2::array_copy_requires_gc_barriers()` will return true. As a result, we mark the newly created `ArrayCopyNode` for the cloning as `CloneOopArray`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5631-L5632
> 
> The destination type of `ArrayCopyNode` is known to be some kind of array since we called `Object::clone()` on an array. Therefore, when expanding the node during macro expansion, the destination type will always be an array type and consequently, `top_dest` will be nun-null in `PhaseMacroExpand::expand_arraycopy_node()`: 
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
> 
> However, with reflection, we can still directly call `Object::clone()` on an array without C2 knowing that it's an array. This is done in the failing test when calling `TestObjectArrayClone::testCloneObjectWithMethodHandle()`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java#L192-L194
> 
> `clone` is the `Object::clone()` method and `obj` is a `String[]` but passed in as an `Object` to the method. As a result, C2 just knows that the destination type is `Object`. Therefore, `top_dest` will be null here (i.e. not an array type):
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1360
> 
> Later, we check whether the destination is a flat array:
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/macroArrayCopy.cpp#L1382
> 
> Since `top_dest` is null, we crash with a segfault.
> 
> The solution is to just check whether `top_dest` is non-null. Note that in this case, we do not need a membar. When it turns out that the array behind `Object` is flat during runtime, we will go to the slow path and make a call to `clone()`:
> 
> https://github.com/openjdk/valhalla/blob/d42ac5c615e34a1d6ba20cfec5aa34316eafc374/src/hotspot/share/opto/library_call.cpp#L5611-L5613
> 
> I added the failing flag combination to the existing test which covers this bug.
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: d868876c
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d868876ca10fc3f93a32164c378ecdb6c9488bbf
Stats:     14 lines in 2 files changed: 6 ins; 0 del; 8 mod

8348962: [lworld] compiler/arraycopy/TestObjectArrayClone.java fails with SIGSEGV in PhaseMacroExpand::expand_arraycopy_node

Reviewed-by: thartmann

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

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

From dsimms at openjdk.org  Mon Feb 10 15:58:44 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 10 Feb 2025 15:58:44 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <s3e5F_Fl4G6Y7tu5YHVOuTjF0qgASv5UFEtL3Pc7yNA=.5e5ab5a8-2fd7-48ea-9825-ac5c68f4d3dd@github.com>

Merge jdk-25+6

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

Commit messages:
 - Test in jdk trying to use testlibrary/asm from Hotspot
 - Merge tag 'jdk-25+6' into lworld_merge_jdk_25_6
 - 8336920: ArithmeticException in javax.sound.sampled.AudioInputStream
 - 8347431: Update ObjectMonitor comments
 - 8344049: Shenandoah: Eliminate init-update-refs safepoint
 - 8342550: Log warning for using JDK1.1 compatible time zone IDs for future removal
 - 8347727: Replace SIZE_FORMAT in shared gc
 - 8347424: Fix and rewrite sun/security/x509/DNSName/LeadingPeriod.java test
 - 8345493: JFR: JVM.flush hangs intermittently
 - 8345134: Test sun/security/tools/jarsigner/ConciseJarsigner.java failed: unable to find valid certification path to requested target
 - ... and 132 more: https://git.openjdk.org/valhalla/compare/92472fd8...4bbf9aff

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

Changes: https://git.openjdk.org/valhalla/pull/1357/files
  Stats: 23726 lines in 1181 files changed: 10168 ins; 7456 del; 6102 mod
  Patch: https://git.openjdk.org/valhalla/pull/1357.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1357/head:pull/1357

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

From qamai at openjdk.org  Mon Feb 10 18:35:45 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 10 Feb 2025 18:35:45 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
Message-ID: <TAWoB8EnCCjlDlLNV1ivE0WXirQSwdB9xEqRqB-9he8=.9e1301da-98f7-4999-b1e3-19cc704576c5@github.com>

Hi,

The assert fires because in this place:

    if (is_osr_parse()) {
      Node* osr_buf = entry_map->in(TypeFunc::Parms+0);
      entry_map->set_req(TypeFunc::Parms+0, top());
      set_map(entry_map);
      load_interpreter_state(osr_buf);
    } else {
      set_map(entry_map);
      do_method_entry();
    }

`load_interpreter_state` assumes that all incoming inline types are non-larval, while in the following place:

    if (t->is_inlinetypeptr()) {
      // Create InlineTypeNode from the oop and replace the parameter
      bool is_larval = (i == 0) && method()->is_object_constructor() && !method()->holder()->is_java_lang_Object();
      Node* vt = InlineTypeNode::make_from_oop(this, parm, t->inline_klass(), !t->maybe_null(), is_larval);
      replace_in_map(parm, vt);
    }

`is_larval == true` because we are osr-compiling the constructor of a value class. As a result, we pass a non-larval object into `InlineTypeNode::make_from_oop` and want to make it larval, triggering the assert.

Thinking more deeply into this, I think there is no way we can know the larval-ness of an incoming object in an osr-compilation unless `ciTypeFlow` does so. For example, consider this bytecode sequence:

    ValueObject x = new ValueObject;
    for {
    }
    x.<init>();

Then, when we osr-compile the method from the loop, `x` will be a larval object and it can be at any place on the JVM stack or in the local slots.

As a result, I propose optimistically assuming all osr parameters be non-larval, then we can change them to larval when encountering a constructor invocation or a field store instruction. The verifier should ensure that we cannot do anything else on a larval object as well as do these actions on a non-larval object, so we should recognize the correct state of the value object if any operation is performed on them. Otherwise, they should be dead and not apear here.

Please take a look and give your advices, thanks a lot.

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

Commit messages:
 - Fix osr inline type parameter

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

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

From qamai at openjdk.org  Mon Feb 10 18:40:54 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 10 Feb 2025 18:40:54 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v2]
In-Reply-To: <TAWoB8EnCCjlDlLNV1ivE0WXirQSwdB9xEqRqB-9he8=.9e1301da-98f7-4999-b1e3-19cc704576c5@github.com>
References: <TAWoB8EnCCjlDlLNV1ivE0WXirQSwdB9xEqRqB-9he8=.9e1301da-98f7-4999-b1e3-19cc704576c5@github.com>
Message-ID: <c284UPL28XQjP8e6Xxj3vNpvBtjuBeCcfb6vDZPtPN0=.cf8792c4-042a-4fa1-8d5f-0e3f58b0a78e@github.com>

> Hi,
> 
> The assert fires because in this place:
> 
>     if (is_osr_parse()) {
>       Node* osr_buf = entry_map->in(TypeFunc::Parms+0);
>       entry_map->set_req(TypeFunc::Parms+0, top());
>       set_map(entry_map);
>       load_interpreter_state(osr_buf);
>     } else {
>       set_map(entry_map);
>       do_method_entry();
>     }
> 
> `load_interpreter_state` assumes that all incoming inline types are non-larval, while in the following place:
> 
>     if (t->is_inlinetypeptr()) {
>       // Create InlineTypeNode from the oop and replace the parameter
>       bool is_larval = (i == 0) && method()->is_object_constructor() && !method()->holder()->is_java_lang_Object();
>       Node* vt = InlineTypeNode::make_from_oop(this, parm, t->inline_klass(), !t->maybe_null(), is_larval);
>       replace_in_map(parm, vt);
>     }
> 
> `is_larval == true` because we are osr-compiling the constructor of a value class. As a result, we pass a non-larval object into `InlineTypeNode::make_from_oop` and want to make it larval, triggering the assert.
> 
> Thinking more deeply into this, I think there is no way we can know the larval-ness of an incoming object in an osr-compilation unless `ciTypeFlow` does so. For example, consider this bytecode sequence:
> 
>     ValueObject x = new ValueObject;
>     for {
>     }
>     x.<init>();
> 
> Then, when we osr-compile the method from the loop, `x` will be a larval object and it can be at any place on the JVM stack or in the local slots.
> 
> As a result, I propose optimistically assuming all osr parameters be non-larval, then we can change them to larval when encountering a constructor invocation or a field store instruction. The verifier should ensure that we cannot do anything else on a larval object as well as do these actions on a non-larval object, so we should recognize the correct state of the value object if any operation is performed on them. Otherwise, they should be dead and not apear here.
> 
> Please take a look and give your advices, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1358/files
  - new: https://git.openjdk.org/valhalla/pull/1358/files/7b69cccd..d4b28aae

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

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

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

From liach at openjdk.org  Mon Feb 10 20:32:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Feb 2025 20:32:34 GMT
Subject: [lworld] RFR: 8349725: [lworld]
 jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm
Message-ID: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>

Migrate ObjectMehodsViaCondy to use ClassFile API to generate the class that calls condy.

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

Commit messages:
 - 8349725: [lworld] jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm

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

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

From dsimms at openjdk.org  Tue Feb 11 07:35:27 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 11 Feb 2025 07:35:27 GMT
Subject: [lworld] RFR: 8349725: [lworld]
 jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm
In-Reply-To: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
References: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
Message-ID: <K1S3WAmF8EHz_x4TWeQyjNXEx-hBSfJ0n1E1wRveOME=.57a47651-03cc-46b5-89e4-e57c7cfe6aff@github.com>

On Mon, 10 Feb 2025 20:27:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrate ObjectMehodsViaCondy to use ClassFile API to generate the class that calls condy.

Marked as reviewed by dsimms (Committer).

NIce, thanks for the fix. Please undo the problem listing before integrating, cheers (https://github.com/openjdk/valhalla/pull/1357/commits/4bbf9aff9ae29a944dd17b3698d221b0be44d83f)

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

PR Review: https://git.openjdk.org/valhalla/pull/1359#pullrequestreview-2607899629
PR Comment: https://git.openjdk.org/valhalla/pull/1359#issuecomment-2650019779

From dsimms at openjdk.org  Tue Feb 11 07:37:30 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 11 Feb 2025 07:37:30 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <s3e5F_Fl4G6Y7tu5YHVOuTjF0qgASv5UFEtL3Pc7yNA=.5e5ab5a8-2fd7-48ea-9825-ac5c68f4d3dd@github.com>
References: <s3e5F_Fl4G6Y7tu5YHVOuTjF0qgASv5UFEtL3Pc7yNA=.5e5ab5a8-2fd7-48ea-9825-ac5c68f4d3dd@github.com>
Message-ID: <YwBlXYGYk3yas1s8nbmM4y5JHnN1DfAZ1JQZ-C1wg4s=.eadd2b74-4769-4385-8b8a-5e9390536d7d@github.com>

On Mon, 10 Feb 2025 15:52:07 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+6

This pull request has now been integrated.

Changeset: f1de470b
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f1de470be357d1b31b258147a111e8683e3bc7b9
Stats:     23726 lines in 1181 files changed: 10168 ins; 7456 del; 6102 mod

Merge jdk

Merge jdk-25+6

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

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

From dsimms at openjdk.org  Tue Feb 11 14:31:36 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 11 Feb 2025 14:31:36 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <seN9LRndamibcznFDYW52MjA2aRlHwxsbdn24TBmNFI=.c95c10e9-9374-46d6-b4c0-4e8f0bcd94de@github.com>

Merge jdk-25+7

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

Commit messages:
 - Logical merge fixes
 - Merge tag 'jdk-25+7' into lworld_merge_jdk_25_7
 - 8348102: java/net/httpclient/HttpClientSNITest.java fails intermittently
 - 8348241: ZGC: Unnecessarily reinitialize ZFragmentationLimit's default value
 - 8348108: Race condition in AggregatePublisher.AggregateSubscription
 - 8348169: Destruct values on free in Treap
 - 8348195: More u2 conversion warnings after JDK-8347147
 - 8346388: Cannot use DllMain in libawt for static builds
 - 8347563: C2: clean up ModRefBarrierSetC2
 - 8337458: Remove debugging code print_cpool_bytes
 - ... and 75 more: https://git.openjdk.org/valhalla/compare/f1de470b...4b717316

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

Changes: https://git.openjdk.org/valhalla/pull/1360/files
  Stats: 16331 lines in 2000 files changed: 7350 ins; 4672 del; 4309 mod
  Patch: https://git.openjdk.org/valhalla/pull/1360.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1360/head:pull/1360

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

From dsimms at openjdk.org  Tue Feb 11 14:31:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 11 Feb 2025 14:31:37 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <seN9LRndamibcznFDYW52MjA2aRlHwxsbdn24TBmNFI=.c95c10e9-9374-46d6-b4c0-4e8f0bcd94de@github.com>
References: <seN9LRndamibcznFDYW52MjA2aRlHwxsbdn24TBmNFI=.c95c10e9-9374-46d6-b4c0-4e8f0bcd94de@github.com>
Message-ID: <REerpOB40vtOphHAHrg6v9AG4jBrLR0ntjSYGVnPF3A=.93ef644d-8cbd-48fa-93bd-564a6f696858@github.com>

On Tue, 11 Feb 2025 14:24:09 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+7

This pull request has now been integrated.

Changeset: 12e5ddae
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/12e5ddae614f88ad9262cd73f06003b569495cc4
Stats:     16331 lines in 2000 files changed: 7350 ins; 4672 del; 4309 mod

Merge jdk

Merge jdk-25+7

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

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

From qamai at openjdk.org  Tue Feb 11 15:51:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 11 Feb 2025 15:51:04 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v3]
In-Reply-To: <TAWoB8EnCCjlDlLNV1ivE0WXirQSwdB9xEqRqB-9he8=.9e1301da-98f7-4999-b1e3-19cc704576c5@github.com>
References: <TAWoB8EnCCjlDlLNV1ivE0WXirQSwdB9xEqRqB-9he8=.9e1301da-98f7-4999-b1e3-19cc704576c5@github.com>
Message-ID: <TrfeanD8BAdKW-UYuDZQV91TNnHNdmAn_zqMNvo0UrE=.8d67b840-868e-460c-8337-2364fe07e06d@github.com>

> Hi,
> 
> The assert fires because in this place:
> 
>     if (is_osr_parse()) {
>       Node* osr_buf = entry_map->in(TypeFunc::Parms+0);
>       entry_map->set_req(TypeFunc::Parms+0, top());
>       set_map(entry_map);
>       load_interpreter_state(osr_buf);
>     } else {
>       set_map(entry_map);
>       do_method_entry();
>     }
> 
> `load_interpreter_state` assumes that all incoming inline types are non-larval, while in the following place:
> 
>     if (t->is_inlinetypeptr()) {
>       // Create InlineTypeNode from the oop and replace the parameter
>       bool is_larval = (i == 0) && method()->is_object_constructor() && !method()->holder()->is_java_lang_Object();
>       Node* vt = InlineTypeNode::make_from_oop(this, parm, t->inline_klass(), !t->maybe_null(), is_larval);
>       replace_in_map(parm, vt);
>     }
> 
> `is_larval == true` because we are osr-compiling the constructor of a value class. As a result, we pass a non-larval object into `InlineTypeNode::make_from_oop` and want to make it larval, triggering the assert.
> 
> Thinking more deeply into this, I think there is no way we can know the larval-ness of an incoming object in an osr-compilation unless `ciTypeFlow` does so. For example, consider this bytecode sequence:
> 
>     ValueObject x = new ValueObject;
>     for {
>     }
>     x.<init>();
> 
> Then, when we osr-compile the method from the loop, `x` will be a larval object and it can be at any place on the JVM stack or in the local slots.
> 
> As a result, I propose optimistically assuming all osr parameters be non-larval, then we can change them to larval when encountering a constructor invocation or a field store instruction. The verifier should ensure that we cannot do anything else on a larval object as well as do these actions on a non-larval object, so we should recognize the correct state of the value object if any operation is performed on them. Otherwise, they should be dead and not apear here.
> 
> Please take a look and give your advices, thanks a lot.

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

 - Merge branch 'lworld' into osrinlinetype
 - typo
 - Fix osr inline type parameter

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1358/files
  - new: https://git.openjdk.org/valhalla/pull/1358/files/d4b28aae..49991764

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

  Stats: 40002 lines in 2969 files changed: 17505 ins; 12109 del; 10388 mod
  Patch: https://git.openjdk.org/valhalla/pull/1358.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1358/head:pull/1358

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

From liach at openjdk.org  Tue Feb 11 16:32:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 16:32:52 GMT
Subject: [lworld] RFR: 8349725: [lworld]
 jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm
 [v2]
In-Reply-To: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
References: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
Message-ID: <4mqaRSmDV4lrZaZwsRmoFo1aDnCcvCunh3hCT4gUNJ4=.78e01686-4ce6-4498-89fd-d3a6922e29fd@github.com>

> Migrate ObjectMehodsViaCondy to use ClassFile API to generate the class that calls condy.

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

 - Remove problemlist entry
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/test/obj-mth-via-condy
 - 8349725: [lworld] jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm

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

Changes: https://git.openjdk.org/valhalla/pull/1359/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1359&range=01
  Stats: 128 lines in 2 files changed: 39 ins; 78 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1359.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1359/head:pull/1359

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

From liach at openjdk.org  Tue Feb 11 16:32:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 16:32:52 GMT
Subject: [lworld] RFR: 8349725: [lworld]
 jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm
In-Reply-To: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
References: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
Message-ID: <FtMi0GtnmbYLT4OLDXTyaa5LKGelrg1XUtr4zqphIV0=.8625fed7-107b-4bf0-b39d-05dda1dd05a8@github.com>

On Mon, 10 Feb 2025 20:27:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrate ObjectMehodsViaCondy to use ClassFile API to generate the class that calls condy.

I have merged mainline to fix merge conflicts and have removed the problemlist entry, and tested locally. Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1359#issuecomment-2651340371

From duke at openjdk.org  Tue Feb 11 16:32:53 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Feb 2025 16:32:53 GMT
Subject: [lworld] RFR: 8349725: [lworld]
 jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm
In-Reply-To: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
References: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
Message-ID: <c6GvqkA5J-OnG2DPKSrFwdP4kPrk0SZsoqFT98uLawo=.a8601a82-524d-4c80-9f80-8870d4130af9@github.com>

On Mon, 10 Feb 2025 20:27:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrate ObjectMehodsViaCondy to use ClassFile API to generate the class that calls condy.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1359#issuecomment-2651342123

From fparain at openjdk.org  Tue Feb 11 16:35:34 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Feb 2025 16:35:34 GMT
Subject: [lworld] Integrated: [lworld[ Add flagless VM requirement to tests
 needing CDS off.
Message-ID: <OvGGGE_lvvjB6XI9pKk55in2qcgXUk6ObmJRuULD8Og=.a7bebf5d-9389-4e30-856b-30c7dd875dd7@github.com>

Add  "@requires vm.flagless" to tests that need to disable CDS.

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

Commit messages:
 - Add flagless VM requirement to tests needing CDS off.

Changes: https://git.openjdk.org/valhalla/pull/1361/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1361&range=00
  Stats: 21 lines in 6 files changed: 21 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1361.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1361/head:pull/1361

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

From fparain at openjdk.org  Tue Feb 11 16:35:34 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 11 Feb 2025 16:35:34 GMT
Subject: [lworld] Integrated: [lworld[ Add flagless VM requirement to tests
 needing CDS off.
In-Reply-To: <OvGGGE_lvvjB6XI9pKk55in2qcgXUk6ObmJRuULD8Og=.a7bebf5d-9389-4e30-856b-30c7dd875dd7@github.com>
References: <OvGGGE_lvvjB6XI9pKk55in2qcgXUk6ObmJRuULD8Og=.a7bebf5d-9389-4e30-856b-30c7dd875dd7@github.com>
Message-ID: <Fkjh5hk-Cv-iIDM3hoGUmKIxMj7o2EhRE_5Y0Fuymzo=.e817a421-6810-4a5c-b8bc-2dfd8f7895f8@github.com>

On Tue, 11 Feb 2025 16:29:31 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Add  "@requires vm.flagless" to tests that need to disable CDS.

This pull request has now been integrated.

Changeset: 0b99768e
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0b99768e515935f0a0b73cf7c6881a52ca36aed4
Stats:     21 lines in 6 files changed: 21 ins; 0 del; 0 mod

[lworld[ Add flagless VM requirement to tests needing CDS off.

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

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

From liach at openjdk.org  Tue Feb 11 16:45:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 11 Feb 2025 16:45:27 GMT
Subject: [lworld] Integrated: 8349725: [lworld]
 jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm
In-Reply-To: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
References: <kIctuW9RIQN_n2DLKbkVvGcoFdvnIycvS8VE8AEJoPA=.4e2d674e-60dd-4057-955f-b6dcb273728f@github.com>
Message-ID: <v4zChKsxxwB_8BwrdXY-sK_Lh2HjZd7NWmDZLFa9pJU=.203fa326-1f95-4a1e-89cb-b28ee62368eb@github.com>

On Mon, 10 Feb 2025 20:27:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Migrate ObjectMehodsViaCondy to use ClassFile API to generate the class that calls condy.

This pull request has now been integrated.

Changeset: e6201caa
Author:    Chen Liang <liach at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e6201caab3893b64ad801d36dfedecee1b57b509
Stats:     128 lines in 2 files changed: 39 ins; 78 del; 11 mod

8349725: [lworld] jdk/valhalla/valuetypes/ObjectMethodsViaCondy.java can't find /testlibrary/asm

Reviewed-by: dsimms

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

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

From dsimms at openjdk.org  Wed Feb 12 09:29:52 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Feb 2025 09:29:52 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <wMvnb4W1l3LBQ09eCiNYsV7SwlBx9sQnqZFXv7mv4Lk=.12b2c568-1be8-4f05-b788-22346a632d29@github.com>

Merge tag 'jdk-25+8' into lworld_merge_jdk_25_8
Added tag jdk-25+8 for changeset d985b31c

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

Commit messages:
 - Merge tag 'jdk-25+8' into lworld_merge_jdk_25_8
 - 8342096: Popup menus that request focus are not shown on Linux with Wayland
 - 8348905: Add support to specify the JDK for compiling Jtreg tests
 - 8347997: assert(false) failed: EA: missing memory path
 - 8348687: [BACKOUT] C2: Non-fluid StringBuilder pattern bails out in OptoStringConcat
 - 8348752: Enable -XX:+AOTClassLinking by default when -XX:AOTMode is specified
 - 8348898: Remove unused OctalDigits to clean up code
 - 8319850: PrintInlining should print which methods are late inlines
 - 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale
 - 8333386: TestAbortOnVMOperationTimeout test fails for client VM
 - ... and 92 more: https://git.openjdk.org/valhalla/compare/12e5ddae...353572d7

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

Changes: https://git.openjdk.org/valhalla/pull/1362/files
  Stats: 13416 lines in 989 files changed: 7883 ins; 1934 del; 3599 mod
  Patch: https://git.openjdk.org/valhalla/pull/1362.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1362/head:pull/1362

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

From dsimms at openjdk.org  Wed Feb 12 12:41:26 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Feb 2025 12:41:26 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <wMvnb4W1l3LBQ09eCiNYsV7SwlBx9sQnqZFXv7mv4Lk=.12b2c568-1be8-4f05-b788-22346a632d29@github.com>
References: <wMvnb4W1l3LBQ09eCiNYsV7SwlBx9sQnqZFXv7mv4Lk=.12b2c568-1be8-4f05-b788-22346a632d29@github.com>
Message-ID: <X0SXIjfakVV9wyZymO8tz0DSZ8TU9HS_nzb8N_SUWXg=.eb8b2486-945e-405b-ab9b-459d16c28b80@github.com>

On Wed, 12 Feb 2025 09:23:17 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+8' into lworld_merge_jdk_25_8
> Added tag jdk-25+8 for changeset d985b31c

This pull request has now been integrated.

Changeset: d94c5895
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d94c58952d2f9a0193af4cd9df66868fd0a6e3db
Stats:     13416 lines in 989 files changed: 7883 ins; 1934 del; 3599 mod

Merge jdk

Merge jdk-25+8

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

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

From qamai at openjdk.org  Wed Feb 12 16:36:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 12 Feb 2025 16:36:06 GMT
Subject: [lworld] RFR: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
Message-ID: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>

Hi,

The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:

    // Oops, need to call into the VM to resolve the klasses at runtime.
    // Note:  This call must not deoptimize, since it is not a real at this bci!
    kill_dead_locals();

    make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
                      OptoRuntime::rethrow_Type(),
                      OptoRuntime::rethrow_stub(),
                      nullptr, nullptr,
                      ex_node);

As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.

The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.

Please share your thoughts, thanks a lot.

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

Commit messages:
 - Remove assert

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

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

From liach at openjdk.org  Thu Feb 13 00:14:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Feb 2025 00:14:44 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform heap
 allocations
Message-ID: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>

Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.

Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.

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

Commit messages:
 - 8348606: [lworld] Substitutability test may perform heap allocations

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

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

From liach at openjdk.org  Thu Feb 13 01:17:07 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Feb 2025 01:17:07 GMT
Subject: [lworld] RFR: 8348606: [lworld] Substitutability test may perform
 heap allocations [v2]
In-Reply-To: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
References: <oYHpLdEio63u889P4XlXEZKpnfWjw5DwBZa7gSek3Yw=.e9106456-d6c1-4928-ad8e-9d4a89100561@github.com>
Message-ID: <Il9Yb3IDQPRrBpnyR-sF4FCXei7SBxfwP0DQL3ofmaY=.ce9727fb-cfc6-4d91-929e-6534cba69572@github.com>

> Update substitutability test to use MethodHandles that access independent primitive/pointer instead heap reallocated copies of inlined values with an object header. Need long-term solution for user MethodHandle that accesses nested values in the future; hope the intrinsics can help in the future.
> 
> Testing: test/jdk/valhalla and test/hotspot/jtreg/*/valhalla, tier 1-3 tests running.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix redundant debug and failing IO test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1364/files
  - new: https://git.openjdk.org/valhalla/pull/1364/files/63c46847..4d6a7d5c

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

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

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

From liach at openjdk.org  Thu Feb 13 01:17:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Feb 2025 01:17:12 GMT
Subject: [lworld] RFR: 8327214: [lworld] Valhalla compiler testing move to
 classfile API
Message-ID: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>

Testing: 3 updated tests, tier 1-3 in progress

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

Commit messages:
 - Broken
 - Remove obsolete lib imports
 - 8327214: [lworld] Valhalla compiler testing move to classfile API

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

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

From dsimms at openjdk.org  Thu Feb 13 07:37:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 13 Feb 2025 07:37:37 GMT
Subject: [lworld] RFR: 8327214: [lworld] Valhalla compiler testing move to
 classfile API
In-Reply-To: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>
References: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>
Message-ID: <LZmEHbR53VtKgGyPaeUX8S3f99D6WWUq7zv2KjzmC3o=.65b81a92-7ac3-4f67-af5e-1e3424c13cbf@github.com>

On Thu, 13 Feb 2025 01:12:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Testing: 3 updated tests, tier 1-3 in progress

NIce, thanks for the clean up !

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1365#pullrequestreview-2614093181

From jbhateja at openjdk.org  Thu Feb 13 11:28:29 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 13 Feb 2025 11:28:29 GMT
Subject: [lworld] RFR: 8335256: [lworld]
 compiler/valhalla/inlinetypes/TestValueConstruction.java fails intermittently
 [v3]
In-Reply-To: <TrfeanD8BAdKW-UYuDZQV91TNnHNdmAn_zqMNvo0UrE=.8d67b840-868e-460c-8337-2364fe07e06d@github.com>
References: <TAWoB8EnCCjlDlLNV1ivE0WXirQSwdB9xEqRqB-9he8=.9e1301da-98f7-4999-b1e3-19cc704576c5@github.com>
 <TrfeanD8BAdKW-UYuDZQV91TNnHNdmAn_zqMNvo0UrE=.8d67b840-868e-460c-8337-2364fe07e06d@github.com>
Message-ID: <jq2C4-gLxRtdCX4by-YM9liXQRvoDpA2_Lc_MzBW3Zg=.d9437e9b-2bd7-4694-b7f0-93f6fa4fbeba@github.com>

On Tue, 11 Feb 2025 15:51:04 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> The assert fires because in this place:
>> 
>>     if (is_osr_parse()) {
>>       Node* osr_buf = entry_map->in(TypeFunc::Parms+0);
>>       entry_map->set_req(TypeFunc::Parms+0, top());
>>       set_map(entry_map);
>>       load_interpreter_state(osr_buf);
>>     } else {
>>       set_map(entry_map);
>>       do_method_entry();
>>     }
>> 
>> `load_interpreter_state` assumes that all incoming inline types are non-larval, while in the following place:
>> 
>>     if (t->is_inlinetypeptr()) {
>>       // Create InlineTypeNode from the oop and replace the parameter
>>       bool is_larval = (i == 0) && method()->is_object_constructor() && !method()->holder()->is_java_lang_Object();
>>       Node* vt = InlineTypeNode::make_from_oop(this, parm, t->inline_klass(), !t->maybe_null(), is_larval);
>>       replace_in_map(parm, vt);
>>     }
>> 
>> `is_larval == true` because we are osr-compiling the constructor of a value class. As a result, we pass a non-larval object into `InlineTypeNode::make_from_oop` and want to make it larval, triggering the assert.
>> 
>> Thinking more deeply into this, I think there is no way we can know the larval-ness of an incoming object in an osr-compilation unless `ciTypeFlow` does so. For example, consider this bytecode sequence:
>> 
>>     ValueObject x = new ValueObject;
>>     for {
>>     }
>>     x.<init>();
>> 
>> Then, when we osr-compile the method from the loop, `x` will be a larval object and it can be at any place on the JVM stack or in the local slots.
>> 
>> As a result, I propose optimistically assuming all osr parameters be non-larval, then we can change them to larval when encountering a constructor invocation or a field store instruction. The verifier should ensure that we cannot do anything else on a larval object as well as do these actions on a non-larval object, so we should recognize the correct state of the value object if any operation is performed on them. Otherwise, they should be dead and not apear here.
>> 
>> Please take a look and give your advices, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'lworld' into osrinlinetype
>  - typo
>  - Fix osr inline type parameter

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

> 586:     // optimistically assume all parameters are non-larval. Then, a parameter is changed to larval
> 587:     // if we encounter a store into one of its fields, or if we encounter a constructor invocation
> 588:     // with it being the first argument

The implicit larval transition has a limited life span, it begins from the new allocation and ends just before exiting constructor.

[https://github.com/openjdk/valhalla/blob/d94c58952d2f9a0193af4cd9df66868fd0a6e3db/src/hotspot/share/opto/doCall.cpp#L830](https://github.com/openjdk/valhalla/blob/d94c58952d2f9a0193af4cd9df66868fd0a6e3db/src/hotspot/share/opto/doCall.cpp#L830
)

The only possibility to create a larval value that gets passed on to OSR buffer is by explicitly marking it as larval using Unsafe.makePrivateBuffer API before the loop.

May I request you to kindly add a new or identify an existing test case for this scenario

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1358#discussion_r1954316155

From duke at openjdk.org  Thu Feb 13 14:25:34 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Feb 2025 14:25:34 GMT
Subject: [lworld] RFR: 8327214: [lworld] Valhalla compiler testing move to
 classfile API
In-Reply-To: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>
References: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>
Message-ID: <vHrZPL9uucKdUQNfBRK7AlqtOf-5MN4SAB2Otsyq8-s=.6fb80a31-14fe-4410-9eae-f50e92eb9ca5@github.com>

On Thu, 13 Feb 2025 01:12:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Testing: 3 updated tests, tier 1-3 in progress

@liach 
Your change (at version 2e8ee14e424e4631870ac7d66de701ac8327f947) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1365#issuecomment-2656748604

From liach at openjdk.org  Thu Feb 13 16:37:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 13 Feb 2025 16:37:27 GMT
Subject: [lworld] Integrated: 8327214: [lworld] Valhalla compiler testing move
 to classfile API
In-Reply-To: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>
References: <tdJvFyoYzM8pHp5Kmq5MYS9QykGpIZZMPMfM0xtMo9Y=.d7be3ce7-aace-4a8d-a6d1-e3e860cc5534@github.com>
Message-ID: <_-KtLmDPrmvodHX8QVlh3UU9Jz3SCH01aM5Zrn0_cjQ=.be824955-66d9-4db6-a657-40e7337e7b2d@github.com>

On Thu, 13 Feb 2025 01:12:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> Testing: 3 updated tests, tier 1-3 in progress

This pull request has now been integrated.

Changeset: 991ec927
Author:    Chen Liang <liach at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/991ec927a2a111e5021b12be3413dfc96efbc74a
Stats:     6403 lines in 26 files changed: 0 ins; 6378 del; 25 mod

8327214: [lworld] Valhalla compiler testing move to classfile API

Reviewed-by: dsimms

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

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

From chagedorn at openjdk.org  Fri Feb 14 11:30:58 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 14 Feb 2025 11:30:58 GMT
Subject: [lworld] RFR: 8348961: [lworld] C2: Joining "Object:flat_in_array"
 with "Object:exact" does not properly work
Message-ID: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>

This patch fixes the wrong joining operation of two types of the same klass with regard to flat in array. We have the following shape in the test case (how we end up with such a graph can be found as comments in the added tests):
 
![image](https://github.com/user-attachments/assets/3ea680fa-d93c-4994-92b7-dd1c271c0030)

The type of `341 CheckCastPP` is `Object:exact`, so we definitely know that the type is `Object` and nothing else and thus also not flat in array (Object is not a value class). For `339 CheckCastPP`, we know that it is some kind of value class but definitely not `Object` itself - it's just chosen because we do not know more about the klass.

Joining these two should result in an empty set since they are unrelated. However, the type system is not handling it correctly and we conclude that one is a sub type of the other and we later fail with an assert.

### Reworking flat in array Meet Operation
I revisited the way we meet two instruction types with regard to the flat in array property. The code was a little hard to understand, so I added a summary how the flat in array property should be treated when doing a meet or join:

https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4604-L4630

I added a new case for joining the same klasses (see `(FiA-J-Same)`) which was missing before and resulting in an assertion failure.

### Adding dual of `_flat_in_array`?
I kept asking myself if we should introduce a proper lattice with a dual for flat in array:

https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4593-L4597

While it's probably the proper way to address this long term, I think we should investigate this separately as we would need to touch quite some code. I therefore left the idea as a comment and went with a point fix on top - keeping the way we currently handle `_flat_in_array` in meet operations without a proper dual.

### Including Changes
- More detailed summary how the meet/join of `flat_in_array` is done .
- Refactored the code in `meet_instptr()` to make it more readable/clear how the `flat_in_array` property is treated.
- For better debugging:
  - Dumping `(flat in array)` also for `TypeInstKlassPtr` and not only for `TypeInstPtr`.
  - Adapting "Show types" IGV filter to also show the flat in array property (see image of graph above).

### Additionally Required Fixes
- (i) With the type system fix above, we sanely remove the conflicting data nodes but we fail to remove the corresponding control path as well. The reason is that `TypeInstKlassPtr::not_flat_in_array()` does not take exactness information into account:
https://github.com/openjdk/valhalla/blob/991ec927a2a111e5021b12be3413dfc96efbc74a/src/hotspot/share/opto/type.hpp#L1787

   `_klass->can_be_inline_klass()` will treat the klass as inexact (note that `TypeInstPtr::not_flat_in_array()` takes exactness into account). As a result, `TypeInstKlassPtr::not_flat_in_array()` called on `Object:exact` returns false even though it is statically known that this should be true (i.e. not flat in array). This is fixed by passing `klass_is_exact()` to `_klass->can_be_inline_klass()`:
https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.hpp#L1793-L1795

- (ii) Applying (i) resulted in some assertion failures because we now wrongly treat a sub type check of the form `X <: Object` as false even though this should be true for any class `X`. We check in `SubTypeCheckNode::Value()` -> `SybTypeCheckNode::sub()` the following:
https://github.com/openjdk/valhalla/blob/991ec927a2a111e5021b12be3413dfc96efbc74a/src/hotspot/share/opto/subtypenode.cpp#L53-L54

  In a failing case, `subk` is a value class that is flat in array while `superk` is `Object:exact`. Due to now passing the exactness information in `TypeInstKlassPtr::not_flat_in_array()` with (i), this returns true. We wrongly assume the classes are unrelated  due to conflicting `flat_in_array` information and thus the check is wrongly treated as false. 

  The fix I propose for this is to introduce a special `not_flat_in_array_inexact()` that reflects the old behavior of `not_flat_in_array()` to ignore exactness information.
 
I added some comments in the PR to help understanding the change better.

Thanks,
Christian

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

Commit messages:
 - update comment
 - 8348961: [lworld] C2: Joining "Object:flat_in_array" with "Object:exact" does not properly work

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

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

From chagedorn at openjdk.org  Fri Feb 14 11:30:59 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 14 Feb 2025 11:30:59 GMT
Subject: [lworld] RFR: 8348961: [lworld] C2: Joining "Object:flat_in_array"
 with "Object:exact" does not properly work
In-Reply-To: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
References: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
Message-ID: <k_h-P1n0V4B9RnbSmORPtEoHNqSANr5NbGeINz4LPXU=.4e50f19b-d6a9-4dd2-8f17-5b9ab45dcd13@github.com>

On Fri, 14 Feb 2025 11:18:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes the wrong joining operation of two types of the same klass with regard to flat in array. We have the following shape in the test case (how we end up with such a graph can be found as comments in the added tests):
>  
> ![image](https://github.com/user-attachments/assets/3ea680fa-d93c-4994-92b7-dd1c271c0030)
> 
> The type of `341 CheckCastPP` is `Object:exact`, so we definitely know that the type is `Object` and nothing else and thus also not flat in array (Object is not a value class). For `339 CheckCastPP`, we know that it is some kind of value class but definitely not `Object` itself - it's just chosen because we do not know more about the klass.
> 
> Joining these two should result in an empty set since they are unrelated. However, the type system is not handling it correctly and we conclude that one is a sub type of the other and we later fail with an assert.
> 
> ### Reworking flat in array Meet Operation
> I revisited the way we meet two instruction types with regard to the flat in array property. The code was a little hard to understand, so I added a summary how the flat in array property should be treated when doing a meet or join:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4604-L4630
> 
> I added a new case for joining the same klasses (see `(FiA-J-Same)`) which was missing before and resulting in an assertion failure.
> 
> ### Adding dual of `_flat_in_array`?
> I kept asking myself if we should introduce a proper lattice with a dual for flat in array:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4593-L4597
> 
> While it's probably the proper way to address this long term, I think we should investigate this separately as we would need to touch quite some code. I therefore left the idea as a comment and went with a point fix on top - keeping the way we currently handle `_flat_in_array` in meet operations without a proper dual.
> 
> ### Including Changes
> - More detailed summary how the meet/join of `flat_in_array` is done .
> - Refactored the code in `meet_instptr()` to make it more readable/clear how the `flat_in_array` property is treated.
> - For better debugging:
>   - Dumping `(flat in array)` also for `TypeInstKlassPtr` and not only for `TypeInstPtr`.
>   - Adapting "Show types" IGV filter to also show the flat in array property (see image of graph above).
> 
> ### Additionally Required Fixes
> - (i) With the type system fix above, we...

src/hotspot/share/opto/subtypenode.cpp line 55:

> 53:   // Handle inline type arrays
> 54:   if (subk->flat_in_array() && superk->not_flat_in_array_inexact()) {
> 55:     // The subtype is in flat arrays and the supertype is not in flat arrays and no subklass can be. Must be unrelated.

Case `(ii)` from PR.

src/hotspot/share/opto/subtypenode.cpp line 71:

> 69: 
> 70:   if (subk != nullptr) {
> 71:     switch (Compile::current()->static_subtype_check(superk, subk, false)) {

Should always be true and thus removed.

src/hotspot/share/opto/type.cpp line 1028:

> 1026:   //    which corresponds to
> 1027:   //       !(t meet this)  meet !this ==
> 1028:   //       (!t join !this) meet !this == !this

While working on the fix I ran into the meet not symmetric assert several times and had some difficulties to figure out what type corresponds to what. I improved the comments here for better aid.

src/hotspot/share/opto/type.cpp line 4653:

> 4651:     subtype_exact = below_centerline(ptr) ? (this_xk && other_xk) : (this_xk || other_xk);
> 4652:     if (above_centerline(ptr)) {
> 4653:       // Case (FiA-J-Same)

Eagerly checking this case and setting `is_empty` to make sure we don't override the result later again. Same for `(FiA-J-Sub)`.

src/hotspot/share/opto/type.cpp line 4682:

> 4680: 
> 4681: 
> 4682:   if (subtype && !is_empty) {

If we already figured out that we have an empty set as result, we can just skip this code here.

src/hotspot/share/opto/type.cpp line 4717:

> 4715:     res_klass = this_type->klass();
> 4716:     res_xk = this_xk;
> 4717:     res_flat_in_array = flat_in_array;

With the refactoring above, we can now just set our figured out property `flat_in_array` here directly.

src/hotspot/share/opto/type.hpp line 1805:

> 1803:   //
> 1804:   // Thus, this version checks if we know that the klass is not flat in array even if it's not exact.
> 1805:   virtual bool not_flat_in_array_inexact() const {

For Case `(ii)`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955984673
PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955985360
PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955986907
PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955990296
PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955994621
PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955991732
PR Review Comment: https://git.openjdk.org/valhalla/pull/1367#discussion_r1955992783

From rriggs at openjdk.org  Fri Feb 14 14:44:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Feb 2025 14:44:44 GMT
Subject: [lworld] RFR: 8350099: [lworld] ProblemList
 java/lang/Thread/virtual/stress/Skynet.java#default
Message-ID: <Qt326pHmKbee9edTG3dy-kiYZ9MmCHII0fdcYRUFc50=.e23f7775-f1c6-4945-85d9-90e419289d31@github.com>

Add to test/jdk/ProblemList.txt:
   java/lang/Thread/virtual/stress/Skynet.java#default

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

Commit messages:
 - 8350099: [lworld] ProblemList java/lang/Thread/virtual/stress/Skynet.java#default

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

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

From rriggs at openjdk.org  Fri Feb 14 15:51:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Feb 2025 15:51:55 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1
Message-ID: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>

Jtreg is updated to 7.5.1
7.5.1 drops support for LIBRARY.properties.
Some tests have added @enableProperties to pass.

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

Commit messages:
 - Merge branch 'langtools-needs-preview' into jtreg7-5-1-trial
 - Insert @enablePreview for tests that expect accessFlags to be have IDENTITY, etc.
 - Remove LIBRARY.properties unused by jtreg 7.5.1
 - Vahalla trial using jtreg 7.5.1+1.

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

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

From rriggs at openjdk.org  Fri Feb 14 15:51:55 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Feb 2025 15:51:55 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1
In-Reply-To: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
Message-ID: <AAFOk_DrLB4b1K2QEp3l6ulbkK9_P_NYF1g0gKEOKz8=.47fafb1a-e62e-4154-ac7c-9e4e532f62a7@github.com>

On Fri, 14 Feb 2025 15:43:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Jtreg is updated to 7.5.1
> 7.5.1 drops support for LIBRARY.properties.
> Some tests have added @enableProperties to pass.

@sormuras Please review for consistency with JTreg 7.5.1

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

PR Comment: https://git.openjdk.org/valhalla/pull/1369#issuecomment-2659677403

From cstein at openjdk.org  Fri Feb 14 17:43:26 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 14 Feb 2025 17:43:26 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1
In-Reply-To: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
Message-ID: <8KCMtytXvuvcTsGQn0vqGbmZh143WB8gDBonvEOVKlI=.82558e26-146e-4e13-a303-75033850f47e@github.com>

On Fri, 14 Feb 2025 15:43:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Jtreg is updated to 7.5.1
> 7.5.1 drops support for LIBRARY.properties.
> Some tests have added @enableProperties to pass.

test/docs/TEST.ROOT line 1:

> 1: #

Interesting, that file `test/docs/TEST.ROOT` was not yet touched by https://github.com/openjdk/jdk/pull/20766 - will update it to use 7.5.1 as well.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1369#discussion_r1956512761

From cstein at openjdk.org  Fri Feb 14 17:48:20 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 14 Feb 2025 17:48:20 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1
In-Reply-To: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
Message-ID: <t2wk6aYH72xHur7z4CCkE6OUmdVKsVNjnqeWTdoI53k=.5a50bb0f-f26f-4d93-8c4b-2f26958cf4dd@github.com>

On Fri, 14 Feb 2025 15:43:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Jtreg is updated to 7.5.1
> 7.5.1 drops support for LIBRARY.properties.
> Some tests have added @enableProperties to pass.

Update to use jtreg `7.5.1` looks good, even found a `TEST.ROOT` at https://github.com/openjdk/jdk/pull/20766 that lacks an update.

Deletion of `LIBRARY.properties` files looks good.

Addition of `@enablePreview` looks also good; might be no longer required after merging with `openjdk/jdk` mainline, as the Classfile API is no in preview mode?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1369#issuecomment-2659926139

From rriggs at openjdk.org  Fri Feb 14 20:07:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Feb 2025 20:07:25 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1
In-Reply-To: <t2wk6aYH72xHur7z4CCkE6OUmdVKsVNjnqeWTdoI53k=.5a50bb0f-f26f-4d93-8c4b-2f26958cf4dd@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
 <t2wk6aYH72xHur7z4CCkE6OUmdVKsVNjnqeWTdoI53k=.5a50bb0f-f26f-4d93-8c4b-2f26958cf4dd@github.com>
Message-ID: <eqq9nKyCG7qA9Sz5in2DGVu-w6Yc0dtItgmKpv7HG2w=.a259008e-000d-46f1-a310-13e80a3da429@github.com>

On Fri, 14 Feb 2025 17:45:32 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Addition of `@enablePreview` looks also good; might be no longer required after merging with `openjdk/jdk` mainline, as the Classfile API is no in preview mode?

Right, not needed for ClassFile API but the test is written to require the enable-preview interpretation of AccessFlags.
In particular, yielding ACC_IDENTITY instead of ACC_SUPER.  (Same bit, different name and semantics).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1369#issuecomment-2660167659

From liach at openjdk.org  Fri Feb 14 20:45:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 14 Feb 2025 20:45:22 GMT
Subject: [lworld] RFR: 8350099: [lworld] ProblemList
 java/lang/Thread/virtual/stress/Skynet.java#default
In-Reply-To: <Qt326pHmKbee9edTG3dy-kiYZ9MmCHII0fdcYRUFc50=.e23f7775-f1c6-4945-85d9-90e419289d31@github.com>
References: <Qt326pHmKbee9edTG3dy-kiYZ9MmCHII0fdcYRUFc50=.e23f7775-f1c6-4945-85d9-90e419289d31@github.com>
Message-ID: <m_d_4gXNIfSXhOmHLj32thtI7RY6Niu3tFkF1E_jXcA=.2dfa7283-98cc-4eab-937c-c180db8dfe31@github.com>

On Fri, 14 Feb 2025 14:37:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add to test/jdk/ProblemList.txt:
>    java/lang/Thread/virtual/stress/Skynet.java#default

Marked as reviewed by liach (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1368#pullrequestreview-2618762449

From liach at openjdk.org  Sun Feb 16 15:19:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 16 Feb 2025 15:19:26 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v4]
In-Reply-To: <OcGqhM0HrS8vAuoa3hIAkHeTwpYA6Fq8wCm7tMfRwvc=.294a8e59-df3b-4b6e-beca-1a874831681d@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
 <OcGqhM0HrS8vAuoa3hIAkHeTwpYA6Fq8wCm7tMfRwvc=.294a8e59-df3b-4b6e-beca-1a874831681d@github.com>
Message-ID: <Apikz3d0QyrIq7sk40Iund6HbWQEa4dAESFYCRmuw4g=.7c6a9795-5e4c-4678-bff7-23d369a540fa@github.com>

On Tue, 4 Feb 2025 20:59:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
>> Simplified WeakHashMap javadoc updates for IdentityException. 
>> Added note to System.identityHashCode to include value objects.
>> Added to class javadoc for IdentityHashMap for value objects.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand javadoc reference to Reference

Indeed, this API is returning `false` for interfaces and primitive types if preview features are not enabled, which is wrong. Making it simply return `!isIdentity()` may be better and conforms to the javadoc specification here. See https://github.com/openjdk/valhalla/blob/991ec927a2a111e5021b12be3413dfc96efbc74a/src/hotspot/share/prims/jvm.cpp#L1333-L1337

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1327#discussion_r1957349591

From rriggs at openjdk.org  Mon Feb 17 15:12:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Feb 2025 15:12:25 GMT
Subject: [lworld] Integrated: 8350099: [lworld] ProblemList
 java/lang/Thread/virtual/stress/Skynet.java#default
In-Reply-To: <Qt326pHmKbee9edTG3dy-kiYZ9MmCHII0fdcYRUFc50=.e23f7775-f1c6-4945-85d9-90e419289d31@github.com>
References: <Qt326pHmKbee9edTG3dy-kiYZ9MmCHII0fdcYRUFc50=.e23f7775-f1c6-4945-85d9-90e419289d31@github.com>
Message-ID: <KrCNXUkNn86K8Vsnc9MGkUzFBsE2sErxrreQi1ytnL0=.e48fca51-1088-43f3-81ff-beb6d759bec4@github.com>

On Fri, 14 Feb 2025 14:37:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Add to test/jdk/ProblemList.txt:
>    java/lang/Thread/virtual/stress/Skynet.java#default

This pull request has now been integrated.

Changeset: 3311f7e9
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3311f7e95c9d30365babb0329d0d96194376c683
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8350099: [lworld] ProblemList java/lang/Thread/virtual/stress/Skynet.java#default

Reviewed-by: liach

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

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

From thartmann at openjdk.org  Tue Feb 18 09:59:42 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Feb 2025 09:59:42 GMT
Subject: [lworld] RFR: 8348961: [lworld] C2: Joining "Object:flat_in_array"
 with "Object:exact" does not properly work
In-Reply-To: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
References: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
Message-ID: <xcTQmPQbnMhC-pFTXYgX9SkQks1DDH8ao6kgEauIJRY=.ef61e3b0-fd49-4735-9005-b8ca4d5be2c4@github.com>

On Fri, 14 Feb 2025 11:18:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes the wrong joining operation of two types of the same klass with regard to flat in array. We have the following shape in the test case (how we end up with such a graph can be found as comments in the added tests):
>  
> ![image](https://github.com/user-attachments/assets/3ea680fa-d93c-4994-92b7-dd1c271c0030)
> 
> The type of `341 CheckCastPP` is `Object:exact`, so we definitely know that the type is `Object` and nothing else and thus also not flat in array (Object is not a value class). For `339 CheckCastPP`, we know that it is some kind of value class but definitely not `Object` itself - it's just chosen because we do not know more about the klass.
> 
> Joining these two should result in an empty set since they are unrelated. However, the type system is not handling it correctly and we conclude that one is a sub type of the other and we later fail with an assert.
> 
> ### Reworking flat in array Meet Operation
> I revisited the way we meet two instruction types with regard to the flat in array property. The code was a little hard to understand, so I added a summary how the flat in array property should be treated when doing a meet or join:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4604-L4630
> 
> I added a new case for joining the same klasses (see `(FiA-J-Same)`) which was missing before and resulting in an assertion failure.
> 
> ### Adding dual of `_flat_in_array`?
> I kept asking myself if we should introduce a proper lattice with a dual for flat in array:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4593-L4597
> 
> While it's probably the proper way to address this long term, I think we should investigate this separately as we would need to touch quite some code. I therefore left the idea as a comment and went with a point fix on top - keeping the way we currently handle `_flat_in_array` in meet operations without a proper dual.
> 
> ### Including Changes
> - More detailed summary how the meet/join of `flat_in_array` is done .
> - Refactored the code in `meet_instptr()` to make it more readable/clear how the `flat_in_array` property is treated.
> - For better debugging:
>   - Dumping `(flat in array)` also for `TypeInstKlassPtr` and not only for `TypeInstPtr`.
>   - Adapting "Show types" IGV filter to also show the flat in array property (see image of graph above).
> 
> ### Additionally Required Fixes
> - (i) With the type system fix above, we...

Nice analysis and fix, Christian! Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1367#pullrequestreview-2623010188

From thartmann at openjdk.org  Tue Feb 18 10:02:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Feb 2025 10:02:35 GMT
Subject: [lworld] RFR: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
In-Reply-To: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
References: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
Message-ID: <aoTN630RsgxHSYw_OMalHh_YihDomHjVPTZkUOGLm5o=.97be4c5e-a684-4e9c-a6b6-d25d5e6dd7bf@github.com>

On Wed, 12 Feb 2025 16:31:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:
> 
>     // Oops, need to call into the VM to resolve the klasses at runtime.
>     // Note:  This call must not deoptimize, since it is not a real at this bci!
>     kill_dead_locals();
> 
>     make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
>                       OptoRuntime::rethrow_Type(),
>                       OptoRuntime::rethrow_stub(),
>                       nullptr, nullptr,
>                       ex_node);
> 
> As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.
> 
> The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.
> 
> Please share your thoughts, thanks a lot.

The fix looks reasonable to me. Just wondering, as an alternative, could we weaken the assert by checking if the call is to `OptoRuntime::rethrow_stub`?

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

PR Review: https://git.openjdk.org/valhalla/pull/1363#pullrequestreview-2623018176

From chagedorn at openjdk.org  Tue Feb 18 10:26:32 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 18 Feb 2025 10:26:32 GMT
Subject: [lworld] RFR: 8348961: [lworld] C2: Joining "Object:flat_in_array"
 with "Object:exact" does not properly work
In-Reply-To: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
References: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
Message-ID: <Ld4hK8HJlj_wkhLfoiFZmYeDICrAt6Ko911CL8NNiww=.cbec473e-9336-4600-9541-2ca8005cfb1d@github.com>

On Fri, 14 Feb 2025 11:18:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes the wrong joining operation of two types of the same klass with regard to flat in array. We have the following shape in the test case (how we end up with such a graph can be found as comments in the added tests):
>  
> ![image](https://github.com/user-attachments/assets/3ea680fa-d93c-4994-92b7-dd1c271c0030)
> 
> The type of `341 CheckCastPP` is `Object:exact`, so we definitely know that the type is `Object` and nothing else and thus also not flat in array (Object is not a value class). For `339 CheckCastPP`, we know that it is some kind of value class but definitely not `Object` itself - it's just chosen because we do not know more about the klass.
> 
> Joining these two should result in an empty set since they are unrelated. However, the type system is not handling it correctly and we conclude that one is a sub type of the other and we later fail with an assert.
> 
> ### Reworking flat in array Meet Operation
> I revisited the way we meet two instruction types with regard to the flat in array property. The code was a little hard to understand, so I added a summary how the flat in array property should be treated when doing a meet or join:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4604-L4630
> 
> I added a new case for joining the same klasses (see `(FiA-J-Same)`) which was missing before and resulting in an assertion failure.
> 
> ### Adding dual of `_flat_in_array`?
> I kept asking myself if we should introduce a proper lattice with a dual for flat in array:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4593-L4597
> 
> While it's probably the proper way to address this long term, I think we should investigate this separately as we would need to touch quite some code. I therefore left the idea as a comment and went with a point fix on top - keeping the way we currently handle `_flat_in_array` in meet operations without a proper dual.
> 
> ### Including Changes
> - More detailed summary how the meet/join of `flat_in_array` is done .
> - Refactored the code in `meet_instptr()` to make it more readable/clear how the `flat_in_array` property is treated.
> - For better debugging:
>   - Dumping `(flat in array)` also for `TypeInstKlassPtr` and not only for `TypeInstPtr`.
>   - Adapting "Show types" IGV filter to also show the flat in array property (see image of graph above).
> 
> ### Additionally Required Fixes
> - (i) With the type system fix above, we...

Thanks Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1367#issuecomment-2665199641

From chagedorn at openjdk.org  Tue Feb 18 10:26:32 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 18 Feb 2025 10:26:32 GMT
Subject: [lworld] Integrated: 8348961: [lworld] C2: Joining
 "Object:flat_in_array" with "Object:exact" does not properly work
In-Reply-To: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
References: <3-QU9SU2tTVXU1YTs7yTjU5_7xc6RSph04bo5Et3ptw=.8404c1eb-7fc0-4eca-8d23-fe4ef8e7f780@github.com>
Message-ID: <MafPMzgbNdjA8BVjNg5ixpB8qWbkBZKHcwF64qYLjPs=.0bc95589-ad51-460c-89f7-00a15a65af60@github.com>

On Fri, 14 Feb 2025 11:18:39 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch fixes the wrong joining operation of two types of the same klass with regard to flat in array. We have the following shape in the test case (how we end up with such a graph can be found as comments in the added tests):
>  
> ![image](https://github.com/user-attachments/assets/3ea680fa-d93c-4994-92b7-dd1c271c0030)
> 
> The type of `341 CheckCastPP` is `Object:exact`, so we definitely know that the type is `Object` and nothing else and thus also not flat in array (Object is not a value class). For `339 CheckCastPP`, we know that it is some kind of value class but definitely not `Object` itself - it's just chosen because we do not know more about the klass.
> 
> Joining these two should result in an empty set since they are unrelated. However, the type system is not handling it correctly and we conclude that one is a sub type of the other and we later fail with an assert.
> 
> ### Reworking flat in array Meet Operation
> I revisited the way we meet two instruction types with regard to the flat in array property. The code was a little hard to understand, so I added a summary how the flat in array property should be treated when doing a meet or join:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4604-L4630
> 
> I added a new case for joining the same klasses (see `(FiA-J-Same)`) which was missing before and resulting in an assertion failure.
> 
> ### Adding dual of `_flat_in_array`?
> I kept asking myself if we should introduce a proper lattice with a dual for flat in array:
> 
> https://github.com/openjdk/valhalla/blob/b6b30301998e09e61b9c05282878f0596bc2f61b/src/hotspot/share/opto/type.cpp#L4593-L4597
> 
> While it's probably the proper way to address this long term, I think we should investigate this separately as we would need to touch quite some code. I therefore left the idea as a comment and went with a point fix on top - keeping the way we currently handle `_flat_in_array` in meet operations without a proper dual.
> 
> ### Including Changes
> - More detailed summary how the meet/join of `flat_in_array` is done .
> - Refactored the code in `meet_instptr()` to make it more readable/clear how the `flat_in_array` property is treated.
> - For better debugging:
>   - Dumping `(flat in array)` also for `TypeInstKlassPtr` and not only for `TypeInstPtr`.
>   - Adapting "Show types" IGV filter to also show the flat in array property (see image of graph above).
> 
> ### Additionally Required Fixes
> - (i) With the type system fix above, we...

This pull request has now been integrated.

Changeset: d32388fc
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d32388fc2be932cf0f2c5fb2ee5809b447a8073a
Stats:     197 lines in 5 files changed: 157 ins; 2 del; 38 mod

8348961: [lworld] C2: Joining "Object:flat_in_array" with "Object:exact" does not properly work

Reviewed-by: thartmann

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

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

From thartmann at openjdk.org  Tue Feb 18 19:26:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Feb 2025 19:26:23 GMT
Subject: [lworld] RFR: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
In-Reply-To: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
References: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
Message-ID: <Kjaqi2jv1x3D4k4Q14dqgWa8EB29XK5GlWGAvjo_2_c=.ab9017c2-91a0-438c-b6dc-c1ad16c4afb0@github.com>

On Wed, 12 Feb 2025 16:31:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:
> 
>     // Oops, need to call into the VM to resolve the klasses at runtime.
>     // Note:  This call must not deoptimize, since it is not a real at this bci!
>     kill_dead_locals();
> 
>     make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
>                       OptoRuntime::rethrow_Type(),
>                       OptoRuntime::rethrow_stub(),
>                       nullptr, nullptr,
>                       ex_node);
> 
> As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.
> 
> The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.
> 
> Please share your thoughts, thanks a lot.

I just wanted to add the same comment. If this is indeed the same issue as [JDK-8350208](https://bugs.openjdk.org/browse/JDK-8350208), the fix should be done in mainline and [JDK-8349068](https://bugs.openjdk.org/browse/JDK-8349068) should be closed as duplicate.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1363#issuecomment-2666526076

From dlong at openjdk.org  Tue Feb 18 19:26:22 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 18 Feb 2025 19:26:22 GMT
Subject: [lworld] RFR: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
In-Reply-To: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
References: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
Message-ID: <omExO5UjgkQlU2sdTlmYL7xN_JC1-rTLOICqut-94ys=.92bf0420-e37e-4919-a093-6b408bd5eef7@github.com>

On Wed, 12 Feb 2025 16:31:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:
> 
>     // Oops, need to call into the VM to resolve the klasses at runtime.
>     // Note:  This call must not deoptimize, since it is not a real at this bci!
>     kill_dead_locals();
> 
>     make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
>                       OptoRuntime::rethrow_Type(),
>                       OptoRuntime::rethrow_stub(),
>                       nullptr, nullptr,
>                       ex_node);
> 
> As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.
> 
> The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.
> 
> Please share your thoughts, thanks a lot.

I disagree with removing the assert.  It seems like we should be skipping this code if `must_throw` is set, and possibly even calling set_should_reexecute(false) instead.  Also, should the fix be moved to jdk25 because of JDK-8350208?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1363#issuecomment-2666484811

From duke at openjdk.org  Tue Feb 18 19:27:16 2025
From: duke at openjdk.org (Andrew Byrd)
Date: Tue, 18 Feb 2025 19:27:16 GMT
Subject: [valhalla-docs] RFR: Add Brian Goetz presentation from July 2024
Message-ID: <ip23GH35NbfvTlcarPaXMsVMExTiaJ3sF72cyaQQqds=.7f09ecb3-b56b-4942-a5ea-45bd598fd9df@github.com>

Looking into the present state of project Valhalla, I found a very good presentation from July of 2024 at https://inside.java/tag/valhalla that was not listed on the page at https://openjdk.org/projects/valhalla/ but seems to fit well alongside the other presentations listed there.

I updated the page to include this presentation from Brian Goetz. I also sorted the presentations in reverse chronological order, as some of the information in this 2024 presentation seems to supersede previous ones.

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

Commit messages:
 - Add Brian Goetz presentation (July 2024)

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

PR: https://git.openjdk.org/valhalla-docs/pull/14

From duke at openjdk.org  Tue Feb 18 19:28:14 2025
From: duke at openjdk.org (Joseph Tarbit)
Date: Tue, 18 Feb 2025 19:28:14 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v4]
In-Reply-To: <OcGqhM0HrS8vAuoa3hIAkHeTwpYA6Fq8wCm7tMfRwvc=.294a8e59-df3b-4b6e-beca-1a874831681d@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
 <OcGqhM0HrS8vAuoa3hIAkHeTwpYA6Fq8wCm7tMfRwvc=.294a8e59-df3b-4b6e-beca-1a874831681d@github.com>
Message-ID: <3Knyg7S3gTPAySF6J37zPCqJd_Fr3mPFmKvoosH3T-I=.b3e314e9-d461-4d31-839c-cc59b65370d1@github.com>

On Tue, 4 Feb 2025 20:59:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
>> Simplified WeakHashMap javadoc updates for IdentityException. 
>> Added note to System.identityHashCode to include value objects.
>> Added to class javadoc for IdentityHashMap for value objects.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand javadoc reference to Reference

src/java.base/share/classes/java/lang/Class.java line 713:

> 711:     @PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS, reflective=true)
> 712:     public boolean isValue() {
> 713:         return PreviewFeatures.isEnabled() ? !isIdentity() : false;

Is there a reason this isn't just `PreviewFeatures.isEnabled() && !isIdentity()`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1327#discussion_r1957317190

From archie.cobbs at gmail.com  Tue Feb 18 19:35:24 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 18 Feb 2025 13:35:24 -0600
Subject: Status of: Null-Restricted and Nullable Types (Preview)
Message-ID: <CANSoFxuG+ZxLDg8YR4+_unEcKWJpiUNQsRAb-+CTpbL9HSgstA@mail.gmail.com>

Question about JDK-8303099 <https://bugs.openjdk.org/browse/JDK-8303099> -
"Null-Restricted and Nullable Types (Preview)".

This idea really clicks for me. The need to prove that some variable is not
null is utterly pervasive, so the addition of a single "!" character that
proves it would be a huge win. It would be yet another "help me prove this
code is correct" task I can offload to the compiler, adding it to a long
list that includes final fields, unchecked warnings, exhaustive switch,
sealed types, etc.

What is the current status of this JEP?

   - Is there some general consensus on the idea?
   - Has anyone started work on a prototype?
   - Does it really depend on valhalla, or could it stand by itself?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250218/e68012a8/attachment.htm>

From fparain at openjdk.org  Tue Feb 18 22:02:38 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 18 Feb 2025 22:02:38 GMT
Subject: [lworld] RFR: 8350283: [lworld] Layout helper can have incorrect
 is_null_free bit for flat arrays
Message-ID: <bV7i3v3ktof34SO7cqU0l7uJU4LN-_MyEp7PnF9geEs=.932f0a9c-f150-4d91-bc5a-c38bbad78d9d@github.com>

Small fix to correct the generation of the layout helper for flat arrays using the NULLABLE_ATOMIC_FLAT layout.

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

Commit messages:
 - Fix layout helper for flat arrays

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

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

From vicente.romero at oracle.com  Tue Feb 18 22:21:12 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 18 Feb 2025 17:21:12 -0500
Subject: Status of: Null-Restricted and Nullable Types (Preview)
In-Reply-To: <CANSoFxuG+ZxLDg8YR4+_unEcKWJpiUNQsRAb-+CTpbL9HSgstA@mail.gmail.com>
References: <CANSoFxuG+ZxLDg8YR4+_unEcKWJpiUNQsRAb-+CTpbL9HSgstA@mail.gmail.com>
Message-ID: <3a786632-df62-4963-b27b-67ca918d2118@oracle.com>

Hi Archie,

The lw5 branch that hangs from the (lworld branch) in the valhalla repo 
has the javac implementation of this JEP, please ping me with any 
comments / suggestions / proposals etc,

Vicente

On 2/18/25 14:35, Archie Cobbs wrote:
> Question about JDK-8303099 
> <https://bugs.openjdk.org/browse/JDK-8303099> - "Null-Restricted and 
> Nullable Types (Preview)".
>
> This idea really clicks for me. The need to prove that some variable 
> is not null is utterly pervasive, so the addition of a single "!" 
> character that proves it would be a huge win. It would be yet 
> another?"help me prove this code is correct" task I can offload to the 
> compiler, adding it to a long list that includes final fields, 
> unchecked warnings, exhaustive switch, sealed types, etc.
>
> What is the current status of this JEP?
>
>   * Is there some general consensus on the idea?
>   * Has anyone started work on a prototype?
>   * Does it really depend on valhalla, or could it stand by itself?
>
> Thanks,
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250218/03983ce2/attachment-0001.htm>

From archie.cobbs at gmail.com  Tue Feb 18 23:29:36 2025
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 18 Feb 2025 17:29:36 -0600
Subject: Status of: Null-Restricted and Nullable Types (Preview)
In-Reply-To: <3a786632-df62-4963-b27b-67ca918d2118@oracle.com>
References: <CANSoFxuG+ZxLDg8YR4+_unEcKWJpiUNQsRAb-+CTpbL9HSgstA@mail.gmail.com>
 <3a786632-df62-4963-b27b-67ca918d2118@oracle.com>
Message-ID: <CANSoFxtjQ28=56gs+yOp-FXJPTYuqCwMCB5euVqqMnmZP2UhZA@mail.gmail.com>

Hi Vicente,

Thanks for the pointer.

Is there some place where the branches in the valhalla git repo are
described (in just a sentence or two)?

If not I'd be happy to collect those descriptions and submit a PR to update
valhalla-docs if that would be useful.

I know some branches are probably obsolete... regardless it would be good
to include all of them in the list.

Thanks,
-Archie

On Tue, Feb 18, 2025 at 4:21?PM Vicente Romero <vicente.romero at oracle.com>
wrote:

> The lw5 branch that hangs from the (lworld branch) in the valhalla repo
> has the javac implementation of this JEP, please ping me with any comments
> / suggestions / proposals etc,
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250218/c7eabacf/attachment.htm>

From duke at openjdk.org  Wed Feb 19 07:14:01 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Feb 2025 07:14:01 GMT
Subject: [valhalla-docs] RFR: Add Brian Goetz presentation from July 2024
In-Reply-To: <ip23GH35NbfvTlcarPaXMsVMExTiaJ3sF72cyaQQqds=.7f09ecb3-b56b-4942-a5ea-45bd598fd9df@github.com>
References: <ip23GH35NbfvTlcarPaXMsVMExTiaJ3sF72cyaQQqds=.7f09ecb3-b56b-4942-a5ea-45bd598fd9df@github.com>
Message-ID: <g45dRruR1-eEBEI39UNk3okjDYB-ssgmCFscXdwtF1w=.fa2e9426-9e5a-4595-b073-f8cc1dc394ce@github.com>

On Tue, 18 Feb 2025 15:33:14 GMT, Andrew Byrd <duke at openjdk.org> wrote:

> Looking into the present state of project Valhalla, I found a very good presentation from July of 2024 at https://inside.java/tag/valhalla that was not listed on the page at https://openjdk.org/projects/valhalla/ but seems to fit well alongside the other presentations listed there.
> 
> I updated the page to include this presentation from Brian Goetz. I also sorted the presentations in reverse chronological order, as some of the information in this 2024 presentation seems to supersede previous ones.

@abyrd 
Your change (at version 62686f98c206c7dbfe1fdaac6cd6ea9603e29a97) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla-docs/pull/14#issuecomment-2667694442

From fparain at openjdk.org  Wed Feb 19 12:52:09 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 19 Feb 2025 12:52:09 GMT
Subject: [lworld] Integrated: 8350283: [lworld] Layout helper can have
 incorrect is_null_free bit for flat arrays
In-Reply-To: <bV7i3v3ktof34SO7cqU0l7uJU4LN-_MyEp7PnF9geEs=.932f0a9c-f150-4d91-bc5a-c38bbad78d9d@github.com>
References: <bV7i3v3ktof34SO7cqU0l7uJU4LN-_MyEp7PnF9geEs=.932f0a9c-f150-4d91-bc5a-c38bbad78d9d@github.com>
Message-ID: <NxZ6vzWm-tlOi17H-MbDckaP2iaenZoMDLfEVjTT6kw=.96f5a130-e361-415d-9037-0cd5528443af@github.com>

On Tue, 18 Feb 2025 21:53:17 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix to correct the generation of the layout helper for flat arrays using the NULLABLE_ATOMIC_FLAT layout.

This pull request has now been integrated.

Changeset: a8047381
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a804738133c326d4d59dcc65061f474ccdfa98fe
Stats:     18 lines in 1 file changed: 9 ins; 5 del; 4 mod

8350283: [lworld] Layout helper can have incorrect is_null_free bit for flat arrays

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

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

From vicente.romero at oracle.com  Wed Feb 19 15:03:58 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 19 Feb 2025 10:03:58 -0500
Subject: [External] : Re: Status of: Null-Restricted and Nullable Types
 (Preview)
In-Reply-To: <CANSoFxtjQ28=56gs+yOp-FXJPTYuqCwMCB5euVqqMnmZP2UhZA@mail.gmail.com>
References: <CANSoFxuG+ZxLDg8YR4+_unEcKWJpiUNQsRAb-+CTpbL9HSgstA@mail.gmail.com>
 <3a786632-df62-4963-b27b-67ca918d2118@oracle.com>
 <CANSoFxtjQ28=56gs+yOp-FXJPTYuqCwMCB5euVqqMnmZP2UhZA@mail.gmail.com>
Message-ID: <fd44e249-6ea7-47fc-88e5-1f7d0bcbae0f@oracle.com>



On 2/18/25 18:29, Archie Cobbs wrote:
> Hi Vicente,
>
> Thanks for the pointer.
>
> Is there some place where the branches in the valhalla git repo are 
> described (in just a sentence or two)?

not that I know to be honest
>
> If not I'd be happy to collect those descriptions and submit a PR to 
> update valhalla-docs if that would be useful.
>
> I know some branches are probably obsolete... regardless it would be 
> good to include all of them in the list.

yep some are although we keep them just in case,

>
> Thanks,
> -Archie

Vicente

>
> On Tue, Feb 18, 2025 at 4:21?PM Vicente Romero 
> <vicente.romero at oracle.com> wrote:
>
>     The lw5 branch that hangs from the (lworld branch) in the valhalla
>     repo has the javac implementation of this JEP, please ping me with
>     any comments / suggestions / proposals etc,
>
>
> -- 
> Archie L. Cobbs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20250219/a672ad32/attachment-0001.htm>

From rriggs at openjdk.org  Wed Feb 19 19:04:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Feb 2025 19:04:28 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1 [v2]
In-Reply-To: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
Message-ID: <jZYkS1FUgjhm4TmDNY4Zhozhr_koBDDsMBuw1x8bQZU=.d6896cfc-bab6-435f-956d-29fd39fda563@github.com>

> Jtreg is updated to 7.5.1
> 7.5.1 drops support for LIBRARY.properties.
> Some tests have added @enableProperties to pass.

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

  Updated requireVersion in test/docs/TEST.ROOT to 7.5.1+1

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1369/files
  - new: https://git.openjdk.org/valhalla/pull/1369/files/6f867914..5af07de8

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

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

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

From rriggs at openjdk.org  Wed Feb 19 19:45:56 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Feb 2025 19:45:56 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v5]
In-Reply-To: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
Message-ID: <h3rESDhnLTk39dHmvMTNjV2u9KIsLYdTLUerv6qZyFw=.4b8fb656-874d-4232-888b-3994fa76de9c@github.com>

> Add APINote  and javadoc for IdentityException where it will be useful to know that identity or value objects are treated differently. 
> Simplified WeakHashMap javadoc updates for IdentityException. 
> Added note to System.identityHashCode to include value objects.
> Added to class javadoc for IdentityHashMap for value objects.

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

 - Merge branch 'lworld' into 8346307-throws-identityexception
 - Merge
 - Expand javadoc reference to Reference
 - Merge remote-tracking branch 'refs/remotes/origin/8346307-throws-identityexception' into 8346307-throws-identityexception
 - Merge branch 'openjdk:lworld' into 8346307-throws-identityexception
 - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException
   Add APINote  and javadoc for IdentityException where it will be useful to know.
   Simplified WeakHashMap javadoc updates for IdentityException.
   Added note to System.identityHashCode to include value objects.
 - 8346307: [lworld] Document WeakHashMap and other apis that may throw IdentityException
   Add APINote and javadoc for IdentityException where it will be useful to know.
   Updated Objects.hasIdentity to return true for non-null reference to identity class; else false
   Added Objects.isValueObject to return true for non-null reference to value class; else false
   Updated tests for value objects.

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

Changes: https://git.openjdk.org/valhalla/pull/1327/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1327&range=04
  Stats: 251 lines in 11 files changed: 193 ins; 14 del; 44 mod
  Patch: https://git.openjdk.org/valhalla/pull/1327.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1327/head:pull/1327

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

From rriggs at openjdk.org  Wed Feb 19 19:45:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Feb 2025 19:45:57 GMT
Subject: [lworld] RFR: 8346307: [lworld] Clarify identity vs value in
 Class, Objects, and document limitations of value objects [v4]
In-Reply-To: <Apikz3d0QyrIq7sk40Iund6HbWQEa4dAESFYCRmuw4g=.7c6a9795-5e4c-4678-bff7-23d369a540fa@github.com>
References: <dTbzA9c4c47_6Tmd0i-IcWdzCOMxn6J4OCWFraJuJ8M=.d93f7eb8-337c-42f7-876c-b37f149dc8b8@github.com>
 <OcGqhM0HrS8vAuoa3hIAkHeTwpYA6Fq8wCm7tMfRwvc=.294a8e59-df3b-4b6e-beca-1a874831681d@github.com>
 <Apikz3d0QyrIq7sk40Iund6HbWQEa4dAESFYCRmuw4g=.7c6a9795-5e4c-4678-bff7-23d369a540fa@github.com>
Message-ID: <MSn6q1gEJsdioEkR0ObItlCSUQFd4FrFxvrSURS3kS0=.932962a7-661e-4e98-b655-163da77ebfd9@github.com>

On Sun, 16 Feb 2025 15:15:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 713:
>> 
>>> 711:     @PreviewFeature(feature = PreviewFeature.Feature.VALUE_OBJECTS, reflective=true)
>>> 712:     public boolean isValue() {
>>> 713:         return PreviewFeatures.isEnabled() ? !isIdentity() : false;
>> 
>> Is there a reason this isn't just `PreviewFeatures.isEnabled() && !isIdentity()`?
>
> Indeed, this API is returning `false` for interfaces and primitive types if preview features are not enabled, which is wrong. Making it simply return `!isIdentity()` may be better and conforms to the javadoc specification here. See https://github.com/openjdk/valhalla/blob/991ec927a2a111e5021b12be3413dfc96efbc74a/src/hotspot/share/prims/jvm.cpp#L1333-L1337

Corrected in 68dd3fb675d0f87da8de2bc7525d5bcc2a87dac1

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1327#discussion_r1962271307

From matsaave at openjdk.org  Wed Feb 19 21:31:26 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 19 Feb 2025 21:31:26 GMT
Subject: [lworld] RFR: 8349923: Refactor StackMapTable constructor and
 StackMapReader
Message-ID: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>

This patch upstreams a commit from mainline which is needed for the implementation of strict fields.
Originally reviewed-by: coleenp, dholmes

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

Commit messages:
 - 8349923: Refactor StackMapTable constructor and StackMapReader

Changes: https://git.openjdk.org/valhalla/pull/1371/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349923
  Stats: 170 lines in 3 files changed: 61 ins; 18 del; 91 mod
  Patch: https://git.openjdk.org/valhalla/pull/1371.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1371/head:pull/1371

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

From heidinga at openjdk.org  Wed Feb 19 21:31:26 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 19 Feb 2025 21:31:26 GMT
Subject: [lworld] RFR: 8349923: Refactor StackMapTable constructor and
 StackMapReader
In-Reply-To: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
References: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
Message-ID: <6wNSQkl07SICpv8lrdxgaM5hsODIQYlC9iID8cXE0DE=.a342c78e-dca7-433d-a3e4-c37ddb576694@github.com>

On Wed, 19 Feb 2025 21:16:22 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch upstreams a commit from mainline which is needed for the implementation of strict fields.
> Originally reviewed-by: coleenp, dholmes

lgtm

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1371#pullrequestreview-2628020256

From liach at openjdk.org  Wed Feb 19 22:16:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Feb 2025 22:16:58 GMT
Subject: [lworld] RFR: 8349923: Refactor StackMapTable constructor and
 StackMapReader
In-Reply-To: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
References: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
Message-ID: <IxAWuozFJsy7_yD9yLVMkO3850_DrDO0PNuTle0PJoE=.f2d78311-a658-4067-ab74-de1fa5945b1f@github.com>

On Wed, 19 Feb 2025 21:16:22 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch upstreams a commit from mainline which is needed for the implementation of strict fields.
> Originally reviewed-by: coleenp, dholmes

I think @MrSimms periodically syncs master into lworld. Should we wait for the next sync?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1371#issuecomment-2669880864

From matsaave at openjdk.org  Thu Feb 20 15:20:21 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 20 Feb 2025 15:20:21 GMT
Subject: [lworld] RFR: 8349923: Refactor StackMapTable constructor and
 StackMapReader
In-Reply-To: <IxAWuozFJsy7_yD9yLVMkO3850_DrDO0PNuTle0PJoE=.f2d78311-a658-4067-ab74-de1fa5945b1f@github.com>
References: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
 <IxAWuozFJsy7_yD9yLVMkO3850_DrDO0PNuTle0PJoE=.f2d78311-a658-4067-ab74-de1fa5945b1f@github.com>
Message-ID: <HuSKjAetbR5k1w_RAhAdpF-XS29zecVYiR_jPkkVNmQ=.093e0366-e999-4457-a54d-67399fc8100e@github.com>

On Wed, 19 Feb 2025 22:14:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think @MrSimms periodically syncs master into lworld. Should we wait for the next sync?

This patch was done because the strict field implementation relies on it. This shouldn't impact the syncs in a negative way but it should smooth the process by having this patch upstreamed early.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1371#issuecomment-2671804492

From matsaave at openjdk.org  Thu Feb 20 15:20:21 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 20 Feb 2025 15:20:21 GMT
Subject: [lworld] RFR: 8349923: Refactor StackMapTable constructor and
 StackMapReader
In-Reply-To: <6wNSQkl07SICpv8lrdxgaM5hsODIQYlC9iID8cXE0DE=.a342c78e-dca7-433d-a3e4-c37ddb576694@github.com>
References: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
 <6wNSQkl07SICpv8lrdxgaM5hsODIQYlC9iID8cXE0DE=.a342c78e-dca7-433d-a3e4-c37ddb576694@github.com>
Message-ID: <ORn-UbSwKpLCRPRYwHh5XgCi8WsWThrrBkeuTpUJ06k=.15b53923-6674-4cc4-9f4d-e33c6bfb46ef@github.com>

On Wed, 19 Feb 2025 21:28:02 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> This patch upstreams a commit from mainline which is needed for the implementation of strict fields.
>> Originally reviewed-by: coleenp, dholmes
>
> lgtm

Thanks for the review @DanHeidinga!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1371#issuecomment-2671805451

From duke at openjdk.org  Thu Feb 20 15:20:21 2025
From: duke at openjdk.org (duke)
Date: Thu, 20 Feb 2025 15:20:21 GMT
Subject: [lworld] RFR: 8349923: Refactor StackMapTable constructor and
 StackMapReader
In-Reply-To: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
References: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
Message-ID: <_jXmSS1bOBaR9-bi39-YeU7ThpqUIAqpQydujgKBros=.71426aac-d141-4b98-92ee-a65c04ce5e44@github.com>

On Wed, 19 Feb 2025 21:16:22 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch upstreams a commit from mainline which is needed for the implementation of strict fields.
> Originally reviewed-by: coleenp, dholmes

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1371#issuecomment-2671806927

From matsaave at openjdk.org  Thu Feb 20 19:33:03 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 20 Feb 2025 19:33:03 GMT
Subject: [lworld] Integrated: 8349923: Refactor StackMapTable constructor and
 StackMapReader
In-Reply-To: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
References: <JqrJgcrO4GeQ-1ojJfPWPETl8pgtNnfNP1VOknbV4WU=.8657bab2-7fe1-40bb-835a-f91d61ffaccc@github.com>
Message-ID: <zHGk53dXIi_hM3stOyVQfvx8hiJ5bM4LKHMdLWU5dnU=.8114d8d3-b7f6-4762-ab64-0e8fbea1c32d@github.com>

On Wed, 19 Feb 2025 21:16:22 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch upstreams a commit from mainline which is needed for the implementation of strict fields.
> Originally reviewed-by: coleenp, dholmes

This pull request has now been integrated.

Changeset: 0bcf2675
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0bcf2675a5d68b9316c49b1cad3cffe7b0df022c
Stats:     170 lines in 3 files changed: 61 ins; 18 del; 91 mod

8349923: Refactor StackMapTable constructor and StackMapReader

Reviewed-by: heidinga

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

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

From matsaave at openjdk.org  Fri Feb 21 17:28:41 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 21 Feb 2025 17:28:41 GMT
Subject: [lworld] RFR: 8350444: Check for verifer error in
 StackMapReader::check_offset()
Message-ID: <dJzFIu_vQeMafDc70iSYO2aa5qJJRFlrsAIACiO_CK8=.1284e8ab-b69b-4e63-9ab1-22ad0a8ceb17@github.com>

This patch upstreams a change from mainline that is needed to implement strict fields. 
Originally reviewed-by: coleenp, dholmes

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

Commit messages:
 - 8350444: Check for verifer error in StackMapReader::check_offset()

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

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

From matsaave at openjdk.org  Fri Feb 21 21:24:53 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 21 Feb 2025 21:24:53 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack map
 tables
Message-ID: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>

This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 

The patch is divided across 3 major commits:
1. VM changes for asserting that strict fields are initialized before the super constructor is called
2. Javac changes for generating the stack map table entries
3. Test

Verified with tier 1-3 tests

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

Commit messages:
 - Fixed build failures and changed test
 - Added test
 - Implemented javac changes
 - Implemented VM changes to handle strict instance fields

Changes: https://git.openjdk.org/valhalla/pull/1373/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1373&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343846
  Stats: 1193 lines in 26 files changed: 965 ins; 43 del; 185 mod
  Patch: https://git.openjdk.org/valhalla/pull/1373.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1373/head:pull/1373

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

From liach at openjdk.org  Fri Feb 21 21:24:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 21:24:53 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables
In-Reply-To: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
Message-ID: <2Hm9YCCIPZvCjfVOSL_AKVwYHqqcYvaFUjsFM_7H50o=.4b4c2bf7-9809-40d6-a661-f1fe035a52dd@github.com>

On Fri, 21 Feb 2025 20:10:39 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
> 
> The patch is divided across 3 major commits:
> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
> 2. Javac changes for generating the stack map table entries
> 3. Test
> 
> Verified with tier 1-3 tests

Do we require complete ClassFile API support for the spec change immediately? Currently ClassFile support is reading-only, still need some tweaks to support writing the correct assert_unset_fields (either through user-specified or through auto generation)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1373#issuecomment-2675503986

From vromero at openjdk.org  Fri Feb 21 21:44:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 21 Feb 2025 21:44:06 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables
In-Reply-To: <2Hm9YCCIPZvCjfVOSL_AKVwYHqqcYvaFUjsFM_7H50o=.4b4c2bf7-9809-40d6-a661-f1fe035a52dd@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <2Hm9YCCIPZvCjfVOSL_AKVwYHqqcYvaFUjsFM_7H50o=.4b4c2bf7-9809-40d6-a661-f1fe035a52dd@github.com>
Message-ID: <YLvzD5kJZocgwvzgD-7qXmK-3fta4uVmg8-e1v8tWjU=.feed2f71-9acd-48b3-9816-f2b5c163c6e5@github.com>

On Fri, 21 Feb 2025 20:43:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Do we require complete ClassFile API support for the spec change immediately? Currently ClassFile support is reading-only, still need some tweaks to support writing the correct assert_unset_fields (either through user-specified or through auto generation)

it would be a nice to have I think but I don't think it is a must as part of this PR. This is still an experimental feature and we don't know what the final version will be, it could even be possible for this feature to be dropped, so

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

PR Comment: https://git.openjdk.org/valhalla/pull/1373#issuecomment-2675602334

From liach at openjdk.org  Fri Feb 21 21:44:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 21 Feb 2025 21:44:06 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables
In-Reply-To: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
Message-ID: <UibKvBnOjAzLd1rdBBJCYyVsCsvBVmvEOq-v3p1YTRc=.d9cb1eac-8714-4453-884b-2f6fe3946f3f@github.com>

On Fri, 21 Feb 2025 20:10:39 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
> 
> The patch is divided across 3 major commits:
> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
> 2. Javac changes for generating the stack map table entries
> 3. Test
> 
> Verified with tier 1-3 tests

Sure, we can always add them later.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1373#issuecomment-2675605349

From jbhateja at openjdk.org  Mon Feb 24 09:16:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Feb 2025 09:16:17 GMT
Subject: [lworld] RFR: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
In-Reply-To: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
References: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
Message-ID: <zZvtn9LpvT7SCioxZPDymcXIPhjDB-DXnsXudSDXxmc=.630c80c9-8023-4523-8da2-513b0288d10f@github.com>

On Wed, 12 Feb 2025 16:31:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:
> 
>     // Oops, need to call into the VM to resolve the klasses at runtime.
>     // Note:  This call must not deoptimize, since it is not a real at this bci!
>     kill_dead_locals();
> 
>     make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
>                       OptoRuntime::rethrow_Type(),
>                       OptoRuntime::rethrow_stub(),
>                       nullptr, nullptr,
>                       ex_node);
> 
> As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.
> 
> The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.
> 
> Please share your thoughts, thanks a lot.

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

> 939:     assert(method() == youngest_jvms->method(), "sanity");
> 940:     assert(compute_stack_effects(inputs, not_used), "unknown bytecode: %s", Bytecodes::name(java_bc()));
> 941:     assert(out_jvms->sp() >= (uint)inputs, "not enough operands for reexecution");

Removal of this assertion looks incorrect, given that stack holds the active expressions this sanity check ensures that required number of inputs needed to re-construction of interpreter frame are present.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1363#discussion_r1967251981

From dsimms at openjdk.org  Mon Feb 24 12:14:10 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 24 Feb 2025 12:14:10 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <S-tCJlkkykGA3TIh2smIqMJnC2W2nZlCleNcGEBx4mA=.5632f517-ac78-4be5-984b-a7ab353d10e7@github.com>

Merge jdk-25+9

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_25_9
 - Adjust test for new return type on Unsafe.arrayBaseOffset
 - Merge tag 'jdk-25+9' into lworld_merge_jdk_25_9
 - 8349417: Fix NULL usage from JDK-8346433
 - 8349511: [BACKOUT] Framework for tracing makefile inclusion and parsing
 - 8349504: Support platform-specific JUnit tests in jpackage
 - 8349155: The "log" parameter to Lint.logIfEnabled() is not needed
 - 8333569: jpackage tests must run app launchers with retries on Linux only
 - 8349383: (fs) FileTreeWalker.next() superfluous null check of visit() return value
 - 8347836: Disabled PopupMenu shows shortcuts on Mac
 - ... and 74 more: https://git.openjdk.org/valhalla/compare/0bcf2675...a8e78116

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

Changes: https://git.openjdk.org/valhalla/pull/1374/files
  Stats: 21266 lines in 363 files changed: 8144 ins; 8529 del; 4593 mod
  Patch: https://git.openjdk.org/valhalla/pull/1374.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1374/head:pull/1374

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

From dsimms at openjdk.org  Mon Feb 24 12:14:11 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 24 Feb 2025 12:14:11 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <S-tCJlkkykGA3TIh2smIqMJnC2W2nZlCleNcGEBx4mA=.5632f517-ac78-4be5-984b-a7ab353d10e7@github.com>
References: <S-tCJlkkykGA3TIh2smIqMJnC2W2nZlCleNcGEBx4mA=.5632f517-ac78-4be5-984b-a7ab353d10e7@github.com>
Message-ID: <NLTbuGKrkpHeyghXjsDqfstZaAwZ4D_nlcoZ49l6mP4=.dc08cd0e-8c20-4f81-bba2-0b394c8d8ba4@github.com>

On Mon, 24 Feb 2025 12:05:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+9

This pull request has now been integrated.

Changeset: 0f91ae6c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0f91ae6c28982583cce48c865739ca8365e30682
Stats:     21266 lines in 363 files changed: 8144 ins; 8529 del; 4593 mod

Merge jdk

Merge jdk-25+9

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

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

From rriggs at openjdk.org  Mon Feb 24 17:38:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Feb 2025 17:38:18 GMT
Subject: [lworld] RFR: 8350509: [lworld] Test MHZeroValue is obsolete
Message-ID: <dphojoIwQuGMKwRRQ3ElLAw6KljOZxmDlZo5vsBSKMw=.1697cadd-a9a4-48bd-a8fa-b9d12c7709a9@github.com>

Remove MHZeroValue.java, it is obsolete since the defaultValue concept was removed.

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

Commit messages:
 - 8350509: [lworld] Test MHZeroValue is obsolete

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

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

From liach at openjdk.org  Mon Feb 24 17:45:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Feb 2025 17:45:08 GMT
Subject: [lworld] RFR: 8350509: [lworld] Test MHZeroValue is obsolete
In-Reply-To: <dphojoIwQuGMKwRRQ3ElLAw6KljOZxmDlZo5vsBSKMw=.1697cadd-a9a4-48bd-a8fa-b9d12c7709a9@github.com>
References: <dphojoIwQuGMKwRRQ3ElLAw6KljOZxmDlZo5vsBSKMw=.1697cadd-a9a4-48bd-a8fa-b9d12c7709a9@github.com>
Message-ID: <Fuht6IAbEdNPFMzxIKK4rniiSgyjMh3RrrClPsUXQWs=.223b6bfa-1749-4436-acf0-0625eb2ad1f8@github.com>

On Mon, 24 Feb 2025 17:34:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove MHZeroValue.java, it is obsolete since the defaultValue concept was removed.

Thanks for this cleanup.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1375#pullrequestreview-2637945918

From rriggs at openjdk.org  Mon Feb 24 19:14:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 24 Feb 2025 19:14:02 GMT
Subject: [lworld] Integrated: 8350509: [lworld] Test MHZeroValue is obsolete
In-Reply-To: <dphojoIwQuGMKwRRQ3ElLAw6KljOZxmDlZo5vsBSKMw=.1697cadd-a9a4-48bd-a8fa-b9d12c7709a9@github.com>
References: <dphojoIwQuGMKwRRQ3ElLAw6KljOZxmDlZo5vsBSKMw=.1697cadd-a9a4-48bd-a8fa-b9d12c7709a9@github.com>
Message-ID: <LyHE7-jnDMn3XjTovA6xq4kPmYWdLg-T8Os6iMjYG30=.51d4dfd3-8a48-4a29-9e31-1468e9bd5a1e@github.com>

On Mon, 24 Feb 2025 17:34:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove MHZeroValue.java, it is obsolete since the defaultValue concept was removed.

This pull request has now been integrated.

Changeset: cc0f8d4a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cc0f8d4a8795fdcb62504be78c0ca7e7a59ea5bf
Stats:     92 lines in 1 file changed: 0 ins; 92 del; 0 mod

8350509: [lworld] Test MHZeroValue is obsolete

Reviewed-by: liach

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

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

From dsimms at openjdk.org  Tue Feb 25 07:54:45 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 07:54:45 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <x7w5Zb_BWFzwlJdoaNX2-KZUIwPGZdGmYFT55-9YKEE=.8f8469ec-cf8b-4636-81f9-f30550cffdd0@github.com>

Merge jdk-25+10

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

Commit messages:
 - Adjust merge, disable assert, filed 8350632
 - Logical merge errors
 - Merge tag 'jdk-25+10' into lworld_jdk_25_10
 - 8349851: RISC-V: Call VM leaf can use movptr2
 - 8349787: java/lang/Thread/virtual/ThreadPollOnYield.java#default passes unexpectedly without libVThreadPinner.so
 - 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni
 - 6562489: Font-Renderer should ignore invisible characters \u2062 and \u2063
 - 8349934: Wrong file regex for copyright header format check in .jcheck/conf
 - 8349571: Remove JavaThreadFactory interface from SA
 - 8349684: Remove SA core file tests from problem list for macosx-x64
 - ... and 73 more: https://git.openjdk.org/valhalla/compare/0f91ae6c...7695e60a

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

Changes: https://git.openjdk.org/valhalla/pull/1376/files
  Stats: 12381 lines in 690 files changed: 8285 ins; 1905 del; 2191 mod
  Patch: https://git.openjdk.org/valhalla/pull/1376.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1376/head:pull/1376

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

From dsimms at openjdk.org  Tue Feb 25 07:59:08 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 07:59:08 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <x7w5Zb_BWFzwlJdoaNX2-KZUIwPGZdGmYFT55-9YKEE=.8f8469ec-cf8b-4636-81f9-f30550cffdd0@github.com>
References: <x7w5Zb_BWFzwlJdoaNX2-KZUIwPGZdGmYFT55-9YKEE=.8f8469ec-cf8b-4636-81f9-f30550cffdd0@github.com>
Message-ID: <CZmQgRngf5q-j8CANBCCS_-w05zrD9CYeXUKYuQMb68=.44775198-fe09-4b2d-8722-001d33482be3@github.com>

On Tue, 25 Feb 2025 07:48:45 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+10

This pull request has now been integrated.

Changeset: 4d262327
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4d262327f1c2d0b4a1bb583f5b9eb3db9c224ea8
Stats:     12381 lines in 690 files changed: 8285 ins; 1905 del; 2191 mod

Merge jdk

Merge jdk-25+10

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

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

From dsimms at openjdk.org  Tue Feb 25 08:07:13 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 08:07:13 GMT
Subject: [lworld] RFR: 8350109: [lworld] Adopt jtreg 7.5.1 [v2]
In-Reply-To: <jZYkS1FUgjhm4TmDNY4Zhozhr_koBDDsMBuw1x8bQZU=.d6896cfc-bab6-435f-956d-29fd39fda563@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
 <jZYkS1FUgjhm4TmDNY4Zhozhr_koBDDsMBuw1x8bQZU=.d6896cfc-bab6-435f-956d-29fd39fda563@github.com>
Message-ID: <aM8FHdYhUpMKX6nRmtxXXb0YKgsoTGdDjm6eQgUW_9w=.fa75315b-c1f4-4a3a-9ac1-9522f1910888@github.com>

On Wed, 19 Feb 2025 19:04:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jtreg is updated to 7.5.1
>> 7.5.1 drops support for LIBRARY.properties.
>> Some tests have added @enableProperties to pass.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated requireVersion in test/docs/TEST.ROOT to 7.5.1+1

Was about to merge in the config change in jdk-25+11...will hold it back at let this PR do the work. Thanks Roger, ship it

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

Marked as reviewed by dsimms (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1369#pullrequestreview-2639989567

From dsimms at openjdk.org  Tue Feb 25 10:43:13 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 10:43:13 GMT
Subject: [lworld] Integrated: 8350641: [lworld] NULL rather than nullptr still
 in Valhalla project repo
Message-ID: <hhRJ0wwV1OuqFTOnO0twZR-jct-XYVp_Lub8lMFqhZM=.4ab40628-08e5-41ea-9b8a-2fb827f094e5@github.com>

Removed remaining "NULL"

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

Commit messages:
 - 8350641: [lworld] NULL rather than nullptr still in Valhalla project repo

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

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

From dsimms at openjdk.org  Tue Feb 25 10:43:13 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 10:43:13 GMT
Subject: [lworld] Integrated: 8350641: [lworld] NULL rather than nullptr
 still in Valhalla project repo
In-Reply-To: <hhRJ0wwV1OuqFTOnO0twZR-jct-XYVp_Lub8lMFqhZM=.4ab40628-08e5-41ea-9b8a-2fb827f094e5@github.com>
References: <hhRJ0wwV1OuqFTOnO0twZR-jct-XYVp_Lub8lMFqhZM=.4ab40628-08e5-41ea-9b8a-2fb827f094e5@github.com>
Message-ID: <SbE4sIuNd1qjAWSR2IJF6WZ8z-RAuVnWU9mMT82ACHk=.b2dd76b2-2a91-4c78-a25f-c06ffd5c9e14@github.com>

On Tue, 25 Feb 2025 10:37:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed remaining "NULL"

Trivial, compiles and tests run

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

PR Comment: https://git.openjdk.org/valhalla/pull/1377#issuecomment-2681520559

From dsimms at openjdk.org  Tue Feb 25 10:43:13 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 10:43:13 GMT
Subject: [lworld] Integrated: 8350641: [lworld] NULL rather than nullptr still
 in Valhalla project repo
In-Reply-To: <hhRJ0wwV1OuqFTOnO0twZR-jct-XYVp_Lub8lMFqhZM=.4ab40628-08e5-41ea-9b8a-2fb827f094e5@github.com>
References: <hhRJ0wwV1OuqFTOnO0twZR-jct-XYVp_Lub8lMFqhZM=.4ab40628-08e5-41ea-9b8a-2fb827f094e5@github.com>
Message-ID: <FI01EEfTEQvCJih1zs2PqZZZd3iIWZtjRJYGsDk3BwU=.7b49dcd7-65c5-4e89-bb41-6c2c503e2f5b@github.com>

On Tue, 25 Feb 2025 10:37:19 GMT, David Simms <dsimms at openjdk.org> wrote:

> Removed remaining "NULL"

This pull request has now been integrated.

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

8350641: [lworld] NULL rather than nullptr still in Valhalla project repo

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

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

From thartmann at openjdk.org  Tue Feb 25 10:49:10 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 25 Feb 2025 10:49:10 GMT
Subject: [lworld] RFR: 8349068: [lworld] C2 compilation fails with
 "not enough operands for reexecution"
In-Reply-To: <zZvtn9LpvT7SCioxZPDymcXIPhjDB-DXnsXudSDXxmc=.630c80c9-8023-4523-8da2-513b0288d10f@github.com>
References: <d9c2CBjX6YMYl9gxGvI4P2y27F2Bg44VDqP0KlpX_q4=.7dd0518b-e04b-4002-838b-01e456d2c535@github.com>
 <zZvtn9LpvT7SCioxZPDymcXIPhjDB-DXnsXudSDXxmc=.630c80c9-8023-4523-8da2-513b0288d10f@github.com>
Message-ID: <g_yaTAAasPxILf7Yd4q4oBgoZHE1hMqWM7zlkrFnKp0=.26947e2d-bf39-4dfb-a6e7-5188b41f9795@github.com>

On Mon, 24 Feb 2025 09:13:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> The issue here is that `GraphKit::make_runtime_call` is often used to execute a bytecode. As a result, it expects that it may deoptimize and thus need to reexecute the current bytecode in the interpreter. This is the intention of the `assert`, to verify that we are having enough operands for reexecution of the bytecode. However, in the failing case, `GraphKit::make_runtime_call` is not used to execute the bytecode, but to handle the exceptions thrown by that bytecode. In this case, the bytecode itself has finished executing and must not be reexecuted, we can see that in `Parse::catch_inline_exceptions`:
>> 
>>     // Oops, need to call into the VM to resolve the klasses at runtime.
>>     // Note:  This call must not deoptimize, since it is not a real at this bci!
>>     kill_dead_locals();
>> 
>>     make_runtime_call(RC_NO_LEAF | RC_MUST_THROW,
>>                       OptoRuntime::rethrow_Type(),
>>                       OptoRuntime::rethrow_stub(),
>>                       nullptr, nullptr,
>>                       ex_node);
>> 
>> As a result, reexecution is impossible and we don't need to worry about the operand stack, I propose removing the `assert` as it seems to be the cleanest fix.
>> 
>> The reason this only fails on `lworld` is because here the execution of `aastore` involves a static Java call, resulting in a potential exception that needs catching.
>> 
>> Please share your thoughts, thanks a lot.
>
> src/hotspot/share/opto/graphKit.cpp line 941:
> 
>> 939:     assert(method() == youngest_jvms->method(), "sanity");
>> 940:     assert(compute_stack_effects(inputs, not_used), "unknown bytecode: %s", Bytecodes::name(java_bc()));
>> 941:     assert(out_jvms->sp() >= (uint)inputs, "not enough operands for reexecution");
> 
> Removal of this assertion looks incorrect, given that stack holds the active expressions this sanity check ensures that required number of inputs needed to re-construction of interpreter frame are present.

This will be fixed by [JDK-8350208](https://bugs.openjdk.org/browse/JDK-8350208) in mainline.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1363#discussion_r1969518653

From dsimms at openjdk.org  Tue Feb 25 11:05:13 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 11:05:13 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <lbTCnH2MAT6WDGsjw4EefintQURxisRamQNzBMQqNY0=.031cfa79-0752-42a9-876a-58c46b6440c9@github.com>

Merge jdk-25+11

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_25_11
 - Using ACC_IDENTITY needs preview on
 - Merge tag 'jdk-25+11' into lworld_merge_jdk_25_11
 - 8349953: Avoid editing AOTConfiguration file in "make test JTREG=AOT_JDK=true"
 - 8349943: [JMH] Use jvmArgs consistently
 - 8350344: Cross-build failure: _vptr name conflict
 - 8229012: When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
 - 8349699: XSL transform fails with certain UTF-8 characters on 1024 byte boundaries
 - 8349664: HEX dump should always use ASCII or ISO_8859_1
 - 8349923: Refactor StackMapTable constructor and StackMapReader
 - ... and 70 more: https://git.openjdk.org/valhalla/compare/b6c7e8bb...31f56716

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

Changes: https://git.openjdk.org/valhalla/pull/1378/files
  Stats: 10582 lines in 461 files changed: 7006 ins; 1798 del; 1778 mod
  Patch: https://git.openjdk.org/valhalla/pull/1378.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1378/head:pull/1378

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

From dsimms at openjdk.org  Tue Feb 25 14:41:22 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 25 Feb 2025 14:41:22 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <lbTCnH2MAT6WDGsjw4EefintQURxisRamQNzBMQqNY0=.031cfa79-0752-42a9-876a-58c46b6440c9@github.com>
References: <lbTCnH2MAT6WDGsjw4EefintQURxisRamQNzBMQqNY0=.031cfa79-0752-42a9-876a-58c46b6440c9@github.com>
Message-ID: <xn8c8tn46h82nluU_EdQug56QdtSyXCjrT3mSu0PPAY=.0c5f0a11-42a8-4890-bb25-13b53731b2cd@github.com>

On Tue, 25 Feb 2025 11:00:02 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-25+11

This pull request has now been integrated.

Changeset: a5cd110c
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a5cd110c170080992d93256b04729e87eb41638d
Stats:     10582 lines in 461 files changed: 7006 ins; 1798 del; 1778 mod

Merge jdk

Merge jdk-25+11

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

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

From fparain at openjdk.org  Tue Feb 25 15:06:49 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 25 Feb 2025 15:06:49 GMT
Subject: [lworld] Integrated: 8350630: [lworld] ObjBufferAllocator::initialize
 fails with assert(has_klass_gap()) failed: precondition
Message-ID: <YyQYscpP_nctmQjnnMFnPWvJ4sQqfNfpOiIvQrRE1JQ=.15dedb90-6e85-46d6-a3f8-2681806d9b1d@github.com>

Small fix to adjust Valhalla memory allocator to new code from mainline.
More details in the CR.

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

Commit messages:
 - Fix memory initialization in allocator

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

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

From fparain at openjdk.org  Tue Feb 25 15:06:50 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 25 Feb 2025 15:06:50 GMT
Subject: [lworld] Integrated: 8350630: [lworld] ObjBufferAllocator::initialize
 fails with assert(has_klass_gap()) failed: precondition
In-Reply-To: <YyQYscpP_nctmQjnnMFnPWvJ4sQqfNfpOiIvQrRE1JQ=.15dedb90-6e85-46d6-a3f8-2681806d9b1d@github.com>
References: <YyQYscpP_nctmQjnnMFnPWvJ4sQqfNfpOiIvQrRE1JQ=.15dedb90-6e85-46d6-a3f8-2681806d9b1d@github.com>
Message-ID: <uVucbMs61b9Dw9HyPX-W9LGYNfIs9r36J0f5tbqmxX8=.bafabd4e-320a-4fe8-ad33-f5df88ffad47@github.com>

On Tue, 25 Feb 2025 14:58:45 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Small fix to adjust Valhalla memory allocator to new code from mainline.
> More details in the CR.

This pull request has now been integrated.

Changeset: 263bf8a4
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/263bf8a45e8e927fd89da2bf1703712e5a45076a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8350630: [lworld] ObjBufferAllocator::initialize fails with assert(has_klass_gap()) failed: precondition

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

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

From rriggs at openjdk.org  Tue Feb 25 15:24:14 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Feb 2025 15:24:14 GMT
Subject: [lworld] Integrated: 8350109: [lworld] Adopt jtreg 7.5.1
In-Reply-To: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
References: <dyO_zYcHFAfV5MwvD-vcT3rh9s-T4ifNMSVVdP6Fs_c=.bb8587e0-3473-4aee-9d38-6102ef3138ce@github.com>
Message-ID: <eonKIX7DK3boaIXpZVBJXFTbqbwDbSQzzxe0QltUHTI=.5239edef-6bf7-46b5-b2f9-ea5ef6637115@github.com>

On Fri, 14 Feb 2025 15:43:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Jtreg is updated to 7.5.1
> 7.5.1 drops support for LIBRARY.properties.
> Some tests have added @enableProperties to pass.

This pull request has now been integrated.

Changeset: 46e19425
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/46e19425017ed4fc0e8e116bbe9ef8617e599b7f
Stats:     27 lines in 27 files changed: 22 ins; 5 del; 0 mod

8350109: [lworld] Adopt jtreg 7.5.1

Reviewed-by: dsimms

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

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

From fparain at openjdk.org  Tue Feb 25 20:20:13 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 25 Feb 2025 20:20:13 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables
In-Reply-To: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
Message-ID: <UnAHdtBKN30BA_ltS49Iq3Iihs0UQ_3X6tRZ9O_4yuc=.060d7d8b-4f90-4f31-9da6-85e4fcbb095f@github.com>

On Fri, 21 Feb 2025 20:10:39 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
> 
> The patch is divided across 3 major commits:
> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
> 2. Javac changes for generating the stack map table entries
> 3. Test
> 
> Verified with tier 1-3 tests

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

> 2419:             ResourceMark rm(THREAD);
> 2420:             if (!current_frame->satisfy_unset_field(fd.name(), fd.signature())) {
> 2421:               log_info(verification)("Attempting to initialize field not found in initial stict instance fields: %s%s",

typo: stict -> strict

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1970485388

From fparain at openjdk.org  Wed Feb 26 18:46:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 26 Feb 2025 18:46:30 GMT
Subject: [lworld] Integrated: 8350763: [lworld] InlineKlass::flat_array_klass
 hits assert(has_non_atomic_layout()) failed: Must be
Message-ID: <9--qwlzbgGVHrE4O7o8_cD1dsjpHyxj5rKn8jc2uzzw=.9b8ed2be-34fa-404a-98bc-249f52acd967@github.com>

Check layout availability before creating a flat array.

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

Commit messages:
 - Check layout availability in  null-restricted array creation

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

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

From fparain at openjdk.org  Wed Feb 26 18:46:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 26 Feb 2025 18:46:30 GMT
Subject: [lworld] Integrated: 8350763: [lworld] InlineKlass::flat_array_klass
 hits assert(has_non_atomic_layout()) failed: Must be
In-Reply-To: <9--qwlzbgGVHrE4O7o8_cD1dsjpHyxj5rKn8jc2uzzw=.9b8ed2be-34fa-404a-98bc-249f52acd967@github.com>
References: <9--qwlzbgGVHrE4O7o8_cD1dsjpHyxj5rKn8jc2uzzw=.9b8ed2be-34fa-404a-98bc-249f52acd967@github.com>
Message-ID: <8ByXypr49ALNX9AaEw-5m1JJzq5CNnTyqy19pY00dsY=.1f36578f-2244-4735-97f1-9bc2e7c6e11e@github.com>

On Wed, 26 Feb 2025 18:39:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Check layout availability before creating a flat array.

This pull request has now been integrated.

Changeset: f2a6f448
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f2a6f448cd15349df77ba06ba9ecca75df60d026
Stats:     6 lines in 1 file changed: 2 ins; 2 del; 2 mod

8350763: [lworld] InlineKlass::flat_array_klass hits assert(has_non_atomic_layout()) failed: Must be

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

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

From thartmann at openjdk.org  Thu Feb 27 08:55:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 27 Feb 2025 08:55:23 GMT
Subject: [lworld] Integrated: [lworld] ValueGetObjectHashCodeTest needs
 -XX:+UnlockDiagnosticVMOptions
In-Reply-To: <UZfJ0ut5_7cyxnl_9RWvZ6IpPa55zoybuGgpDSiABho=.b9f8e1fd-9927-40f0-b918-a8722752bb93@github.com>
References: <UZfJ0ut5_7cyxnl_9RWvZ6IpPa55zoybuGgpDSiABho=.b9f8e1fd-9927-40f0-b918-a8722752bb93@github.com>
Message-ID: <qQEkZevCyoalAiCaC6rElNXnj5b0FYygZ73wNw00JZw=.7759183a-aa2e-432f-b24e-c6aae35d416e@github.com>

On Thu, 27 Feb 2025 08:50:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Test added with [JDK-8348743](https://bugs.openjdk.org/browse/JDK-8348743) (paging @alexmenkov) fails with release builds because:
> 
> 
> Error: VM option 'PrintInlineLayout' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'PrintInlineLayout'.
> Improperly specified VM option 'PrintInlineLayout'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

[lworld] ValueGetObjectHashCodeTest needs -XX:+UnlockDiagnosticVMOptions

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

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

From thartmann at openjdk.org  Thu Feb 27 08:55:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 27 Feb 2025 08:55:23 GMT
Subject: [lworld] Integrated: [lworld] ValueGetObjectHashCodeTest needs
 -XX:+UnlockDiagnosticVMOptions
Message-ID: <UZfJ0ut5_7cyxnl_9RWvZ6IpPa55zoybuGgpDSiABho=.b9f8e1fd-9927-40f0-b918-a8722752bb93@github.com>

Test added with [JDK-8348743](https://bugs.openjdk.org/browse/JDK-8348743) (paging @alexmenkov) fails with release builds because:


Error: VM option 'PrintInlineLayout' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions.
Error: The unlock option must precede 'PrintInlineLayout'.
Improperly specified VM option 'PrintInlineLayout'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


Thanks,
Tobias

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

Commit messages:
 - [lworld] ValueGetObjectHashCodeTest needs -XX:+UnlockDiagnosticVMOptions

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

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

From dsimms at openjdk.org  Thu Feb 27 12:02:51 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 27 Feb 2025 12:02:51 GMT
Subject: [lworld] RFR: 8348970: [lworld] Runtime: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
Message-ID: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>

Added prototype header to Klass constructor for the various Valhalla layouts

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

Commit messages:
 - 8348970: [lworld] Runtime: Update Valhalla with UseCompactObjectHeaders for oop->klass load/stores

Changes: https://git.openjdk.org/valhalla/pull/1382/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1382&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8348970
  Stats: 96 lines in 14 files changed: 22 ins; 38 del; 36 mod
  Patch: https://git.openjdk.org/valhalla/pull/1382.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1382/head:pull/1382

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

From fparain at openjdk.org  Thu Feb 27 13:51:14 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 27 Feb 2025 13:51:14 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables
In-Reply-To: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
Message-ID: <zOZ0LZVdpDPj8yx53rNEj9IC1G3LdN5Dz41tXFpNens=.629c3ef5-57d6-4693-984b-ebeac670b40b@github.com>

On Fri, 21 Feb 2025 20:10:39 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
> 
> The patch is divided across 3 major commits:
> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
> 2. Javac changes for generating the stack map table entries
> 3. Test
> 
> Verified with tier 1-3 tests

src/hotspot/share/classfile/stackMapTable.cpp line 275:

> 273:       _prev_frame->verifier()->verify_error(
> 274:         ErrorContext::bad_strict_fields(_prev_frame->offset(), _prev_frame),
> 275:         "Cannot have uninitialzied strict fields after class initialization");

typo: uninitialzied -> uninitialized

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1973616461

From matsaave at openjdk.org  Thu Feb 27 16:46:27 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 27 Feb 2025 16:46:27 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v2]
In-Reply-To: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
Message-ID: <GJDQ8XAKSJyzLD7EfVxlr5LSDpDB2IbYIgn7aQmXAr8=.70c6611c-9196-432f-b175-2c08310ab540@github.com>

> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
> 
> The patch is divided across 3 major commits:
> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
> 2. Javac changes for generating the stack map table entries
> 3. Test
> 
> Verified with tier 1-3 tests

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Typo corrections and method renaming

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1373/files
  - new: https://git.openjdk.org/valhalla/pull/1373/files/77f8a1fe..040d3eac

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

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

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

From coleenp at openjdk.org  Thu Feb 27 20:51:12 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Feb 2025 20:51:12 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v2]
In-Reply-To: <GJDQ8XAKSJyzLD7EfVxlr5LSDpDB2IbYIgn7aQmXAr8=.70c6611c-9196-432f-b175-2c08310ab540@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <GJDQ8XAKSJyzLD7EfVxlr5LSDpDB2IbYIgn7aQmXAr8=.70c6611c-9196-432f-b175-2c08310ab540@github.com>
Message-ID: <DluhhZcuUyknKLohwwulpnDAtP-lTui5uYpLsuKDhu0=.15c8be7a-2984-48d3-87bb-97f0ee8b0367@github.com>

On Thu, 27 Feb 2025 16:46:27 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
>> 
>> The patch is divided across 3 major commits:
>> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
>> 2. Javac changes for generating the stack map table entries
>> 3. Test
>> 
>> Verified with tier 1-3 tests
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo corrections and method renaming

This looks really good!  I have a few comment and name suggestions, and was wondering if your Hashtable could be <NameAndSig, bool> where satisfied is the value?

src/hotspot/share/classfile/stackMapFrame.cpp line 205:

> 203: 
> 204:   // Check that assert unset fields are compatible
> 205:   bool compatible = is_unset_fields_compatible(target->assert_unset_fields());

We decided 'is' was more consistent but it does read funny.  Maybe verify_unset_fields_are_compatible ?

src/hotspot/share/classfile/stackMapFrame.hpp line 166:

> 164:   }
> 165: 
> 166:   bool satisfy_unset_field(Symbol* name, Symbol* signature) {

Could you add a comment above this to say when it's called?  Is this called for putfield?

src/hotspot/share/classfile/stackMapFrame.hpp line 177:

> 175:   }
> 176: 
> 177:   bool is_unset_fields_satisfied() {

Also add a comment when this is called - ie. when you get to the super() call?

Maybe also this one could be verify_unset_fields_are_satisfied().

src/hotspot/share/classfile/stackMapFrame.hpp line 200:

> 198:   }
> 199: 
> 200:   bool is_unset_fields_compatible(AssertUnsetFieldTable* target_table) const {

This one is called at branch targets?

src/hotspot/share/classfile/stackMapTable.cpp line 259:

> 257: 
> 258:       if (!_prev_frame->assert_unset_fields()->contains(tmp)) {
> 259:         log_info(verification)("Field %s%s is not found among initial strict instance fields", name->as_C_string(), sig->as_C_string());

I think you can put a ResourceMark here without breaking everything for the as_C_string() calls and printing.

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

> 729:       if (fs.access_flags().is_strict() && !fs.access_flags().is_static()) {
> 730:         NameAndSig new_field(fs.name(), fs.signature());
> 731:         strict_fields->put(new_field, new_field);

For put, you get a pointer back to the new item, so you could save an iteration by having

if (VerifyNoDebts) {
   new_field._satisfied = true;
}

Or can the value of the hashtable be bool satisfied and the key is NameAndSig ?

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

> 741:       strict_fields->iterate_all(satisfy_all);
> 742:     }
> 743:   }

The name of this option seems like the opposite of what it does.  Maybe it should be IgnoreAssertUnsetFields ?

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

Changes requested by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1373#pullrequestreview-2649017747
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974298262
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974301061
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974300380
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974302160
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974303764
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974312224
PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974315079

From fparain at openjdk.org  Thu Feb 27 21:47:05 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 27 Feb 2025 21:47:05 GMT
Subject: [lworld] RFR: 8348970: [lworld] Runtime: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
References: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
Message-ID: <GkePV3NsDlOwkV44A-KkP6xdCvCVEWOC3dgabJr2Z8E=.838a49be-120c-4052-96b6-ffaa34258f35@github.com>

On Thu, 27 Feb 2025 11:57:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Added prototype header to Klass constructor for the various Valhalla layouts

src/hotspot/share/oops/klass.inline.hpp line 65:

> 63:   if (UseCompactObjectHeaders) {
> 64:     // With compact object headers, the narrow Klass ID is part of the mark word.
> 65:     // We therfore seed the mark word with the narrow Klass ID.

typo: therfore -> therefore

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1382#discussion_r1974378919

From rriggs at openjdk.org  Thu Feb 27 21:53:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 27 Feb 2025 21:53:43 GMT
Subject: [lworld] RFR: 8350901: [lworld] Substitutability check is broken for
 non-flat fields
Message-ID: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>

Revert "8348904: [lworld] Remove concept of default value object and zeroInstance"

This reverts commit 38041d7572e853348691af5b384a08f245e2354d.

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

Commit messages:
 - 8350901: [lworld] Substitutability check is broken for non-flat fields

Changes: https://git.openjdk.org/valhalla/pull/1383/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1383&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350901
  Stats: 109 lines in 13 files changed: 69 ins; 4 del; 36 mod
  Patch: https://git.openjdk.org/valhalla/pull/1383.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1383/head:pull/1383

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

From fparain at openjdk.org  Thu Feb 27 21:55:11 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 27 Feb 2025 21:55:11 GMT
Subject: [lworld] RFR: 8348970: [lworld] Runtime: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
References: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
Message-ID: <CiZ4b7LZ5p9ENhYajCE0Fe32Y1H_byID1fEKqpzSB3M=.016c68e8-d5fb-4b1e-bb1d-89d9cb893487@github.com>

On Thu, 27 Feb 2025 11:57:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Added prototype header to Klass constructor for the various Valhalla layouts

LGTM, only a small typo in a comment.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1382#pullrequestreview-2649165972

From matsaave at openjdk.org  Thu Feb 27 21:58:04 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 27 Feb 2025 21:58:04 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v2]
In-Reply-To: <DluhhZcuUyknKLohwwulpnDAtP-lTui5uYpLsuKDhu0=.15c8be7a-2984-48d3-87bb-97f0ee8b0367@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <GJDQ8XAKSJyzLD7EfVxlr5LSDpDB2IbYIgn7aQmXAr8=.70c6611c-9196-432f-b175-2c08310ab540@github.com>
 <DluhhZcuUyknKLohwwulpnDAtP-lTui5uYpLsuKDhu0=.15c8be7a-2984-48d3-87bb-97f0ee8b0367@github.com>
Message-ID: <N7Avp4jYPF8YDUKNAVoBCXeTQa9kb3YQJt_9YDgXDoc=.07e190fd-72fb-49b4-b1df-794b5806a2fe@github.com>

On Thu, 27 Feb 2025 20:31:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo corrections and method renaming
>
> src/hotspot/share/classfile/stackMapFrame.cpp line 205:
> 
>> 203: 
>> 204:   // Check that assert unset fields are compatible
>> 205:   bool compatible = is_unset_fields_compatible(target->assert_unset_fields());
> 
> We decided 'is' was more consistent but it does read funny.  Maybe verify_unset_fields_are_compatible ?

Maybe `verify_unset_fields_compatibility` works?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1974390671

From liach at openjdk.org  Thu Feb 27 22:24:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Feb 2025 22:24:13 GMT
Subject: [lworld] RFR: 8350901: [lworld] Substitutability check is broken
 for non-flat fields
In-Reply-To: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>
References: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>
Message-ID: <MuO3rYOMw_o0pzFOieubOlCULi7Z3jo23pW_k9LnP-g=.f6b53a4b-5be0-45a8-9965-531361822c91@github.com>

On Thu, 27 Feb 2025 21:49:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revert "8348904: [lworld] Remove concept of default value object and zeroInstance"
> 
> This reverts commit 38041d7572e853348691af5b384a08f245e2354d.

I don't think this is the right way to resolve this problem; this "broken" only happens through null-restricted arrays not properly running value class constructors. The right way to resolve this is to encapsulate `ValueClass.newNullRestrictedArray` to fill the array with valid instances, which can be running the component type constructor.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1383#issuecomment-2689238121

From dsimms at openjdk.org  Fri Feb 28 07:03:12 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 28 Feb 2025 07:03:12 GMT
Subject: [lworld] RFR: 8348970: [lworld] Runtime: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <GkePV3NsDlOwkV44A-KkP6xdCvCVEWOC3dgabJr2Z8E=.838a49be-120c-4052-96b6-ffaa34258f35@github.com>
References: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
 <GkePV3NsDlOwkV44A-KkP6xdCvCVEWOC3dgabJr2Z8E=.838a49be-120c-4052-96b6-ffaa34258f35@github.com>
Message-ID: <JDyPgL5n3pHrYhx9-TlMRxkL9RZekSaWOvLCSyaA3NI=.7c2d8203-f474-4079-97a3-dc8ecce7a880@github.com>

On Thu, 27 Feb 2025 21:44:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Added prototype header to Klass constructor for the various Valhalla layouts
>
> src/hotspot/share/oops/klass.inline.hpp line 65:
> 
>> 63:   if (UseCompactObjectHeaders) {
>> 64:     // With compact object headers, the narrow Klass ID is part of the mark word.
>> 65:     // We therfore seed the mark word with the narrow Klass ID.
> 
> typo: therfore -> therefore

oops, cheers

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1382#discussion_r1974907213

From dsimms at openjdk.org  Fri Feb 28 07:11:45 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 28 Feb 2025 07:11:45 GMT
Subject: [lworld] RFR: 8348970: [lworld] Runtime: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores [v2]
In-Reply-To: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
References: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
Message-ID: <QjPeqexRdO1QYU8RAq2qB9EBMcoT_BXBdtYumhP_Idc=.d546e870-d9e0-4510-84db-d08d21465cad@github.com>

> Added prototype header to Klass constructor for the various Valhalla layouts

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

  Copy pasted typo

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1382/files
  - new: https://git.openjdk.org/valhalla/pull/1382/files/99cb2603..1b6e96e6

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

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

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

From dsimms at openjdk.org  Fri Feb 28 07:11:46 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 28 Feb 2025 07:11:46 GMT
Subject: [lworld] Integrated: 8348970: [lworld] Runtime: Update Valhalla with
 UseCompactObjectHeaders for oop->klass load/stores
In-Reply-To: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
References: <9l8vS46jIFfMLLDvR-v-hNkTAEQFZQhPl-i3TG5kV2w=.4348a4a4-9da2-4ce6-afbd-c10ea1821c9b@github.com>
Message-ID: <nKnPi-Y03LGw6KpvdFmdAnDI4bbmtUAlrPlWS8T0uWU=.f074b7d8-4b43-424f-a379-3e2b98f5c6b7@github.com>

On Thu, 27 Feb 2025 11:57:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Added prototype header to Klass constructor for the various Valhalla layouts

This pull request has now been integrated.

Changeset: 65b5649e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/65b5649e2e599b90bd263d80d8ec4f980af16653
Stats:     96 lines in 14 files changed: 22 ins; 38 del; 36 mod

8348970: [lworld] Runtime: Update Valhalla with UseCompactObjectHeaders for oop->klass load/stores

Reviewed-by: fparain

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

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

From dsimms at openjdk.org  Fri Feb 28 08:56:02 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 28 Feb 2025 08:56:02 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <P7btcces-gYXcB80I3QNi9OIte7tNjbnwMz1VuL3tZs=.aa513d48-5100-426c-ac62-6b729f382db0@github.com>

Merge tag 'jdk-25+12' into lworld_merge_jdk_25_12
Added tag jdk-25+12 for changeset 78c18cfb

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

Commit messages:
 - Merge tag 'jdk-25+12' into lworld_merge_jdk_25_12
 - 8349399: GHA: Add static-jdk build on linux-x64
 - 8350616: Skip ValidateHazardPtrsClosure in non-debug builds
 - 8350313: Include timings for leaving safepoint in safepoint logging
 - 8350649: Class unloading accesses/resurrects dead Java mirror after JDK-8346567
 - 8024695: new File("").exists() returns false whereas it is the current working directory
 - 8350770: [BACKOUT] Protection zone for easier detection of accidental zero-nKlass use
 - 8350443: GHA: Split static-libs-bundles into a separate job
 - 8287749: Re-enable javadoc -serialwarn option
 - 8345598: Upgrade NSS binaries for interop tests
 - ... and 69 more: https://git.openjdk.org/valhalla/compare/65b5649e...c76c7185

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

Changes: https://git.openjdk.org/valhalla/pull/1384/files
  Stats: 12988 lines in 322 files changed: 6551 ins; 5359 del; 1078 mod
  Patch: https://git.openjdk.org/valhalla/pull/1384.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1384/head:pull/1384

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

From rriggs at openjdk.org  Fri Feb 28 09:57:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 28 Feb 2025 09:57:06 GMT
Subject: [lworld] RFR: 8350901: [lworld] Substitutability check is broken
 for non-flat fields
In-Reply-To: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>
References: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>
Message-ID: <-493Dzgy85lK9U6OmkQK1fVLuBsB_5bpKfDXUfpYRlk=.5bd3aac9-a082-4e04-a96f-c0e48b2d6285@github.com>

On Thu, 27 Feb 2025 21:49:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revert "8348904: [lworld] Remove concept of default value object and zeroInstance"
> 
> This reverts commit 38041d7572e853348691af5b384a08f245e2354d.

This resolves the short term blocking of the VM work.
When the VM support is in place, this will be re-re-verted and the arrays will be properly initialized.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1383#issuecomment-2690212675

From rriggs at openjdk.org  Fri Feb 28 09:57:06 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 28 Feb 2025 09:57:06 GMT
Subject: [lworld] Integrated: 8350901: [lworld] Substitutability check is
 broken for non-flat fields
In-Reply-To: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>
References: <-4XVTYGj_h1_Qgp9KwzRlAiAoeNOa-3CdssbvlqMyMo=.b8c5a42d-053d-4ba4-947f-92a3a880cde6@github.com>
Message-ID: <sb_V_YS9W_tbQJK7yg9ABS8dxYTZI2XbtjktytsK3WI=.b99f3aea-8406-42e1-83b1-aaada0ef4a61@github.com>

On Thu, 27 Feb 2025 21:49:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revert "8348904: [lworld] Remove concept of default value object and zeroInstance"
> 
> This reverts commit 38041d7572e853348691af5b384a08f245e2354d.

This pull request has now been integrated.

Changeset: ca409f88
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ca409f889158d7b3704fac879a4a3a1405ab2704
Stats:     109 lines in 13 files changed: 69 ins; 4 del; 36 mod

8350901: [lworld] Substitutability check is broken for non-flat fields

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

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

From dsimms at openjdk.org  Fri Feb 28 10:20:20 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 28 Feb 2025 10:20:20 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <P7btcces-gYXcB80I3QNi9OIte7tNjbnwMz1VuL3tZs=.aa513d48-5100-426c-ac62-6b729f382db0@github.com>
References: <P7btcces-gYXcB80I3QNi9OIte7tNjbnwMz1VuL3tZs=.aa513d48-5100-426c-ac62-6b729f382db0@github.com>
Message-ID: <gFGlQQ8RYMtuodgLs6kFHXPnrawy65C8hFa1uFKp6aU=.88b194f9-437a-4ff9-b26b-ffc311e35ea2@github.com>

On Fri, 28 Feb 2025 08:49:05 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-25+12' into lworld_merge_jdk_25_12
> Added tag jdk-25+12 for changeset 78c18cfb

This pull request has now been integrated.

Changeset: b8652c4a
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b8652c4ad94e62ab6e8dfb646bbcd85ad722d213
Stats:     12988 lines in 322 files changed: 6551 ins; 5359 del; 1078 mod

Merge jdk

Merge jdk-25+12

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

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

From liach at openjdk.org  Fri Feb 28 16:58:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 16:58:43 GMT
Subject: [lworld] RFR: 8350961: [lworld] Some VarHandles tests fail when field
 flattening is not applied
Message-ID: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>

#1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.

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

Commit messages:
 - 8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

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

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

From fparain at openjdk.org  Fri Feb 28 17:07:10 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Feb 2025 17:07:10 GMT
Subject: [lworld] RFR: 8350872: [lworld] Field is flattened although
 -XX:-UseFieldFlattening is set
Message-ID: <p3Zfhzrt59uBXKF8yr2ZXI0WezsM9Gy1czQxqSSHRrs=.4c3aff89-c49a-47a4-8d66-74d48f03fc26@github.com>

Fix behavior of -UseFieldFlattening.

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

Commit messages:
 - Fix UseFieldFlattening

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

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

From fparain at openjdk.org  Fri Feb 28 17:12:11 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Feb 2025 17:12:11 GMT
Subject: [lworld] Integrated: 8350872: [lworld] Field is flattened although
 -XX:-UseFieldFlattening is set
In-Reply-To: <p3Zfhzrt59uBXKF8yr2ZXI0WezsM9Gy1czQxqSSHRrs=.4c3aff89-c49a-47a4-8d66-74d48f03fc26@github.com>
References: <p3Zfhzrt59uBXKF8yr2ZXI0WezsM9Gy1czQxqSSHRrs=.4c3aff89-c49a-47a4-8d66-74d48f03fc26@github.com>
Message-ID: <uPFTXLM0W3A3ev9fRBiWz530sHMyiQCkQKef2UoXVzo=.901d6391-e2e5-4767-8eb0-b790a672efc0@github.com>

On Fri, 28 Feb 2025 17:03:26 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix behavior of -UseFieldFlattening.

This pull request has now been integrated.

Changeset: 6761b574
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6761b5744ec2a551dfba21c944fc442966173fa6
Stats:     8 lines in 2 files changed: 6 ins; 0 del; 2 mod

8350872: [lworld] Field is flattened although -XX:-UseFieldFlattening is set

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

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

From liach at openjdk.org  Fri Feb 28 17:14:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 17:14:15 GMT
Subject: [lworld] RFR: 8350961: [lworld] Some VarHandles tests fail when
 field flattening is not applied [v2]
In-Reply-To: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
References: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
Message-ID: <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>

> #1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.

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

 - Remove problemlist
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vh-null-default-mask
 - 8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1385/files
  - new: https://git.openjdk.org/valhalla/pull/1385/files/ed83ae4e..d7deb87e

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

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

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

From liach at openjdk.org  Fri Feb 28 17:24:13 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 17:24:13 GMT
Subject: [lworld] RFR: 8350961: [lworld] Some VarHandles tests fail when
 field flattening is not applied [v2]
In-Reply-To: <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
References: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
 <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
Message-ID: <bgl1AimljZjztC_Mzm__eNYgN3YVR5kRIBPtUyZTtNk=.afa457b6-0bde-41cb-86ee-a365ca3fb104@github.com>

On Fri, 28 Feb 2025 17:14:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> #1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove problemlist
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vh-null-default-mask
>  - 8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

@RogerRiggs mind review this, as this is part of the work related to #1386?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1385#issuecomment-2691175235

From matsaave at openjdk.org  Fri Feb 28 20:06:09 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 28 Feb 2025 20:06:09 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v2]
In-Reply-To: <DluhhZcuUyknKLohwwulpnDAtP-lTui5uYpLsuKDhu0=.15c8be7a-2984-48d3-87bb-97f0ee8b0367@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <GJDQ8XAKSJyzLD7EfVxlr5LSDpDB2IbYIgn7aQmXAr8=.70c6611c-9196-432f-b175-2c08310ab540@github.com>
 <DluhhZcuUyknKLohwwulpnDAtP-lTui5uYpLsuKDhu0=.15c8be7a-2984-48d3-87bb-97f0ee8b0367@github.com>
Message-ID: <cSMuqRMhjEnwnN4mJoYiYN3aw3u5VapUBLtHGJTlViM=.15ae58e4-2a6c-4ce0-83f3-5699eb9ab95d@github.com>

On Thu, 27 Feb 2025 20:43:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo corrections and method renaming
>
> src/hotspot/share/classfile/verifier.cpp line 731:
> 
>> 729:       if (fs.access_flags().is_strict() && !fs.access_flags().is_static()) {
>> 730:         NameAndSig new_field(fs.name(), fs.signature());
>> 731:         strict_fields->put(new_field, new_field);
> 
> For put, you get a pointer back to the new item, so you could save an iteration by having
> 
> if (VerifyNoDebts) {
>    new_field._satisfied = true;
> }
> 
> Or can the value of the hashtable be bool satisfied and the key is NameAndSig ?

I think using bool as the table value might make things a lot cleaner and will save some space so I'll move forward with that if I can. Thanks for the suggestion!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1373#discussion_r1975952019

From matsaave at openjdk.org  Fri Feb 28 20:12:43 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 28 Feb 2025 20:12:43 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v3]
In-Reply-To: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
Message-ID: <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>

> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
> 
> The patch is divided across 3 major commits:
> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
> 2. Javac changes for generating the stack map table entries
> 3. Test
> 
> Verified with tier 1-3 tests

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Changed AssertUnsetFieldsTable to NameAndSig to bool
 - Coleen suggestions

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1373/files
  - new: https://git.openjdk.org/valhalla/pull/1373/files/040d3eac..728753ba

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

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

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

From liach at openjdk.org  Fri Feb 28 20:18:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 20:18:00 GMT
Subject: [lworld] RFR: 8350961: [lworld] Some VarHandles tests fail when
 field flattening is not applied [v2]
In-Reply-To: <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
References: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
 <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
Message-ID: <fMEg-iUE843KfvbCQ-GTlBv-LW_CJTPhJ3mKDaOCnfs=.d1a2024d-b344-40c3-9243-454b020f17c7@github.com>

On Fri, 28 Feb 2025 17:14:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> #1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove problemlist
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vh-null-default-mask
>  - 8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

Thanks for the review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1385#issuecomment-2691472501

From rriggs at openjdk.org  Fri Feb 28 20:18:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 28 Feb 2025 20:18:00 GMT
Subject: [lworld] RFR: 8350961: [lworld] Some VarHandles tests fail when
 field flattening is not applied [v2]
In-Reply-To: <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
References: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
 <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
Message-ID: <ykeHnPO2DeXtMp1Slzy6OZwWa4oerjMeC_pZpJhO9k8=.ba3ae7ec-8a01-4802-9f8a-8b80b5438ef1@github.com>

On Fri, 28 Feb 2025 17:14:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> #1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove problemlist
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vh-null-default-mask
>  - 8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1385#pullrequestreview-2651693595

From duke at openjdk.org  Fri Feb 28 20:18:00 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Feb 2025 20:18:00 GMT
Subject: [lworld] RFR: 8350961: [lworld] Some VarHandles tests fail when
 field flattening is not applied [v2]
In-Reply-To: <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
References: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
 <m2Is0KQNIRT52uMclyaatrewbH1k3tSGNjCuo7yiDuM=.8bba65de-95d2-46b6-bba3-833fac8697f5@github.com>
Message-ID: <vpvf7TU1b8fI9m_2uICWWe3GSOHkyrE2qv31flwtIDw=.d3110691-9ef6-48d1-9bd0-e6685ca7ea62@github.com>

On Fri, 28 Feb 2025 17:14:15 GMT, Chen Liang <liach at openjdk.org> wrote:

>> #1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Remove problemlist
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/vh-null-default-mask
>  - 8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1385#issuecomment-2691473221

From liach at openjdk.org  Fri Feb 28 20:27:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 20:27:09 GMT
Subject: [lworld] Integrated: 8350961: [lworld] Some VarHandles tests fail when
 field flattening is not applied
In-Reply-To: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
References: <hJ1RFsNd5LmX0mPLDFGEoXFvImG3p4dF6eHpk6JyNsQ=.adca28d0-a8a8-424f-955f-b3fe2f5320ee@github.com>
Message-ID: <5yTw_S5KI_SgDyE5d8XpmAGLy5kPeOrkqomiaRHIjAw=.d063bfcf-d7c6-4123-8912-d183bc14a9d6@github.com>

On Fri, 28 Feb 2025 16:52:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> #1340 removed null masking for references incorrectly before strict field checks are in place. As a result, we have to mask nulls to default values before the default value concept is gone.

This pull request has now been integrated.

Changeset: b22815a5
Author:    Chen Liang <liach at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b22815a547e93cbffc22c5f4e15e680afacbb31a
Stats:     41 lines in 2 files changed: 40 ins; 1 del; 0 mod

8350961: [lworld] Some VarHandles tests fail when field flattening is not applied

Reviewed-by: rriggs

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

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

From coleenp at openjdk.org  Fri Feb 28 20:52:59 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 28 Feb 2025 20:52:59 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v3]
In-Reply-To: <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>
Message-ID: <PF3Nnxa9ms0Mmq6pfxsM5_xloyPzIhV982JNiComD4Q=.7acc7e0d-8f25-4323-8503-f37ceee74ae1@github.com>

On Fri, 28 Feb 2025 20:12:43 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
>> 
>> The patch is divided across 3 major commits:
>> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
>> 2. Javac changes for generating the stack map table entries
>> 3. Test
>> 
>> Verified with tier 1-3 tests
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed AssertUnsetFieldsTable to NameAndSig to bool
>  - Coleen suggestions

This looks really good, and the design fits very nicely with the work of the verifier in verifying stackmap tables.  I reviewed the Hotspot changes.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1373#pullrequestreview-2651750832

From fparain at openjdk.org  Fri Feb 28 21:29:03 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 28 Feb 2025 21:29:03 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v3]
In-Reply-To: <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>
Message-ID: <0m9ILXsh5FSV5g9tuLhZlzhbwVfEzOkFx7QO4RlgTpw=.92e65843-c29a-47f7-a55e-ed5379431fbf@github.com>

On Fri, 28 Feb 2025 20:12:43 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
>> 
>> The patch is divided across 3 major commits:
>> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
>> 2. Javac changes for generating the stack map table entries
>> 3. Test
>> 
>> Verified with tier 1-3 tests
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed AssertUnsetFieldsTable to NameAndSig to bool
>  - Coleen suggestions

LGTM. Nice integration with the verifier code.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1373#pullrequestreview-2651800939

From liach at openjdk.org  Fri Feb 28 22:02:00 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Feb 2025 22:02:00 GMT
Subject: [lworld] RFR: 8343846: [lworld] implement spec changes to stack
 map tables [v3]
In-Reply-To: <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>
References: <TTbj-Jx9NPGwyr-X1zgWrw6SWk1bVhexlc4WNXxQ2-g=.0169f9e1-e93e-4281-a20c-d6889febda55@github.com>
 <vHO5cE6WK0oZplBcszLhjKu4yFI3A4XogHHPZkMAGFM=.86f2edf6-9965-4d95-83d4-412b57e67545@github.com>
Message-ID: <326oxQq4I_ieME68olUBzMQ2ZhSLh1Ou0fIHwp7EQ_M=.5a07ef9e-e991-46cb-83f3-cf361a06b44a@github.com>

On Fri, 28 Feb 2025 20:12:43 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This patch implements the spec changes needed to realize the ACC_STRICT flag. See the JBS issue for more details. 
>> 
>> The patch is divided across 3 major commits:
>> 1. VM changes for asserting that strict fields are initialized before the super constructor is called
>> 2. Javac changes for generating the stack map table entries
>> 3. Test
>> 
>> Verified with tier 1-3 tests
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Changed AssertUnsetFieldsTable to NameAndSig to bool
>  - Coleen suggestions

The language and tooling changes look fine.

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

Marked as reviewed by liach (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1373#pullrequestreview-2651845006