From cay.horstmann at gmail.com  Sat Nov  1 16:58:12 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Sat, 1 Nov 2025 17:58:12 +0100
Subject: Raytracing Experience Report
In-Reply-To: <CA+NR86hvzTuqBbDzH_aZOCN-CsiKPfO68Q+1ONFvcjPpx=R7nA@mail.gmail.com>
References: <CA+NR86j08y06gA74qZs4GsHm_Ch9SmYnEfxe9+2234sdgQDBfw@mail.gmail.com>
 <CH3PR10MB7833F23CBEA8F3B242D994999BFAA@CH3PR10MB7833.namprd10.prod.outlook.com>
 <CA+NR86gJkvod+2Qb9FYXd6OxAPmcAKjZHNecfU2yMkgxqSHLYg@mail.gmail.com>
 <MRWP250MB14112F112E796F26A1C1CEDBEBFBA@MRWP250MB1411.EURP250.PROD.OUTLOOK.COM>
 <CA+NR86hvzTuqBbDzH_aZOCN-CsiKPfO68Q+1ONFvcjPpx=R7nA@mail.gmail.com>
Message-ID: <d3e69d50-dfc4-4ecc-a3bf-9e4c47700ab1@gmail.com>

You are on the right track replacing the array list with an array.

But if you want the VM to flatten the array, you need to use the non-public API for now. And you need to tell the VM that the values are never null, and if they are > 64 bits, that you don't care about tearing.

https://horstmann.com/presentations/2025/jfn-valhalla/#(15)
https://horstmann.com/presentations/2025/jfn-valhalla/#(17)

Cheers,

Cay

Il 30/10/2025 19:08, Ethan McCue ha scritto:
> I did try that - by replacing the ArrayList<Material> with a Sphere[] - there was a modest speedup. But the C++ code itself uses an abstract hittableclass and has a std::vector<shared_ptr<hittable>>. So if I were to make that change in the Java version to get better performance I would feel the need to do the same in the C++ or else it would not be a fair comparison.
> 
> The only other thing I could think of - replacing Optional<HitRecord>with a nullable HitRecord?- didn't move the needle. VisualVM doesn't support the EA so I'm not experienced in how I would need to dig down. It is possible System.out.println might be the bottleneck now, but I somewhat doubt it.
> 
> 
> 
> On Thu, Oct 30, 2025 at 1:56?PM Piotr Tarsa <piotr.tarsa at hotmail.com <mailto:piotr.tarsa at hotmail.com>> wrote:
> 
>     Hi Ethan,
> 
>     IIRC Valhalla still doesn't have reified nor specialized generics in any way, so anything generic, like List<Whatever> or Optional<Whatever>, is erased to non-generic form. The layout of generic classes is not specialized to the generic parameter, but instead the instances of 'Whatever' are unconditionally boxed. I think that the first step to get performance closer to C++ with current Valhalla state would be to avoid all generics in hot execution paths and then redo the experiments.
> 
>     Regards,
>     Piotr
>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>     *Od:* valhalla-dev <valhalla-dev-retn at openjdk.org <mailto:valhalla-dev-retn at openjdk.org>> w imieniu u?ytkownika Ethan McCue <ethan at mccue.dev <mailto:ethan at mccue.dev>>
>     *Wys?ane:* czwartek, 30 pa?dziernika 2025 18:21
>     *Do:* Sergey Kuksenko <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>>
>     *DW:* valhalla-dev at openjdk.org <mailto:valhalla-dev at openjdk.org> <valhalla-dev at openjdk.org <mailto:valhalla-dev at openjdk.org>>
>     *Temat:* Re: Raytracing Experience Report
>     Continuing from this, I ran it against the reference C++ implementation and got these numbers.
> 
>     # Reference C++ implementation (-O3)
> 
>     ```
>     real 6m35.702s
>     user 6m33.780s
>     sys 0m1.454s
>     ```
> 
>     # Java With Value Classes
> 
>     ```
>     real 11m50.122s
>     user 11m36.536s
>     sys 0m13.281s
>     ```
> 
>     # Java Without Value Classes
> 
>     ```
>     real 17m1.038s
>     user 16m40.993s
>     sys 0m29.400s
>     ```
> 
>     I am wondering if using an AOT cache could help catch up to the C++, but I get a class file version error running with -XX:AOTCache=value.aot
> 
>     Error: LinkageError occurred while loading main class Main
>      ? ? ? ? java.lang.UnsupportedClassVersionError: Main has been compiled by a more recent version of the Java Runtime (class file version 70.0), this version of the Java Runtime only recognizes class file versions up to 69.0
> 
>     On Wed, Oct 29, 2025 at 3:44?PM Sergey Kuksenko <sergey.kuksenko at oracle.com <mailto:sergey.kuksenko at oracle.com>> wrote:
> 
>         Hi Ethan,
> 
>         Thank you for the information. Your example and the code are pretty straightforward, and I was able to repeat and diagnose the issue.
> 
>         The fact is, the performance issue is not directly related to value classes. The problem is that HittableList::hit method (invoked at Camera::rayColor) was inlined by JIT in the non-value version and wasn't inlined in the value classes version.
>         When you inline that invocation manually, you should get the same performance for both versions.
>         HittableList::hit was not inlined in the value classes version because value classes resulted in a different code size and changed the inline heuristics. It's a mainline issue; you'll encounter it quite rarely. Current inline heuristics work well in 99% of cases, and you should be very lucky (or unlucky) to get it in real life.
> 
>         Best regards,
>         Sergey Kuksenko
> 
> 
> 
>         ________________________________________
>         From: valhalla-dev <valhalla-dev-retn at openjdk.org <mailto:valhalla-dev-retn at openjdk.org>> on behalf of Ethan McCue <ethan at mccue.dev <mailto:ethan at mccue.dev>>
>         Sent: Monday, October 27, 2025 5:08 PM
>         To: valhalla-dev at openjdk.org <mailto:valhalla-dev at openjdk.org>
>         Subject: Raytracing Experience Report
> 
>         Hi all,
> 
>         I have been following along in the "Ray Tracing in a Weekend" book and trying to make as many classes as possible value classes. (Vec3, Ray, etc.)
> 
>         https://github.com/bowbahdoe/raytracer <https://github.com/bowbahdoe/raytracer>
> 
>         https://raytracing.github.io/books/RayTracingInOneWeekend.html <https://raytracing.github.io/books/RayTracingInOneWeekend.html>
> 
>         (without value classes)
> 
>         time java --enable-preview --class-path build/classes Main > image.ppm
> 
>         real 4m33.190s
>         user 4m28.984s
>         sys 0m5.511s
> 
>         (with value classes)
> 
>         time java --enable-preview --class-path build/classes Main > image.ppm
> 
>         real 3m54.623s
>         user 3m52.205s
>         sys 0m2.064s
> 
>         So by the end the version using value classes beats the version without them by ~14% using unscientific measurements.
> 
>         But that is at the end, running the ray tracer on a relatively large scene with all the features turned on. Before that point there were some checkpoints where using value classes performed noticeably worse than the equivalent code sans the value modifier
> 
>         https://github.com/bowbahdoe/raytracer/tree/no-value-faster <https://github.com/bowbahdoe/raytracer/tree/no-value-faster>
> 
>         real 1m22.172s
>         user 1m9.871s
>         sys 0m12.951s
> 
>         https://github.com/bowbahdoe/raytracer/tree/with-value-slower <https://github.com/bowbahdoe/raytracer/tree/with-value-slower>
> 
>         real 3m34.440s
>         user 3m19.656s
>         sys 0m14.870s
> 
>         So for some reason just adding value to the records/classes makes the program run a over 2x as slow.
> 
>         https://github.com/bowbahdoe/raytracer/compare/no-value-faster...with-value-slower <https://github.com/bowbahdoe/raytracer/compare/no-value-faster...with-value-slower>
> 
>         Is there some intuition that explains this? I am on a stock M1 Arm Mac.
> 

-- 

Cay S. Horstmann | https://horstmann.com


From forax at univ-mlv.fr  Sat Nov  1 18:32:28 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 1 Nov 2025 19:32:28 +0100 (CET)
Subject: Raytracing Experience Report
In-Reply-To: <d3e69d50-dfc4-4ecc-a3bf-9e4c47700ab1@gmail.com>
References: <CA+NR86j08y06gA74qZs4GsHm_Ch9SmYnEfxe9+2234sdgQDBfw@mail.gmail.com>
 <CH3PR10MB7833F23CBEA8F3B242D994999BFAA@CH3PR10MB7833.namprd10.prod.outlook.com>
 <CA+NR86gJkvod+2Qb9FYXd6OxAPmcAKjZHNecfU2yMkgxqSHLYg@mail.gmail.com>
 <MRWP250MB14112F112E796F26A1C1CEDBEBFBA@MRWP250MB1411.EURP250.PROD.OUTLOOK.COM>
 <CA+NR86hvzTuqBbDzH_aZOCN-CsiKPfO68Q+1ONFvcjPpx=R7nA@mail.gmail.com>
 <d3e69d50-dfc4-4ecc-a3bf-9e4c47700ab1@gmail.com>
Message-ID: <1111764982.28600420.1762021948025.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "cay horstmann" <cay.horstmann at gmail.com>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Saturday, November 1, 2025 5:58:12 PM
> Subject: Re: Raytracing Experience Report

> You are on the right track replacing the array list with an array.
> 
> But if you want the VM to flatten the array, you need to use the non-public API
> for now. And you need to tell the VM that the values are never null, and if
> they are > 64 bits, that you don't care about tearing.
> 
> https://horstmann.com/presentations/2025/jfn-valhalla/#(15)
> https://horstmann.com/presentations/2025/jfn-valhalla/#(17)
> 
> Cheers,
> 
> Cay

Or you can use an implementation of List that uses specialization

https://github.com/forax/weather-alert/blob/master/src/main/java/util/FlatListFactory.java#L433

R?mi

> 
> Il 30/10/2025 19:08, Ethan McCue ha scritto:
>> I did try that - by replacing the ArrayList<Material> with a Sphere[] - there
>> was a modest speedup. But the C++ code itself uses an abstract hittableclass
>> and has a std::vector<shared_ptr<hittable>>. So if I were to make that change
>> in the Java version to get better performance I would feel the need to do the
>> same in the C++ or else it would not be a fair comparison.
>> 
>> The only other thing I could think of - replacing Optional<HitRecord>with a
>> nullable HitRecord?- didn't move the needle. VisualVM doesn't support the EA so
>> I'm not experienced in how I would need to dig down. It is possible
>> System.out.println might be the bottleneck now, but I somewhat doubt it.
>> 
>> 
>> 
>> On Thu, Oct 30, 2025 at 1:56?PM Piotr Tarsa <piotr.tarsa at hotmail.com
>> <mailto:piotr.tarsa at hotmail.com>> wrote:
>> 
>>     Hi Ethan,
>> 
>>     IIRC Valhalla still doesn't have reified nor specialized generics in any way, so
>>     anything generic, like List<Whatever> or Optional<Whatever>, is erased to
>>     non-generic form. The layout of generic classes is not specialized to the
>>     generic parameter, but instead the instances of 'Whatever' are unconditionally
>>     boxed. I think that the first step to get performance closer to C++ with
>>     current Valhalla state would be to avoid all generics in hot execution paths
>>     and then redo the experiments.
>> 
>>     Regards,
>>     Piotr
>>     ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>     *Od:* valhalla-dev <valhalla-dev-retn at openjdk.org
>>     <mailto:valhalla-dev-retn at openjdk.org>> w imieniu u?ytkownika Ethan McCue
>>     <ethan at mccue.dev <mailto:ethan at mccue.dev>>
>>     *Wys?ane:* czwartek, 30 pa?dziernika 2025 18:21
>>     *Do:* Sergey Kuksenko <sergey.kuksenko at oracle.com
>>     <mailto:sergey.kuksenko at oracle.com>>
>>     *DW:* valhalla-dev at openjdk.org <mailto:valhalla-dev at openjdk.org>
>>     <valhalla-dev at openjdk.org <mailto:valhalla-dev at openjdk.org>>
>>     *Temat:* Re: Raytracing Experience Report
>>     Continuing from this, I ran it against the reference C++ implementation and got
>>     these numbers.
>> 
>>     # Reference C++ implementation (-O3)
>> 
>>     ```
>>     real 6m35.702s
>>     user 6m33.780s
>>     sys 0m1.454s
>>     ```
>> 
>>     # Java With Value Classes
>> 
>>     ```
>>     real 11m50.122s
>>     user 11m36.536s
>>     sys 0m13.281s
>>     ```
>> 
>>     # Java Without Value Classes
>> 
>>     ```
>>     real 17m1.038s
>>     user 16m40.993s
>>     sys 0m29.400s
>>     ```
>> 
>>     I am wondering if using an AOT cache could help catch up to the C++, but I get a
>>     class file version error running with -XX:AOTCache=value.aot
>> 
>>     Error: LinkageError occurred while loading main class Main
>>      ? ? ? ? java.lang.UnsupportedClassVersionError: Main has been compiled by a more recent
>>      ? ? ? ? version of the Java Runtime (class file version 70.0), this version of the Java
>>      ? ? ? ? Runtime only recognizes class file versions up to 69.0
>> 
>>     On Wed, Oct 29, 2025 at 3:44?PM Sergey Kuksenko <sergey.kuksenko at oracle.com
>>     <mailto:sergey.kuksenko at oracle.com>> wrote:
>> 
>>         Hi Ethan,
>> 
>>         Thank you for the information. Your example and the code are pretty
>>         straightforward, and I was able to repeat and diagnose the issue.
>> 
>>         The fact is, the performance issue is not directly related to value classes. The
>>         problem is that HittableList::hit method (invoked at Camera::rayColor) was
>>         inlined by JIT in the non-value version and wasn't inlined in the value classes
>>         version.
>>         When you inline that invocation manually, you should get the same performance
>>         for both versions.
>>         HittableList::hit was not inlined in the value classes version because value
>>         classes resulted in a different code size and changed the inline heuristics.
>>         It's a mainline issue; you'll encounter it quite rarely. Current inline
>>         heuristics work well in 99% of cases, and you should be very lucky (or unlucky)
>>         to get it in real life.
>> 
>>         Best regards,
>>         Sergey Kuksenko
>> 
>> 
>> 
>>         ________________________________________
>>         From: valhalla-dev <valhalla-dev-retn at openjdk.org
>>         <mailto:valhalla-dev-retn at openjdk.org>> on behalf of Ethan McCue
>>         <ethan at mccue.dev <mailto:ethan at mccue.dev>>
>>         Sent: Monday, October 27, 2025 5:08 PM
>>         To: valhalla-dev at openjdk.org <mailto:valhalla-dev at openjdk.org>
>>         Subject: Raytracing Experience Report
>> 
>>         Hi all,
>> 
>>         I have been following along in the "Ray Tracing in a Weekend" book and trying to
>>         make as many classes as possible value classes. (Vec3, Ray, etc.)
>> 
>>         https://github.com/bowbahdoe/raytracer <https://github.com/bowbahdoe/raytracer>
>> 
>>         https://raytracing.github.io/books/RayTracingInOneWeekend.html
>>         <https://raytracing.github.io/books/RayTracingInOneWeekend.html>
>> 
>>         (without value classes)
>> 
>>         time java --enable-preview --class-path build/classes Main > image.ppm
>> 
>>         real 4m33.190s
>>         user 4m28.984s
>>         sys 0m5.511s
>> 
>>         (with value classes)
>> 
>>         time java --enable-preview --class-path build/classes Main > image.ppm
>> 
>>         real 3m54.623s
>>         user 3m52.205s
>>         sys 0m2.064s
>> 
>>         So by the end the version using value classes beats the version without them by
>>         ~14% using unscientific measurements.
>> 
>>         But that is at the end, running the ray tracer on a relatively large scene with
>>         all the features turned on. Before that point there were some checkpoints where
>>         using value classes performed noticeably worse than the equivalent code sans
>>         the value modifier
>> 
>>         https://github.com/bowbahdoe/raytracer/tree/no-value-faster
>>         <https://github.com/bowbahdoe/raytracer/tree/no-value-faster>
>> 
>>         real 1m22.172s
>>         user 1m9.871s
>>         sys 0m12.951s
>> 
>>         https://github.com/bowbahdoe/raytracer/tree/with-value-slower
>>         <https://github.com/bowbahdoe/raytracer/tree/with-value-slower>
>> 
>>         real 3m34.440s
>>         user 3m19.656s
>>         sys 0m14.870s
>> 
>>         So for some reason just adding value to the records/classes makes the program
>>         run a over 2x as slow.
>> 
>>         https://github.com/bowbahdoe/raytracer/compare/no-value-faster...with-value-slower
>>         <https://github.com/bowbahdoe/raytracer/compare/no-value-faster...with-value-slower>
>> 
>>         Is there some intuition that explains this? I am on a stock M1 Arm Mac.
>> 
> 
> --
> 
> Cay S. Horstmann | https://horstmann.com

From dannyt at netflix.com  Mon Nov  3 03:52:47 2025
From: dannyt at netflix.com (Danny Thomas)
Date: Mon, 3 Nov 2025 14:52:47 +1100
Subject: 64 bit Value Limitation
Message-ID: <CAABjz11adcf9rWe_LuLUuucUzjobm1tcUKT7D-6852iY7_PQeQ@mail.gmail.com>

Hi folks,

I caught Frederic's excellent JVMLS talk over the weekend and was most
interested in the updates on tearing, and appreciate the pragmatism of not
allowing tearing of flattened values.

At 13:15[1] it's mentioned that there's no flattening for value types
larger than 64 bits, as most platforms don't have support for larger atomic
operations. My understanding is that both Intel and AMD have guaranteed the
atomicity of 128 bit SSE loads and stores on CPUs with AVX[2] and aarch64
has had support for 128 bit atomic instructions for some time (and without
any performance limitations w/ LSE).

JEP 401 only has this to say:

In the future, 128-bit flattened references may be possible on platforms
that support atomic reads and writes of that size, or in special cases like
final fields.

Is there a misunderstanding of the state of platform support for 128-bit
atomics or have I missed details omitted for brevity?

Cheers,
Danny

1. https://youtu.be/NF4CpL_EWFI?t=795
2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251103/ff2c8584/attachment.htm>

From davidalayachew at gmail.com  Mon Nov  3 05:25:34 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 3 Nov 2025 00:25:34 -0500
Subject: 64 bit Value Limitation
In-Reply-To: <CAABjz11adcf9rWe_LuLUuucUzjobm1tcUKT7D-6852iY7_PQeQ@mail.gmail.com>
References: <CAABjz11adcf9rWe_LuLUuucUzjobm1tcUKT7D-6852iY7_PQeQ@mail.gmail.com>
Message-ID: <CAA9v-_NCbM+znbbyjjTF7EVEDna0KaVd5D1hptgGeZ0ygqjO9Q@mail.gmail.com>

To my understanding, they just haven't gotten to that part yet.

Multiple folks on the OpenJDK team (especially Brian Goetz) have expressed
desire to put that in ASAP, with the caveat that ASAP is going to take
time. Considering that they are just now providing EA Access to JEP 401.

On Sun, Nov 2, 2025, 10:53?PM Danny Thomas <dannyt at netflix.com> wrote:

> Hi folks,
>
> I caught Frederic's excellent JVMLS talk over the weekend and was most
> interested in the updates on tearing, and appreciate the pragmatism of not
> allowing tearing of flattened values.
>
> At 13:15[1] it's mentioned that there's no flattening for value types
> larger than 64 bits, as most platforms don't have support for larger atomic
> operations. My understanding is that both Intel and AMD have guaranteed the
> atomicity of 128 bit SSE loads and stores on CPUs with AVX[2] and aarch64
> has had support for 128 bit atomic instructions for some time (and without
> any performance limitations w/ LSE).
>
> JEP 401 only has this to say:
>
> In the future, 128-bit flattened references may be possible on platforms
> that support atomic reads and writes of that size, or in special cases like
> final fields.
>
> Is there a misunderstanding of the state of platform support for 128-bit
> atomics or have I missed details omitted for brevity?
>
> Cheers,
> Danny
>
> 1. https://youtu.be/NF4CpL_EWFI?t=795
> 2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251103/3628378a/attachment.htm>

From thartmann at openjdk.org  Mon Nov  3 06:50:38 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 06:50:38 GMT
Subject: [lworld] RFR: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
In-Reply-To: <QMtuYNRqiNkRtbob0LQs9mfVXJrGG1_zdQSCK-Kh9T4=.62f715bb-fbae-4a9b-87a3-b6f34e5fe84a@github.com>
References: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
 <hiDZOaCqu6-iuGXQqSrUZ3a8XK3wo5aoJHWEO32P2p0=.ecb5f0d9-a6a0-4673-a3ff-eb9d8fe3ee8f@github.com>
 <QMtuYNRqiNkRtbob0LQs9mfVXJrGG1_zdQSCK-Kh9T4=.62f715bb-fbae-4a9b-87a3-b6f34e5fe84a@github.com>
Message-ID: <3Mm0D4iG6MhEYeJjE-uGNUrDWF8VbI_7fxk9XXQxxuI=.a89b8b89-f489-40cd-b1e5-993b65ed86c4@github.com>

On Fri, 31 Oct 2025 16:25:40 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> I thought this entry blanket skips all tests in the file?

No, unfortunately it's not skipping all the tests. The latest CI run still shows a failure with `compiler/valhalla/inlinetypes/TestNullableArrays.java#id0`, for example.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1707#issuecomment-3479133457

From thartmann at openjdk.org  Mon Nov  3 06:58:39 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 06:58:39 GMT
Subject: [lworld] RFR: Problem list
 compiler/valhalla/inlinetypes/TestNullableArrays.java
In-Reply-To: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
References: <jbuluXyGt2SJXEP3FLeClDjL8Q-1gOB3b6yrbjO0IjI=.5924c5d8-f724-4b2a-8d59-9294ada1d512@github.com>
Message-ID: <gRMte0-5XqhPvrojX4oxoFBzUn2mQLvIfHs0LFxvqdI=.2dc00b7e-0a4e-4360-8b6e-2ad8b9298816@github.com>

On Tue, 28 Oct 2025 08:19:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> The test is causing a lot of noise in the CI.

I'll fix this with https://github.com/openjdk/valhalla/pull/1711.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1707#issuecomment-3479148420

From thartmann at openjdk.org  Mon Nov  3 07:06:04 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 07:06:04 GMT
Subject: [lworld] Integrated: [lworld] Fix problem listing for 8367553
Message-ID: <wX159PMXhh5sPguxEJErGV-Oik4UqKyd4M09nclNNUg=.0c8abdcd-667e-44f5-a902-2a8ab3807fbc@github.com>

All sub-tests need to be problem listed individually.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Fix problem listing for 8367553

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

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

From thartmann at openjdk.org  Mon Nov  3 07:06:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 07:06:05 GMT
Subject: [lworld] Integrated: [lworld] Fix problem listing for 8367553
In-Reply-To: <wX159PMXhh5sPguxEJErGV-Oik4UqKyd4M09nclNNUg=.0c8abdcd-667e-44f5-a902-2a8ab3807fbc@github.com>
References: <wX159PMXhh5sPguxEJErGV-Oik4UqKyd4M09nclNNUg=.0c8abdcd-667e-44f5-a902-2a8ab3807fbc@github.com>
Message-ID: <B0WSikbtFIpLRWaVWZuWcrcsMxkXh6AQbqB92mOXWEw=.d8b15d52-d1fa-4bf4-8abe-719cba1668d6@github.com>

On Mon, 3 Nov 2025 06:56:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> All sub-tests need to be problem listed individually.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 9b57864a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9b57864a3b1be8772685ced0118c523e8637bffe
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

[lworld] Fix problem listing for 8367553

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

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

From thartmann at openjdk.org  Mon Nov  3 07:44:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 07:44:52 GMT
Subject: [lworld] RFR: [lworld] Disable assert until JDK-8350208 is fixed in
 mainline
Message-ID: <KWIPlybTcMZsiKycCDK8LEdZ9EIxXhlHe9gWThCLzkU=.8ee03780-b655-448f-80e0-befeb507ffb9@github.com>

As @merykitty explained in https://github.com/openjdk/valhalla/pull/1363, the assert triggers frequently in Valhalla but the underlying issue is not Valhalla specific. We see massive failures due to this in higher tiers, so I'll disable the assert for now.

I filed [JDK-8371125](https://bugs.openjdk.org/browse/JDK-8371125) to keep track of this.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Disable assert until JDK-8350208 is fixed in mainline

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

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

From thartmann at openjdk.org  Mon Nov  3 07:49:28 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 07:49:28 GMT
Subject: [lworld] Integrated: [lworld] Disable assert until JDK-8350208 is
 fixed in mainline
In-Reply-To: <KWIPlybTcMZsiKycCDK8LEdZ9EIxXhlHe9gWThCLzkU=.8ee03780-b655-448f-80e0-befeb507ffb9@github.com>
References: <KWIPlybTcMZsiKycCDK8LEdZ9EIxXhlHe9gWThCLzkU=.8ee03780-b655-448f-80e0-befeb507ffb9@github.com>
Message-ID: <t3511rC7SeqMGUWSB3DhzPizJBoFFPD9MWgDJfh4rJ8=.0f2e2806-4bc7-4243-b191-ec1f6e96f020@github.com>

On Mon, 3 Nov 2025 07:39:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> As @merykitty explained in https://github.com/openjdk/valhalla/pull/1363, the assert triggers frequently in Valhalla but the underlying issue is not Valhalla specific. We see massive failures due to this in higher tiers, so I'll disable the assert for now.
> 
> I filed [JDK-8371125](https://bugs.openjdk.org/browse/JDK-8371125) to keep track of this.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

[lworld] Disable assert until JDK-8350208 is fixed in mainline

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

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

From phubner at openjdk.org  Mon Nov  3 08:25:38 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 3 Nov 2025 08:25:38 GMT
Subject: [lworld] Integrated: [lworld] Fix problem listing for 8367553
In-Reply-To: <wX159PMXhh5sPguxEJErGV-Oik4UqKyd4M09nclNNUg=.0c8abdcd-667e-44f5-a902-2a8ab3807fbc@github.com>
References: <wX159PMXhh5sPguxEJErGV-Oik4UqKyd4M09nclNNUg=.0c8abdcd-667e-44f5-a902-2a8ab3807fbc@github.com>
Message-ID: <zosHhQs2i8YMTY1OZpDANj9puugHy3dfdHXQVmm8QLw=.897f2550-4cc8-4862-8d12-c573e77f1cfb@github.com>

On Mon, 3 Nov 2025 06:56:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> All sub-tests need to be problem listed individually.
> 
> Thanks,
> Tobias

Thanks for doing this Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1711#issuecomment-3479381743

From brian.goetz at oracle.com  Mon Nov  3 12:05:08 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 3 Nov 2025 12:05:08 +0000
Subject: 64 bit Value Limitation
In-Reply-To: <CAABjz11adcf9rWe_LuLUuucUzjobm1tcUKT7D-6852iY7_PQeQ@mail.gmail.com>
References: <CAABjz11adcf9rWe_LuLUuucUzjobm1tcUKT7D-6852iY7_PQeQ@mail.gmail.com>
Message-ID: <E30AEA35-7AC6-40F6-96B4-AFEDAC5A156D@oracle.com>

Please keep in mind that this is just an EA, of the _first_ Valhalla JEP.  The goal is to get feedback on the fundamentals, there are many JEPs coming after 401, and many optimizations that we understand but have not yet committed to practice.

There are many ways we might _eventually_ get to 128 bit atomicity, but I suspect that day is ? not close.  All the possible mechanisms have tradeoffs that make it not the slam-dunk it might appear.  STM, TSX, LLSC, CAS, and friends all have access cost penalties.  Vector registers have costs to move data between the vector and regular registers.  128 bit atomics almost surely means 128 bit alignment ? which becomes a tradeoff between flatness and density.  (And not just 128 bit alignment for flattened fields; possibly for _all_ objects.)

We are also working on mechanisms to allow relaxed atomicity based on user directives, but this dramatically raises the complexity of the programming model, because it takes you from ?its just an immutable object? (which anyone can reason about) to having to think about tconcurrency and data races.

So, yes, there are instructions that on paper have the desired characteristics ? but this is merely a necessary but not sufficient condition for routinely flattening to 128.



On Nov 2, 2025, at 10:52 PM, Danny Thomas <dannyt at netflix.com<mailto:dannyt at netflix.com>> wrote:

Hi folks,

I caught Frederic's excellent JVMLS talk over the weekend and was most interested in the updates on tearing, and appreciate the pragmatism of not allowing tearing of flattened values.

At 13:15[1] it's mentioned that there's no flattening for value types larger than 64 bits, as most platforms don't have support for larger atomic operations. My understanding is that both Intel and AMD have guaranteed the atomicity of 128 bit SSE loads and stores on CPUs with AVX[2] and aarch64 has had support for 128 bit atomic instructions for some time (and without any performance limitations w/ LSE).

JEP 401 only has this to say:

In the future, 128-bit flattened references may be possible on platforms that support atomic reads and writes of that size, or in special cases like final fields.

Is there a misunderstanding of the state of platform support for 128-bit atomics or have I missed details omitted for brevity?

Cheers,
Danny

1. https://youtu.be/NF4CpL_EWFI?t=795
2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251103/6149779c/attachment.htm>

From phubner at openjdk.org  Mon Nov  3 12:07:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 3 Nov 2025 12:07:03 GMT
Subject: [lworld] RFR: 8370951: [lworld] Value record ClassCircularityError
Message-ID: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>

Hi all,

When we encounter situations where we can't preload, for example if two value classes refer to each other, **may** not be able to do flattening as we cannot compute the field layout. We have log messages as a hint to application or library developers to let them know of that fact. They are very useful for debugging. However, retaining them at the `warning` level means they are shown by default. This may be misleading, as seeing e.g. `ClassCircularityError` in a log may indicate that something has gone gravely wrong, which is not the case with preload failures. This PR relegates all preload failure logs to level `info`, such that the information is opt-in and will not unnecessarily cause confusion.

Testing: tier 1.

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

Commit messages:
 - Forgot to update a test.
 - Relegate preload logs to info.

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

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

From thartmann at openjdk.org  Mon Nov  3 13:12:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 13:12:35 GMT
Subject: [lworld] RFR: 8370484: [lworld] PhaseOutput::FillLocArray asserts with
 Unexpected type: anyptr
Message-ID: <F6SH9I58RsbnHOCmqi26nHpt2bsFvWnnUlNWSK0AU64=.673f02e9-7625-4d3a-b6ff-e4ee7a3029a6@github.com>

[JDK-8366973](https://bugs.openjdk.org/browse/JDK-8366973) / https://github.com/openjdk/valhalla/pull/1554 added code to handle calls to a method with an unloaded return type. That code also changes the return type of the call to a scalarized return:
https://github.com/openjdk/valhalla/blob/a6d6cb8b9107cc6f8aeb28d5547cec9a5e58f711/src/hotspot/share/opto/graphKit.cpp#L2042-L2046

As a result, the old projection node still used in the "return is null" branch gets a bottom type which confuses code that generates the oop map. We should just use constant null there.

No regression test because basically all the serviceability tests fail with `-Xcomp`.

Thanks,
Tobias

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

Commit messages:
 - 8370484: [lworld] PhaseOutput::FillLocArray asserts with Unexpected type: anyptr

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

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

From thartmann at openjdk.org  Mon Nov  3 14:00:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 14:00:05 GMT
Subject: [lworld] Integrated: [lworld] Don't run TestMethodHandles.java with
 -Xcomp
Message-ID: <E98fmjH_Vs_ceyuGxbgaMKMjwxPXUYo7PcNjnPyLiVk=.678dfe1e-44b6-44e0-b701-775f6e37bfb3@github.com>

`TestMethodHandles.java` is really slow with `-Xcomp` and constantly times out. I filed [JDK-8371149](https://bugs.openjdk.org/browse/JDK-8371149) to track this but let's just not run the test with `-Xcomp` for now.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Don't run TestMethodHandles.java with -Xcomp

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

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

From thartmann at openjdk.org  Mon Nov  3 14:00:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 14:00:05 GMT
Subject: [lworld] Integrated: [lworld] Don't run TestMethodHandles.java with
 -Xcomp
In-Reply-To: <E98fmjH_Vs_ceyuGxbgaMKMjwxPXUYo7PcNjnPyLiVk=.678dfe1e-44b6-44e0-b701-775f6e37bfb3@github.com>
References: <E98fmjH_Vs_ceyuGxbgaMKMjwxPXUYo7PcNjnPyLiVk=.678dfe1e-44b6-44e0-b701-775f6e37bfb3@github.com>
Message-ID: <Pqtkmc4wlgRNmDMXryeBquEqAOtsIAsTG6V5zG8Uhhs=.c5e04336-b39d-4d63-ba6f-525a1970db5e@github.com>

On Mon, 3 Nov 2025 13:52:08 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `TestMethodHandles.java` is really slow with `-Xcomp` and constantly times out. I filed [JDK-8371149](https://bugs.openjdk.org/browse/JDK-8371149) to track this but let's just not run the test with `-Xcomp` for now.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 88f413d8
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/88f413d8459c39181aa7528fb9155b07dca39236
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

[lworld] Don't run TestMethodHandles.java with -Xcomp

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

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

From mhaessig at openjdk.org  Mon Nov  3 14:36:08 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Mon, 3 Nov 2025 14:36:08 GMT
Subject: [lworld] RFR: 8367244: [lworld] C2 compilation fails with assert
 "no node with a side effect"
Message-ID: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>

## Problem Analysis

The stress test `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`, which uses the `StressUnstableIfTrap` flag, failed intermittently with the assert "no node with a side effect" during C2 compilation. I tracked down the origin of the failure to the raw store of the unstable if trap stress counter that was missing a memory edge to the backedge phi and thus had no side effect in the loop, which lead to the aforementioned assert. During parsing, the missing memory edge gets discarded with as vestigial parsing state when `do_if()` ends up `stopped()`. However, the effect of the stress counter should still be wired back into the backedge since it will be incremented in the next iteration.

## Patch Description

To prevent the stress counters memory state being lost to `PreserveJVMState`, I pass it to the caller over an out-parameter and `set_memory` with that node, similar to what is already done for control. This is only necessary for the two last invocation of `do_if()` in `do_acmp()` where they are actually allowed to trap. Further, this PR reenables `StressUnstableIfTrap` in `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`.

## Testing

- [ ] tier1,tier2,tier3 plus internal stress testing

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

Commit messages:
 - Cosmetic changes
 - Add regression test
 - Reenable test
 - Add stress counter in acmp to backedge phi when stopped

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

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

From thartmann at openjdk.org  Mon Nov  3 15:21:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 3 Nov 2025 15:21:25 GMT
Subject: [lworld] Integrated: 8370484: [lworld] PhaseOutput::FillLocArray
 asserts with Unexpected type: anyptr
In-Reply-To: <F6SH9I58RsbnHOCmqi26nHpt2bsFvWnnUlNWSK0AU64=.673f02e9-7625-4d3a-b6ff-e4ee7a3029a6@github.com>
References: <F6SH9I58RsbnHOCmqi26nHpt2bsFvWnnUlNWSK0AU64=.673f02e9-7625-4d3a-b6ff-e4ee7a3029a6@github.com>
Message-ID: <B_CONc0xaQ1mkTSks-aHC4ygcllnbGad7K8OsxkC4yc=.b2af8bd8-ee24-43b4-a218-7d1daa64e4a4@github.com>

On Mon, 3 Nov 2025 13:05:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> [JDK-8366973](https://bugs.openjdk.org/browse/JDK-8366973) / https://github.com/openjdk/valhalla/pull/1554 added code to handle calls to a method with an unloaded return type. That code also changes the return type of the call to a scalarized return:
> https://github.com/openjdk/valhalla/blob/a6d6cb8b9107cc6f8aeb28d5547cec9a5e58f711/src/hotspot/share/opto/graphKit.cpp#L2042-L2046
> 
> As a result, the old projection node still used in the "return is null" branch gets a bottom type which confuses code that generates the oop map. We should just use constant null there.
> 
> No regression test because basically all the serviceability tests fail with `-Xcomp`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8370484: [lworld] PhaseOutput::FillLocArray asserts with Unexpected type: anyptr

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

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

From phubner at openjdk.org  Tue Nov  4 08:42:18 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 08:42:18 GMT
Subject: [lworld] RFR: 8370479: [lworld] OOP-related crashes via mvn surefire
Message-ID: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>

Hi all, 

This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.

## Context

If we consider a value class/record that contains a single field, which is a reference to an identity object:

public static value record Element(Identity underlying) {}
public static class Identity {}

We can create a flattened array via the JDK-internal `ValueClass` API:

Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);

This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  

When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.

## New Barrier Emission

We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 

**Old G1 barrier emission during flat array copying:**
|  | oopless | contains oops |
| --- | --- | --- |
| uninitialized | | |
| initialized | | pre, post |

**New G1 barrier emission during flat array copying:**
| | oopless | contains oops |
| --- | --- | --- |
| uninitialized | | post |
| initialized | | pre, post |

As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.

## New Test Cases

I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.

## Fixed Oop Printing

When G1 verification fails, it tries to print diagnostic information. This will eventually end up printing oops. We handle the case of `String` oops specially, and for that we need to check the klass. However, in this failed verification state, we can't guarantee that the class isn't garbage (either through a race or literal garbage). While debugging this issue, I ran into a scenario where the klass does not pass assertion. Consequently, we crash before the helpful diagnostic error messages finish printing. I've introduced a `klass_without_asserts` version of the string check, intended to be used only for diagnostics, which will perform the `String` check even if the VM is metaphorically on fire after a failed GC. That way, G1 is able to finish printing what it wants to print.

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

Commit messages:
 - Rework the G1 barrier model with flat oops.
 - Improve flat array copying test.
 - Clean up test.
 - Add test.
 - Update Access API to not check uninitialized memory.
 - Fix oop error printing bug.

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

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

From fparain at openjdk.org  Tue Nov  4 12:47:02 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Nov 2025 12:47:02 GMT
Subject: [lworld] RFR: 8370951: [lworld] Value record ClassCircularityError
In-Reply-To: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
References: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
Message-ID: <uoqw9pa4IeVMm3_qdhNN23wro2Fq4jVm75nczkuRaC4=.31bb19bb-720c-4f3c-9c16-39fb58b373cf@github.com>

On Fri, 31 Oct 2025 13:37:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> When we encounter situations where we can't preload, for example if two value classes refer to each other, **may** not be able to do flattening as we cannot compute the field layout. We have log messages as a hint to application or library developers to let them know of that fact. They are very useful for debugging. However, retaining them at the `warning` level means they are shown by default. This may be misleading, as seeing e.g. `ClassCircularityError` in a log may indicate that something has gone gravely wrong, which is not the case with preload failures. This PR relegates all preload failure logs to level `info`, such that the information is opt-in and will not unnecessarily cause confusion.
> 
> Testing: tier 1.

LGTM.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1710#pullrequestreview-3416285535

From fparain at openjdk.org  Tue Nov  4 12:49:14 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Nov 2025 12:49:14 GMT
Subject: [lworld] RFR: 8370479: [lworld] OOP-related crashes via mvn
 surefire
In-Reply-To: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
References: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
Message-ID: <gB7C57e_1akanJVPFD2n_euUuy0LCzQTaEUpzcnKoSw=.4836057d-4e42-4000-a0e0-66e5035fd9be@github.com>

On Mon, 3 Nov 2025 13:00:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.
> 
> ## Context
> 
> If we consider a value class/record that contains a single field, which is a reference to an identity object:
> 
> public static value record Element(Identity underlying) {}
> public static class Identity {}
> 
> We can create a flattened array via the JDK-internal `ValueClass` API:
> 
> Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);
> 
> This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  
> 
> When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.
> 
> ## New Barrier Emission
> 
> We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 
> 
> **Old G1 barrier emission during flat array copying:**
> |  | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | |
> | initialized | | pre, post |
> 
> **New G1 barrier emission during flat array copying:**
> | | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | post |
> | initialized | | pre, post |
> 
> As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.
> 
> ## New Test Cases
> 
> I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.
> 
> ## Fixed Oop Printing
> 
> When G1 verification fails, it tries to print diagnostic information. This will eventually end up printing oops. We handle the ca...

Good catch on the memory barrier!
LGTM.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1713#pullrequestreview-3416291992

From phubner at openjdk.org  Tue Nov  4 12:53:16 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 12:53:16 GMT
Subject: [lworld] RFR: 8370951: [lworld] Value record ClassCircularityError
In-Reply-To: <uoqw9pa4IeVMm3_qdhNN23wro2Fq4jVm75nczkuRaC4=.31bb19bb-720c-4f3c-9c16-39fb58b373cf@github.com>
References: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
 <uoqw9pa4IeVMm3_qdhNN23wro2Fq4jVm75nczkuRaC4=.31bb19bb-720c-4f3c-9c16-39fb58b373cf@github.com>
Message-ID: <NM2iuxro_X3qPoP56etXmVhJchm1lVZXyPFFbDooGNc=.85c147cb-1358-48a9-a101-b0e929f90aa4@github.com>

On Tue, 4 Nov 2025 12:44:23 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Hi all,
>> 
>> When we encounter situations where we can't preload, for example if two value classes refer to each other, **may** not be able to do flattening as we cannot compute the field layout. We have log messages as a hint to application or library developers to let them know of that fact. They are very useful for debugging. However, retaining them at the `warning` level means they are shown by default. This may be misleading, as seeing e.g. `ClassCircularityError` in a log may indicate that something has gone gravely wrong, which is not the case with preload failures. This PR relegates all preload failure logs to level `info`, such that the information is opt-in and will not unnecessarily cause confusion.
>> 
>> Testing: tier 1.
>
> LGTM.

Thanks for the review @fparain.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1710#issuecomment-3485839537

From duke at openjdk.org  Tue Nov  4 12:53:18 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Nov 2025 12:53:18 GMT
Subject: [lworld] RFR: 8370951: [lworld] Value record ClassCircularityError
In-Reply-To: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
References: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
Message-ID: <sv17TIZs-mnIkvFvXG39YbKRL5XqXqx3yaBxTym2w6M=.9fc76770-67fb-48e1-91a0-11a109309a3f@github.com>

On Fri, 31 Oct 2025 13:37:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> When we encounter situations where we can't preload, for example if two value classes refer to each other, **may** not be able to do flattening as we cannot compute the field layout. We have log messages as a hint to application or library developers to let them know of that fact. They are very useful for debugging. However, retaining them at the `warning` level means they are shown by default. This may be misleading, as seeing e.g. `ClassCircularityError` in a log may indicate that something has gone gravely wrong, which is not the case with preload failures. This PR relegates all preload failure logs to level `info`, such that the information is opt-in and will not unnecessarily cause confusion.
> 
> Testing: tier 1.

@Arraying 
Your change (at version 86dd4bcbdff5440f6cdd52d67d200028d848b492) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1710#issuecomment-3485844641

From coleenp at openjdk.org  Tue Nov  4 13:09:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Nov 2025 13:09:24 GMT
Subject: [lworld] RFR: 8370479: [lworld] OOP-related crashes via mvn
 surefire
In-Reply-To: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
References: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
Message-ID: <7xWvSiIBeSFKte97emsa6x36O2AST9jn3h--TYB1rX0=.df3bdea2-0865-441e-8924-c1e98b379aa0@github.com>

On Mon, 3 Nov 2025 13:00:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.
> 
> ## Context
> 
> If we consider a value class/record that contains a single field, which is a reference to an identity object:
> 
> public static value record Element(Identity underlying) {}
> public static class Identity {}
> 
> We can create a flattened array via the JDK-internal `ValueClass` API:
> 
> Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);
> 
> This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  
> 
> When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.
> 
> ## New Barrier Emission
> 
> We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 
> 
> **Old G1 barrier emission during flat array copying:**
> |  | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | |
> | initialized | | pre, post |
> 
> **New G1 barrier emission during flat array copying:**
> | | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | post |
> | initialized | | pre, post |
> 
> As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.
> 
> ## New Test Cases
> 
> I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.
> 
> ## Fixed Oop Printing
> 
> When G1 verification fails, it tries to print diagnostic information. This will eventually end up printing oops. We handle the ca...

Great bug fix and find and very nice comments.

src/hotspot/share/classfile/javaClasses.inline.hpp line 135:

> 133:   return obj != nullptr && obj->klass_without_asserts() == vmClasses::String_klass();
> 134: }
> 135: 

Can you make a small upstream patch for this in mainline (either in addition or instead of this part of the change?)

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1713#pullrequestreview-3416382235
PR Review Comment: https://git.openjdk.org/valhalla/pull/1713#discussion_r2490455382

From phubner at openjdk.org  Tue Nov  4 13:12:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 13:12:32 GMT
Subject: [lworld] RFR: 8370479: [lworld] OOP-related crashes via mvn
 surefire
In-Reply-To: <7xWvSiIBeSFKte97emsa6x36O2AST9jn3h--TYB1rX0=.df3bdea2-0865-441e-8924-c1e98b379aa0@github.com>
References: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
 <7xWvSiIBeSFKte97emsa6x36O2AST9jn3h--TYB1rX0=.df3bdea2-0865-441e-8924-c1e98b379aa0@github.com>
Message-ID: <MUL3E6uIU-Of47h-DquYF1VW9QUKeb0pmGoySnwZj74=.6b77b696-172d-42d5-9013-9ec20f9e6b43@github.com>

On Tue, 4 Nov 2025 13:06:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.
>> 
>> ## Context
>> 
>> If we consider a value class/record that contains a single field, which is a reference to an identity object:
>> 
>> public static value record Element(Identity underlying) {}
>> public static class Identity {}
>> 
>> We can create a flattened array via the JDK-internal `ValueClass` API:
>> 
>> Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);
>> 
>> This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  
>> 
>> When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.
>> 
>> ## New Barrier Emission
>> 
>> We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 
>> 
>> **Old G1 barrier emission during flat array copying:**
>> |  | oopless | contains oops |
>> | --- | --- | --- |
>> | uninitialized | | |
>> | initialized | | pre, post |
>> 
>> **New G1 barrier emission during flat array copying:**
>> | | oopless | contains oops |
>> | --- | --- | --- |
>> | uninitialized | | post |
>> | initialized | | pre, post |
>> 
>> As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.
>> 
>> ## New Test Cases
>> 
>> I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.
>> 
>> ## Fixed Oop Printing
>> 
>> When G1 verification fails, it tries to p...
>
> src/hotspot/share/classfile/javaClasses.inline.hpp line 135:
> 
>> 133:   return obj != nullptr && obj->klass_without_asserts() == vmClasses::String_klass();
>> 134: }
>> 135: 
> 
> Can you make a small upstream patch for this in mainline (either in addition or instead of this part of the change?)

Sure, I'll do it separately, I want to get this fixed in Valhalla ASAP.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1713#discussion_r2490465812

From fparain at openjdk.org  Tue Nov  4 13:50:11 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Nov 2025 13:50:11 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v9]
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <5Zm3hPNPyak7LdSIG-JPAxbGn-HXtQNKuVCz0iPWEGA=.955c111b-1b8e-4f5a-bbc5-d12d94f760f5@github.com>

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

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

 - Fix behavior when alt method is not used
 - Merge remote-tracking branch 'upstream/lworld' into new_acmp
 - Field to field map must be final
 - Add comment
 - Add comment
 - Remove useless check
 - More fixes uggested in reviews
 - Merge remote-tracking branch 'upstream/lworld' into new_acmp
 - Apply changes suggested in review
 - Merge remote-tracking branch 'upstream/lworld' into new_acmp
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/0ff86987...899f4800

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

Changes: https://git.openjdk.org/valhalla/pull/1695/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1695&range=08
  Stats: 351 lines in 19 files changed: 346 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1695.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1695/head:pull/1695

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

From mchevalier at openjdk.org  Tue Nov  4 14:26:04 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 4 Nov 2025 14:26:04 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
Message-ID: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>

# Analysis
## Obervationally
### IGVN
During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:

in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
in(2): java/lang/Object * (speculative=null)

We compute the join (HS' meet):
https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317

t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)

But the current `_type` (of the `PhiNode` as a `TypeNode`) is

_type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)

We filter `t` by `_type`
https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
and we get

ft=java/lang/Object *

which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
and
https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133


### Verification
On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time

_type=java/lang/Object *

and so after filtering `t` by (new) `_type` and we get

ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)

which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.

## But why?!
### Details on type computation
In short, we are doing

t = typeof(in(1)) / typeof(in(2))
ft  = t /\ _type (* IGVN *)
ft' = t /\ ft    (* Verification *)

and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".

To me, the surprising fact was that the intersection

java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
/\
_type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
~>
java/lang/Object *

What happened to the speculative type? Both `MyValue2` and `MyValue3` are inheriting `MyAbstract` (and implementing `MyInterface`). So the code correctly find that the intersection of these speculative type is

compiler/valhalla/inlinetypes/MyAbstract (compiler/valhalla/inlinetypes/MyInterface):AnyNull * (flat in array),iid=top

The interesting part is that it's `AnyNull`: indeed, what else is a `MyValue2` and `MyValue3` at the same time? And then, `above_centerline` decides it's not useful enough (too precise, too clone from HS' top/normal bottom) and remove the speculative type.
https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/type.cpp#L2886-L2888
But on the verification run, `compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *` is intersected with the speculative type of `java/lang/Object *`, which is unknown (HS' bottom/normal top), so we are simply getting `MyValue2`. If we did not discard `AnyNull` using `above_centerline`, we would have the intersection of `MyValue2` and `AnyNull`, giving `AnyNull`, which is indeed stable.

## Ok, but the types are weird?

Indeed, they are! How can we get a speculative type `MyValue3` on the `PhiNode` when inputs are both `Object`, and one is speculated to be a `MyValue2`? This comes from incremental inlining. It seems that we have some profiling information on the returned type of a callee, that happens to be `MyValue3`, which propagate to the `PhiNode`. Later, the callee is inlined, and we get new type information (`MyValue2`) from its body (from the returned type of a callee of our callee, if I remember well), that reaches the input of our `PhiNode`.

# Reproducing

## In Valhalla

This crash is quite rare because:
1. it needs a specific speculative type setup, which depends heavily on timing
2. if `PhiNode::Value` is called a second time, it will stabilize the `_type` field before verification.

To limitate the influence of 2., I've tested with an additional assert that would immediately do

const Type* ft_ = t->filter_speculative(ft);

in `PhiNode::Value` and compare `ft` and `ft_`. Indeed, we are never sure a run of `Value` is not the last one: it should always be legal to stop anywhere (even if in a particular case), it was going to run further.

With this extra check, the crash a bit more common, but still pretty rare. Tests that have been witness to crash then at least once:
- `compiler/valhalla/inlinetypes/TestCallingConvention.java`
- `compiler/valhalla/inlinetypes/TestIntrinsics.java`
- `compiler/valhalla/inlinetypes/TestArrays.java`
- `compiler/valhalla/inlinetypes/TestBasicFunctionality.java`

All in `compiler/valhalla/inlinetypes` while I was also testing with mainline tests. Suspicious, uh.

## In mainline

With the aforementioned extra check, I've tried to see if it could happen on mainline since the involved code seems not to be valhalla-specific. As we could expect given that only valhalla tests have been seen to crash, no such crash at all.

## Crafting an example

I've tried to craft an example that would create a similar situation, but without luck. I never managed to reach a correct setup of incremental inlining, conflicting type profiling...

# Fixing

I think changing the type system would be quite risky: it is all over the place. Also, fixing would require not to drop the speculative type when `above_centerline`. This is not like something missing or a corner case that one didn't think of, it's rather removing a feature that is explicitly here, so probably on purpose.

As a first approach, one could simply run `filter_speculative` twice, that should be enough as the second filter will simply select the non empty speculative type if there is only one, and this one won't be `above_centerline`, or it would not exist as a speculative type already.

To try to be a bit less aggressive, we can rather do that in case where we know it cannot be useful. If `ft` obtained from `filter_speculative` has no speculative type, but `t` has, we can know that it might be because it has been dropped, and computing `t->filter_speculative(ft)` could pick the speculative type of `t`. The speculative type can still be removed if the non-speculative type of `ft` is exact and non null for instance, but we've still reached a fixpoint, so it's correct, but a little bit too much work.

That being said, I'm not claiming it's a great solution: it seems that many parts do their job as expected, but the result is unfortunate. Ignoring speculative types in verification (or maybe of `PhiNode`s only) would also work. Anyway, the problem is an unprecise type, but it is still sound: working with it shouldn't be an issue.

I was told that maybe @rwestrel would have an opinion, or an idea to do differently.

Thanks,
Marc

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

Commit messages:
 - fix assert message
 - Assert after each filter
 - without the assert
 - With instrumentation
 - Tentative fix

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

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

From phubner at openjdk.org  Tue Nov  4 14:38:25 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 14:38:25 GMT
Subject: [lworld] Integrated: 8370951: [lworld] Value record
 ClassCircularityError
In-Reply-To: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
References: <A3Bze3A968LiviVoPS1m2Vi1go_8t-2toQffYrAWwWg=.abd1b7c5-0c54-4d92-b520-dcbdc88e6fe3@github.com>
Message-ID: <F47mHa9ql85F5BjJjvF4wejYJQl4aAbzRW8yQyarsw4=.f1acd3a3-080f-43d3-9f05-9af18afbd776@github.com>

On Fri, 31 Oct 2025 13:37:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> When we encounter situations where we can't preload, for example if two value classes refer to each other, **may** not be able to do flattening as we cannot compute the field layout. We have log messages as a hint to application or library developers to let them know of that fact. They are very useful for debugging. However, retaining them at the `warning` level means they are shown by default. This may be misleading, as seeing e.g. `ClassCircularityError` in a log may indicate that something has gone gravely wrong, which is not the case with preload failures. This PR relegates all preload failure logs to level `info`, such that the information is opt-in and will not unnecessarily cause confusion.
> 
> Testing: tier 1.

This pull request has now been integrated.

Changeset: f6387412
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f638741248d57152bd9f07f338db36798d9a2697
Stats:     32 lines in 6 files changed: 0 ins; 0 del; 32 mod

8370951: [lworld] Value record ClassCircularityError

Reviewed-by: fparain

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

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

From roland at openjdk.org  Tue Nov  4 16:08:53 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 4 Nov 2025 16:08:53 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <g2tytQWZzYovZ9MGd5oAJMEhmULEYuiNSbBvKhoV2Yc=.94881d19-e92a-4f8e-afed-ece9031213a9@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

Do I understand right that 1) `Value` is run first the `Phi` has 2 different nodes as inputs. 2) then the `Phi`'s input change and are the same 3)  something breaks at verification time?

If that's correct why don't we run `Value` again after 2)?

With:

in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
in(2): java/lang/Object * (speculative=null)


How can the meet be `t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)`? Is one of the region's input `top`?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3486782400

From duke at openjdk.org  Tue Nov  4 16:57:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 16:57:54 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v5]
In-Reply-To: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
Message-ID: <t0hWlOD7tibYVVtbfrEQqptU0IsS8KpJvw3WGiJr1Ww=.962e5e2c-af22-4a9a-94d8-22a1af507ec4@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This should be review against https://github.com/openjdk/valhalla/pull/1621.

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

 - Makefile change and test fix rolled into one.
   
   * likely test fix
   * Copy value classes into preview directories for inclusion in jimage
 - Fixing up after dependent PR changes
 - feedback and remove unused code
 - [[AUTOMATIC FORMATTING]]
 - new tests for ImageLocation
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - Remove TODOs now jimage version is bumped
 - jimage writer changes to support preview mode.
 - feedback changes
 - ... and 11 more: https://git.openjdk.org/valhalla/compare/7257a072...6ea658b0

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

Changes: https://git.openjdk.org/valhalla/pull/1622/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1622&range=04
  Stats: 4452 lines in 37 files changed: 2447 ins; 608 del; 1397 mod
  Patch: https://git.openjdk.org/valhalla/pull/1622.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1622/head:pull/1622

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

From duke at openjdk.org  Tue Nov  4 17:04:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:04:19 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v6]
In-Reply-To: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
Message-ID: <0vfz4MhZO4V8swABFfOm3mdjB0oIqmzf-MF4SXjAciM=.f584492e-6325-4602-a0f3-24e11266d415@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This should be review against https://github.com/openjdk/valhalla/pull/1621.

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

 - Roll up of makefile and test fix (temporary)
   
   * likely test fix
   * Copy value classes into preview directories for inclusion in jimage
 - fixing tests after refactoring
 - Fixing up after dependent PR changes
 - feedback and remove unused code
 - [[AUTOMATIC FORMATTING]]
 - new tests for ImageLocation
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - Remove TODOs now jimage version is bumped
 - jimage writer changes to support preview mode.

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

Changes: https://git.openjdk.org/valhalla/pull/1622/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1622&range=05
  Stats: 2852 lines in 25 files changed: 1280 ins; 389 del; 1183 mod
  Patch: https://git.openjdk.org/valhalla/pull/1622.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1622/head:pull/1622

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

From duke at openjdk.org  Tue Nov  4 17:04:20 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:04:20 GMT
Subject: [lworld] Withdrawn: 8368475: [lworld] Add preview classes to jimage at
 make time
In-Reply-To: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
References: <38CiZMk5GesLreQPwVnWTJquCUJkdFT35bO7QTtQlCc=.b3382f2f-9372-4bb6-af09-93cc6b835dd8@github.com>
Message-ID: <BrAOCkJ-iMny6nlMNcwu419lzRTt1fIkGN7iCXTU5CM=.2a559a68-815e-4ce1-bae9-4a9090d4150b@github.com>

On Tue, 23 Sep 2025 19:28:28 GMT, David Beaumont <duke at openjdk.org> wrote:

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
> 
> This should be review against https://github.com/openjdk/valhalla/pull/1621.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue Nov  4 17:16:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:16:10 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage to
 support preview mode
Message-ID: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>

Adds support for writing preview related flags into jimage files.

Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".

Specific issues include:

Supporting preview-only resources without forcing a double lookup on everything.
Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.

To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.

Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.

This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

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

Commit messages:
 - Roll up of writer changes.

Changes: https://git.openjdk.org/valhalla/pull/1718/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1718&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368467
  Stats: 2052 lines in 15 files changed: 892 ins; 155 del; 1005 mod
  Patch: https://git.openjdk.org/valhalla/pull/1718.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1718/head:pull/1718

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

From duke at openjdk.org  Tue Nov  4 17:16:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:16:12 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <KRMWAxZK4nl9VEBuJmYxdPnmOYDNKtgdbO9OodzqL60=.8e8b5b67-3712-42ff-bcf5-287832207e13@github.com>

On Tue, 4 Nov 2025 17:08:45 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 230:

> 228:             boolean generateRuntimeImage
> 229:     ) throws IOException {
> 230:         ResourcePool resultResources;

Pulling this into a helper means that resultResources is effectively final and usable in the lambda.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageLocationWriter.java line 93:

> 91: 
> 92:         return new ImageLocationWriter(strings)
> 93:                .addAttribute(ATTRIBUTE_MODULE, moduleName)

Original has bad indentation.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2491372924
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2491374736

From duke at openjdk.org  Tue Nov  4 17:21:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:21:17 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <3QlrOwGByFPYDQBUmbrC466yGCLA0BDzylkcPi-YjeI=.39c994db-17c3-4c3e-833b-1f390684df9c@github.com>

On Tue, 4 Nov 2025 17:08:45 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 393:

> 391:                 ByteBuffer byteBuffer = ByteBuffer.allocate(8 * refs.size());
> 392:                 byteBuffer.order(writer.getByteOrder());
> 393:                 ModuleReference.write(refs, byteBuffer.asIntBuffer(), writer::addString);

By letting the ModuleReference helper do the writing, the calculation of package entry flags is completely hidden so nothing can be confused with image location flags.

test/jdk/jdk/internal/jimage/ImageLocationTest.java line 1:

> 1: /*

Probably more ImageLocation tests could be written for existing functionality, but that something someone could add later. At least the preview flag stuff is tested now.

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 1:

> 1: /*

Now we've got the code to do the jimage writing, we can add tests for the preview flags.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2491391198
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2491405512
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2491397325

From mchevalier at openjdk.org  Tue Nov  4 17:22:12 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 4 Nov 2025 17:22:12 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <_u0XLbEKWGLq1x7lMSJL0ZUQrLCjzWwF3kqiKY7auyk=.6b8b8b9d-09cd-4f7b-9806-b3f3105748b5@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

I don't think this is quite correct. At first, we have

in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 [...]
in(2): java/lang/Object * (speculative=null)

which make `_type` to be

java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)

(which I'm not arguing with: it seems correct at that point).

Then, some incremental inlining happen, the types of inputs change to

in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
in(2): java/lang/Object * (speculative=null)

(`MyValue3` is replaced by `MyValue2` in the type of `in(1)`) and from this point, we run `PhiNode::Value` (since indeed, the input changed) with the previously computed `_type` involving `MyValue3`.

In this invocation of `Value` (the last non-verification invocation), we compute `(typeof(in(1)) / typeof(in(2))) /\ _type` which gives `java/lang/Object *` (dropping the speculative type). This type becomes the `_type` of the `PhiNode`.

After that, we do verification (so no change to the inputs anymore), and we re-call `PhiNode::Value`. We recompute `(typeof(in(1)) / typeof(in(2))) /\ _type` with this new `_type` and here we get

java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)

It's not the same as before, so it's a verification failure.

----

As, for why the meet of

in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
in(2): java/lang/Object * (speculative=null)

is

java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)

maybe there is a misunderstanding (that I had myself): null here means Java's null, not C++ nullptr. So, basically, the Phi is either null or a MyValue2 (possibly null). It seems natural that the (Hotspot's) meet is the same as `in(1)`, since `typeof(in(1)) < typeof(in(2))`. And I've double checked, this meet really happens, both Region's inputs are non-top. The lack of speculative type is displayed by simply omitting the "speculative=" part.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3487177477

From duke at openjdk.org  Tue Nov  4 17:25:15 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:25:15 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <E9lmQnCT7Nhf2s-atsMJCIlpU0hAWBV_1GpjVDl7R7Y=.9d1e26bb-7393-4c2d-b0ff-d24490dcf360@github.com>

On Tue, 4 Nov 2025 17:08:45 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 1:

> 1: /*

Extra benchmarks for preview mode.
Sorry for the monster diff, it's just indentation from moving the big list into a nested class (the benchmarks want both "list of names" and "list of module/path pairs", so easier to manage generating both statically with a nested class).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2491420747

From duke at openjdk.org  Tue Nov  4 17:33:52 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:33:52 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
Message-ID: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>

Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.

There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).

To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

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

Depends on: https://git.openjdk.org/valhalla/pull/1718

Commit messages:
 - Rollup of makefile change and jlink fix (temp).
 - [[AUTOMATIC FORMATTING]]
 - fixing tests after refactoring
 - Fixing up after dependent PR changes
 - feedback and remove unused code
 - [[AUTOMATIC FORMATTING]]
 - new tests for ImageLocation
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - Remove TODOs now jimage version is bumped
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/a6d6cb8b...14f2a490

Changes: https://git.openjdk.org/valhalla/pull/1719/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1719&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368475
  Stats: 3595 lines in 39 files changed: 1306 ins; 391 del; 1898 mod
  Patch: https://git.openjdk.org/valhalla/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1719/head:pull/1719

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

From duke at openjdk.org  Tue Nov  4 17:38:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:38:50 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v2]
In-Reply-To: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
Message-ID: <Yon7rqyNBuEZLECPGkT0sQxtooZmULOLz1KswLKgoag=.2888e6ec-d5ed-4137-8c59-b3a9d21ef995@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

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

 - Merge branch 'jdk_8368467_reader/squashed' into jdk_8368475_makefile/squashed
 - Rollup of makefile change and jlink fix (temp).
   
   * likely test fix
   * Copy value classes into preview directories for inclusion in jimage
 - [[AUTOMATIC FORMATTING]]
 - fixing tests after refactoring
 - Fixing up after dependent PR changes
 - feedback and remove unused code
 - [[AUTOMATIC FORMATTING]]
 - new tests for ImageLocation
 - Restoring lost changes and updating some comments.
 - add system property guard to preview mode
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/1cc77d40...747b24d0

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

Changes: https://git.openjdk.org/valhalla/pull/1719/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1719&range=01
  Stats: 1543 lines in 28 files changed: 414 ins; 236 del; 893 mod
  Patch: https://git.openjdk.org/valhalla/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1719/head:pull/1719

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

From duke at openjdk.org  Tue Nov  4 17:42:24 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 17:42:24 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
Message-ID: <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Rollup of makefile changes and jlink fix (temp).
  
  * likely test fix
  * Copy value classes into preview directories for inclusion in jimage

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1719/files
  - new: https://git.openjdk.org/valhalla/pull/1719/files/747b24d0..3b7c8cc3

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

  Stats: 794 lines in 18 files changed: 3 ins; 27 del; 764 mod
  Patch: https://git.openjdk.org/valhalla/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1719/head:pull/1719

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

From duke at openjdk.org  Tue Nov  4 18:00:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 18:00:32 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
 <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
Message-ID: <FZnn3zopZL2b7SGHvEzLnLlddSKoPSqbIciOyNUYTJw=.6b525815-1eaf-4e2b-a64a-69616f8556cb@github.com>

On Tue, 4 Nov 2025 17:42:24 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Rollup of makefile changes and jlink fix (temp).
>   
>   * likely test fix
>   * Copy value classes into preview directories for inclusion in jimage

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java line 88:

> 86:         }
> 87: 
> 88:         /**

I'm not 100% sure why this method didn't exist before. This whole base class is a bit of a mystery really since some of its fields are only used by some subclasses and others by others. Feels like it would be just as good to make it an interface for all the value it has (and the lack of docs about what the fields actually do/are doesn't help).

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 576:

> 574:     }
> 575: 
> 576:     /**

Unused now. There was once use of 'toPackage()' but that went away.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 197:

> 195:                                          .filter(rd -> rd.getKind() == ResourceDiff.Kind.REMOVED)
> 196:                                          .map(s -> {
> 197:                                                  int secondSlash = s.getName().indexOf("/", 1);

No need for any string munging now because the new API uses the same "full entry name" value everywhere.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 447:

> 445:                     @Override
> 446:                     public long size() {
> 447:                         return archive.imageResources.sizeOf(path());

*if* we didn't want a new 'path()' method in Entry, I could always capture 'resPath' here from the record, but using the actual value in the base class makes the Entry more self contained and avoid it being a hybrid of both "values from the base class" and "values from the outer class", which is just confusing.

Alternatively, make Entry an interface and just capture what's needed for each implementation (since you much have that available when Entry is made).

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 456:

> 454:                 public long size() {
> 455:                     try {
> 456:                         if (resType != EntryType.CLASS_OR_RESOURCE) {

Having all this complexity inside the provided methods was never necessary. There are 3 types of behaviour to support, and each entry is always just 1 of them, determined by data available when it's constructed.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 352:

> 350: 
> 351:         // First create the image provider
> 352:         try (ImageHelper imageProvider =

Wrap in a try-with-resources because this is where Archive lifetimes are bounded (by the ImageHelper instance).
Right now it's not doing much to improve things (Archive.close() is actually being called now to free a few things, but the resource entry API isn't closed because it's a singleton.
However, eventually, ImageHelper is likely the proper owner for a non-singleton resource API.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java line 154:

> 152:          *     if no name could be inferred.
> 153:          */
> 154:         private static Optional<String> inferPackageName(ResourcePoolEntry res) {

This change is related to the need to reflect preview-only packages in the modules list.
It's different to the resource entry stuff however, but also needed. I'll figure out what PR this really goes in later.

test/jdk/tools/jlink/ResourcePoolTest.java line 166:

> 164:         Optional<ResourcePoolModule> modBase = manager.moduleView().findModule("java.base");
> 165:         assertTrue(modBase.isPresent());
> 166:         // Preview only package is included, and no packages start with 'META-INF'.

Test for the behaviour implemented in ResourcePoolManager.

test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java line 148:

> 146:     }
> 147: 
> 148:     // Helper to assert the content of two jimage files are the same and provide

Having the test fail with a one line error and no information was a bad experience, so I made it actually report the difference clearly. Seems worth submitting this.

test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java line 189:

> 187:     }
> 188: 
> 189:     private static boolean isTreeInfoResource(String path) {

This logic is used repeatedly around the modules code, and it's wrong.
You must account for paths starting `/modulesfoo/...` existing and *not* being an "info resource".

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491503992
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491506972
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491512106
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491535167
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491540963
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491551206
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491560803
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491565398
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491569432
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2491573889

From fparain at openjdk.org  Tue Nov  4 19:00:53 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Nov 2025 19:00:53 GMT
Subject: [lworld] RFR: 8370450: [lworld] Alternate implementation of the
 substitutability test method [v9]
In-Reply-To: <5Zm3hPNPyak7LdSIG-JPAxbGn-HXtQNKuVCz0iPWEGA=.955c111b-1b8e-4f5a-bbc5-d12d94f760f5@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
 <5Zm3hPNPyak7LdSIG-JPAxbGn-HXtQNKuVCz0iPWEGA=.955c111b-1b8e-4f5a-bbc5-d12d94f760f5@github.com>
Message-ID: <joQTlN0ehZhffm8V_0q15BHnit2CHfYjx6onrIg-GUI=.768d337a-d84a-4de3-899e-899d40da4f12@github.com>

On Tue, 4 Nov 2025 13:50:11 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> This is an alternate version of the substitutability method.
>> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.
>
> Frederic Parain has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Fix behavior when alt method is not used
>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>  - Field to field map must be final
>  - Add comment
>  - Add comment
>  - Remove useless check
>  - More fixes uggested in reviews
>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>  - Apply changes suggested in review
>  - Merge remote-tracking branch 'upstream/lworld' into new_acmp
>  - ... and 1 more: https://git.openjdk.org/valhalla/compare/0ff86987...899f4800

Coleen, Chen,
Thank you for your reviews and your feedback.

Fred

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

PR Comment: https://git.openjdk.org/valhalla/pull/1695#issuecomment-3487589240

From fparain at openjdk.org  Tue Nov  4 19:00:54 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Nov 2025 19:00:54 GMT
Subject: [lworld] Integrated: 8370450: [lworld] Alternate implementation of the
 substitutability test method
In-Reply-To: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
References: <FrFP3hc0lqUedQhx4OI-uEvZ7-AyQQ2JCydZiHYrjtw=.c3c94c30-4144-4504-9788-1a3deefdb6ea@github.com>
Message-ID: <4ZlmRd-JPzVEDTI4HQLooTNXRDxKOl2jRNyve1StdYA=.4336f3c7-90ed-42ee-a02c-c631e5008c3f@github.com>

On Wed, 22 Oct 2025 17:54:29 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> This is an alternate version of the substitutability method.
> To use it, add -Xshare:off -XX:+UseAltSubstitutabilityMethod to the command line of the Valhalla VM in preview mode.

This pull request has now been integrated.

Changeset: 047e2327
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/047e2327071e7f5a78f09f3a19980df2a82c00ba
Stats:     351 lines in 19 files changed: 346 ins; 0 del; 5 mod

8370450: [lworld] Alternate implementation of the substitutability test method

Reviewed-by: coleenp, liach

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

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

From qamai at openjdk.org  Tue Nov  4 19:56:17 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Nov 2025 19:56:17 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
Message-ID: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>

Hi,

Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.

We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.

C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.

Please take a look and leave your reviews, thanks a lot.

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

Commit messages:
 - typo
 - add support for unnatural nullable atomic layout

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

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

From forax at openjdk.org  Tue Nov  4 20:32:12 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 4 Nov 2025 20:32:12 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
In-Reply-To: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
Message-ID: <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>

On Tue, 4 Nov 2025 19:50:25 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
> 
> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
> 
> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
> 
> Please take a look and leave your reviews, thanks a lot.

Hello,
I do not fully understand why you care about GCs given that the 64bits payload of the value type can not be a pointer or contains a pointer ?
I'm sure i'm missing something :)

Also I suppose that at some point this patch (or a following one) will change the VarHandle implementation (or Unsafe ?), because currently the read/write through a VarHandle will not have the required the memory barriers.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3487903736

From qamai at openjdk.org  Tue Nov  4 21:00:32 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 4 Nov 2025 21:00:32 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
In-Reply-To: <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
Message-ID: <20fzSPeTCAEy47QccETAmCy4xGSEgCVd_v5T8_VYyWU=.a00188ff-17cc-41e2-9225-385167cfefbd@github.com>

On Tue, 4 Nov 2025 20:30:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
>> 
>> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
>> 
>> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Hello,
> I do not fully understand why you care about GCs given that the 64bits payload of the value type can not be a pointer or contains a pointer ?
> I'm sure i'm missing something :)
> 
> Also I suppose that at some point this patch (or a following one) will change the VarHandle implementation (or Unsafe ?), because currently the read/write through a VarHandle will not have the required the memory barriers.

@forax Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.

For your second point, `Unsafe::putFlatValue` and `Unsafe::getFlatValue` will call into `InlineKlass::write_value_to_addr` and `InlineKlass::read_payload_from_addr`, respectively, which are covered by this patch. `j.l.i.VarHandleNonAtomicFlatValues`, in turns, calls `Unsafe::getFlatValue` for the `get` method and `Unsafe::putFlatValue` for the set method. So, I believe they are also fine.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3487987382

From duke at openjdk.org  Tue Nov  4 23:41:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 23:41:50 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API
Message-ID: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>

Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.

Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 

I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

Depends on: https://git.openjdk.org/valhalla/pull/1718

Commit messages:
 - Make jlink use a new narrow API for raw jimage access

Changes: https://git.openjdk.org/valhalla/pull/1721/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1721&range=00
  Stats: 439 lines in 7 files changed: 273 ins; 86 del; 80 mod
  Patch: https://git.openjdk.org/valhalla/pull/1721.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1721/head:pull/1721

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

From duke at openjdk.org  Tue Nov  4 23:48:46 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 4 Nov 2025 23:48:46 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v2]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <OKRLH2oIw__LYzG2iBoLwPTKTyb1IxPjH-CkjxrCuvY=.b2902739-580c-4b8a-809a-320c8b60570e@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

  Remove redundant extra method (part of original prototype)

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/3fcfea64..a433f096

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

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

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

From duke at openjdk.org  Wed Nov  5 00:11:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 00:11:40 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v2]
In-Reply-To: <OKRLH2oIw__LYzG2iBoLwPTKTyb1IxPjH-CkjxrCuvY=.b2902739-580c-4b8a-809a-320c8b60570e@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <OKRLH2oIw__LYzG2iBoLwPTKTyb1IxPjH-CkjxrCuvY=.b2902739-580c-4b8a-809a-320c8b60570e@github.com>
Message-ID: <UBZHH0zGlvSQHhjwI2QTCC2VPvgZJoc40N4iLBfbA5Q=.7cbee96e-2f11-4337-8a58-abcf325f79bb@github.com>

On Tue, 4 Nov 2025 23:48:46 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant extra method (part of original prototype)

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 343:

> 341:      */
> 342:     // Package visible for use by ImageReader.
> 343:     ResourceEntries getResourceEntries() {

This is the implementation of the new, narrow, API. That's it.

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 353:

> 351:                         .map(offsets::get)
> 352:                         .filter(offset -> offset != 0)
> 353:                         // Reusing a location instance or getting the module

It's important to put the filtering as early as possible since callers are going to enumerate ~30,000 entries to get back maybe 50 entry names in a module.
We DO NOT want to sort here, because the caller might (and does) do more filtering before getting the final set.
If there's any performance issues (which I doubt given that this is build-time stuff) there are ways to reduce the number of ImageLocation instances being churned.

src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 242:

> 240:      * obtained is closed.
> 241:      */
> 242:     public ResourceEntries getResourceEntries() {

This is just exposing the [Shared]ImageReader API out via [System]ImageReader.

I'll probably move this to be package protected here and only publicly available via a static method in SystemImage, which really tightens its use to the one use case we have for it right now.

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 20:

> 18:  * or packages (i.e. {@code "/packages/..."}.
> 19:  */
> 20: public interface ResourceEntries {

This is an API so that we can avoid using ImageReader directly in the jlink code.
ImageReader is not conceptually the right API for this, and in future we might want to decouple things even more so it's clear that ImageReader is for inspection of resource in a runtime, and something else is there to read the jimage contents directly.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java line 38:

> 36:  * other, for a module.
> 37:  */
> 38: public interface Archive extends Closeable {

Archives have a close() method and nobody was ever calling it.
Seems good to try and address that a bit.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java line 89:

> 87: 
> 88:         /**
> 89:          * Returns the path of this entry.

Don't know why this wasn't a method before, and if there's a conceptual issue with it being as method, I can work around it, but this is cleaner.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 179:

> 177:             // Add classes/resources from the run-time image,
> 178:             // patched with the run-time image diff
> 179:             imageResources.entryNamesIn(module)

No more mucking about with String.format() here since the APIs are better aligned and everything is using the full entry name.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 305:

> 303: 
> 304:         /**
> 305:          *  line: {@code <int>|<int>|<hashOrTarget>|<path>}

Tidying bad HTML JavaDoc in passing since it renders terribly in an IDE.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 418:

> 416:     }
> 417: 
> 418:     record JrtModuleFile(

There are really two dinstinct types of files here; those inside a module, and those read from the "root" namespace. And for module files, there are two cases; those defined by a "diff" and those read from the jimage.

The old code mushed all of this together so that the size() and stream() methods make runtime checks to decide what to do each time they're called, despite the role being fixed when they are created. It also used a single record with the union of all necessary parameters in it.

The new code split each case into its own, very simple, class with any decisions about the role being made before its created. The code has less duplication of checks and is simpler to reason about.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 433:

> 431:                 assert diff.getName().equals(resPath);
> 432: 
> 433:                 return new Entry(archive, resPath, resName, EntryType.CLASS_OR_RESOURCE) {

The returned Entry instances are now free of if-statements and each does exactly one well defined job that's easy to see at a glance.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 456:

> 454:                 public long size() {
> 455:                     try {
> 456:                         if (resType != EntryType.CLASS_OR_RESOURCE) {

The checks are asserts are needlessly duplicated in both size() and stream() methods.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 478:

> 476:             return new Entry(
> 477:                     archive,
> 478:                     String.format("/%s/%s", archive.moduleName(), resPath),

The problem with the Entry parent class is that it demands a "path", even for cases where none make sense (or at least where the path and name are really the same). This munging of the path to have the module name at the front is what the old code did too, but it really serves no purpose since the path isn't used for this entry.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 352:

> 350: 
> 351:         // First create the image provider
> 352:         try (ImageHelper imageProvider =

ImageHelper holds Archive instances, which should be closed, so putting this in a try-with-resources seems better than what was there.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 1058:

> 1056:         public void close() throws IOException {
> 1057:             for (Archive archive : archives) {
> 1058:                 archive.close();

I could put each close in a try/catch if we were worried about close() actually failing here.

test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java line 148:

> 146:     }
> 147: 
> 148:     // Helper to assert the content of two jimage files are the same and provide

This is an optional (but nice) improvement to how the test reported mismatched lists of entries.
Without it, the test just fails with no useful output.
If anyone knows a neater way (e.g. some set difference methods) then I'll happily neaten this up.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492341607
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492347237
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492352870
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492355482
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492356659
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492357728
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492359299
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492360202
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492368103
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492361952
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492371879
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492370888
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492373080
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492374175
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492376185

From duke at openjdk.org  Wed Nov  5 02:08:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 02:08:45 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v3]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <BgYbBXYPpyKIEdgpbEpPjS68ZvIfdnxjMjdswFuTVGc=.feb008ef-a0dc-4abd-aa5d-1afc22a3f22a@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

  Tighted access to new API and undo new path() method.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/a433f096..67984e27

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

  Stats: 28 lines in 4 files changed: 10 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1721.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1721/head:pull/1721

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

From duke at openjdk.org  Wed Nov  5 02:08:47 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 02:08:47 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v3]
In-Reply-To: <BgYbBXYPpyKIEdgpbEpPjS68ZvIfdnxjMjdswFuTVGc=.feb008ef-a0dc-4abd-aa5d-1afc22a3f22a@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <BgYbBXYPpyKIEdgpbEpPjS68ZvIfdnxjMjdswFuTVGc=.feb008ef-a0dc-4abd-aa5d-1afc22a3f22a@github.com>
Message-ID: <iuOtd5wGgFw80dV6cPAp0Gx-bintOhCCk8jw9Gmgcuk=.e71e640d-a69b-44d6-840d-f414fdbd10c4@github.com>

On Wed, 5 Nov 2025 02:05:46 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighted access to new API and undo new path() method.

src/java.base/share/classes/jdk/internal/jimage/SystemImageReader.java line 76:

> 74:     }
> 75: 
> 76:     /**

I moved the public method to SystemImageReader, since that's the only use-case we have for it at the moment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492576433

From duke at openjdk.org  Wed Nov  5 02:12:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 02:12:04 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v3]
In-Reply-To: <BgYbBXYPpyKIEdgpbEpPjS68ZvIfdnxjMjdswFuTVGc=.feb008ef-a0dc-4abd-aa5d-1afc22a3f22a@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <BgYbBXYPpyKIEdgpbEpPjS68ZvIfdnxjMjdswFuTVGc=.feb008ef-a0dc-4abd-aa5d-1afc22a3f22a@github.com>
Message-ID: <G_74_AlvS-PhuxyhRMUkDQR3TIAmRugeBj1TlVfFLQE=.8d0ebdec-f3cc-459a-9d82-c54ab7525b56@github.com>

On Wed, 5 Nov 2025 02:08:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighted access to new API and undo new path() method.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java line 66:

> 64:          *
> 65:          * @param archive the archive in which this entry exists.
> 66:          * @param path the complete path of the entry, including the module.

Note that now I removed the path() method I added, the path passed here serves absolutely no purpose other than to appear in the toString() output. I'd vote for removing it completely and simplifying callers.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2492581696

From qamai at openjdk.org  Wed Nov  5 02:45:11 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 5 Nov 2025 02:45:11 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long [v2]
In-Reply-To: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
Message-ID: <gSYJ1VkzmMsT8iiL4DiLmlsGYVHXSVCwYL6v4v1nxOA=.820a5434-1b22-429c-850a-eb318e32884e@github.com>

> Hi,
> 
> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
> 
> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
> 
> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
> 
> Please take a look and leave your reviews, thanks a lot.

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

  add Unsafe and VarHandle tests

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1720/files
  - new: https://git.openjdk.org/valhalla/pull/1720/files/de358f1a..542c2fd8

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

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

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

From qamai at openjdk.org  Wed Nov  5 04:20:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 5 Nov 2025 04:20:06 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long [v3]
In-Reply-To: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
Message-ID: <IIMC7zyR4lT5FoBPd5XGFuqQylvmSBJS_EN3bzQgcmc=.03a93469-d815-485a-894b-a7b80a0189e5@github.com>

> Hi,
> 
> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
> 
> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
> 
> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
> 
> Please take a look and leave your reviews, thanks a lot.

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

  dead code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1720/files
  - new: https://git.openjdk.org/valhalla/pull/1720/files/542c2fd8..e80107b7

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

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

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

From qamai at openjdk.org  Wed Nov  5 04:25:55 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 5 Nov 2025 04:25:55 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long [v4]
In-Reply-To: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
Message-ID: <EQkdR7gABlfo0WeaPc9-apoD1p_yKmc1KMXqL4BdLwc=.7c483e3f-baa8-46f0-913b-5e7cb518278b@github.com>

> Hi,
> 
> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
> 
> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
> 
> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
> 
> Please take a look and leave your reviews, thanks a lot.

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

  missing barrier

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1720/files
  - new: https://git.openjdk.org/valhalla/pull/1720/files/e80107b7..217c3670

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

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

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

From hgreule at openjdk.org  Wed Nov  5 07:33:39 2025
From: hgreule at openjdk.org (Hannes Greule)
Date: Wed, 5 Nov 2025 07:33:39 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
In-Reply-To: <20fzSPeTCAEy47QccETAmCy4xGSEgCVd_v5T8_VYyWU=.a00188ff-17cc-41e2-9225-385167cfefbd@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
 <20fzSPeTCAEy47QccETAmCy4xGSEgCVd_v5T8_VYyWU=.a00188ff-17cc-41e2-9225-385167cfefbd@github.com>
Message-ID: <-ipD8MAdZzoJaxMAm7u5vL75p-yPYXBq1yes088ztN0=.e70e699a-b18e-4d4d-9847-4ba7c057022f@github.com>

On Tue, 4 Nov 2025 20:57:29 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.

I don't know how this is currently implemented in the GC, but wouldn't it make sense for the GC to check whether the value is marked as null first, and ignore the rest of the value in that case?

Especially for ZGC flattening currently doesn't happen even for `value record(String name)` from my understanding (and more generally, with compressed oops disabled?), this might be beneficial. I don't know how this interacts with GC barriers, there is most likely more to it than I know of :)

That said, restricting to payloads without oops makes this change easier to reason about, so - assuming it makes sense - extending to payloads with oops as a follow-up might be better.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3489739462

From phubner at openjdk.org  Wed Nov  5 09:17:54 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 5 Nov 2025 09:17:54 GMT
Subject: [lworld] RFR: 8370479: [lworld] OOP-related crashes via mvn
 surefire
In-Reply-To: <gB7C57e_1akanJVPFD2n_euUuy0LCzQTaEUpzcnKoSw=.4836057d-4e42-4000-a0e0-66e5035fd9be@github.com>
References: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
 <gB7C57e_1akanJVPFD2n_euUuy0LCzQTaEUpzcnKoSw=.4836057d-4e42-4000-a0e0-66e5035fd9be@github.com>
Message-ID: <iHM21IHnAqjKQKo4ivToQbJVY55jQiGIMt_CP07f8GI=.a49c872d-c3d4-4bc7-9ebc-4691d6b40839@github.com>

On Tue, 4 Nov 2025 12:46:10 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.
>> 
>> ## Context
>> 
>> If we consider a value class/record that contains a single field, which is a reference to an identity object:
>> 
>> public static value record Element(Identity underlying) {}
>> public static class Identity {}
>> 
>> We can create a flattened array via the JDK-internal `ValueClass` API:
>> 
>> Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);
>> 
>> This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  
>> 
>> When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.
>> 
>> ## New Barrier Emission
>> 
>> We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 
>> 
>> **Old G1 barrier emission during flat array copying:**
>> |  | oopless | contains oops |
>> | --- | --- | --- |
>> | uninitialized | | |
>> | initialized | | pre, post |
>> 
>> **New G1 barrier emission during flat array copying:**
>> | | oopless | contains oops |
>> | --- | --- | --- |
>> | uninitialized | | post |
>> | initialized | | pre, post |
>> 
>> As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.
>> 
>> ## New Test Cases
>> 
>> I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.
>> 
>> ## Fixed Oop Printing
>> 
>> When G1 verification fails, it tries to p...
>
> Good catch on the memory barrier!
> LGTM.

Thanks for your reviews @fparain @coleenp!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1713#issuecomment-3490081685

From duke at openjdk.org  Wed Nov  5 09:17:55 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 09:17:55 GMT
Subject: [lworld] RFR: 8370479: [lworld] OOP-related crashes via mvn
 surefire
In-Reply-To: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
References: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
Message-ID: <i4ctLZ1T1ztvLZVlMU8wgvVRSr1QMjbW4mJC3H3oKOM=.442f4f39-1b32-4c0c-8c00-b3030cc8050a@github.com>

On Mon, 3 Nov 2025 13:00:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.
> 
> ## Context
> 
> If we consider a value class/record that contains a single field, which is a reference to an identity object:
> 
> public static value record Element(Identity underlying) {}
> public static class Identity {}
> 
> We can create a flattened array via the JDK-internal `ValueClass` API:
> 
> Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);
> 
> This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  
> 
> When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.
> 
> ## New Barrier Emission
> 
> We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 
> 
> **Old G1 barrier emission during flat array copying:**
> |  | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | |
> | initialized | | pre, post |
> 
> **New G1 barrier emission during flat array copying:**
> | | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | post |
> | initialized | | pre, post |
> 
> As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.
> 
> ## New Test Cases
> 
> I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.
> 
> ## Fixed Oop Printing
> 
> When G1 verification fails, it tries to print diagnostic information. This will eventually end up printing oops. We handle the ca...

@Arraying 
Your change (at version 18472fd274267d167635ddf89cb0b5d118086efb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1713#issuecomment-3490084351

From phubner at openjdk.org  Wed Nov  5 09:22:11 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 5 Nov 2025 09:22:11 GMT
Subject: [lworld] Integrated: 8370479: [lworld] OOP-related crashes via mvn
 surefire
In-Reply-To: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
References: <MCHrn9vuYDp7IE0vylreW26NupcC-FiEZ0_wYWsTI6g=.a068c142-2166-4886-b9cf-16da0b264644@github.com>
Message-ID: <vYFl98qS1nn26kJbIde8UdYWx_KEOsaX75dJCfqVCnE=.9ff841b3-ac95-4e3d-9de8-286b747918c1@github.com>

On Mon, 3 Nov 2025 13:00:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This PR fixes [JDK-8370479](https://bugs.openjdk.org/browse/JDK-8370479), as we currently don't emit barriers correctly. Tested tiers 1-3.
> 
> ## Context
> 
> If we consider a value class/record that contains a single field, which is a reference to an identity object:
> 
> public static value record Element(Identity underlying) {}
> public static class Identity {}
> 
> We can create a flattened array via the JDK-internal `ValueClass` API:
> 
> Object[] array = ValueClass.newNullableAtomicArray(Element.class, 16);
> 
> This will indeed be flattened when running with compressed oops. T the reference to `underlying` will be four bytes, and the null-marker an additional byte. Hence, we are below the 64-bit limit. Copying this array via `Arrays.copyOf` will trigger Valhalla-specific copying.  
> 
> When running with G1, there are various crashes and verification errors. This should not impact ZGC, as the pointers are too large to be flattened in a nullable array.
> 
> ## New Barrier Emission
> 
> We do not emit a post-write barrier when copying to an uninitialized memory destination. The tables below summarize what barriers, if any, are emitted both in the old and new versions of the copy implementation. Note that Serial, Parallel and G1 have the notion of post-write barriers to track intergenerational references. G1 is the only GC requiring pre-write barriers. 
> 
> **Old G1 barrier emission during flat array copying:**
> |  | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | |
> | initialized | | pre, post |
> 
> **New G1 barrier emission during flat array copying:**
> | | oopless | contains oops |
> | --- | --- | --- |
> | uninitialized | | post |
> | initialized | | pre, post |
> 
> As mentioned, when copying to uninitialized memory, a cross-generational could be "lost" due to the lack of a post-write barrier. We should *not* use a pre-write barrier when copying to uninitialized memory when running with G1. Doing so means we may get garbage in our SATB buffers.
> 
> ## New Test Cases
> 
> I introduce a test scenario where we grow a flat array similar to how one would grow an `ArrayList`. This should generate plenty of garbage, and triggers this crash even without the whitebox GC. I test the three GCs that use `ModRefBarrierSet`: Serial, Parallel and G1. These are tweaked to be less concurrent/parallel to aid with reproducability in case of crashes.
> 
> ## Fixed Oop Printing
> 
> When G1 verification fails, it tries to print diagnostic information. This will eventually end up printing oops. We handle the ca...

This pull request has now been integrated.

Changeset: 6f5c72ec
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6f5c72ecd048ca9d980248a2f4af87eab0a9b996
Stats:     131 lines in 5 files changed: 128 ins; 0 del; 3 mod

8370479: [lworld] OOP-related crashes via mvn surefire

Reviewed-by: fparain, coleenp

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

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

From phubner at openjdk.org  Wed Nov  5 10:05:35 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 5 Nov 2025 10:05:35 GMT
Subject: [lworld] Integrated: 8371318: [lworld] Bump copyright after
 JDK-8370479
In-Reply-To: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>
References: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>
Message-ID: <LeV40OJ6MvGAfZPvv5xrCh2WJTE3JhDf2w6CQiINNK0=.0cda7a7f-f4d8-4f24-8c81-4b50dfc99955@github.com>

On Wed, 5 Nov 2025 09:31:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> This is a trivial follow-up fix.
> 
> Sanity tested with `hotspot_valhalla`.

This pull request has now been integrated.

Changeset: 1cb01022
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1cb010221d0df2d05273c412b385a26a5978f477
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8371318: [lworld] Bump copyright after JDK-8370479

Reviewed-by: dsimms

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

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

From dsimms at openjdk.org  Wed Nov  5 10:05:32 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 5 Nov 2025 10:05:32 GMT
Subject: [lworld] Integrated: 8371318: [lworld] Bump copyright after
 JDK-8370479
In-Reply-To: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>
References: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>
Message-ID: <KLBer2-ui-LYzLxSBwsEzVAU2_3tTtwLHE5vZD2kE9A=.81f72fc8-c225-4d1a-9f02-5c7bf96e4bae@github.com>

On Wed, 5 Nov 2025 09:31:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> This is a trivial follow-up fix.
> 
> Sanity tested with `hotspot_valhalla`.

Marked as reviewed by dsimms (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1722#pullrequestreview-3420967221

From phubner at openjdk.org  Wed Nov  5 10:05:33 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 5 Nov 2025 10:05:33 GMT
Subject: [lworld] Integrated: 8371318: [lworld] Bump copyright after
 JDK-8370479
In-Reply-To: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>
References: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>
Message-ID: <L4sKq5JKdfOZORM07va82nk8jhY_JNhPhkG9YXq6Xc8=.e89b11e8-efb2-4014-801d-019d0d22da60@github.com>

On Wed, 5 Nov 2025 09:31:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> This is a trivial follow-up fix.
> 
> Sanity tested with `hotspot_valhalla`.

Thanks.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1722#issuecomment-3490271242

From phubner at openjdk.org  Wed Nov  5 10:05:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 5 Nov 2025 10:05:32 GMT
Subject: [lworld] Integrated: 8371318: [lworld] Bump copyright after
 JDK-8370479
Message-ID: <K62KqBd9sMDToMIFDUoDdE70BixsPqHrQnAKCqrYI7w=.0eaee0e6-2a30-4016-b5b1-e07cd5fe0189@github.com>

This is a trivial follow-up fix.

Sanity tested with `hotspot_valhalla`.

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

Commit messages:
 - Update copyright.

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

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

From roland at openjdk.org  Wed Nov  5 12:23:02 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Wed, 5 Nov 2025 12:23:02 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <HLFrWcjmv2vt3EALCq73u0e_2q6-TsxNd8b6z8JojrY=.b30a868e-e1cb-4b51-84cf-a45f751ddb56@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

[TestSpeculativeTypes.java](https://github.com/user-attachments/files/23359519/TestSpeculativeTypes.java)

Attached test case fails with "Missed optimization opportunity in PhaseIterGVN" as well (with mainline, nothing valhalla specific here). I run it with:

$ java -XX:-TieredCompilation -XX:-UseOnStackReplacement -XX:-BackgroundCompilation -XX:+PrintCompilation -XX:CompileOnly=TestSpeculativeTypes::test1 -XX:CompileCommand=quiet -XX:TypeProfileLevel=222 -XX:+AlwaysIncrementalInline -XX:VerifyIterativeGVN=10 -XX:CompileCommand=dontinline,TestSpeculativeTypes::notInlined1 TestSpeculativeTypes


Can you confirm it's indeed the same issue?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3490913594

From duke at openjdk.org  Wed Nov  5 13:08:19 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 13:08:19 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v4]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <-PGfXIIzLxMAxBL5nAeewKPkExgvAEaE-rICC7tC02o=.df688cdf-f9ac-4b8f-addc-7089781dbd49@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

  Added copyright notice and tidied a couple of comments.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/67984e27..a2f0c0c9

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

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

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

From duke at openjdk.org  Wed Nov  5 13:13:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 13:13:45 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v4]
In-Reply-To: <-PGfXIIzLxMAxBL5nAeewKPkExgvAEaE-rICC7tC02o=.df688cdf-f9ac-4b8f-addc-7089781dbd49@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <-PGfXIIzLxMAxBL5nAeewKPkExgvAEaE-rICC7tC02o=.df688cdf-f9ac-4b8f-addc-7089781dbd49@github.com>
Message-ID: <eRSvmZtrYhASPgytsAll7K6paj_JtBJNn7rg-hokQj0=.2c924b26-cf18-4072-800a-58ea8f67ef2e@github.com>

On Wed, 5 Nov 2025 13:08:19 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added copyright notice and tidied a couple of comments.

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 1:

> 1: /*

This is a copy of the notice in BasicImageReader, so I assume the clause about the GPL is correct.
Please let me know if not.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2494414833

From rriggs at openjdk.org  Wed Nov  5 13:54:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Nov 2025 13:54:54 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <O6JP3yO9sWduWlpvzt6rHLeHCZezdOSZ5K91jATDICw=.41dd0295-0597-4448-8d63-ceabfb5b8b5f@github.com>

On Tue, 4 Nov 2025 17:08:45 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 89:

> 87:         }
> 88:     }
> 89:     ;

Extra "'"

src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 95:

> 93:     // will be always 'true' and this code, and all related dead-code can be removed.
> 94:     private static final boolean DISABLE_PREVIEW_PATCHING_DEFAULT = false;
> 95:     private static final boolean ENABLE_PREVIEW_MODE = Boolean.parseBoolean(

the naming is confusing: stick to the same sense as the system property; (Or change the system property)

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java line 204:

> 202:                 try {
> 203:                     processPath(fullPath, modulesRoot, packageToModules);
> 204:                 } catch (InvalidTreeException err) {

Exception varialble "err" is ambiguous with System.err used below.
"ex" is more conventional for exceptions.

test/jdk/tools/jlink/whitebox/ImageResourcesTreeTestDriver.java line 24:

> 22:  */
> 23: 
> 24: /*

Why is this separate from the test itself?

test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 318:

> 316:     }
> 317: 
> 318:     /// Note: This list is inherently a little fragile and may end up being more

Yes, this kind of test/benchmark will bit rot very fast.
The existing startup measurements are more stable and reflect actual startup times, not a simulation thereof.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2492033684
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2492038687
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2492084995
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2492060924
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2492057544

From duke at openjdk.org  Wed Nov  5 14:15:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 14:15:08 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v5]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <0Z0GWagr7CiINBZ_KQmm2cZkX_clxw-CiO6surKEkZI=.67e8f880-649e-4cfb-a8cd-37ffd53116b3@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

  Tidied up diff code in test.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/a2f0c0c9..fdcb73f7

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

  Stats: 30 lines in 2 files changed: 5 ins; 19 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1721.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1721/head:pull/1721

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

From duke at openjdk.org  Wed Nov  5 14:23:05 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 14:23:05 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v2]
In-Reply-To: <UBZHH0zGlvSQHhjwI2QTCC2VPvgZJoc40N4iLBfbA5Q=.7cbee96e-2f11-4337-8a58-abcf325f79bb@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <OKRLH2oIw__LYzG2iBoLwPTKTyb1IxPjH-CkjxrCuvY=.b2902739-580c-4b8a-809a-320c8b60570e@github.com>
 <UBZHH0zGlvSQHhjwI2QTCC2VPvgZJoc40N4iLBfbA5Q=.7cbee96e-2f11-4337-8a58-abcf325f79bb@github.com>
Message-ID: <ztztEwPwrk5_s0oCykifOX6InujGWGelPUOBcazsopE=.34024f97-76cd-483c-a166-ac8882fd19b5@github.com>

On Wed, 5 Nov 2025 00:08:05 GMT, David Beaumont <duke at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant extra method (part of original prototype)
>
> test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java line 148:
> 
>> 146:     }
>> 147: 
>> 148:     // Helper to assert the content of two jimage files are the same and provide
> 
> This is an optional (but nice) improvement to how the test reported mismatched lists of entries.
> Without it, the test just fails with no useful output.
> If anyone knows a neater way (e.g. some set difference methods) then I'll happily neaten this up.

I tidied it up (should have done this from the start).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2494721587

From duke at openjdk.org  Wed Nov  5 14:44:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 14:44:07 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode
In-Reply-To: <O6JP3yO9sWduWlpvzt6rHLeHCZezdOSZ5K91jATDICw=.41dd0295-0597-4448-8d63-ceabfb5b8b5f@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <O6JP3yO9sWduWlpvzt6rHLeHCZezdOSZ5K91jATDICw=.41dd0295-0597-4448-8d63-ceabfb5b8b5f@github.com>
Message-ID: <aKI8doML1Aqs7XpesSiq5knsMucBouL9K3MvObM8wLA=.e9676caa-aaad-448f-a94f-e56123fa5b1b@github.com>

On Tue, 4 Nov 2025 21:12:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> test/jdk/tools/jlink/whitebox/ImageResourcesTreeTestDriver.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: /*
> 
> Why is this separate from the test itself?

I don't understand the question.
This is needed because the test is a whitebox test and accesses package visible things.
Is that what you mean?

> test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java line 318:
> 
>> 316:     }
>> 317: 
>> 318:     /// Note: This list is inherently a little fragile and may end up being more
> 
> Yes, this kind of test/benchmark will bit rot very fast.
> The existing startup measurements are more stable and reflect actual startup times, not a simulation thereof.

Indeed. Mas talking to Michel yesterday and we were saying that, once this is in and the dust settles, it might be good to either convert this to an Aurora benchmark or just delete it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2494829885
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2494822167

From chagedorn at openjdk.org  Wed Nov  5 14:56:50 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 5 Nov 2025 14:56:50 GMT
Subject: [lworld] RFR: 8367244: [lworld] C2 compilation fails with assert
 "no node with a side effect"
In-Reply-To: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
References: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
Message-ID: <qZt7jydontf9YIKxLK14T0bJCBzb8zZe_gRSaZIpRhE=.9c3773cc-19fd-4eef-96cd-263ae746476c@github.com>

On Mon, 3 Nov 2025 14:12:55 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> ## Problem Analysis
> 
> The stress test `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`, which uses the `StressUnstableIfTrap` flag, failed intermittently with the assert "no node with a side effect" during C2 compilation. I tracked down the origin of the failure to the raw store of the unstable if trap stress counter that was missing a memory edge to the backedge phi and thus had no side effect in the loop, which lead to the aforementioned assert. During parsing, the missing memory edge gets discarded with as vestigial parsing state when `do_if()` ends up `stopped()`. However, the effect of the stress counter should still be wired back into the backedge since it will be incremented in the next iteration.
> 
> ## Patch Description
> 
> To prevent the stress counters memory state being lost to `PreserveJVMState`, I pass it to the caller over an out-parameter and `set_memory` with that node, similar to what is already done for control. This is only necessary for the two last invocation of `do_if()` in `do_acmp()` where they are actually allowed to trap. Further, this PR reenables `StressUnstableIfTrap` in `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`.
> 
> ## Testing
> 
> - [x] tier1,tier2,tier3 plus internal stress testing

Looks reasonable to me, thanks for fixing this!

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAcmpStressUnstableIf.java line 36:

> 34:  * @run main/othervm -Xbatch -XX:-TieredCompilation
> 35:  *                   -XX:CompileCommand=compileonly,compiler/valhalla/inlinetypes/TestAcmpStressUnstableIf.test
> 36:  *                   -XX:+UnlockDiagnosticVMOptions -XX:+StressUnstableIfTraps -XX:RepeatCompilation=100

Given that the test will be run over and over again, I think we can remove `RepeatCompilation` to improve test execution time.

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1716#pullrequestreview-3422589358
PR Review Comment: https://git.openjdk.org/valhalla/pull/1716#discussion_r2494886907

From duke at openjdk.org  Wed Nov  5 15:07:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 15:07:12 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v2]
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

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

  Minor feedback changes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1718/files
  - new: https://git.openjdk.org/valhalla/pull/1718/files/1cc77d40..e52692f1

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

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

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

From duke at openjdk.org  Wed Nov  5 15:21:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 15:21:00 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v2]
In-Reply-To: <O6JP3yO9sWduWlpvzt6rHLeHCZezdOSZ5K91jATDICw=.41dd0295-0597-4448-8d63-ceabfb5b8b5f@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <O6JP3yO9sWduWlpvzt6rHLeHCZezdOSZ5K91jATDICw=.41dd0295-0597-4448-8d63-ceabfb5b8b5f@github.com>
Message-ID: <3YqrDHQO_ok2n2Eu-0U5ehz3kejiB2OfrcH_QjKisQo=.db95b660-e699-47f9-87ad-3fd96ae59b37@github.com>

On Tue, 4 Nov 2025 21:02:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor feedback changes
>
> src/java.base/share/classes/jdk/internal/jimage/PreviewMode.java line 95:
> 
>> 93:     // will be always 'true' and this code, and all related dead-code can be removed.
>> 94:     private static final boolean DISABLE_PREVIEW_PATCHING_DEFAULT = false;
>> 95:     private static final boolean ENABLE_PREVIEW_MODE = Boolean.parseBoolean(
> 
> the naming is confusing: stick to the same sense as the system property; (Or change the system property)

Done. New snapshot uploaded.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2495021061

From rriggs at openjdk.org  Wed Nov  5 17:04:44 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Nov 2025 17:04:44 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v2]
In-Reply-To: <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>
Message-ID: <MD4IOtEtyvvonqbWPmrPHVOK8u39POTSe-J0kMIXMFY=.01a0294f-3a6e-45ba-853f-9a5f4a744acc@github.com>

On Wed, 5 Nov 2025 15:07:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor feedback changes

Changes requested by rriggs (Committer).

test/jdk/jdk/internal/jimage/ImageLocationTest.java line 92:

> 90:     public void getPackageFlags_noPreview() {
> 91:         List<ModuleReference> refs = List.of(
> 92:                 ModuleReference.forPackage("modfoo", false),

Rename the method in ModuleReference back to "forPackage".

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

PR Review: https://git.openjdk.org/valhalla/pull/1718#pullrequestreview-3423305568
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2495373320

From rriggs at openjdk.org  Wed Nov  5 17:12:47 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Nov 2025 17:12:47 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v2]
In-Reply-To: <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>
Message-ID: <UL3UtbgJxPZLOQ28c_4ToueSxRG5P7qJu51AUNaJdaI=.dca00d4c-581f-427d-8641-f8fa8c1ba3e3@github.com>

On Wed, 5 Nov 2025 15:07:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor feedback changes

Changes requested by rriggs (Committer).

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 251:

> 249: 
> 250:             // Preview version of classes either overwrite existing entries or are added to directories.
> 251:             assertEquals("Preview: com.foo.HasPreviewVersion", loader.loadAndGetToString("modfoo", "com.foo.HasPreviewVersion"));

This test fails:

[12:00:51.621] STARTED    ImageReaderTest::testPreviewResources_enabled 'testPreviewResources_enabled()'
org.opentest4j.AssertionFailedError: expected: <Preview: com.foo.HasPreviewVersion> but was: <Class: com.foo.HasPreviewVersion>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
	at ImageReaderTest.testPreviewResources_enabled(ImageReaderTest.java:251)

test/jdk/jdk/internal/jimage/ImageReaderTest.java line 310:

> 308:         try (ImageReader reader = ImageReader.open(image, PreviewMode.ENABLED)) {
> 309:             // In preview mode there is a new preview-only module visible.
> 310:             assertDirContents(reader, "/packages/com.bar", "modbar", "modgus");

This test fails, not clear if its the impl or the test.

org.opentest4j.AssertionFailedError: Unexpected child names in directory '/packages/com.bar' ==> expected: <[modbar, modgus]> but was: <[modbar]>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1156)
	at ImageReaderTest.assertDirContents(ImageReaderTest.java:362)
	at ImageReaderTest.testPreviewModeLinks_enabled(ImageReaderTest.java:310)

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

PR Review: https://git.openjdk.org/valhalla/pull/1718#pullrequestreview-3423380755
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2495429041
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2495425964

From dlsmith at openjdk.org  Wed Nov  5 17:40:20 2025
From: dlsmith at openjdk.org (Dan Smith)
Date: Wed, 5 Nov 2025 17:40:20 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long [v4]
In-Reply-To: <EQkdR7gABlfo0WeaPc9-apoD1p_yKmc1KMXqL4BdLwc=.7c483e3f-baa8-46f0-913b-5e7cb518278b@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <EQkdR7gABlfo0WeaPc9-apoD1p_yKmc1KMXqL4BdLwc=.7c483e3f-baa8-46f0-913b-5e7cb518278b@github.com>
Message-ID: <XyxEUb7cdCO7t18NvCyvL2PpMX3c5MdL00s4F7Kq3LQ=.ec76b7af-d8f3-4752-a77c-0bc9b341fe2e@github.com>

On Wed, 5 Nov 2025 04:25:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
>> 
>> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
>> 
>> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing barrier

FYI, we explored some ideas along these lines a couple of years ago. Ended up concluding that it was a dead end?I'd suggest discussing on valhalla-dev at openjdk.org if you'd like to understand what the concerns were.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3492524355

From forax at openjdk.org  Wed Nov  5 17:40:21 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 5 Nov 2025 17:40:21 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
In-Reply-To: <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
Message-ID: <ezfmyzbh8hLxNpq8bIMJL3nQ50m3Tkr0PhzT71KzoHM=.14f551b7-5c12-4176-8513-2f8ebff64016@github.com>

On Tue, 4 Nov 2025 20:30:02 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
>> 
>> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
>> 
>> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Hello,
> I do not fully understand why you care about GCs given that the 64bits payload of the value type can not be a pointer or contains a pointer ?
> I'm sure i'm missing something :)
> 
> Also I suppose that at some point this patch (or a following one) will change the VarHandle implementation (or Unsafe ?), because currently the read/write through a VarHandle will not have the required the memory barriers.

> @forax Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.
> 

yes, i get that.
Let me try to rephrase, what your are proposing in optimization that only work if the payload does not contains a pointer.
The pointer can be a 32bits or a 64 bits pointer, it makes no difference. So i've trouble to understand the code around
https://github.com/openjdk/valhalla/pull/1720/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aeaR1845
that behave differently depending on the GC.

> For your second point, `Unsafe::putFlatValue` and `Unsafe::getFlatValue` will call into `InlineKlass::write_value_to_addr` and `InlineKlass::read_payload_from_addr`, respectively, which are covered by this patch. `j.l.i.VarHandleNonAtomicFlatValues`, in turns, calls `Unsafe::getFlatValue` for the `get` method and `Unsafe::putFlatValue` for the set method. So, I believe they are also fine.

Okay, so i suppose it means that because this considered as non-atomic on the VarHandle side, something like a CAS operation is not supported.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3492527038

From duke at openjdk.org  Wed Nov  5 18:35:49 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 18:35:49 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

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

  Feedback and test fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1718/files
  - new: https://git.openjdk.org/valhalla/pull/1718/files/e52692f1..533e5aff

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

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

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

From duke at openjdk.org  Wed Nov  5 18:38:55 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 5 Nov 2025 18:38:55 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v2]
In-Reply-To: <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <gOtCp7_Uwrd_71FXx-zj2BtXHQqpsPIKsc2sUxuxFDU=.06f94b21-a5a7-4614-ae32-d4c4afafe957@github.com>
Message-ID: <Eh31JU-qLY8rpzNtbUcxC7PGfMUoaqg9uWXZWe24N48=.b9a7f1d6-ef3b-4389-ae88-72d40d604831@github.com>

On Wed, 5 Nov 2025 15:07:12 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor feedback changes

Sorry about the test failures, I'd left the DISABLE_PREVIEW_PATCHING system property in the wrong state. It should all work now. I fixed the method rename to `forPackageIn(<module>...)` because I strongly feel it's better than `forPackage(<module>...)`  which I think just leaves the reader wondering why a package name isn't passed here.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1718#issuecomment-3492751186

From qamai at openjdk.org  Wed Nov  5 18:59:51 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 5 Nov 2025 18:59:51 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
In-Reply-To: <ezfmyzbh8hLxNpq8bIMJL3nQ50m3Tkr0PhzT71KzoHM=.14f551b7-5c12-4176-8513-2f8ebff64016@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
 <ezfmyzbh8hLxNpq8bIMJL3nQ50m3Tkr0PhzT71KzoHM=.14f551b7-5c12-4176-8513-2f8ebff64016@github.com>
Message-ID: <XLMsu5DeM_qZ1f7-VPTu61jkzVWgIs-Hqf50gigkk80=.75968c6e-0f8b-4ec2-8460-6034efc1db21@github.com>

On Wed, 5 Nov 2025 17:37:58 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Hello,
>> I do not fully understand why you care about GCs given that the 64bits payload of the value type can not be a pointer or contains a pointer ?
>> I'm sure i'm missing something :)
>> 
>> Also I suppose that at some point this patch (or a following one) will change the VarHandle implementation (or Unsafe ?), because currently the read/write through a VarHandle will not have the required the memory barriers.
>
>> @forax Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.
>> 
> 
> yes, i get that.
> Let me try to rephrase, what your are proposing in optimization that only work if the payload does not contains a pointer.
> The pointer can be a 32bits or a 64 bits pointer, it makes no difference. So i've trouble to understand the code around
> https://github.com/openjdk/valhalla/pull/1720/files#diff-b0ea998b1ae6491c87dae54a2a70644f8e957e7f3522f780883d72fb29107aeaR1845
> that behave differently depending on the GC.
> 
>> For your second point, `Unsafe::putFlatValue` and `Unsafe::getFlatValue` will call into `InlineKlass::write_value_to_addr` and `InlineKlass::read_payload_from_addr`, respectively, which are covered by this patch. `j.l.i.VarHandleNonAtomicFlatValues`, in turns, calls `Unsafe::getFlatValue` for the `get` method and `Unsafe::putFlatValue` for the set method. So, I believe they are also fine.
> 
> Okay, so i suppose it means that because this considered as non-atomic on the VarHandle side, something like a CAS operation is not supported.

@forax That line is in the `else` branch, i.e. the branch in which we access the payload as a whole. The only change to that part in this PR is to indent it 2 spaces further.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3492838856

From anhmdq at gmail.com  Wed Nov  5 19:00:49 2025
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Thu, 6 Nov 2025 02:00:49 +0700
Subject: About flattening a nullable j.l.Long
Message-ID: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>

Hi,

Currently, I'm having a PR that allows flattening of a nullable value class
with a 64-bit payload [1]. Dan Smith told me that some ideas along these
lines were discussed a few years ago, and the consensus was that it was a
dead end. May I ask what the concerns were, and whether they are still
relevant now?

Thanks a lot,
Quan Anh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251106/3cf941aa/attachment.htm>

From fparain at openjdk.org  Wed Nov  5 20:30:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 5 Nov 2025 20:30:32 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats
In-Reply-To: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
Message-ID: <WhbXbQB0_3a62j7cxlEYwBlBA0L1Vhgp8kyV2YUq8L8=.0736fd32-7753-4503-bf31-4890b989cef7@github.com>

On Fri, 24 Oct 2025 00:57:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix re-implements flat object support in heap dumper.
> New approach does not require changes in .hprof format.
> Flat value objects are dumped as heap-allocated objects with generated ID.
> For heap-allocated objects the ID is their address (oop), they are always aligned.
> ID generator for flat objects uses unaligned values (so there is no conflicts with oops).
> 
> HeapDump test was reimplemented (it was disabled for a long time)
> Changes in hprof test lib were reverted (they are not needed anymore)
> 
> testing: tier1..4,hs-tier5-svc

src/hotspot/share/services/heapDumper.cpp line 1818:

> 1816: void JavaStackRefDumper::dump_java_stack_refs(StackValueCollection* values) {
> 1817:   for (int index = 0; index < values->size(); index++) {
> 1818:     // TODO: can it be T_FLAT_ELEMENT?

The BasicType T_FLAT_ELEMENT is used exclusively in the context of flat arrays: in the layout_helper of flat arrays, and in a few array methods like arrayOopDesc::base_offset_in_bytes().
T_FLAT_ELEMENT cannot be used to describe the type of a field, the type of the argument of a Java method or the type of a value on the stack.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2496036627

From fparain at openjdk.org  Wed Nov  5 20:59:33 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 5 Nov 2025 20:59:33 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats
In-Reply-To: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
Message-ID: <_Bk5YXkJfNz-1FNN0SoEV0UmGYqk5f-bHcR40HUo2VY=.97439f09-038f-4fd9-8ac5-09d60b857790@github.com>

On Fri, 24 Oct 2025 00:57:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix re-implements flat object support in heap dumper.
> New approach does not require changes in .hprof format.
> Flat value objects are dumped as heap-allocated objects with generated ID.
> For heap-allocated objects the ID is their address (oop), they are always aligned.
> ID generator for flat objects uses unaligned values (so there is no conflicts with oops).
> 
> HeapDump test was reimplemented (it was disabled for a long time)
> Changes in hprof test lib were reverted (they are not needed anymore)
> 
> testing: tier1..4,hs-tier5-svc

test/lib/jdk/test/lib/hprof/model/JavaObject.java line 324:

> 322: 
> 323:                 }
> 324:         } catch (IOException exp) {

The indentation of the catch block seems off.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2496130964

From amenkov at openjdk.org  Wed Nov  5 21:50:58 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 5 Nov 2025 21:50:58 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats [v2]
In-Reply-To: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
Message-ID: <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>

> The fix re-implements flat object support in heap dumper.
> New approach does not require changes in .hprof format.
> Flat value objects are dumped as heap-allocated objects with generated ID.
> For heap-allocated objects the ID is their address (oop), they are always aligned.
> ID generator for flat objects uses unaligned values (so there is no conflicts with oops).
> 
> HeapDump test was reimplemented (it was disabled for a long time)
> Changes in hprof test lib were reverted (they are not needed anymore)
> 
> testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  removed T_FLAT_ELEMENT in StackRefDumper

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1700/files
  - new: https://git.openjdk.org/valhalla/pull/1700/files/796bf148..a980b464

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

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

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

From amenkov at openjdk.org  Wed Nov  5 21:57:24 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 5 Nov 2025 21:57:24 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats [v2]
In-Reply-To: <WhbXbQB0_3a62j7cxlEYwBlBA0L1Vhgp8kyV2YUq8L8=.0736fd32-7753-4503-bf31-4890b989cef7@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
 <WhbXbQB0_3a62j7cxlEYwBlBA0L1Vhgp8kyV2YUq8L8=.0736fd32-7753-4503-bf31-4890b989cef7@github.com>
Message-ID: <-stDutDP0LPX319a3DWeIFsbzLCOzgPsFxar1SWY8bo=.181884fe-9598-4276-92a5-65499ee5c682@github.com>

On Wed, 5 Nov 2025 20:28:16 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed T_FLAT_ELEMENT in StackRefDumper
>
> src/hotspot/share/services/heapDumper.cpp line 1818:
> 
>> 1816: void JavaStackRefDumper::dump_java_stack_refs(StackValueCollection* values) {
>> 1817:   for (int index = 0; index < values->size(); index++) {
>> 1818:     // TODO: can it be T_FLAT_ELEMENT?
> 
> The BasicType T_FLAT_ELEMENT is used exclusively in the context of flat arrays: in the layout_helper of flat arrays, and in a few array methods like arrayOopDesc::base_offset_in_bytes().
> T_FLAT_ELEMENT cannot be used to describe the type of a field, the type of the argument of a Java method or the type of a value on the stack.

Thank you, removed

> test/lib/jdk/test/lib/hprof/model/JavaObject.java line 324:
> 
>> 322: 
>> 323:                 }
>> 324:         } catch (IOException exp) {
> 
> The indentation of the catch block seems off.

This is revert of the previous implementation (first 2 commits)
With new approach hprof format is not changed, so I restored hprof test lib as it is in mainline

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2496305454
PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2496311310

From rriggs at openjdk.org  Wed Nov  5 21:58:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Nov 2025 21:58:29 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
Message-ID: <5r_KFiOmOE98et0QXLVI3oYacTmCtjaBJhasPiKRYE4=.51ee3470-c2bb-49fe-ad5c-903302bc079a@github.com>

On Wed, 5 Nov 2025 18:35:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback and test fix

Warts included, should work as intended.

src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 177:

> 175:      * @return package flags for {@code "/packages/xxx"} directory entries.
> 176:      */
> 177:     public static int getPackageFlags(List<ModuleReference> moduleReferences) {

This exclusively works on ModuleReferences, it seems that it should be in ModuleReference, not ImageLocation. It is only in ImageLocation because the flags are private.
And it is only used by ImageResourceTree, so should be there.
There has to be a better structure that doesn't cause so much confusion and crossing boundaries.
And yes, I think it is another example where having similar but different flags is harmful to the structure and meaning of the code.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1718#pullrequestreview-3424569473
PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2496272604

From davidalayachew at gmail.com  Thu Nov  6 00:26:35 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 5 Nov 2025 19:26:35 -0500
Subject: About flattening a nullable j.l.Long
In-Reply-To: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
Message-ID: <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>

Just a heads up, your [1] is a dead link. Can you try to put the url in
again?

On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com> wrote:

> Hi,
>
> Currently, I'm having a PR that allows flattening of a nullable
> value class with a 64-bit payload [1]. Dan Smith told me that some ideas
> along these lines were discussed a few years ago, and the consensus was
> that it was a dead end. May I ask what the concerns were, and whether they
> are still relevant now?
>
> Thanks a lot,
> Quan Anh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251105/30fbe77e/attachment.htm>

From anhmdq at gmail.com  Thu Nov  6 02:52:41 2025
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Thu, 6 Nov 2025 09:52:41 +0700
Subject: About flattening a nullable j.l.Long
In-Reply-To: <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
Message-ID: <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>

Ah yes, my bad, it is https://github.com/openjdk/valhalla/pull/1720

On Thu, 6 Nov 2025 at 07:26, David Alayachew <davidalayachew at gmail.com>
wrote:

> Just a heads up, your [1] is a dead link. Can you try to put the url in
> again?
>
> On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>
>> Hi,
>>
>> Currently, I'm having a PR that allows flattening of a nullable
>> value class with a 64-bit payload [1]. Dan Smith told me that some ideas
>> along these lines were discussed a few years ago, and the consensus was
>> that it was a dead end. May I ask what the concerns were, and whether they
>> are still relevant now?
>>
>> Thanks a lot,
>> Quan Anh
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251106/633035fd/attachment.htm>

From rriggs at openjdk.org  Thu Nov  6 03:49:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Nov 2025 03:49:30 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
Message-ID: <R6ulE2R_yQxNvsl9umEqrhtpRtq5AOKYsJZRBfvSkOg=.078aa175-b248-41c8-9fe7-2358e1e8612c@github.com>

On Wed, 5 Nov 2025 18:35:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback and test fix

Is the failure of Test `tools/jimage/JImageExtractTest.java` expected?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1718#issuecomment-3494799181

From mhaessig at openjdk.org  Thu Nov  6 07:36:34 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 6 Nov 2025 07:36:34 GMT
Subject: [lworld] RFR: 8367244: [lworld] C2 compilation fails with assert
 "no node with a side effect" [v2]
In-Reply-To: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
References: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
Message-ID: <TBV82E9DkbRTqvlnlvkzuqHHUvNgVMSidwa2fvPBmOA=.a8fdaf9b-c51b-45de-8685-75785288c72d@github.com>

> ## Problem Analysis
> 
> The stress test `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`, which uses the `StressUnstableIfTrap` flag, failed intermittently with the assert "no node with a side effect" during C2 compilation. I tracked down the origin of the failure to the raw store of the unstable if trap stress counter that was missing a memory edge to the backedge phi and thus had no side effect in the loop, which lead to the aforementioned assert. During parsing, the missing memory edge gets discarded with as vestigial parsing state when `do_if()` ends up `stopped()`. However, the effect of the stress counter should still be wired back into the backedge since it will be incremented in the next iteration.
> 
> ## Patch Description
> 
> To prevent the stress counters memory state being lost to `PreserveJVMState`, I pass it to the caller over an out-parameter and `set_memory` with that node, similar to what is already done for control. This is only necessary for the two last invocation of `do_if()` in `do_acmp()` where they are actually allowed to trap. Further, this PR reenables `StressUnstableIfTrap` in `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`.
> 
> ## Testing
> 
> - [x] tier1,tier2,tier3 plus internal stress testing

Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:

  Review Christian

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1716/files
  - new: https://git.openjdk.org/valhalla/pull/1716/files/42542a7c..9e09aa23

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

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

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

From mhaessig at openjdk.org  Thu Nov  6 07:39:33 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 6 Nov 2025 07:39:33 GMT
Subject: [lworld] RFR: 8367244: [lworld] C2 compilation fails with assert
 "no node with a side effect" [v2]
In-Reply-To: <qZt7jydontf9YIKxLK14T0bJCBzb8zZe_gRSaZIpRhE=.9c3773cc-19fd-4eef-96cd-263ae746476c@github.com>
References: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
 <qZt7jydontf9YIKxLK14T0bJCBzb8zZe_gRSaZIpRhE=.9c3773cc-19fd-4eef-96cd-263ae746476c@github.com>
Message-ID: <3AFkPYy3evig2yXHUmZZxu4PADcIWxhIIerot6FW6YQ=.b71b9229-0266-48af-83cb-db83f6a057e9@github.com>

On Wed, 5 Nov 2025 14:54:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Christian
>
> Looks reasonable to me, thanks for fixing this!

Thank you for having a look, @chhagedorn. I removed the repeated compilation.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1716#issuecomment-3495537596

From cay.horstmann at gmail.com  Thu Nov  6 08:19:07 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Thu, 6 Nov 2025 09:19:07 +0100
Subject: Prebuilt Valhalla JDK build 26-jep401ea2
Message-ID: <e90acbd2-a5e3-4c4e-ad08-9707cbc70e1d@gmail.com>

Hi, how was that build created? When I build from scratch from https://github.com/openjdk/valhalla, I get a different behavior with the last example on https://inside.java/2025/10/27/try-jep-401-value-classes/ (i.e. no heap flattening).

Thanks,

Cay
-- 

Cay S. Horstmann | https://horstmann.com


From mchevalier at openjdk.org  Thu Nov  6 08:43:33 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 6 Nov 2025 08:43:33 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <LrRSLeIoxO_LS9XwvpJuax0kSgrjftj_ttapwPeU4Dg=.a2984149-c15b-4e0b-969b-8ac9c11ce7f7@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

I agree it's the same issue. Very nice! Both with mainline and valhalla. I had the suspicion it wasn't valhalla-specific because none of the concept and code involved was, but I couldn't find an example. I'll add the test.

For the record, we have:

in(1): java/lang/Object * (speculative=TestSpeculativeTypes$C2:NotNull:exact * (inline_depth=3))
in(2): null
t: java/lang/Object * (speculative=TestSpeculativeTypes$C1:exact *)
_type: java/lang/Object * (speculative=TestSpeculativeTypes$C1:exact *)
Filter once: java/lang/Object *
Filter twice: java/lang/Object * (speculative=TestSpeculativeTypes$C2:exact *)


It's now to fix in mainline (and maybe only in mainline, and just count on jdk -> valhalla merges). But there is still the question of the solution, and it is still not clear what is the best way to me.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3495890513

From paul.hubner at oracle.com  Thu Nov  6 08:54:42 2025
From: paul.hubner at oracle.com (Paul Hubner)
Date: Thu, 6 Nov 2025 08:54:42 +0000
Subject: Prebuilt Valhalla JDK build 26-jep401ea2
In-Reply-To: <e90acbd2-a5e3-4c4e-ad08-9707cbc70e1d@gmail.com>
References: <e90acbd2-a5e3-4c4e-ad08-9707cbc70e1d@gmail.com>
Message-ID: <DS0PR10MB607818E0743C703A602A1B8783C2A@DS0PR10MB6078.namprd10.prod.outlook.com>

Hi Cay,

The binaries are built from the jep401ea2 branch: https://github.com/openjdk/valhalla/tree/jep401ea2. For clarification, are you observing heap flattening locally with our ea2 binaries?

Best,
Paul

________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Thursday, November 6, 2025 9:19 AM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: Prebuilt Valhalla JDK build 26-jep401ea2

Hi, how was that build created? When I build from scratch from https://github.com/openjdk/valhalla, I get a different behavior with the last example on https://inside.java/2025/10/27/try-jep-401-value-classes/ (i.e. no heap flattening).

Thanks,

Cay
--

Cay S. Horstmann | https://horstmann.com

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

From qamai at openjdk.org  Thu Nov  6 08:58:32 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Nov 2025 08:58:32 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <cwfbyUoD9UGSj5uSI9VAtJ3RPJGVDjbxlI54ESGQOAg=.c33fa29c-4372-4963-939f-54820ebd882e@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

I think it is better to fix the type system. Having a join that does not satisfy `X join Y < X` is really confusing and opens the chance for many kinds of issues.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3495960300

From chagedorn at openjdk.org  Thu Nov  6 08:59:30 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 6 Nov 2025 08:59:30 GMT
Subject: [lworld] RFR: 8367244: [lworld] C2 compilation fails with assert
 "no node with a side effect" [v2]
In-Reply-To: <TBV82E9DkbRTqvlnlvkzuqHHUvNgVMSidwa2fvPBmOA=.a8fdaf9b-c51b-45de-8685-75785288c72d@github.com>
References: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
 <TBV82E9DkbRTqvlnlvkzuqHHUvNgVMSidwa2fvPBmOA=.a8fdaf9b-c51b-45de-8685-75785288c72d@github.com>
Message-ID: <DGLMmPf7j9iTnPnDYVo8Zn0A1LyMnt1K1kqWVGp2Jkw=.3ddd9365-f43d-4832-9076-89053e5f56f0@github.com>

On Thu, 6 Nov 2025 07:36:34 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> ## Problem Analysis
>> 
>> The stress test `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`, which uses the `StressUnstableIfTrap` flag, failed intermittently with the assert "no node with a side effect" during C2 compilation. I tracked down the origin of the failure to the raw store of the unstable if trap stress counter that was missing a memory edge to the backedge phi and thus had no side effect in the loop, which lead to the aforementioned assert. During parsing, the missing memory edge gets discarded with as vestigial parsing state when `do_if()` ends up `stopped()`. However, the effect of the stress counter should still be wired back into the backedge since it will be incremented in the next iteration.
>> 
>> ## Patch Description
>> 
>> To prevent the stress counters memory state being lost to `PreserveJVMState`, I pass it to the caller over an out-parameter and `set_memory` with that node, similar to what is already done for control. This is only necessary for the two last invocation of `do_if()` in `do_acmp()` where they are actually allowed to trap. Further, this PR reenables `StressUnstableIfTrap` in `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`.
>> 
>> ## Testing
>> 
>> - [x] tier1,tier2,tier3 plus internal stress testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Christian

Marked as reviewed by chagedorn (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1716#pullrequestreview-3426987185

From mchevalier at openjdk.org  Thu Nov  6 09:05:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 6 Nov 2025 09:05:32 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <UIwxiBOGuskRQ7NdYlLcXzLa6ND2R1PTlU2Un1vd1xA=.143b75fa-28e6-4fc2-bf17-9965549f4b1e@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

I agree on principle, but I find that weird to have exactly this test with the `above_centerline`: it looks like it was made on purpose, and not just an overlooked detail. I'm somewhat shy to remove such a "feature", there might be a good reason it's here.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3495995836

From roland at openjdk.org  Thu Nov  6 09:09:34 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 6 Nov 2025 09:09:34 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <IGMaZSpt8S48orSHXUGRwnWCu-ROU6c3mV0CjnXl2RI=.fc5e26c3-621b-4453-a8fe-25d8a96dc370@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

The type system is quite complicated and it's hard to get right. This seems like a corner case: only for `Phi`s and speculative types and mostly harmless unless caught by verification code. So I would not bother with the type system and go with a point fix similar to what Marc proposes.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496019631

From duke at openjdk.org  Thu Nov  6 09:12:35 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Nov 2025 09:12:35 GMT
Subject: [lworld] RFR: 8367244: [lworld] C2 compilation fails with assert
 "no node with a side effect" [v2]
In-Reply-To: <TBV82E9DkbRTqvlnlvkzuqHHUvNgVMSidwa2fvPBmOA=.a8fdaf9b-c51b-45de-8685-75785288c72d@github.com>
References: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
 <TBV82E9DkbRTqvlnlvkzuqHHUvNgVMSidwa2fvPBmOA=.a8fdaf9b-c51b-45de-8685-75785288c72d@github.com>
Message-ID: <PWrtnhFECL4LtuhyghjS14HIGA8tmVRrFWPl7_9cMcQ=.9d1c565f-7e72-4826-8eed-d89024edcc9b@github.com>

On Thu, 6 Nov 2025 07:36:34 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> ## Problem Analysis
>> 
>> The stress test `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`, which uses the `StressUnstableIfTrap` flag, failed intermittently with the assert "no node with a side effect" during C2 compilation. I tracked down the origin of the failure to the raw store of the unstable if trap stress counter that was missing a memory edge to the backedge phi and thus had no side effect in the loop, which lead to the aforementioned assert. During parsing, the missing memory edge gets discarded with as vestigial parsing state when `do_if()` ends up `stopped()`. However, the effect of the stress counter should still be wired back into the backedge since it will be incremented in the next iteration.
>> 
>> ## Patch Description
>> 
>> To prevent the stress counters memory state being lost to `PreserveJVMState`, I pass it to the caller over an out-parameter and `set_memory` with that node, similar to what is already done for control. This is only necessary for the two last invocation of `do_if()` in `do_acmp()` where they are actually allowed to trap. Further, this PR reenables `StressUnstableIfTrap` in `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`.
>> 
>> ## Testing
>> 
>> - [x] tier1,tier2,tier3 plus internal stress testing
>
> Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Christian

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1716#issuecomment-3496033789

From qamai at openjdk.org  Thu Nov  6 09:20:31 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Nov 2025 09:20:31 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

I disagree. The issue only surfaces in this particular occasion does not mean it will not appear in other circumstances, possibly in the future. Even if the code is there on purpose, it seems that the purpose is executed incorrectly.

Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable, which is not the case here. So, another approach may be to fix the injection of speculative and assert that we should not obtain an empty speculative type?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496085483

From roland at openjdk.org  Thu Nov  6 09:33:34 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 6 Nov 2025 09:33:34 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
 <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
Message-ID: <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>

On Thu, 6 Nov 2025 09:17:39 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,

Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.

Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496151715

From mchevalier at openjdk.org  Thu Nov  6 10:36:36 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 6 Nov 2025 10:36:36 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
 <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
 <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
Message-ID: <lBFEd9fxnHPb5VgT6O8XoXVOgKm1BiL4wMjEQJQh71o=.c3d288ef-bc2b-47ce-9fae-9e33081c7ba3@github.com>

On Thu, 6 Nov 2025 09:30:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I disagree. The issue only surfaces in this particular occasion does not mean it will not appear in other circumstances, possibly in the future. Even if the code is there on purpose, it seems that the purpose is executed incorrectly.
>> 
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable, which is not the case here. So, another approach may be to fix the injection of speculative and assert that we should not obtain an empty speculative type?
>
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,
> 
> Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.
> 
> Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.

I'm trying to understand why `cleanup_speculative` is doing so. It seems to come from [JDK-8031755: Type speculation should be used to optimize explicit null checks](https://bugs.openjdk.org/browse/JDK-8031755). Maybe @rwestrel would remember something about it, but it has been quite a while since!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496451968

From qamai at openjdk.org  Thu Nov  6 10:40:28 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Nov 2025 10:40:28 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <B2qImnf31Dv5FfXLGHEWIVbhQHOucZA4300xP2VytJA=.2d755b64-654f-4375-b82f-cfd0315d926d@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

An important point is that:

> The interesting part is that it's `AnyNull`: indeed, what else is a `MyValue2` and `MyValue3` at the same time?

There is one, though, and it is `null`. The join is incorrect here.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496472165

From cay.horstmann at gmail.com  Thu Nov  6 10:43:57 2025
From: cay.horstmann at gmail.com (Cay Horstmann)
Date: Thu, 6 Nov 2025 11:43:57 +0100
Subject: Prebuilt Valhalla JDK build 26-jep401ea2
In-Reply-To: <DS0PR10MB607818E0743C703A602A1B8783C2A@DS0PR10MB6078.namprd10.prod.outlook.com>
References: <e90acbd2-a5e3-4c4e-ad08-9707cbc70e1d@gmail.com>
 <DS0PR10MB607818E0743C703A602A1B8783C2A@DS0PR10MB6078.namprd10.prod.outlook.com>
Message-ID: <e9547034-5dfe-428b-a981-9217b5445260@gmail.com>

Thanks, it worked with that branch.

Here the GC.class_histogram outputs.

Without --enable-preview:

    1:      50000003     1200000072  java.time.LocalDate (java.base at 26-jep401ea2)
    2:             1      200000016  [Ljava.time.LocalDate; (java.base at 26-jep401ea2)
  
With --enable-preview:

    1:             1      400000016  [Ljava.time.LocalDate; (java.base at 26-jep401ea2)

Cheers,

Cay


Il 06/11/2025 09:54, Paul Hubner ha scritto:
> Hi Cay,
> 
> The binaries are built from the jep401ea2 branch: https://github.com/openjdk/valhalla/tree/jep401ea2 <https://github.com/openjdk/valhalla/tree/jep401ea2>. For clarification, are you observing heap flattening locally with our ea2 binaries?
> 
> Best,
> Paul
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
> *Sent:* Thursday, November 6, 2025 9:19 AM
> *To:* valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
> *Subject:* Prebuilt Valhalla JDK build 26-jep401ea2
> Hi, how was that build created? When I build from scratch from https://github.com/openjdk/valhalla <https://github.com/openjdk/valhalla>, I get a different behavior with the last example on https://inside.java/2025/10/27/try-jep-401-value-classes/ <https://inside.java/2025/10/27/try-jep-401-value-classes/> (i.e. no heap flattening).
> 
> Thanks,
> 
> Cay
> -- 
> 
> Cay S. Horstmann | https://horstmann.com <https://horstmann.com>
> 

-- 

Cay S. Horstmann | https://horstmann.com


From qamai at openjdk.org  Thu Nov  6 10:49:33 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 6 Nov 2025 10:49:33 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
 <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
 <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
Message-ID: <AB9Mu9Q9WeE58yAIMW2d9EvTPaWSF0Ijb9XJ6POY5BU=.9ed4f99e-f8e7-40a5-a163-cf50b6b5597f@github.com>

On Thu, 6 Nov 2025 09:30:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I disagree. The issue only surfaces in this particular occasion does not mean it will not appear in other circumstances, possibly in the future. Even if the code is there on purpose, it seems that the purpose is executed incorrectly.
>> 
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable, which is not the case here. So, another approach may be to fix the injection of speculative and assert that we should not obtain an empty speculative type?
>
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,
> 
> Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.
> 
> Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.

I have looked at the example provided by @rwestrel , and it seems true that when the speculative type is empty, the node is speculatively unreachable (`test1` is always called with `flag1` being `false`, so the return type of `inline2(flag2)` inside the compilation of `test1` is unreachable). Now what can we do with this?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496512649

From roland at openjdk.org  Thu Nov  6 11:17:32 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 6 Nov 2025 11:17:32 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
 <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
 <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
Message-ID: <fVJ2njJHvVh0TbZTQoNCRihAza4HInhHSq4LubaYErw=.57c6922f-55be-48df-beb1-73dccf2dfb35@github.com>

On Thu, 6 Nov 2025 09:30:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I disagree. The issue only surfaces in this particular occasion does not mean it will not appear in other circumstances, possibly in the future. Even if the code is there on purpose, it seems that the purpose is executed incorrectly.
>> 
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable, which is not the case here. So, another approach may be to fix the injection of speculative and assert that we should not obtain an empty speculative type?
>
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,
> 
> Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.
> 
> Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.

> I have looked at the example provided by @rwestrel , and it seems true that when the speculative type is empty, the node is speculatively unreachable (`test1` is always called with `flag1` being `false`, so the return type of `inline2(flag2)` inside the compilation of `test1` is unreachable). Now what can we do with this?

That's how I crafted the test to get conflicting profiles.

I also had to use `TypeProfileLevel=222` to enable some profile collection that's disabled by default. Most compilation wouldn't even see that many speculative types.

Another way to get conflicting profiles would be to make sure profile collection only happens when some particular value is returned and not when some other is returned. Profile collection doesn't start on first execution and stops as soon as a method is compiled by c2. So if a method is called very often, 1) initially returns some type and 2) then only later some other type, and if compilation with c2 happens between 1) and 2), then profile data only reports the type collected in 1).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496652847

From roland at openjdk.org  Thu Nov  6 11:20:31 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Thu, 6 Nov 2025 11:20:31 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <fVJ2njJHvVh0TbZTQoNCRihAza4HInhHSq4LubaYErw=.57c6922f-55be-48df-beb1-73dccf2dfb35@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
 <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
 <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
 <fVJ2njJHvVh0TbZTQoNCRihAza4HInhHSq4LubaYErw=.57c6922f-55be-48df-beb1-73dccf2dfb35@github.com>
Message-ID: <ydOVk0k727f_tlJPQsnVH_lEjdsOfS75RIYTGrSbD2k=.4ce783ff-8a92-4841-b0b4-9a14f98189c0@github.com>

On Thu, 6 Nov 2025 11:15:11 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,
>> 
>> Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.
>> 
>> Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.
>
>> I have looked at the example provided by @rwestrel , and it seems true that when the speculative type is empty, the node is speculatively unreachable (`test1` is always called with `flag1` being `false`, so the return type of `inline2(flag2)` inside the compilation of `test1` is unreachable). Now what can we do with this?
> 
> That's how I crafted the test to get conflicting profiles.
> 
> I also had to use `TypeProfileLevel=222` to enable some profile collection that's disabled by default. Most compilation wouldn't even see that many speculative types.
> 
> Another way to get conflicting profiles would be to make sure profile collection only happens when some particular value is returned and not when some other is returned. Profile collection doesn't start on first execution and stops as soon as a method is compiled by c2. So if a method is called very often, 1) initially returns some type and 2) then only later some other type, and if compilation with c2 happens between 1) and 2), then profile data only reports the type collected in 1).

> I'm trying to understand why `cleanup_speculative` is doing so. It seems to come from [JDK-8031755: Type speculation should be used to optimize explicit null checks](https://bugs.openjdk.org/browse/JDK-8031755). Maybe @rwestrel would remember something about it, but it has been quite a while since!

I don't remember the details but I think the rationale is that if we're seeing conflicting profile, there's a good chance profile data is inaccurate and we can as well ignore it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496666140

From duke at openjdk.org  Thu Nov  6 12:29:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Nov 2025 12:29:33 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
Message-ID: <700WcNORXrdcW7o4eURSjpffoXVs6sMtnBt2WrCCa-k=.42a67dd1-280b-49d4-a903-8404e5eb0a8e@github.com>

On Wed, 5 Nov 2025 18:35:49 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Feedback and test fix

I hadn't noticed tools/jimage/JImageExtractTest.java was failing. Investigating now. Thanks.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1718#issuecomment-3497026453

From duke at openjdk.org  Thu Nov  6 12:29:34 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Nov 2025 12:29:34 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v3]
In-Reply-To: <5r_KFiOmOE98et0QXLVI3oYacTmCtjaBJhasPiKRYE4=.51ee3470-c2bb-49fe-ad5c-903302bc079a@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <sE1jmOp6BZxW86_mR5pM-QQ53Jvfnm19IOS47sm4WuU=.d3d8d011-69cd-40ee-8fab-98ce41b8aa2c@github.com>
 <5r_KFiOmOE98et0QXLVI3oYacTmCtjaBJhasPiKRYE4=.51ee3470-c2bb-49fe-ad5c-903302bc079a@github.com>
Message-ID: <8PQUgC8VcLWsYiSIG7YCyMhmVgPxVCzxwBycpMi-024=.ed0d9b42-794e-419c-a614-bc283302e50e@github.com>

On Wed, 5 Nov 2025 21:39:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Feedback and test fix
>
> src/java.base/share/classes/jdk/internal/jimage/ImageLocation.java line 177:
> 
>> 175:      * @return package flags for {@code "/packages/xxx"} directory entries.
>> 176:      */
>> 177:     public static int getPackageFlags(List<ModuleReference> moduleReferences) {
> 
> This exclusively works on ModuleReferences, it seems that it should be in ModuleReference, not ImageLocation. It is only in ImageLocation because the flags are private.
> And it is only used by ImageResourceTree, so should be there.
> There has to be a better structure that doesn't cause so much confusion and crossing boundaries.
> And yes, I think it is another example where having similar but different flags is harmful to the structure and meaning of the code.

As you point out, the flags are private, so I'd have to change that in some way to move this function elsewhere.
It does operate on module references, but only via their public API (which doesn't require those flags to be public).
As I've said, the flags are similarly named because they have similar semantics. They cannot really share the same constant values because of the differing requirements for each (personally I'd also say it's better if flags stored in different places are different constants).
The most natural place to find it would be ImageResourceTree, and I can do that if we make the ImageLocation flags public (the ModuleReference flags can stay private of course).
Does that sound okay?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1718#discussion_r2498770042

From forax at univ-mlv.fr  Thu Nov  6 13:02:08 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 6 Nov 2025 14:02:08 +0100 (CET)
Subject: About flattening a nullable j.l.Long
In-Reply-To: <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
 <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
Message-ID: <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>

Hello, 
as far as i remember, the problem is that you can resurrect a value, 
for example with a Long 

Thread1 
a.x = new Long(12); 
a.x = null; 
IO.println(a.x); //12 

Thread2 
IO.println(a.x); // null 
a.x = new Long(77); // descheduled in between writing the maker and writing the long 

The thread1 can see the Long(12) to be resurrected, something that is not possible with references. 

regards, 
R?mi 

> From: "Qu?n Anh Mai" <anhmdq at gmail.com>
> To: "David Alayachew" <davidalayachew at gmail.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Thursday, November 6, 2025 3:52:41 AM
> Subject: Re: About flattening a nullable j.l.Long

> Ah yes, my bad, it is [ https://github.com/openjdk/valhalla/pull/1720 |
> https://github.com/openjdk/valhalla/pull/1720 ]

> On Thu, 6 Nov 2025 at 07:26, David Alayachew < [ mailto:davidalayachew at gmail.com
> | davidalayachew at gmail.com ] > wrote:

>> Just a heads up, your [1] is a dead link. Can you try to put the url in again?

>> On Wed, Nov 5, 2025, 2:06 PM Qu?n Anh Mai < [ mailto:anhmdq at gmail.com |
>> anhmdq at gmail.com ] > wrote:

>>> Hi,
>>> Currently, I'm having a PR that allows flattening of a nullable value class with
>>> a 64-bit payload [1]. Dan Smith told me that some ideas along these lines were
>>> discussed a few years ago, and the consensus was that it was a dead end. May I
>>> ask what the concerns were, and whether they are still relevant now?

>>> Thanks a lot,
>>> Quan Anh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251106/4ab060bf/attachment-0001.htm>

From paul.hubner at oracle.com  Thu Nov  6 14:04:10 2025
From: paul.hubner at oracle.com (Paul Hubner)
Date: Thu, 6 Nov 2025 14:04:10 +0000
Subject: Prebuilt Valhalla JDK build 26-jep401ea2
In-Reply-To: <e9547034-5dfe-428b-a981-9217b5445260@gmail.com>
References: <e90acbd2-a5e3-4c4e-ad08-9707cbc70e1d@gmail.com>
 <DS0PR10MB607818E0743C703A602A1B8783C2A@DS0PR10MB6078.namprd10.prod.outlook.com>
 <e9547034-5dfe-428b-a981-9217b5445260@gmail.com>
Message-ID: <DS0PR10MB60782D47A2E16AFA92F30E4983C2A@DS0PR10MB6078.namprd10.prod.outlook.com>

Hi Cay,

Thanks for the information. I'm also observing lworld not flattening that example. I've opened up an issue to investigate: https://bugs.openjdk.org/browse/JDK-8371410.

Thanks for the feedback!

Best,
Paul

________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
Sent: Thursday, November 6, 2025 11:43 AM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: Re: Prebuilt Valhalla JDK build 26-jep401ea2

Thanks, it worked with that branch.

Here the GC.class_histogram outputs.

Without --enable-preview:

    1:      50000003     1200000072  java.time.LocalDate (java.base at 26-jep401ea2)
    2:             1      200000016  [Ljava.time.LocalDate; (java.base at 26-jep401ea2)

With --enable-preview:

    1:             1      400000016  [Ljava.time.LocalDate; (java.base at 26-jep401ea2)

Cheers,

Cay


Il 06/11/2025 09:54, Paul Hubner ha scritto:
> Hi Cay,
>
> The binaries are built from the jep401ea2 branch: https://github.com/openjdk/valhalla/tree/jep401ea2 <https://github.com/openjdk/valhalla/tree/jep401ea2>. For clarification, are you observing heap flattening locally with our ea2 binaries?
>
> Best,
> Paul
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Cay Horstmann <cay.horstmann at gmail.com>
> *Sent:* Thursday, November 6, 2025 9:19 AM
> *To:* valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
> *Subject:* Prebuilt Valhalla JDK build 26-jep401ea2
> Hi, how was that build created? When I build from scratch from https://github.com/openjdk/valhalla <https://github.com/openjdk/valhalla>, I get a different behavior with the last example on https://inside.java/2025/10/27/try-jep-401-value-classes/ <https://inside.java/2025/10/27/try-jep-401-value-classes/> (i.e. no heap flattening).
>
> Thanks,
>
> Cay
> --
>
> Cay S. Horstmann | https://horstmann.com <https://horstmann.com>
>

--

Cay S. Horstmann | https://horstmann.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251106/87b31c66/attachment.htm>

From fparain at openjdk.org  Thu Nov  6 14:38:40 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 6 Nov 2025 14:38:40 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats [v2]
In-Reply-To: <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
 <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>
Message-ID: <kRCW4AtyYGrVpR6r1AsbZFUj1E8l5UHash3hbu0xNvk=.7a98f522-64e6-407a-9060-d1bd5d22775e@github.com>

On Wed, 5 Nov 2025 21:50:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix re-implements flat object support in heap dumper.
>> New approach does not require changes in .hprof format.
>> Flat value objects are dumped as heap-allocated objects with generated ID.
>> For heap-allocated objects the ID is their address (oop), they are always aligned.
>> ID generator for flat objects uses unaligned values (so there is no conflicts with oops).
>> 
>> HeapDump test was reimplemented (it was disabled for a long time)
>> Changes in hprof test lib were reverted (they are not needed anymore)
>> 
>> testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed T_FLAT_ELEMENT in StackRefDumper

src/hotspot/share/services/heapDumper.cpp line 1445:

> 1443:   int type_size;
> 1444:   if (type == T_OBJECT || type == T_FLAT_ELEMENT) {
> 1445:     type_size = sizeof(address);

Array elements size is not always sizeof(address) for flat arrays (could be smaller or bigger).
The real size of the array elements can be retrieved using the element_byte_size() method in FlatArrayKlass.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2499197064

From duke at openjdk.org  Thu Nov  6 16:45:06 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Nov 2025 16:45:06 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v4]
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <8BKAwhd8yGwGdB5TQ3rHm-3FD8MC_pUFw_XT6yRfg6c=.99d548f3-33d4-4de4-9979-c5102b01a229@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

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

  fixing jlink issue

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1718/files
  - new: https://git.openjdk.org/valhalla/pull/1718/files/533e5aff..7263e2e6

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

  Stats: 19 lines in 3 files changed: 5 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1718.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1718/head:pull/1718

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

From duke at openjdk.org  Thu Nov  6 17:40:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Nov 2025 17:40:33 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v5]
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <jQvDhioh0zIM4MofC1YajsJ0lRjXadK87mPSWKzaZcE=.c784f15b-ae0c-4c4d-a71c-56f2e8deb3ee@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

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

  Rename ModuleReference methods back.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1718/files
  - new: https://git.openjdk.org/valhalla/pull/1718/files/7263e2e6..8e702fa3

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

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

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

From duke at openjdk.org  Thu Nov  6 17:50:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Nov 2025 17:50:38 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v6]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <hu5OGSymNOBtxW0B74Ql0EmsRAVixU1FQJ4Cg5Y5-YY=.7f1585fc-b99f-459a-b656-d99c8e4f75d4@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

 - Merge branch 'jdk_8368467_reader/squashed' into jdk_8371292_jlink/squashed
 - Tidied up diff code in test.
 - Added copyright notice and tidied a couple of comments.
 - Tighted access to new API and undo new path() method.
 - Remove redundant extra method (part of original prototype)
 - Make jlink use a new narrow API for raw jimage access

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/fdcb73f7..1f85ff74

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

  Stats: 56 lines in 8 files changed: 5 ins; 11 del; 40 mod
  Patch: https://git.openjdk.org/valhalla/pull/1721.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1721/head:pull/1721

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

From amenkov at openjdk.org  Thu Nov  6 19:33:30 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Nov 2025 19:33:30 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats [v2]
In-Reply-To: <kRCW4AtyYGrVpR6r1AsbZFUj1E8l5UHash3hbu0xNvk=.7a98f522-64e6-407a-9060-d1bd5d22775e@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
 <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>
 <kRCW4AtyYGrVpR6r1AsbZFUj1E8l5UHash3hbu0xNvk=.7a98f522-64e6-407a-9060-d1bd5d22775e@github.com>
Message-ID: <ECJvxd5SKWHw33LYdDW9hWnIGRSIgF_iQH3gEAJ__KU=.387bb1d3-02dd-4f93-9c49-94523442e89c@github.com>

On Thu, 6 Nov 2025 14:35:49 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed T_FLAT_ELEMENT in StackRefDumper
>
> src/hotspot/share/services/heapDumper.cpp line 1445:
> 
>> 1443:   int type_size;
>> 1444:   if (type == T_OBJECT || type == T_FLAT_ELEMENT) {
>> 1445:     type_size = sizeof(address);
> 
> Array elements size is not always sizeof(address) for flat arrays (could be smaller or bigger).
> The real size of the array elements can be retrieved using the element_byte_size() method in FlatArrayKlass.

This is element size in the array dump, not in memory.
Elements of flat arrays are dumped as heap-allocated objects, i.e. each element in the dump is represented by object ID, ObjectID size is sizeof(address).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2500534040

From fparain at openjdk.org  Thu Nov  6 20:12:29 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 6 Nov 2025 20:12:29 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats [v2]
In-Reply-To: <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
 <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>
Message-ID: <MNg6keoNQRYwiFh9l8GHoMZlVTcWPlKSa6YMADSWsVc=.bcba093e-443c-4065-b23f-97f3cbec4b2d@github.com>

On Wed, 5 Nov 2025 21:50:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix re-implements flat object support in heap dumper.
>> New approach does not require changes in .hprof format.
>> Flat value objects are dumped as heap-allocated objects with generated ID.
>> For heap-allocated objects the ID is their address (oop), they are always aligned.
>> ID generator for flat objects uses unaligned values (so there is no conflicts with oops).
>> 
>> HeapDump test was reimplemented (it was disabled for a long time)
>> Changes in hprof test lib were reverted (they are not needed anymore)
>> 
>> testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed T_FLAT_ELEMENT in StackRefDumper

Not a heap dump expert, but the handling of flat fields and flat arrays in the heapDumper code look good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1700#pullrequestreview-3430318341

From fparain at openjdk.org  Thu Nov  6 20:12:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 6 Nov 2025 20:12:30 GMT
Subject: [lworld] RFR: 8341771: [lworld] Heap dump recognizing new flat
 fields formats [v2]
In-Reply-To: <ECJvxd5SKWHw33LYdDW9hWnIGRSIgF_iQH3gEAJ__KU=.387bb1d3-02dd-4f93-9c49-94523442e89c@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
 <1-SP8FdsIzGYTKFOUQOre3EKKxlLM5TCK93AW9DQ3vI=.5245c1c4-88c2-4cc3-b35f-97eaf3801194@github.com>
 <kRCW4AtyYGrVpR6r1AsbZFUj1E8l5UHash3hbu0xNvk=.7a98f522-64e6-407a-9060-d1bd5d22775e@github.com>
 <ECJvxd5SKWHw33LYdDW9hWnIGRSIgF_iQH3gEAJ__KU=.387bb1d3-02dd-4f93-9c49-94523442e89c@github.com>
Message-ID: <jCQxQN9dOAM9Idb5yvyXCw1yLXoHBqjjbuIYxIv2ARI=.90ab9caf-cfe1-4521-89e3-7e2668af85db@github.com>

On Thu, 6 Nov 2025 19:30:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> src/hotspot/share/services/heapDumper.cpp line 1445:
>> 
>>> 1443:   int type_size;
>>> 1444:   if (type == T_OBJECT || type == T_FLAT_ELEMENT) {
>>> 1445:     type_size = sizeof(address);
>> 
>> Array elements size is not always sizeof(address) for flat arrays (could be smaller or bigger).
>> The real size of the array elements can be retrieved using the element_byte_size() method in FlatArrayKlass.
>
> This is element size in the array dump, not in memory.
> Elements of flat arrays are dumped as heap-allocated objects, i.e. each element in the dump is represented by object ID, ObjectID size is sizeof(address).

OK, thank you for the clarification.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1700#discussion_r2500660346

From duke at openjdk.org  Thu Nov  6 20:51:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 6 Nov 2025 20:51:57 GMT
Subject: [lworld] RFR: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode
Message-ID: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>

Switches package inference to handle preview resource paths.

Additionally:
* Updates unit test to use JUnit.
* Deletes unused code (both newly unused and previously unused).

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

Commit messages:
 - Fix resource pool package name inference.

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

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

From rriggs at openjdk.org  Thu Nov  6 21:19:31 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Nov 2025 21:19:31 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v5]
In-Reply-To: <jQvDhioh0zIM4MofC1YajsJ0lRjXadK87mPSWKzaZcE=.c784f15b-ae0c-4c4d-a71c-56f2e8deb3ee@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <jQvDhioh0zIM4MofC1YajsJ0lRjXadK87mPSWKzaZcE=.c784f15b-ae0c-4c4d-a71c-56f2e8deb3ee@github.com>
Message-ID: <oDiYewVOLFvxJ_NkhDbYP1rqzN9gfXi4zFCWIsVks4E=.4123e64a-0e78-4ac4-b7f2-63c621a23ff9@github.com>

On Thu, 6 Nov 2025 17:40:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ModuleReference methods back.

Looks good

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1718#pullrequestreview-3430597991

From rriggs at openjdk.org  Thu Nov  6 23:16:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 6 Nov 2025 23:16:40 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
 <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
Message-ID: <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>

On Tue, 4 Nov 2025 17:42:24 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Rollup of makefile changes and jlink fix (temp).
>   
>   * likely test fix
>   * Copy value classes into preview directories for inclusion in jimage

Copyright updates needed in: Archive, JImageTask, JRTArchive, JlinkTask, ResorucePoolTest, PackageModulesVsRuntimeImageLinkTest.

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 365:

> 363:                 if (name.startsWith("/modules/") || name.startsWith("/packages/")) {
> 364:                     throw new IllegalArgumentException("Invalid entry name: " + name);
> 365:                 }

This can be covered by the == null case below. The distinguished exception isn't necessary.

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 11:

> 9:  * <p>This API is designed only for use by the jlink classes, which manipulate
> 10:  * jimage files directly. For inspection of runtime resources, it is vital that
> 11:  * {@code previewMode} is correctly observed, making this API unsuitable.

"which manipulate jimage files directly" -> "read the raw jimage files". It should be clear that the directory structure is exactly that of the jimage file itself.

The 2nd part could be more clearly stated as use API xxx to access the classes and resources of a runtime depending on the preview mode.

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 24:

> 22:      * Returns the full entry names for all resources in the given module, in
> 23:      * random order. Entry names will always be prefixed by the given module
> 24:      * name (e.g. "/<module-name/...").

Are these names useful with any ImageReader api other than ResourceEntries.sizeOf or open?

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 26:

> 24:      * name (e.g. "/<module-name/...").
> 25:      */
> 26:     Stream<String> entryNamesIn(String module);

A cleaner name would be `entryNames`.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Archive.java line 91:

> 89:          * Returns the path of this entry.
> 90:          */
> 91:         public final String path() {return path;}

Typical style would expand to:

Suggestion:

        public final String path() {
            return path;
        }

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 305:

> 303: 
> 304:         /**
> 305:          *  line: {@code <int>|<int>|<hashOrTarget>|<path>}

For internal doc/methods, javadoc markup makes the source harder to read.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 461:

> 459:                             // hashOrTarget field
> 460:                             if (symlink) {
> 461:                                 return Files.size(BASE.resolve(sha));

The hashes were present to ensure the integrity of the dependent resources. 
With them removed, what ensures the integrity of the dependencies?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 1:

> 1: /*

Will need a copyright update.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 365:

> 363:             ImagePluginStack stack = ImagePluginConfiguration.parseConfiguration(plugins);
> 364: 
> 365:             //Ask the stack to proceed;

Add a space after //

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 508:

> 506:             stack.operate(imageProvider);
> 507:         }
> 508: 

Extra blank line.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 1058:

> 1056:         public void close() throws IOException {
> 1057:             for (Archive archive : archives) {
> 1058:                 archive.close();

Some Archive implementations may throw; a try-catch is needed to make sure all archives are closed.
Extra points for accumulating an extra exceptions as suppressed exceptions on the first exception.
(Though it seems unlikely).

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

PR Review: https://git.openjdk.org/valhalla/pull/1719#pullrequestreview-3430787891
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501053477
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501068207
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501070622
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501071692
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501076708
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501101521
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501123085
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501082503
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501086848
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501089017
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2501095048

From david.simms at oracle.com  Fri Nov  7 06:27:24 2025
From: david.simms at oracle.com (David Simms)
Date: Fri, 7 Nov 2025 06:27:24 +0000
Subject: CFV: New Valhalla Committer: Daniel Daugherty
Message-ID: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>

I hereby nominate Daniel Daugherty [1] to Valhalla Committer.

Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].

Votes are due by November 21st, 2025, 0700Z.

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

For Lazy Consensus voting instructions, see [4].

David Simms

[1] https://openjdk.org/census#dcubed
[2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
[3] https://openjdk.org/census
[4] https://openjdk.org/projects/#committer-vote

From dsimms at openjdk.org  Fri Nov  7 06:58:33 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 7 Nov 2025 06:58:33 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <Bdjvgn0-umQO3juuapVheCzE22tzoCW6CyUFx61oykU=.1561310e-e3eb-4ca8-86d7-faddc3940f9d@github.com>

Merge jdk-26+22

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

Commit messages:
 - Adjust testing
 - Merge tag 'jdk-26+22' into lworld_merge_jdk_26_22_incr
 - 8370807: G1: Improve region attribute table method naming
 - 8366968: Exhaustive switch expression rejected by for not covering all possible values
 - 8369013: Shenandoah: passive mode should support enabling ShenandoahCardBarrier
 - 8316274: javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java fails in Ubuntu 23.10 with Motif LAF
 - 8370797: Test runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java failed on macos 26
 - 8367059: DTLS: loss of NewSessionTicket message results in handshake failure
 - 8370568: Refer to Thread.interrupted as "interrupted status" consistently
 - 8370481: C2 SuperWord: Long/Integer.compareUnsigned return wrong value in SLP
 - ... and 93 more: https://git.openjdk.org/valhalla/compare/1cb01022...7a9737c9

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

Changes: https://git.openjdk.org/valhalla/pull/1725/files
  Stats: 14389 lines in 467 files changed: 8580 ins; 4103 del; 1706 mod
  Patch: https://git.openjdk.org/valhalla/pull/1725.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1725/head:pull/1725

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

From dsimms at openjdk.org  Fri Nov  7 07:02:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 7 Nov 2025 07:02:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <Bdjvgn0-umQO3juuapVheCzE22tzoCW6CyUFx61oykU=.1561310e-e3eb-4ca8-86d7-faddc3940f9d@github.com>
References: <Bdjvgn0-umQO3juuapVheCzE22tzoCW6CyUFx61oykU=.1561310e-e3eb-4ca8-86d7-faddc3940f9d@github.com>
Message-ID: <7QljzbWtjqdf6qP6ej9by5KFghCIccEDcx1ls7odqYU=.dbbb4d65-9710-43a6-ac68-cf385bbcb27f@github.com>

On Fri, 7 Nov 2025 06:51:49 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+22

This pull request has now been integrated.

Changeset: a7478081
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a74780818f624c574adfe3c3380996679ba93fd7
Stats:     14389 lines in 467 files changed: 8580 ins; 4103 del; 1706 mod

Merge jdk

Merge jdk-26+22

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

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

From mhaessig at openjdk.org  Fri Nov  7 09:53:39 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Fri, 7 Nov 2025 09:53:39 GMT
Subject: [lworld] Integrated: 8367244: [lworld] C2 compilation fails with
 assert "no node with a side effect"
In-Reply-To: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
References: <uiRq_HdR7A6EStvytV1Ca8PLkfUUx0NVv81jajfl6Pk=.0f286dcd-7f41-43d0-89ab-629b9ef0d6f1@github.com>
Message-ID: <PTvLwYaYkCL7WvIh_MD6mwlmtXfpGevGnG1OqcaOotA=.706fc05c-bee8-44ba-86ee-013624d2f118@github.com>

On Mon, 3 Nov 2025 14:12:55 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

> ## Problem Analysis
> 
> The stress test `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`, which uses the `StressUnstableIfTrap` flag, failed intermittently with the assert "no node with a side effect" during C2 compilation. I tracked down the origin of the failure to the raw store of the unstable if trap stress counter that was missing a memory edge to the backedge phi and thus had no side effect in the loop, which lead to the aforementioned assert. During parsing, the missing memory edge gets discarded with as vestigial parsing state when `do_if()` ends up `stopped()`. However, the effect of the stress counter should still be wired back into the backedge since it will be incremented in the next iteration.
> 
> ## Patch Description
> 
> To prevent the stress counters memory state being lost to `PreserveJVMState`, I pass it to the caller over an out-parameter and `set_memory` with that node, similar to what is already done for control. This is only necessary for the two last invocation of `do_if()` in `do_acmp()` where they are actually allowed to trap. Further, this PR reenables `StressUnstableIfTrap` in `compiler/valhalla/inlinetypes/TestAcmpWithUnstableIf.java`.
> 
> ## Testing
> 
> - [x] tier1,tier2,tier3 plus internal stress testing

This pull request has now been integrated.

Changeset: a0ec2441
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a0ec2441494f9e77b3a8a3db90358db239b27b4d
Stats:     85 lines in 4 files changed: 77 ins; 2 del; 6 mod

8367244: [lworld] C2 compilation fails with assert "no node with a side effect"

Reviewed-by: chagedorn

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

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

From phubner at openjdk.org  Fri Nov  7 10:08:26 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 7 Nov 2025 10:08:26 GMT
Subject: [lworld] RFR: 8371398: [lworld]
 runtime/valhalla/inlinetypes/FlatArrayCopyingTest.java#g1 fails due to lack of
 UnlockDiagnosticVMOptions
Message-ID: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>

Hi all,

The flag `UnlockDiagnosticVMOptions` should be set explicitly.

Tests: tier 1, tier 5.

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

Commit messages:
 - Explicitly enable diagnostic options.

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

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

From tobias.hartmann at oracle.com  Fri Nov  7 10:20:54 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 7 Nov 2025 11:20:54 +0100
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <e3ab50ab-1746-4f25-9cff-ceac29d98e62@oracle.com>

Vote: yes

Best regards,
Tobias

On 11/7/25 7:27 AM, David Simms wrote:
> I hereby nominate Daniel Daugherty [1] to Valhalla Committer.
> 
> Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].
> 
> Votes are due by November 21st, 2025, 0700Z.
> 
> Only current Valhalla Committers [3] are eligible to vote on this nomination. ?Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [4].
> 
> David Simms
> 
> [1] https://openjdk.org/census#dcubed
> [2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
> [3] https://openjdk.org/census
> [4] https://openjdk.org/projects/#committer-vote


From thartmann at openjdk.org  Fri Nov  7 10:32:30 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 10:32:30 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <VKfGcxToe_jv483w8s2got1s9zd3DAn_nYVLgVJGTZ4=.4fedd897-c8f5-403f-9b54-5dbb4c22635d@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

Given that this is not a Valhalla specific issue, I think this should be fixed in mainline. We can disable the verification in Valhalla or disable the command line in the test until the fix is merged.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3501740824

From tobias.hartmann at oracle.com  Fri Nov  7 10:39:48 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 7 Nov 2025 11:39:48 +0100
Subject: About flattening a nullable j.l.Long
In-Reply-To: <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
 <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
 <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <83faaddd-8097-40bf-94ff-41e608b3b269@oracle.com>

Right, the example provided by R?mi shows the issue. The null marker needs to be written atomically with the payload.

Best regards,
Tobias


On 11/6/25 2:02 PM, Remi Forax wrote:
> Hello,
> as far as i remember, the problem is that you can resurrect a value,
> for example with a Long
> 
> Thread1
>  ? a.x = new Long(12);
>  ? a.x = null;
>  ? IO.println(a.x); //12
> 
> Thread2
>  ? IO.println(a.x);? // null
>  ? a.x = new Long(77);? ?// descheduled in between writing the maker and writing the long
> 
> 
> The thread1 can see the Long(12) to be resurrected, something that is not possible with references.
> 
> regards,
> R?mi
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
>     *From: *"Qu?n Anh Mai" <anhmdq at gmail.com>
>     *To: *"David Alayachew" <davidalayachew at gmail.com>
>     *Cc: *"valhalla-dev" <valhalla-dev at openjdk.org>
>     *Sent: *Thursday, November 6, 2025 3:52:41 AM
>     *Subject: *Re: About flattening a nullable j.l.Long
> 
>     Ah yes, my bad, it is https://github.com/openjdk/valhalla/pull/1720 <https://github.com/openjdk/valhalla/pull/1720>
> 
>     On Thu, 6 Nov 2025 at 07:26, David Alayachew <davidalayachew at gmail.com <mailto:davidalayachew at gmail.com>> wrote:
> 
>         Just a heads up, your [1] is a dead link. Can you try to put the url in again?
> 
>         On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com <mailto:anhmdq at gmail.com>> wrote:
> 
>             Hi,
>             Currently, I'm having a PR that allows flattening of a nullable value?class with a 64-bit payload [1]. Dan Smith told me that some ideas along these lines were discussed a few years ago, and the consensus?was that it was a dead end. May I ask what the concerns were, and whether they are still relevant now?
> 
>             Thanks a lot,
>             Quan Anh
> 
> 


From thartmann at openjdk.org  Fri Nov  7 10:43:31 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 10:43:31 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long [v4]
In-Reply-To: <EQkdR7gABlfo0WeaPc9-apoD1p_yKmc1KMXqL4BdLwc=.7c483e3f-baa8-46f0-913b-5e7cb518278b@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <EQkdR7gABlfo0WeaPc9-apoD1p_yKmc1KMXqL4BdLwc=.7c483e3f-baa8-46f0-913b-5e7cb518278b@github.com>
Message-ID: <UDfthENvjXi4saL2VnhrpsVQhBQXMD5mQDcaskLw5_I=.c7a7db39-ce86-4c47-a8af-9cd4ac7c7224@github.com>

On Wed, 5 Nov 2025 04:25:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, the layout of a nullable `j.l.Long`, if flattened, must be at least 65 bits. This exceeds the maximum size a GPR can generally hold, as well as the default object alignment of Hotspot. As a result, accessing such elements atomically require 128-bit atomic accesses, as well as mechanism from the GC to allocate overaligned objects. And even then, we will encounter the same issue, just with larger objects.
>> 
>> We can observe that, a nullable element does not really have an additional bit of information, it just has an additional state (e.g. a nullable `j.l.Long` has `2^64 + 1` states, not `2^65`), and it is just unfortunate that we need a whole bit to be able to represent such an element.  However, we can rely on the fact that all payload bits are irrelevant when the null marker is 0 to make a sequence of more than 1 memory access instructions look atomic.
>> 
>> C1 has not been implemented yet, we will bailout the compilation when encountering such an access. I will implement this functionality later.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing barrier

>Ended up concluding that it was a dead end?I'd suggest discussing on [valhalla-dev at openjdk.org](mailto:valhalla-dev at openjdk.org) if you'd like to understand what the concerns were.

FTR, @forax provided an example here: https://mail.openjdk.org/pipermail/valhalla-dev/2025-November/016074.html

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3501798087

From thartmann at openjdk.org  Fri Nov  7 10:51:32 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 7 Nov 2025 10:51:32 GMT
Subject: [lworld] RFR: 8371199: [lworld] Flattening of nullable elements of
 classes similar to j.l.Long
In-Reply-To: <-ipD8MAdZzoJaxMAm7u5vL75p-yPYXBq1yes088ztN0=.e70e699a-b18e-4d4d-9847-4ba7c057022f@github.com>
References: <bgTY78GQQcCgEwiLHl4c82NT6pGnJ3RyKIQs_MaTyuM=.faaa483e-753b-43dd-9431-7f0658820638@github.com>
 <OaefRz3MhfdyUP7Hdu3PerI2Z4gLLcXGb_-9lfFQGr8=.34e2d19f-de05-4cbd-a24b-ecaef8c5a406@github.com>
 <20fzSPeTCAEy47QccETAmCy4xGSEgCVd_v5T8_VYyWU=.a00188ff-17cc-41e2-9225-385167cfefbd@github.com>
 <-ipD8MAdZzoJaxMAm7u5vL75p-yPYXBq1yes088ztN0=.e70e699a-b18e-4d4d-9847-4ba7c057022f@github.com>
Message-ID: <39c50j6G2j4gq8xhtGN3gnL-XHjOQSNKxWeouc_fMeA=.a91b9334-051b-4c3f-8c4b-7be937af981b@github.com>

On Wed, 5 Nov 2025 07:31:06 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> @forax Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.
>> 
>> For your second point, `Unsafe::putFlatValue` and `Unsafe::getFlatValue` will call into `InlineKlass::write_value_to_addr` and `InlineKlass::read_payload_from_addr`, respectively, which are covered by this patch. `j.l.i.VarHandleNonAtomicFlatValues`, in turns, calls `Unsafe::getFlatValue` for the `get` method and `Unsafe::putFlatValue` for the set method. So, I believe they are also fine.
>
>> Suppose a value class like this `value record(String name, int idx)`, then it should contain a pointer in its payload.
> 
> I don't know how this is currently implemented in the GC, but wouldn't it make sense for the GC to check whether the value is marked as null first, and ignore the rest of the value in that case?
> 
> Especially for ZGC flattening currently doesn't happen even for `value record(String name)` from my understanding (and more generally, with compressed oops disabled?), this might be beneficial. I don't know how this interacts with GC barriers, there is most likely more to it than I know of :)
> 
> That said, restricting to payloads without oops makes this change easier to reason about, so - assuming it makes sense - extending to payloads with oops as a follow-up might be better.

@SirYwell @forax I think there's some confusion around the GC related code here. First of all, this is not specific to @merykitty's changes. This is **not** new, he just moved existing code.

That particular code is needed to support 64-bit flat accesses with one or two 32-bit compressed oops. Currently, two oops are only possible if the field/array is null-free. Different GCs need different barriers, so we need to emit different code depending on which GC is used.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1720#issuecomment-3501840147

From mchevalier at openjdk.org  Fri Nov  7 11:02:30 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 7 Nov 2025 11:02:30 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <ydOVk0k727f_tlJPQsnVH_lEjdsOfS75RIYTGrSbD2k=.4ce783ff-8a92-4841-b0b4-9a14f98189c0@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
 <INVA4uSgrU1fx6TjeobK8vor8PI1yVKYgZ5AzpttwHU=.ac5718b1-5234-4ee5-8596-ecffb34736a3@github.com>
 <_Fnvu4eCvlEZPfYRSadNbVZNarO52xYd-nZwphNjUGc=.f4ffc1cf-5f44-462c-bf56-3d5572e00428@github.com>
 <fVJ2njJHvVh0TbZTQoNCRihAza4HInhHSq4LubaYErw=.57c6922f-55be-48df-beb1-73dccf2dfb35@github.com>
 <ydOVk0k727f_tlJPQsnVH_lEjdsOfS75RIYTGrSbD2k=.4ce783ff-8a92-4841-b0b4-9a14f98189c0@github.com>
Message-ID: <LkJ0s4r3mS1t3v3--GDocd_DURU7TZVpPl7p3DVoeMk=.6bda27c7-91ac-4f30-9da9-55803e987d9c@github.com>

On Thu, 6 Nov 2025 11:17:58 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I think the rationale is that if we're seeing conflicting profile, there's a good chance profile data is inaccurate and we can as well ignore it.

That makes sense. It's more practical than ignoring it everywhere we use it when it's oddly too specific. Indeed, speculative types don't need to be sound (or complete), and they start with a (probably) unsound premise: profiling data. I wonder if we are implicitly expecting too much soundness from the speculative type in the verification process.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3501882936

From davidalayachew at gmail.com  Fri Nov  7 12:43:27 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 7 Nov 2025 07:43:27 -0500
Subject: Question about JEP 401 Feedback
Message-ID: <CAA9v-_M+Sex43z4mcR3WksgVBvKnbVXeZybXiLwJ2wGYbJOkKQ@mail.gmail.com>

Hello @valhalla-dev <valhalla-dev at openjdk.org>,

I have spent the past week or so playing around with the JEP 401 EA,
gathering a bunch of data. I am nearing completion with the data-gathering
phase, and preparing myself to start writing my experience.

However, I wanted to confirm what type of experience report is wanted for
this JEP 401. It's been mentioned in multiple places that many of the
performance optimizations one would come to expect with Valhalla have yet
to be implemented yet. Understandable -- this is still just the EA of JEP
401.

So does that mean that experience reports should avoid talking about
potential performance increases/decreases? Or should we focus on the
usability and ergonomics of the language feature? Or is this just a typical
experience report, where we just speak freely about what did and didn't
work when trying on a real world program?

I'll post this thread to reddit once receiving answers. That way, others
who see that post will be able to format their experience reports
appropriately as well.

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251107/80735c12/attachment-0001.htm>

From lois.foltan at oracle.com  Fri Nov  7 13:15:44 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 7 Nov 2025 13:15:44 +0000
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <BLAPR10MB515641E3BCC52DBC5D91790E8AC3A@BLAPR10MB5156.namprd10.prod.outlook.com>

Vote: yes

Lois

From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Date: Friday, November 7, 2025 at 1:27?AM
To: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Daniel Daugherty
I hereby nominate Daniel Daugherty [1] to Valhalla Committer.

Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].

Votes are due by November 21st, 2025, 0700Z.

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

For Lazy Consensus voting instructions, see [4].

David Simms

[1] https://openjdk.org/census#dcubed
[2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
[3] https://openjdk.org/census
[4] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251107/310a64ce/attachment.htm>

From duke at openjdk.org  Fri Nov  7 13:21:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 13:21:08 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v4]
In-Reply-To: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
Message-ID: <an5dEaWJvUz6lzS8CbMB3a0Rq_tKNswIsZEcOLrBxGM=.9e66cdc1-633c-400a-bf8d-dd4e8d757075@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

David Beaumont 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 16 additional commits since the last revision:

 - Copy value classes into preview directories for inclusion in jimage
 - Rename ModuleReference methods back.
 - [[AUTOMATIC FORMATTING]]
 - fixing jlink issue
 - Feedback and test fix
 - Minor feedback changes
 - [[AUTOMATIC FORMATTING]]
 - fixing tests after refactoring
 - Fixing up after dependent PR changes
 - feedback and remove unused code
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/3b7c8cc3...4fda33ae

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1719/files
  - new: https://git.openjdk.org/valhalla/pull/1719/files/3b7c8cc3..4fda33ae

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

  Stats: 1622 lines in 35 files changed: 273 ins; 386 del; 963 mod
  Patch: https://git.openjdk.org/valhalla/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1719/head:pull/1719

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

From duke at openjdk.org  Fri Nov  7 13:24:30 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 13:24:30 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
 <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
 <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>
Message-ID: <6mX7TbJ8LjkE5vGyqJeD7TVtRNBqB6zNVfOYHzAulY4=.888d9738-f714-4c4b-8089-e4acb099ad2e@github.com>

On Thu, 6 Nov 2025 22:51:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Rollup of makefile changes and jlink fix (temp).
>>   
>>   * likely test fix
>>   * Copy value classes into preview directories for inclusion in jimage
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 305:
> 
>> 303: 
>> 304:         /**
>> 305:          *  line: {@code <int>|<int>|<hashOrTarget>|<path>}
> 
> For internal doc/methods, javadoc markup makes the source harder to read.

The I'll either make it a `///` markup comment or a plain `/*` block comment.
Making `/**` comment blocks and then putting invalid HTML in is making it harder (sometimes impossible) to be read in an IDE.
If this comment is only about people reading it in source code, it should never have been a "JavaDoc" comment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2503512252

From duke at openjdk.org  Fri Nov  7 13:41:40 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 13:41:40 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
 <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
 <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>
Message-ID: <EhUMpJPKCVDVjQkuPDgYL96c-QwQ6txmWwaV_UGDbc0=.5c8e9317-c8e6-4f01-8acb-0e87a0f2678c@github.com>

On Thu, 6 Nov 2025 22:24:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.
>
> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 365:
> 
>> 363:                 if (name.startsWith("/modules/") || name.startsWith("/packages/")) {
>> 364:                     throw new IllegalArgumentException("Invalid entry name: " + name);
>> 365:                 }
> 
> This can be covered by the == null case below. The distinguished exception isn't necessary.

Note that these changes were only temporary in this PR as a way to let people see where this was going.
They're being reverted and this PR reset to the 
I wasn't expecting anyone to try and review it. Sorry.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2503601081

From duke at openjdk.org  Fri Nov  7 13:46:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 13:46:32 GMT
Subject: Withdrawn: 8368475: [lworld] Add preview classes to jimage at make
 time
In-Reply-To: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
Message-ID: <CeE-An2hwpy18rcNVEJw3iC9Z9v5-azC6cWkckQuBEA=.02e1034f-4f87-4e1e-b5cb-03bffe3d7a03@github.com>

On Tue, 4 Nov 2025 17:28:36 GMT, David Beaumont <duke at openjdk.org> wrote:

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Nov  7 13:57:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 13:57:00 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at make
 time
Message-ID: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>

Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.

There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).

To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

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

Commit messages:
 - Copy value classes into preview directories for inclusion in jimage

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

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

From duke at openjdk.org  Fri Nov  7 14:29:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 14:29:51 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v7]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <T6-vqB9yGPTwhwf0isRUOJs2w5h6wzsz4V8t4H7XzJM=.121e5f82-bff4-41d1-af29-cbb965caa109@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

  Feedback changes.
  
  * copyright update
  * feedback changes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/1f85ff74..726ace98

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

  Stats: 37 lines in 5 files changed: 13 ins; 3 del; 21 mod
  Patch: https://git.openjdk.org/valhalla/pull/1721.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1721/head:pull/1721

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

From duke at openjdk.org  Fri Nov  7 14:41:32 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 14:41:32 GMT
Subject: RFR: 8368475: [lworld] Add preview classes to jimage at make time
 [v3]
In-Reply-To: <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>
References: <apPQi1NeHWde9NHjuQ8VCfDS0zeszwhTKJi1x-kKw3U=.3d5f5345-31c4-4e5a-a418-c6665a538129@github.com>
 <1BUX-fn_ynHsWcO88cLiUWgffgpLGXrx8wHWYdUypUQ=.eed7d42a-0bde-4254-bd25-b2c4377a4351@github.com>
 <KexVeM9AFzN0mzegFs90JP5-U_nLLbe1hnwNcxpRIpU=.797185b2-3889-4d56-bb73-f48d3209780f@github.com>
Message-ID: <096S-rS2uNCBFmLuKCly1GoDpAnE0EY9gKEHV4m0AhQ=.fc9b3809-1f96-4cc4-a50d-ed7874912388@github.com>

On Thu, 6 Nov 2025 22:33:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Rollup of makefile changes and jlink fix (temp).
>>   
>>   * likely test fix
>>   * Copy value classes into preview directories for inclusion in jimage
>
> src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 24:
> 
>> 22:      * Returns the full entry names for all resources in the given module, in
>> 23:      * random order. Entry names will always be prefixed by the given module
>> 24:      * name (e.g. "/<module-name/...").
> 
> Are these names useful with any ImageReader api other than ResourceEntries.sizeOf or open?

Yes, they are just the well defined jimage names for things (think similar to JAR entry names).
I tweaked the wording in 1721 to refer to them as "jimage names".

> src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 26:
> 
>> 24:      * name (e.g. "/<module-name/...").
>> 25:      */
>> 26:     Stream<String> entryNamesIn(String module);
> 
> A cleaner name would be `entryNames`.

Changed to getEntryNames() and getSize() in 1721.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2503891128
PR Review Comment: https://git.openjdk.org/valhalla/pull/1719#discussion_r2503886149

From duke at openjdk.org  Fri Nov  7 14:50:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 14:50:18 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v8]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <oQ-iVitEnY19IPrIHBrRfj_ybox7Y8l_93FXD0ncgpM=.37b0d20f-3a32-4d3e-afda-c9c7b0072e40@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

  comment adjustment

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/726ace98..de2c1be8

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

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

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

From fparain at openjdk.org  Fri Nov  7 14:53:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 7 Nov 2025 14:53:32 GMT
Subject: [lworld] RFR: 8371398: [lworld]
 runtime/valhalla/inlinetypes/FlatArrayCopyingTest.java#g1 fails due to lack of
 UnlockDiagnosticVMOptions
In-Reply-To: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
References: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
Message-ID: <a2HU0vqhpETh0D7VmbreUgvYL3EajQYeBg7ml4edQ0c=.23a7a689-15d6-4403-b6e9-b9b18f63ac54@github.com>

On Fri, 7 Nov 2025 10:01:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The flag `UnlockDiagnosticVMOptions` should be set explicitly.
> 
> Tests: tier 1, tier 5.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1726#pullrequestreview-3434453284

From frederic.parain at oracle.com  Fri Nov  7 15:13:16 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 7 Nov 2025 10:13:16 -0500
Subject: About flattening a nullable j.l.Long
In-Reply-To: <83faaddd-8097-40bf-94ff-41e608b3b269@oracle.com>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
 <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
 <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
 <83faaddd-8097-40bf-94ff-41e608b3b269@oracle.com>
Message-ID: <ab67f828-0e9d-4539-9e7c-3859f2e2d356@oracle.com>

Here's a write-up from John Rose on this subject:

https://cr.openjdk.org/~jrose/values/NullabilityRequiresConsistency.java.txt

Fred


On 11/7/25 05:39, Tobias Hartmann wrote:
> Right, the example provided by R?mi shows the issue. The null marker 
> needs to be written atomically with the payload.
>
> Best regards,
> Tobias
>
>
> On 11/6/25 2:02 PM, Remi Forax wrote:
>> Hello,
>> as far as i remember, the problem is that you can resurrect a value,
>> for example with a Long
>>
>> Thread1
>> ?? a.x = new Long(12);
>> ?? a.x = null;
>> ?? IO.println(a.x); //12
>>
>> Thread2
>> ?? IO.println(a.x);? // null
>> ?? a.x = new Long(77);? ?// descheduled in between writing the maker 
>> and writing the long
>>
>>
>> The thread1 can see the Long(12) to be resurrected, something that is 
>> not possible with references.
>>
>> regards,
>> R?mi
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ 
>>
>>
>> ??? *From: *"Qu?n Anh Mai" <anhmdq at gmail.com>
>> ??? *To: *"David Alayachew" <davidalayachew at gmail.com>
>> ??? *Cc: *"valhalla-dev" <valhalla-dev at openjdk.org>
>> ??? *Sent: *Thursday, November 6, 2025 3:52:41 AM
>> ??? *Subject: *Re: About flattening a nullable j.l.Long
>>
>> ??? Ah yes, my bad, it is 
>> https://github.com/openjdk/valhalla/pull/1720 
>> <https://github.com/openjdk/valhalla/pull/1720>
>>
>> ??? On Thu, 6 Nov 2025 at 07:26, David Alayachew 
>> <davidalayachew at gmail.com <mailto:davidalayachew at gmail.com>> wrote:
>>
>> ??????? Just a heads up, your [1] is a dead link. Can you try to put 
>> the url in again?
>>
>> ??????? On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com 
>> <mailto:anhmdq at gmail.com>> wrote:
>>
>> ??????????? Hi,
>> ??????????? Currently, I'm having a PR that allows flattening of a 
>> nullable value?class with a 64-bit payload [1]. Dan Smith told me 
>> that some ideas along these lines were discussed a few years ago, and 
>> the consensus?was that it was a dead end. May I ask what the concerns 
>> were, and whether they are still relevant now?
>>
>> ??????????? Thanks a lot,
>> ??????????? Quan Anh
>>
>>
>

From phubner at openjdk.org  Fri Nov  7 15:14:17 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 7 Nov 2025 15:14:17 GMT
Subject: [lworld] RFR: 8371398: [lworld]
 runtime/valhalla/inlinetypes/FlatArrayCopyingTest.java#g1 fails due to lack of
 UnlockDiagnosticVMOptions [v2]
In-Reply-To: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
References: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
Message-ID: <bBZXtugVs2lui7droHAPUjzu_vQg-cYKnE9NoSxcMbg=.cc9d55f6-1166-48df-8117-bf671d4b8b75@github.com>

> Hi all,
> 
> The flag `UnlockDiagnosticVMOptions` should be set explicitly.
> 
> Tests: tier 1, tier 5.

Paul H?bner 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 two additional commits since the last revision:

 - Merge branch 'lworld' into JDK-8371398
 - Explicitly enable diagnostic options.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1726/files
  - new: https://git.openjdk.org/valhalla/pull/1726/files/2753e2fb..ba4fb988

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

  Stats: 14389 lines in 467 files changed: 8580 ins; 4103 del; 1706 mod
  Patch: https://git.openjdk.org/valhalla/pull/1726.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1726/head:pull/1726

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

From vicente.romero at oracle.com  Fri Nov  7 15:19:44 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Fri, 7 Nov 2025 10:19:44 -0500
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <34c28929-df85-4fbc-84b3-51731a5e8a2c@oracle.com>

vote: yes

Vicente

On 11/7/25 01:27, David Simms wrote:
> I hereby nominate Daniel Daugherty [1] to Valhalla Committer.
>
> Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].
>
> Votes are due by November 21st, 2025, 0700Z.
>
> Only current Valhalla Committers [3] are eligible to vote on this nomination. ?Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [4].
>
> David Simms
>
> [1] https://openjdk.org/census#dcubed
> [2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
> [3] https://openjdk.org/census
> [4] https://openjdk.org/projects/#committer-vote


From frederic.parain at oracle.com  Fri Nov  7 15:20:52 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 7 Nov 2025 10:20:52 -0500
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <889549fe-c966-4a59-93a4-a238ff68e035@oracle.com>

Vote: yes

Fred


On 11/7/25 01:27, David Simms wrote:
> I hereby nominate Daniel Daugherty [1] to Valhalla Committer.
>
> Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].
>
> Votes are due by November 21st, 2025, 0700Z.
>
> Only current Valhalla Committers [3] are eligible to vote on this nomination. ?Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [4].
>
> David Simms
>
> [1] https://openjdk.org/census#dcubed
> [2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
> [3] https://openjdk.org/census
> [4] https://openjdk.org/projects/#committer-vote

From duke at openjdk.org  Fri Nov  7 15:40:48 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 7 Nov 2025 15:40:48 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v6]
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <ueGV_53MRa3Yu4fJeg-Aude3yjffMpKwhKnF0UF_pWc=.6ca7b9a1-c3ac-4602-b687-e481f4907864@github.com>

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

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

 - Merge branch 'lworld' into jdk_8368467_reader/squashed
 - Rename ModuleReference methods back.
 - fixing jlink issue
 - Feedback and test fix
 - Minor feedback changes
 - Roll up of writer changes.
   
   * fixing tests after refactoring
   * Fixing up after dependent PR changes
   * feedback and remove unused code
   * new tests for ImageLocation
   * Restoring lost changes and updating some comments.
   * add system property guard to preview mode
   * Remove TODOs now jimage version is bumped
   * jimage writer changes to support preview mode.

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

Changes: https://git.openjdk.org/valhalla/pull/1718/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1718&range=05
  Stats: 2089 lines in 16 files changed: 893 ins; 163 del; 1033 mod
  Patch: https://git.openjdk.org/valhalla/pull/1718.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1718/head:pull/1718

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

From rriggs at openjdk.org  Fri Nov  7 15:56:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 15:56:29 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v5]
In-Reply-To: <0Z0GWagr7CiINBZ_KQmm2cZkX_clxw-CiO6surKEkZI=.67e8f880-649e-4cfb-a8cd-37ffd53116b3@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <0Z0GWagr7CiINBZ_KQmm2cZkX_clxw-CiO6surKEkZI=.67e8f880-649e-4cfb-a8cd-37ffd53116b3@github.com>
Message-ID: <d5nQcNIfX2VdYOvv4AepTuSIvQgXX0SD9rVkKuumwYA=.4c2da346-a790-40b0-9f15-5bbd5b86c3c0@github.com>

On Wed, 5 Nov 2025 14:15:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tidied up diff code in test.

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 365:

> 363:                 if (name.startsWith("/modules/") || name.startsWith("/packages/")) {
> 364:                     throw new IllegalArgumentException("Invalid entry name: " + name);
> 365:                 }

This is already covered by the == null case below. The distinguished exception isn't necessary.

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 35:

> 33:  * <p>This API is designed only for use by the jlink classes, which manipulate
> 34:  * jimage files directly. For inspection of runtime resources, it is vital that
> 35:  * {@code previewMode} is correctly observed, making this API unsuitable.

This would be more clearly stated as use API xxx to access the classes and resources of a runtime.

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 56:

> 54:      * name (e.g. {@code "/<module-name>/..."}).
> 55:      */
> 56:     Stream<String> entryNamesIn(String module);

Are these names useful with any ImageReader api other than sizeOf or open?

src/java.base/share/classes/jdk/internal/jimage/ResourceEntries.java line 56:

> 54:      * name (e.g. {@code "/<module-name>/..."}).
> 55:      */
> 56:     Stream<String> entryNamesIn(String module);

Those extra words at the end of the method name are not consistent with naming conventions in openjdk.
Drop the "In".

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2494836681
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2494742427
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2494774562
PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2494788265

From rriggs at openjdk.org  Fri Nov  7 15:56:31 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 15:56:31 GMT
Subject: RFR: [lworld] Switch JLink to not use ImageReader API [v8]
In-Reply-To: <oQ-iVitEnY19IPrIHBrRfj_ybox7Y8l_93FXD0ncgpM=.37b0d20f-3a32-4d3e-afda-c9c7b0072e40@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <oQ-iVitEnY19IPrIHBrRfj_ybox7Y8l_93FXD0ncgpM=.37b0d20f-3a32-4d3e-afda-c9c7b0072e40@github.com>
Message-ID: <B6eSQDmD-t_KIDbSx3D8ZX48HqWYiYrmD0RrCris0vk=.3ab7b9f9-44ab-4fc3-9c31-c69f06ca9158@github.com>

On Fri, 7 Nov 2025 14:50:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment adjustment

test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java line 57:

> 55:  * @build tests.* jdk.test.lib.process.OutputAnalyzer
> 56:  *        jdk.test.lib.process.ProcessTools
> 57:  * @run main/othervm/timeout=1200 -ea -esa -DDISABLE_PREVIEW_PATCHING=false -Xmx1g PackagedModulesVsRuntimeImageLinkTest

Should this test (temporarily) be run both with and without the new packaging?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2504248201

From davidalayachew at gmail.com  Fri Nov  7 16:03:34 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 7 Nov 2025 11:03:34 -0500
Subject: About flattening a nullable j.l.Long
In-Reply-To: <ab67f828-0e9d-4539-9e7c-3859f2e2d356@oracle.com>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
 <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
 <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
 <83faaddd-8097-40bf-94ff-41e608b3b269@oracle.com>
 <ab67f828-0e9d-4539-9e7c-3859f2e2d356@oracle.com>
Message-ID: <CAA9v-_O5W9jhrm-whSw7q-=6T_ve1HCrGz3NAXUGw-=18V+jsg@mail.gmail.com>

?

David reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

On Fri, Nov 7, 2025, 10:13?AM Frederic Parain <frederic.parain at oracle.com>
wrote:

> Here's a write-up from John Rose on this subject:
>
>
> https://cr.openjdk.org/~jrose/values/NullabilityRequiresConsistency.java.txt
>
> Fred
>
>
> On 11/7/25 05:39, Tobias Hartmann wrote:
> > Right, the example provided by R?mi shows the issue. The null marker
> > needs to be written atomically with the payload.
> >
> > Best regards,
> > Tobias
> >
> >
> > On 11/6/25 2:02 PM, Remi Forax wrote:
> >> Hello,
> >> as far as i remember, the problem is that you can resurrect a value,
> >> for example with a Long
> >>
> >> Thread1
> >>    a.x = new Long(12);
> >>    a.x = null;
> >>    IO.println(a.x); //12
> >>
> >> Thread2
> >>    IO.println(a.x);  // null
> >>    a.x = new Long(77);   // descheduled in between writing the maker
> >> and writing the long
> >>
> >>
> >> The thread1 can see the Long(12) to be resurrected, something that is
> >> not possible with references.
> >>
> >> regards,
> >> R?mi
> >>
> >>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> >>
> >>
> >>     *From: *"Qu?n Anh Mai" <anhmdq at gmail.com>
> >>     *To: *"David Alayachew" <davidalayachew at gmail.com>
> >>     *Cc: *"valhalla-dev" <valhalla-dev at openjdk.org>
> >>     *Sent: *Thursday, November 6, 2025 3:52:41 AM
> >>     *Subject: *Re: About flattening a nullable j.l.Long
> >>
> >>     Ah yes, my bad, it is
> >> https://github.com/openjdk/valhalla/pull/1720
> >> <https://github.com/openjdk/valhalla/pull/1720>
> >>
> >>     On Thu, 6 Nov 2025 at 07:26, David Alayachew
> >> <davidalayachew at gmail.com <mailto:davidalayachew at gmail.com>> wrote:
> >>
> >>         Just a heads up, your [1] is a dead link. Can you try to put
> >> the url in again?
> >>
> >>         On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com
> >> <mailto:anhmdq at gmail.com>> wrote:
> >>
> >>             Hi,
> >>             Currently, I'm having a PR that allows flattening of a
> >> nullable value class with a 64-bit payload [1]. Dan Smith told me
> >> that some ideas along these lines were discussed a few years ago, and
> >> the consensus was that it was a dead end. May I ask what the concerns
> >> were, and whether they are still relevant now?
> >>
> >>             Thanks a lot,
> >>             Quan Anh
> >>
> >>
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/vnd.google.email-reaction+json
Size: 37 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251107/c9445b92/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251107/c9445b92/attachment.htm>

From roger.riggs at oracle.com  Fri Nov  7 16:28:08 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 7 Nov 2025 11:28:08 -0500
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <17bedc28-76a4-41f1-b033-d2ddf50774ef@oracle.com>

Vote: Yes

On 11/7/25 1:27 AM, David Simms wrote:
> I hereby nominate Daniel Daugherty [1] to Valhalla Committer.


From rriggs at openjdk.org  Fri Nov  7 16:30:30 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Nov 2025 16:30:30 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v6]
In-Reply-To: <ueGV_53MRa3Yu4fJeg-Aude3yjffMpKwhKnF0UF_pWc=.6ca7b9a1-c3ac-4602-b687-e481f4907864@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <ueGV_53MRa3Yu4fJeg-Aude3yjffMpKwhKnF0UF_pWc=.6ca7b9a1-c3ac-4602-b687-e481f4907864@github.com>
Message-ID: <RtTqFh_VfjuQ4U4iiIsaibRDMB9wwATmwBMzGJsvleo=.e6258aee-9b0d-45be-88bc-157856c3cfe7@github.com>

On Fri, 7 Nov 2025 15:40:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'lworld' into jdk_8368467_reader/squashed
>  - Rename ModuleReference methods back.
>  - fixing jlink issue
>  - Feedback and test fix
>  - Minor feedback changes
>  - Roll up of writer changes.
>    
>    * fixing tests after refactoring
>    * Fixing up after dependent PR changes
>    * feedback and remove unused code
>    * new tests for ImageLocation
>    * Restoring lost changes and updating some comments.
>    * add system property guard to preview mode
>    * Remove TODOs now jimage version is bumped
>    * jimage writer changes to support preview mode.

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1718#pullrequestreview-3435034773

From duke at openjdk.org  Fri Nov  7 16:50:34 2025
From: duke at openjdk.org (duke)
Date: Fri, 7 Nov 2025 16:50:34 GMT
Subject: [lworld] RFR: 8368467: [lworld] Add new flag generation for jimage
 to support preview mode [v6]
In-Reply-To: <ueGV_53MRa3Yu4fJeg-Aude3yjffMpKwhKnF0UF_pWc=.6ca7b9a1-c3ac-4602-b687-e481f4907864@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
 <ueGV_53MRa3Yu4fJeg-Aude3yjffMpKwhKnF0UF_pWc=.6ca7b9a1-c3ac-4602-b687-e481f4907864@github.com>
Message-ID: <aCQdSfvKM4600ND0q7z5hMZYRSDyqo_4n7Sjx0jSSig=.a8835cc5-5507-46ed-8b77-ebc93b9b1879@github.com>

On Fri, 7 Nov 2025 15:40:48 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Adds support for writing preview related flags into jimage files.
>> 
>> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
>> 
>> Specific issues include:
>> 
>> Supporting preview-only resources without forcing a double lookup on everything.
>> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
>> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
>> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
>> 
>> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
>> 
>> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
>> 
>> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'lworld' into jdk_8368467_reader/squashed
>  - Rename ModuleReference methods back.
>  - fixing jlink issue
>  - Feedback and test fix
>  - Minor feedback changes
>  - Roll up of writer changes.
>    
>    * fixing tests after refactoring
>    * Fixing up after dependent PR changes
>    * feedback and remove unused code
>    * new tests for ImageLocation
>    * Restoring lost changes and updating some comments.
>    * add system property guard to preview mode
>    * Remove TODOs now jimage version is bumped
>    * jimage writer changes to support preview mode.

@david-beaumont 
Your change (at version e8ca1c4edd4e4ac829723ebb29d4a60049f1fcbb) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1718#issuecomment-3503618333

From anhmdq at gmail.com  Fri Nov  7 17:06:53 2025
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Sat, 8 Nov 2025 00:06:53 +0700
Subject: About flattening a nullable j.l.Long
In-Reply-To: <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
 <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
 <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAPvyiyKxwCQpyKj6oSNZ-goGJ0eqKOUm9Do8+LsGwRP3Ago8tQ@mail.gmail.com>

Hi,

Thanks a lot for your answer. After thinking about it for a while, I think
it is true that this approach will not work. While it is true that a field
load must act as if it observes 1 of the concurrent stores, I forgot to
take into consideration the possibility that such store may be rendered
invalid due to a store of null happens after it. It seems that for
atomicity to hold, the store must be atomic, and there is no way around
that. How unfortunate!

Regards,
Quan Anh


On Thu, 6 Nov 2025 at 20:02, Remi Forax <forax at univ-mlv.fr> wrote:

> Hello,
> as far as i remember, the problem is that you can resurrect a value,
> for example with a Long
>
> Thread1
>   a.x = new Long(12);
>   a.x = null;
>   IO.println(a.x); //12
>
> Thread2
>   IO.println(a.x);  // null
>   a.x = new Long(77);   // descheduled in between writing the maker and
> writing the long
>
>
> The thread1 can see the Long(12) to be resurrected, something that is not
> possible with references.
>
> regards,
> R?mi
>
> ------------------------------
>
> *From: *"Qu?n Anh Mai" <anhmdq at gmail.com>
> *To: *"David Alayachew" <davidalayachew at gmail.com>
> *Cc: *"valhalla-dev" <valhalla-dev at openjdk.org>
> *Sent: *Thursday, November 6, 2025 3:52:41 AM
> *Subject: *Re: About flattening a nullable j.l.Long
>
> Ah yes, my bad, it is https://github.com/openjdk/valhalla/pull/1720
>
> On Thu, 6 Nov 2025 at 07:26, David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Just a heads up, your [1] is a dead link. Can you try to put the url in
>> again?
>>
>> On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>>
>>> Hi,
>>> Currently, I'm having a PR that allows flattening of a nullable
>>> value class with a 64-bit payload [1]. Dan Smith told me that some ideas
>>> along these lines were discussed a few years ago, and the consensus was
>>> that it was a dead end. May I ask what the concerns were, and whether they
>>> are still relevant now?
>>>
>>> Thanks a lot,
>>> Quan Anh
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251108/f6d5d93a/attachment-0001.htm>

From vromero at openjdk.org  Fri Nov  7 19:14:22 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 7 Nov 2025 19:14:22 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer that
 refers to a superclass field
Message-ID: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>

Javac is accepting this code:


abstract value class ValueParent {
    int b = 5;
}

value class ValueClass extends ValueParent {
    int a = b;
}

This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden

TIA

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

Commit messages:
 - 8371382: [lworld] Javac accepts field initializer that refers to a superclass field

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

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

From vromero at openjdk.org  Fri Nov  7 19:18:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 7 Nov 2025 19:18:45 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v2]
In-Reply-To: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
Message-ID: <N0553wCMhVEGodSphnbjvYGI9vMy54rHylU8BncCwaY=.db9aaca8-dd31-44e2-932c-84b27a6b24ac@github.com>

> Javac is accepting this code:
> 
> 
> abstract value class ValueParent {
>     int b = 5;
> }
> 
> value class ValueClass extends ValueParent {
>     int a = b;
> }
> 
> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
> 
> TIA

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

  additional test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1728/files
  - new: https://git.openjdk.org/valhalla/pull/1728/files/e73c8d8a..e0aa3646

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

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

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

From amenkov at openjdk.org  Fri Nov  7 19:30:26 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Nov 2025 19:30:26 GMT
Subject: [lworld] Integrated: 8341771: [lworld] Heap dump recognizing new flat
 fields formats
In-Reply-To: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
References: <_BI116y1BH6TPq_uraQ4d89TelZv8Fh6Du6HhlK08ww=.6243c3e7-f602-4f74-b231-dda3c6c62583@github.com>
Message-ID: <lVW1fWqC0WDuemDfJeVbgAQ03Q707n4kKyX6HIu-lGI=.f0e94de4-98fb-4f70-9df3-0fe946ca192f@github.com>

On Fri, 24 Oct 2025 00:57:03 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix re-implements flat object support in heap dumper.
> New approach does not require changes in .hprof format.
> Flat value objects are dumped as heap-allocated objects with generated ID.
> For heap-allocated objects the ID is their address (oop), they are always aligned.
> ID generator for flat objects uses unaligned values (so there is no conflicts with oops).
> 
> HeapDump test was reimplemented (it was disabled for a long time)
> Changes in hprof test lib were reverted (they are not needed anymore)
> 
> testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: 296fe862
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/296fe862f73ad92093d62372141dc848a3e42d72
Stats:     1418 lines in 10 files changed: 295 ins; 941 del; 182 mod

8341771: [lworld] Heap dump recognizing new flat fields formats
8328468: [lworld] Reimplement HeapDump test for JEP401
8317416: [lworld] JDK-8306441 (Two phase segmented heap dump) needs Valhalla support

Reviewed-by: fparain

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

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

From daniel.smith at oracle.com  Fri Nov  7 20:36:59 2025
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 7 Nov 2025 20:36:59 +0000
Subject: Question about JEP 401 Feedback
In-Reply-To: <CAA9v-_M+Sex43z4mcR3WksgVBvKnbVXeZybXiLwJ2wGYbJOkKQ@mail.gmail.com>
References: <CAA9v-_M+Sex43z4mcR3WksgVBvKnbVXeZybXiLwJ2wGYbJOkKQ@mail.gmail.com>
Message-ID: <EF895DDF-A502-4037-8887-7DFCA2541448@oracle.com>

> On Nov 7, 2025, at 4:43?AM, David Alayachew <davidalayachew at gmail.com> wrote:
> 
> Hello @valhalla-dev,
> 
> I have spent the past week or so playing around with the JEP 401 EA, gathering a bunch of data. I am nearing completion with the data-gathering phase, and preparing myself to start writing my experience.

Good to hear, look forward to reading about it!

> However, I wanted to confirm what type of experience report is wanted for this JEP 401. It's been mentioned in multiple places that many of the performance optimizations one would come to expect with Valhalla have yet to be implemented yet. Understandable -- this is still just the EA of JEP 401.
> 
> So does that mean that experience reports should avoid talking about potential performance increases/decreases? Or should we focus on the usability and ergonomics of the language feature? Or is this just a typical experience report, where we just speak freely about what did and didn't work when trying on a real world program?

Oh, we're definitely interested in your experiences with performance. Let us know where you see value classes helping, where expected gains don't seem to materialize, or where there are regressions.

As you say, there are some gains you might hope for that simply aren't implemented yet. JEP 401 is the first step on a long journey. I've summarized the notable limitations here:

https://openjdk.org/projects/valhalla/value-objects#value-object-performance

If you have a use case where addressing one of those limitations would really help, great, let us know about it, it's really valuable to have a real-world sense of relative significance. Just understand that it is not a goal of *this* JEP to address those limitations.

If you see other problems, they may be implementation bugs, or they may indicate new problem spaces we haven't been focusing on. Either way, it's valuable to hear about them. These are things that are immediately actionable?either we should go fix the bug, or we should better understand and communicate the limitation.


From chen.l.liang at oracle.com  Fri Nov  7 23:47:41 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 7 Nov 2025 23:47:41 +0000
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <SJ2PR10MB766992F69D57B493971688E4A2C3A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Vote: yes

-Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Friday, November 7, 2025 12:27 AM
To: valhalla-dev <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Daniel Daugherty

I hereby nominate Daniel Daugherty [1] to Valhalla Committer.

Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].

Votes are due by November 21st, 2025, 0700Z.

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

For Lazy Consensus voting instructions, see [4].

David Simms

[1] https://openjdk.org/census#dcubed
[2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
[3] https://openjdk.org/census
[4] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251107/a184b837/attachment.htm>

From chen.l.liang at oracle.com  Sat Nov  8 05:42:50 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 8 Nov 2025 05:42:50 +0000
Subject: Question about JEP 401 Feedback
In-Reply-To: <CAA9v-_M+Sex43z4mcR3WksgVBvKnbVXeZybXiLwJ2wGYbJOkKQ@mail.gmail.com>
References: <CAA9v-_M+Sex43z4mcR3WksgVBvKnbVXeZybXiLwJ2wGYbJOkKQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7669263127993D7C290FDFBBA2C0A@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi David, given that this EA is presented with eventually delivering into mainline as preview features, and given Java's goal for compatibility, I think our primary performance goals are:

  1.
Detect accidental incompatibilities, behavioral changes, or regressions when preview features are off (there should be ideally none)
  2.
Examine the compatibility of existing programs when they run with preview features on, and their performance status (some regressions may be anticipated)
  3.
Examine the specification compliance of value objects and their performance features (need to classify regressions too), such as the "add value modifier and my code slows down" example from Ethan McCue.

For performance improvements related to value objects, our goal is the new programming model unlocks a lot of compiler transformations previously not possible - for example, lack of identity allows free replacement of Vectors in the Vector API. This potential improvement is not in the EA, and that's why Dan says "there are some gains you might hope for that simply aren't implemented yet." One thing of note is that we currently ship "nullable atomic flat" arrays for small value classes in anticipation for future polymorphic array and generic specialization enhancements, which can be seen as a significant performance-oriented change.

Chen Liang
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Friday, November 7, 2025 6:43 AM
To: valhalla-dev <valhalla-dev at openjdk.org>
Subject: Question about JEP 401 Feedback

Hello @valhalla-dev<mailto:valhalla-dev at openjdk.org>,

I have spent the past week or so playing around with the JEP 401 EA, gathering a bunch of data. I am nearing completion with the data-gathering phase, and preparing myself to start writing my experience.

However, I wanted to confirm what type of experience report is wanted for this JEP 401. It's been mentioned in multiple places that many of the performance optimizations one would come to expect with Valhalla have yet to be implemented yet. Understandable -- this is still just the EA of JEP 401.

So does that mean that experience reports should avoid talking about potential performance increases/decreases? Or should we focus on the usability and ergonomics of the language feature? Or is this just a typical experience report, where we just speak freely about what did and didn't work when trying on a real world program?

I'll post this thread to reddit once receiving answers. That way, others who see that post will be able to format their experience reports appropriately as well.

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251108/9de258fa/attachment-0001.htm>

From jatinbha.cloud at gmail.com  Sat Nov  8 06:06:46 2025
From: jatinbha.cloud at gmail.com (Jatin)
Date: Sat, 08 Nov 2025 11:36:46 +0530
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SJ2PR10MB766992F69D57B493971688E4A2C3A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
 <SJ2PR10MB766992F69D57B493971688E4A2C3A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <7C21C9EA-7860-42F1-AFFF-F33514CEE7F3@gmail.com>

Vote: yes

Best Regards,
Jatin
Bhateja
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251108/cc2ed458/attachment.htm>

From christian.hagedorn at oracle.com  Mon Nov 10 07:43:44 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Mon, 10 Nov 2025 08:43:44 +0100
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <2701848e-7cfa-43b0-a5e7-9534715a2cf8@oracle.com>

Vote: yes

Best regards,
Christian

On 11/7/25 07:27, David Simms wrote:
> I hereby nominate Daniel Daugherty [1] to Valhalla Committer.
> 
> Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].
> 
> Votes are due by November 21st, 2025, 0700Z.
> 
> Only current Valhalla Committers [3] are eligible to vote on this nomination. ?Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [4].
> 
> David Simms
> 
> [1] https://openjdk.org/census#dcubed
> [2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
> [3] https://openjdk.org/census
> [4] https://openjdk.org/projects/#committer-vote


From maurizio.cimadamore at oracle.com  Mon Nov 10 09:56:30 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 10 Nov 2025 09:56:30 +0000
Subject: CFV: New Valhalla Committer: Daniel Daugherty
In-Reply-To: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB4459BCCCE0C657E44FA8A85A9AC3A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <2e480920-b2a7-4936-90a0-61d05182f9a9@oracle.com>

Vote: yes!

Maurizio

On 07/11/2025 06:27, David Simms wrote:
> I hereby nominate Daniel Daugherty [1] to Valhalla Committer.
>
> Daniel is a member of the HotSpot Runtime Team at Oracle, a JDK Reviewer, and performs gatekeeping activities within Oracle , leading to over 800 commits for JDK's mainline alone [2].
>
> Votes are due by November 21st, 2025, 0700Z.
>
> Only current Valhalla Committers [3] are eligible to vote on this nomination. ?Votes must be cast in the open by replying to this mailing list.
>
> For Lazy Consensus voting instructions, see [4].
>
> David Simms
>
> [1] https://openjdk.org/census#dcubed
> [2] https://github.com/search?q=committer-name%3A%22Daniel+Daugherty%22+repo%3Aopenjdk%2Fjdk+&type=commits&p=1
> [3] https://openjdk.org/census
> [4] https://openjdk.org/projects/#committer-vote

From phubner at openjdk.org  Mon Nov 10 10:11:40 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 10 Nov 2025 10:11:40 GMT
Subject: [lworld] RFR: 8371398: [lworld]
 runtime/valhalla/inlinetypes/FlatArrayCopyingTest.java#g1 fails due to lack of
 UnlockDiagnosticVMOptions [v2]
In-Reply-To: <bBZXtugVs2lui7droHAPUjzu_vQg-cYKnE9NoSxcMbg=.cc9d55f6-1166-48df-8117-bf671d4b8b75@github.com>
References: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
 <bBZXtugVs2lui7droHAPUjzu_vQg-cYKnE9NoSxcMbg=.cc9d55f6-1166-48df-8117-bf671d4b8b75@github.com>
Message-ID: <j1wEMA0A_pwRyHSMQpfGHzcmefxFLvt-hqxWhexDZ14=.1fffe6d5-2ac0-4805-873f-763009365a77@github.com>

On Fri, 7 Nov 2025 15:14:17 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The flag `UnlockDiagnosticVMOptions` should be set explicitly.
>> 
>> Tests: tier 1, tier 5.
>
> Paul H?bner 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 two additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8371398
>  - Explicitly enable diagnostic options.

Thanks for the review, Fred.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1726#issuecomment-3510598333

From phubner at openjdk.org  Mon Nov 10 10:11:41 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 10 Nov 2025 10:11:41 GMT
Subject: [lworld] Integrated: 8371398: [lworld]
 runtime/valhalla/inlinetypes/FlatArrayCopyingTest.java#g1 fails due to lack of
 UnlockDiagnosticVMOptions
In-Reply-To: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
References: <s58Id7GCy7-S0PxHbaVizDXCWPGnCi0iJmUdv0bK7MA=.7d7ce4ab-2a6d-4c2a-9ff2-a0d076f62d1d@github.com>
Message-ID: <r3fD295KpvXaDah41dFJfO8v1IOrffmR_QvWCGAqUB0=.24f6bfe6-e907-43ba-89d3-83b8688865ed@github.com>

On Fri, 7 Nov 2025 10:01:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The flag `UnlockDiagnosticVMOptions` should be set explicitly.
> 
> Tests: tier 1, tier 5.

This pull request has now been integrated.

Changeset: a180fefd
Author:    Paul H?bner <phubner at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a180fefdd8f427c647f3a4f3a4bc937207d1fe72
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8371398: [lworld] runtime/valhalla/inlinetypes/FlatArrayCopyingTest.java#g1 fails due to lack of UnlockDiagnosticVMOptions

Reviewed-by: fparain

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

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

From thartmann at openjdk.org  Mon Nov 10 14:05:26 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 10 Nov 2025 14:05:26 GMT
Subject: [lworld] RFR: 8371560: [lworld] Disable check_symmetrical until
 JDK-8332406 is fixed
Message-ID: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>

Disabling this assert until [JDK-8332406](https://bugs.openjdk.org/browse/JDK-8332406) is fixed to get the CI clean. Also added a corresponding test.

Thanks,
Tobias

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

Commit messages:
 - 8371560: [lworld] Disable check_symmetrical until JDK-8332406 is fixed

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

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

From liach at openjdk.org  Mon Nov 10 14:07:16 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 14:07:16 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v2]
In-Reply-To: <N0553wCMhVEGodSphnbjvYGI9vMy54rHylU8BncCwaY=.db9aaca8-dd31-44e2-932c-84b27a6b24ac@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
 <N0553wCMhVEGodSphnbjvYGI9vMy54rHylU8BncCwaY=.db9aaca8-dd31-44e2-932c-84b27a6b24ac@github.com>
Message-ID: <K9oyJc8GL4At6E0jEk5FR2mMzIMWp591YgwSNtoxMBQ=.dc8b6574-a2fc-4e0b-b4fe-55630e067335@github.com>

On Fri, 7 Nov 2025 19:18:45 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is accepting this code:
>> 
>> 
>> abstract value class ValueParent {
>>     int b = 5;
>> }
>> 
>> value class ValueClass extends ValueParent {
>>     int a = b;
>> }
>> 
>> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional test

Looks reasonable

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1728#pullrequestreview-3443434008

From chagedorn at openjdk.org  Mon Nov 10 14:32:45 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 10 Nov 2025 14:32:45 GMT
Subject: [lworld] RFR: 8371560: [lworld] Disable check_symmetrical until
 JDK-8332406 is fixed
In-Reply-To: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>
References: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>
Message-ID: <dYSW0oQC8tv-EEas6AB7IgR8qFyr4NgWhglBg7gshbE=.792cacb7-fd44-4a84-89b4-a353a9c9a271@github.com>

On Mon, 10 Nov 2025 13:56:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Disabling this assert until [JDK-8332406](https://bugs.openjdk.org/browse/JDK-8332406) is fixed to get the CI clean. Also added a corresponding test.
> 
> Thanks,
> Tobias

Looks reasonable!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1729#pullrequestreview-3443549288

From thartmann at openjdk.org  Mon Nov 10 15:22:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 10 Nov 2025 15:22:46 GMT
Subject: [lworld] RFR: 8371560: [lworld] Disable check_symmetrical until
 JDK-8332406 is fixed
In-Reply-To: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>
References: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>
Message-ID: <BmNmHDOM2aa1sJflFhU9jofXastkLk6qH3EalU3y0IE=.1b7be314-8ab4-4815-b80c-274b322cfa9d@github.com>

On Mon, 10 Nov 2025 13:56:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Disabling this assert until [JDK-8332406](https://bugs.openjdk.org/browse/JDK-8332406) is fixed to get the CI clean. Also added a corresponding test.
> 
> Thanks,
> Tobias

Thanks Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1729#issuecomment-3512318777

From thartmann at openjdk.org  Mon Nov 10 15:22:46 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 10 Nov 2025 15:22:46 GMT
Subject: [lworld] Integrated: 8371560: [lworld] Disable check_symmetrical until
 JDK-8332406 is fixed
In-Reply-To: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>
References: <E0aBQ6UpRt-aFhXzhAXvXKnZJ780Y_DxZ55WhfAWmV8=.da3e61f3-5cdf-4bda-90e5-959a9a923ebb@github.com>
Message-ID: <FwgQsDkxfo65bVqNGWcr-2CFua4JjlwvBdNnTB0eypQ=.5b08e4bd-9198-4622-9bd5-c921046d3129@github.com>

On Mon, 10 Nov 2025 13:56:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Disabling this assert until [JDK-8332406](https://bugs.openjdk.org/browse/JDK-8332406) is fixed to get the CI clean. Also added a corresponding test.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: f57d72f5
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f57d72f59472269d3b37a81b591ca236e0a03926
Stats:     31 lines in 2 files changed: 29 ins; 0 del; 2 mod

8371560: [lworld] Disable check_symmetrical until JDK-8332406 is fixed

Reviewed-by: chagedorn

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

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

From coleenp at openjdk.org  Mon Nov 10 17:05:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Nov 2025 17:05:01 GMT
Subject: [lworld] RFR: 8370886: [lworld] 8369296 partially reverted for
 resolving static get/put field
Message-ID: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>

Reordered the conditionals so that unresolved static final fields do not have their resolution set during <clinit> so that their strictness can be validated (write before read, no write after read).
Tested with tier1-4 (in progress).  Tested command line the cds test that failed and valhalla/inlinetypes tests.

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

Commit messages:
 - 8370886: [lworld] 8369296 partially reverted for resolving static get/put field

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

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

From matsaave at openjdk.org  Mon Nov 10 18:30:16 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 10 Nov 2025 18:30:16 GMT
Subject: [lworld] RFR: 8370886: [lworld] 8369296 partially reverted for
 resolving static get/put field
In-Reply-To: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>
References: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>
Message-ID: <AU7yLiCoYEZvwhY02woD5YiLDNrudVbSiyBX9rUSeMM=.dd9b3250-5756-4734-b5d2-d4f42c04cb51@github.com>

On Wed, 5 Nov 2025 20:48:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Reordered the conditionals so that unresolved static final fields do not have their resolution set during <clinit> so that their strictness can be validated (write before read, no write after read).
> 
> This should work with JDK-[8334898](https://bugs.openjdk.org/browse/JDK-8334898) when merged because this change will not fill in the cpCache for statics if they're strict final statics:
> 
> Tested with tier1-4 (in progress).  Tested command line the cds test that failed and valhalla/inlinetypes tests.

LGTM!

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1723#pullrequestreview-3444590565

From coleenp at openjdk.org  Mon Nov 10 20:08:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Nov 2025 20:08:10 GMT
Subject: [lworld] RFR: 8370886: [lworld] 8369296 partially reverted for
 resolving static get/put field
In-Reply-To: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>
References: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>
Message-ID: <6N-Y2xnlYA2_LOqsMwwbUkMMPrCSSytN2Zn0QO6H2Pk=.747829aa-b0c1-4fbc-9421-202abfd4d3ed@github.com>

On Wed, 5 Nov 2025 20:48:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Reordered the conditionals so that unresolved static final fields do not have their resolution set during <clinit> so that their strictness can be validated (write before read, no write after read).
> 
> This should work with JDK-[8334898](https://bugs.openjdk.org/browse/JDK-8334898) when merged because this change will not fill in the cpCache for statics if they're strict final statics:
> 
> Tested with tier1-4 (in progress).  Tested command line the cds test that failed and valhalla/inlinetypes tests.

Thanks for the review Matias.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1723#issuecomment-3513702390

From coleenp at openjdk.org  Mon Nov 10 20:08:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 10 Nov 2025 20:08:10 GMT
Subject: [lworld] Integrated: 8370886: [lworld] 8369296 partially reverted for
 resolving static get/put field
In-Reply-To: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>
References: <n9LXa7ibhvowzGpOB1s_1olL4KYQsQz5IOh57oVygdc=.c4d2681b-0dfe-4996-bed3-a3ed58e50092@github.com>
Message-ID: <CuARSRnGfOFq0L8D3PlxhmM17ijqriMOSmpY8xRQsuI=.5d4e2e79-7f28-402b-ad84-e4c46591548b@github.com>

On Wed, 5 Nov 2025 20:48:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Reordered the conditionals so that unresolved static final fields do not have their resolution set during <clinit> so that their strictness can be validated (write before read, no write after read).
> 
> This should work with JDK-[8334898](https://bugs.openjdk.org/browse/JDK-8334898) when merged because this change will not fill in the cpCache for statics if they're strict final statics:
> 
> Tested with tier1-4 (in progress).  Tested command line the cds test that failed and valhalla/inlinetypes tests.

This pull request has now been integrated.

Changeset: a680c717
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a680c717f3204d2f878944b724c4a78560e4f913
Stats:     13 lines in 1 file changed: 6 ins; 6 del; 1 mod

8370886: [lworld] 8369296 partially reverted for resolving static get/put field

Reviewed-by: matsaave

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

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

From thartmann at openjdk.org  Tue Nov 11 11:59:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 11 Nov 2025 11:59:13 GMT
Subject: [lworld] RFR: 8369835: [lworld] Intrinsify new instance-accepting
 array unsafe operations
Message-ID: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>

Intrinsics in C2 as requested by @liach.

Thanks,
Tobias

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

Commit messages:
 - 8369835: [lworld] Intrinsify new instance-accepting array unsafe operations

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

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

From duke at openjdk.org  Tue Nov 11 13:20:36 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 11 Nov 2025 13:20:36 GMT
Subject: [lworld] Integrated: 8368467: [lworld] Add new flag generation for
 jimage to support preview mode
In-Reply-To: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
References: <-OqsGHnIprDckGjjABQPLNhb0xqMOxyjs1Vy441zJKU=.1cd7fe97-a8ed-44d4-95a7-b50cbc7d2205@github.com>
Message-ID: <KXySgox3bcXAA_BTiK-hUlRndh7wekuLIgLNOH7bldY=.427b52c0-5f28-4840-8d40-6a7d7046c60c@github.com>

On Tue, 4 Nov 2025 17:08:45 GMT, David Beaumont <duke at openjdk.org> wrote:

> Adds support for writing preview related flags into jimage files.
> 
> Preview mode is complex. It's not nearly as simple as "does something in /modules/xxx/... have an entry in /modules/xxx/META-INF/preview/...".
> 
> Specific issues include:
> 
> Supporting preview-only resources without forcing a double lookup on everything.
> Changing the set of entries in /packages/xxx directories to account for preview only packages in some modules.
> Minimising the work done during image reader initialization to only need to process the small number of preview resources (rather than scanning the whole file to look for them).
> The new flags added by this code address these issues, but calculating them correctly with only minor adjustments to the existing code was not feasible, it just became a lot larger and very complex.
> 
> To address this, a new type (ModuleReference) is introduced to track and then merge information about packages seen in each module. This allows a much simpler inner loop for processing resource paths when building the node tree, combined with a subsequent merging stage to produce the final package information for each module.
> 
> Not that since ModuleReference is needed during jimage reading, that class is already present in the previous PR on which this is based, but it starts to be used to calculate the module flags in this PR.
> 
> This PR can also adds the ImageReader unit tests for preview mode, which rely on being able to generate jimage files with preview mode flags in.

This pull request has now been integrated.

Changeset: 72539b57
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/72539b57d088940bc18185d1658db6c89f4033fc
Stats:     2089 lines in 16 files changed: 893 ins; 163 del; 1033 mod

8368467: [lworld] Add new flag generation for jimage to support preview mode

Reviewed-by: rriggs

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

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

From thartmann at openjdk.org  Tue Nov 11 13:24:14 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 11 Nov 2025 13:24:14 GMT
Subject: [lworld] RFR: 8369835: [lworld] Intrinsify new instance-accepting
 array unsafe operations [v2]
In-Reply-To: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>
References: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>
Message-ID: <paLQqbAsGR0C8bvXAmH13WW6Vb81ppW5zJvo3whrZ0A=.ca70e25e-7ef5-4698-9288-87e851b1ce71@github.com>

> Intrinsics in C2 as requested by @liach.
> 
> Thanks,
> Tobias

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

  Force inlining

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1730/files
  - new: https://git.openjdk.org/valhalla/pull/1730/files/ae0c279c..1f83ac28

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

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

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

From chagedorn at openjdk.org  Tue Nov 11 14:37:53 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 11 Nov 2025 14:37:53 GMT
Subject: [lworld] RFR: 8369835: [lworld] Intrinsify new instance-accepting
 array unsafe operations [v2]
In-Reply-To: <paLQqbAsGR0C8bvXAmH13WW6Vb81ppW5zJvo3whrZ0A=.ca70e25e-7ef5-4698-9288-87e851b1ce71@github.com>
References: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>
 <paLQqbAsGR0C8bvXAmH13WW6Vb81ppW5zJvo3whrZ0A=.ca70e25e-7ef5-4698-9288-87e851b1ce71@github.com>
Message-ID: <7JRklOw3P2UN02m2zu3PgSik_W9CvUBEJoJayURuQzg=.c0f1c3e9-1489-4e8e-81e0-c717996de633@github.com>

On Tue, 11 Nov 2025 13:24:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Intrinsics in C2 as requested by @liach.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force inlining

That looks good to me!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1730#pullrequestreview-3448372244

From thartmann at openjdk.org  Tue Nov 11 14:42:43 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 11 Nov 2025 14:42:43 GMT
Subject: [lworld] RFR: 8369835: [lworld] Intrinsify new instance-accepting
 array unsafe operations [v2]
In-Reply-To: <paLQqbAsGR0C8bvXAmH13WW6Vb81ppW5zJvo3whrZ0A=.ca70e25e-7ef5-4698-9288-87e851b1ce71@github.com>
References: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>
 <paLQqbAsGR0C8bvXAmH13WW6Vb81ppW5zJvo3whrZ0A=.ca70e25e-7ef5-4698-9288-87e851b1ce71@github.com>
Message-ID: <GmgGNAR5iL1mGsbxk5HeRwC4gQj8nbpRS9xbnkvHj2o=.20418be9-0c01-40d2-a1e9-faf3c6c47d95@github.com>

On Tue, 11 Nov 2025 13:24:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Intrinsics in C2 as requested by @liach.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force inlining

Thanks Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1730#issuecomment-3517229745

From anhmdq at gmail.com  Tue Nov 11 15:10:29 2025
From: anhmdq at gmail.com (=?UTF-8?Q?Qu=C3=A2n_Anh_Mai?=)
Date: Tue, 11 Nov 2025 22:10:29 +0700
Subject: About flattening a nullable j.l.Long
In-Reply-To: <CAPvyiyKxwCQpyKj6oSNZ-goGJ0eqKOUm9Do8+LsGwRP3Ago8tQ@mail.gmail.com>
References: <CAPvyiy+qHiVz7yrt_efFoUGqjYD92XqNqxj-Hs4RweUddDEeuw@mail.gmail.com>
 <CAA9v-_O4b6WQcmAJGAi9SvY9WcYAwXu5hfrdy3q239gJ-HpAfA@mail.gmail.com>
 <CAPvyiyKwGDzAKEtU8u2D8v+VvdMqyhtSxX=_R_OdPoz3NG3CzA@mail.gmail.com>
 <1701360016.33038778.1762434128958.JavaMail.zimbra@univ-eiffel.fr>
 <CAPvyiyKxwCQpyKj6oSNZ-goGJ0eqKOUm9Do8+LsGwRP3Ago8tQ@mail.gmail.com>
Message-ID: <CAPvyiyLYb90GwfR6Tgz2SV-xfWK=hvF4mRHpeKY9z1qSem78Hw@mail.gmail.com>

Hi,

I have been agonizing over this issue for the past few days. In the end, I
may have come up with a way to make flattening work. In exchange, we need
to lock the field so the stores are serialized. My aim is that the loads
keep being lock-free, and for the stores, the supposedly common case of
storing a non-null into a non-null does not require locking. At the moment,
I am starting to implement a prototype and doing some benchmarking to see
if locking would be prohibitively expensive. My proposal and reasoning can
be found in the description of the JBS issue
https://bugs.openjdk.org/browse/JDK-8371199. Please take a look and let me
know what you think.

Cheers,
Quan Anh

On Sat, 8 Nov 2025 at 00:06, Qu?n Anh Mai <anhmdq at gmail.com> wrote:

> Hi,
>
> Thanks a lot for your answer. After thinking about it for a while, I think
> it is true that this approach will not work. While it is true that a field
> load must act as if it observes 1 of the concurrent stores, I forgot to
> take into consideration the possibility that such store may be rendered
> invalid due to a store of null happens after it. It seems that for
> atomicity to hold, the store must be atomic, and there is no way around
> that. How unfortunate!
>
> Regards,
> Quan Anh
>
>
> On Thu, 6 Nov 2025 at 20:02, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hello,
>> as far as i remember, the problem is that you can resurrect a value,
>> for example with a Long
>>
>> Thread1
>>   a.x = new Long(12);
>>   a.x = null;
>>   IO.println(a.x); //12
>>
>> Thread2
>>   IO.println(a.x);  // null
>>   a.x = new Long(77);   // descheduled in between writing the maker and
>> writing the long
>>
>>
>> The thread1 can see the Long(12) to be resurrected, something that is not
>> possible with references.
>>
>> regards,
>> R?mi
>>
>> ------------------------------
>>
>> *From: *"Qu?n Anh Mai" <anhmdq at gmail.com>
>> *To: *"David Alayachew" <davidalayachew at gmail.com>
>> *Cc: *"valhalla-dev" <valhalla-dev at openjdk.org>
>> *Sent: *Thursday, November 6, 2025 3:52:41 AM
>> *Subject: *Re: About flattening a nullable j.l.Long
>>
>> Ah yes, my bad, it is https://github.com/openjdk/valhalla/pull/1720
>>
>> On Thu, 6 Nov 2025 at 07:26, David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> Just a heads up, your [1] is a dead link. Can you try to put the url in
>>> again?
>>>
>>> On Wed, Nov 5, 2025, 2:06?PM Qu?n Anh Mai <anhmdq at gmail.com> wrote:
>>>
>>>> Hi,
>>>> Currently, I'm having a PR that allows flattening of a nullable
>>>> value class with a 64-bit payload [1]. Dan Smith told me that some ideas
>>>> along these lines were discussed a few years ago, and the consensus was
>>>> that it was a dead end. May I ask what the concerns were, and whether they
>>>> are still relevant now?
>>>>
>>>> Thanks a lot,
>>>> Quan Anh
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251111/3f48ecb0/attachment.htm>

From thartmann at openjdk.org  Tue Nov 11 15:14:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 11 Nov 2025 15:14:56 GMT
Subject: [lworld] Integrated: 8369835: [lworld] Intrinsify new
 instance-accepting array unsafe operations
In-Reply-To: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>
References: <_7scwKqC5_WmOKbyLH7PLAd5W1rT7QKnkJ3kH0yBWRY=.61dc4659-7eb9-4c18-8c73-6606968e1762@github.com>
Message-ID: <8-171XEldQhtFDGG-tkUJrc3nLbfV1DPw3S5t1RQHJU=.e1afe829-5d3b-4d2e-88d5-cac2f3466ec7@github.com>

On Tue, 11 Nov 2025 11:22:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Intrinsics in C2 as requested by @liach.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 4eb04ffa
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4eb04ffaa626c687e294731b74b8b8cf21b7e564
Stats:     193 lines in 7 files changed: 193 ins; 0 del; 0 mod

8369835: [lworld] Intrinsify new instance-accepting array unsafe operations

Reviewed-by: chagedorn

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

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

From vromero at openjdk.org  Tue Nov 11 20:18:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 11 Nov 2025 20:18:34 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v2]
In-Reply-To: <K9oyJc8GL4At6E0jEk5FR2mMzIMWp591YgwSNtoxMBQ=.dc8b6574-a2fc-4e0b-b4fe-55630e067335@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
 <N0553wCMhVEGodSphnbjvYGI9vMy54rHylU8BncCwaY=.db9aaca8-dd31-44e2-932c-84b27a6b24ac@github.com>
 <K9oyJc8GL4At6E0jEk5FR2mMzIMWp591YgwSNtoxMBQ=.dc8b6574-a2fc-4e0b-b4fe-55630e067335@github.com>
Message-ID: <QMMZ8cn3yiYswvj7E6VJUKW7dshz1X0VPQhzQQI1DwM=.e510d66c-5127-477f-83e8-b78f49b054ea@github.com>

On Mon, 10 Nov 2025 14:04:37 GMT, Chen Liang <liach at openjdk.org> wrote:

> Looks reasonable

thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1728#issuecomment-3518594506

From dsimms at openjdk.org  Wed Nov 12 12:37:24 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Nov 2025 12:37:24 GMT
Subject: [lworld] RFR: 8371686: [lworld] Realign Valhalla jcheck configuration
 to be more like mainline
Message-ID: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>

Mostly mainline conf

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

Commit messages:
 - 8371686: [lworld] Realign Valhalla jcheck configuration to be more like mainline

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

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

From dsimms at openjdk.org  Wed Nov 12 13:05:04 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Nov 2025 13:05:04 GMT
Subject: [lworld] RFR: 8371686: [lworld] Realign Valhalla jcheck
 configuration to be more like mainline
In-Reply-To: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
References: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
Message-ID: <xQx4EcJC3q1diG7EP-Gi5AhBAv8tZr0LQxX2P2unfyw=.54c67cf8-3893-4861-bd2d-9e1184a2004c@github.com>

On Wed, 12 Nov 2025 12:31:46 GMT, David Simms <dsimms at openjdk.org> wrote:

> Mostly mainline conf

Something is not right ? Reviewer check failed.  @zhaosongzs can you tell why ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1731#issuecomment-3521832323

From rriggs at openjdk.org  Wed Nov 12 14:48:45 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 14:48:45 GMT
Subject: [lworld] RFR: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode
In-Reply-To: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
References: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
Message-ID: <I-7XwP_pVuA-NAFj42sfl3YaAoZPE7ZCx7MOgx1v0AQ=.e99f6420-1244-4093-a752-d2bd9b5706fd@github.com>

On Thu, 6 Nov 2025 20:45:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switches package inference to handle preview resource paths.
> 
> Additionally:
> * Updates unit test to use JUnit.
> * Deletes unused code (both newly unused and previously unused).

Looks good.

test/jdk/tools/jlink/ResourcePoolTest.java line 1:

> 1: /*

Update copyright please.

test/jdk/tools/jlink/ResourcePoolTest.java line 232:

> 230:             assertTrue(resources.findEntry(res.path()).isPresent(), "Resource not found: " + res);
> 231:             assertTrue(modules.contains(res.moduleName()), "Module not found: " + res.moduleName());
> 232:             assertTrue(modules.contains(res.moduleName()), "Module not found: " + res.moduleName());

Duplicate assert.

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

PR Review: https://git.openjdk.org/valhalla/pull/1724#pullrequestreview-3453815212
PR Review Comment: https://git.openjdk.org/valhalla/pull/1724#discussion_r2518600513
PR Review Comment: https://git.openjdk.org/valhalla/pull/1724#discussion_r2518590170

From duke at openjdk.org  Wed Nov 12 14:58:36 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 14:58:36 GMT
Subject: [lworld] RFR: [lworld] Switch JLink to not use ImageReader API
 [v9]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <DIWw9zQdA6ZZXb6-OoBGJiiJ9mrmdJXYpLYxlfdKcoU=.ad2e0696-96a0-45f0-af8b-00e899fb8701@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

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

 - Use byte array not stream for simplicity
 - Merge branch 'lworld' into jdk_8371292_jlink/squashed
 - Merge commit '72539b57d088940bc18185d1658db6c89f4033fc' into jdk_8371292_jlink/squashed
 - comment adjustment
 - Feedback changes.
   
   * copyright update
   * feedback changes
 - Merge branch 'jdk_8368467_reader/squashed' into jdk_8371292_jlink/squashed
 - Rename ModuleReference methods back.
 - fixing jlink issue
 - Feedback and test fix
 - Minor feedback changes
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/4eb04ffa...a27a2883

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

Changes: https://git.openjdk.org/valhalla/pull/1721/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1721&range=08
  Stats: 438 lines in 8 files changed: 267 ins; 87 del; 84 mod
  Patch: https://git.openjdk.org/valhalla/pull/1721.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1721/head:pull/1721

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

From duke at openjdk.org  Wed Nov 12 14:58:39 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 14:58:39 GMT
Subject: [lworld] RFR: [lworld] Switch JLink to not use ImageReader API
 [v8]
In-Reply-To: <B6eSQDmD-t_KIDbSx3D8ZX48HqWYiYrmD0RrCris0vk=.3ab7b9f9-44ab-4fc3-9c31-c69f06ca9158@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <oQ-iVitEnY19IPrIHBrRfj_ybox7Y8l_93FXD0ncgpM=.37b0d20f-3a32-4d3e-afda-c9c7b0072e40@github.com>
 <B6eSQDmD-t_KIDbSx3D8ZX48HqWYiYrmD0RrCris0vk=.3ab7b9f9-44ab-4fc3-9c31-c69f06ca9158@github.com>
Message-ID: <hXsFMF75MT_iGrVJlOoXpaxQ2PH-RlLOy1gXudurHSc=.18994416-d60b-4a54-9c9d-d2e65db1de39@github.com>

On Fri, 7 Nov 2025 15:48:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   comment adjustment
>
> test/jdk/tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java line 57:
> 
>> 55:  * @build tests.* jdk.test.lib.process.OutputAnalyzer
>> 56:  *        jdk.test.lib.process.ProcessTools
>> 57:  * @run main/othervm/timeout=1200 -ea -esa -DDISABLE_PREVIEW_PATCHING=false -Xmx1g PackagedModulesVsRuntimeImageLinkTest
> 
> Should this test (temporarily) be run both with and without the new packaging?

Until the makefile stuff is in, it won't work because there are no preview classes in the image and disabling patching will just mean there's no preview stuff at all.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1721#discussion_r2518638166

From rriggs at openjdk.org  Wed Nov 12 15:09:03 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 15:09:03 GMT
Subject: [lworld] RFR: 8371686: [lworld] Realign Valhalla jcheck
 configuration to be more like mainline
In-Reply-To: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
References: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
Message-ID: <8IqAmpcW905HSfsNA04YssEkRTtkVwVUXjuUvgvI_nc=.cb87bb0b-19b7-4502-8b52-ca2762da9c5f@github.com>

On Wed, 12 Nov 2025 12:31:46 GMT, David Simms <dsimms at openjdk.org> wrote:

> Mostly mainline conf

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1731#pullrequestreview-3453938082

From dsimms at openjdk.org  Wed Nov 12 15:25:05 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Nov 2025 15:25:05 GMT
Subject: [lworld] RFR: 8371686: [lworld] Realign Valhalla jcheck
 configuration to be more like mainline
In-Reply-To: <8IqAmpcW905HSfsNA04YssEkRTtkVwVUXjuUvgvI_nc=.cb87bb0b-19b7-4502-8b52-ca2762da9c5f@github.com>
References: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
 <8IqAmpcW905HSfsNA04YssEkRTtkVwVUXjuUvgvI_nc=.cb87bb0b-19b7-4502-8b52-ca2762da9c5f@github.com>
Message-ID: <gpnk0tO0c6tS8UHSv7lriLUjRxima6IZTWIKVe075LU=.d2a7f96e-04ba-4b0e-be0a-f2a01d0a3c13@github.com>

On Wed, 12 Nov 2025 15:06:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Looks good.

Thanks for the review @RogerRiggs , and now I can see that review has cleared the "reviewer" check. Seems to work.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1731#issuecomment-3522479630

From duke at openjdk.org  Wed Nov 12 16:06:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 16:06:41 GMT
Subject: [lworld] RFR: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode [v2]
In-Reply-To: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
References: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
Message-ID: <78brypZJ-nEBGxZ_mNROUz00kqrrOYTsRvYUT819_Bg=.d2fe3ec9-4f9b-4812-8232-7d8e7555f2db@github.com>

> Switches package inference to handle preview resource paths.
> 
> Additionally:
> * Updates unit test to use JUnit.
> * Deletes unused code (both newly unused and previously unused).

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

  remove duplicate assert and update copyright

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1724/files
  - new: https://git.openjdk.org/valhalla/pull/1724/files/2cd62fc3..e6a4f64b

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

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

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

From duke at openjdk.org  Wed Nov 12 16:08:44 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 16:08:44 GMT
Subject: [lworld] RFR: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode
In-Reply-To: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
References: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
Message-ID: <GEM--dL3gYEUh6dOEWZhfICIJXvBtEDfXjIxd0pA2U8=.31e84dfc-f8db-4d53-83d2-ee10d4929391@github.com>

On Thu, 6 Nov 2025 20:45:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switches package inference to handle preview resource paths.
> 
> Additionally:
> * Updates unit test to use JUnit.
> * Deletes unused code (both newly unused and previously unused).

Done. CI is running, will aim to integrate later tonight or more likely early tomorrow.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1724#issuecomment-3522702794

From rriggs at openjdk.org  Wed Nov 12 16:38:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 16:38:04 GMT
Subject: [lworld] RFR: [lworld] Switch JLink to not use ImageReader API
 [v9]
In-Reply-To: <DIWw9zQdA6ZZXb6-OoBGJiiJ9mrmdJXYpLYxlfdKcoU=.ad2e0696-96a0-45f0-af8b-00e899fb8701@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <DIWw9zQdA6ZZXb6-OoBGJiiJ9mrmdJXYpLYxlfdKcoU=.ad2e0696-96a0-45f0-af8b-00e899fb8701@github.com>
Message-ID: <mrxdqZhV3KF_tFG87udrHDHKP3BWUUDaSHsImW93S48=.862dba6e-caa4-4384-ab7e-e9fc74328951@github.com>

On Wed, 12 Nov 2025 14:58:36 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Use byte array not stream for simplicity
>  - Merge branch 'lworld' into jdk_8371292_jlink/squashed
>  - Merge commit '72539b57d088940bc18185d1658db6c89f4033fc' into jdk_8371292_jlink/squashed
>  - comment adjustment
>  - Feedback changes.
>    
>    * copyright update
>    * feedback changes
>  - Merge branch 'jdk_8368467_reader/squashed' into jdk_8371292_jlink/squashed
>  - Rename ModuleReference methods back.
>  - fixing jlink issue
>  - Feedback and test fix
>  - Minor feedback changes
>  - ... and 6 more: https://git.openjdk.org/valhalla/compare/4eb04ffa...a27a2883

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1721#pullrequestreview-3454382871

From mchevalier at openjdk.org  Wed Nov 12 17:10:17 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 12 Nov 2025 17:10:17 GMT
Subject: [lworld] Withdrawn: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
References: <LF1afa90TbHu9tRCD_MpHQv2Y7VuwIuEci7HqHjQWjM=.1dd559ca-221e-4549-bb9c-2f66ab315ef8@github.com>
Message-ID: <lcEgpTCu6dmBbDxVNUdkEJY2f4WLO8ZApsHD58_W_xI=.e6fcee7d-3be9-4288-b9b6-ba031dff6ffe@github.com>

On Tue, 4 Nov 2025 14:02:10 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> # Analysis
> ## Obervationally
> ### IGVN
> During IGVN, in `PhiNode::Value`, a `PhiNode` has 2 inputs. Their types are:
> 
> in(1): java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact * (inline_depth=4))
> in(2): java/lang/Object * (speculative=null)
> 
> We compute the join (HS' meet):
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1310-L1317
> 
> t=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> But the current `_type` (of the `PhiNode` as a `TypeNode`) is
> 
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> We filter `t` by `_type`
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/cfgnode.cpp#L1332
> and we get
> 
> ft=java/lang/Object *
> 
> which is what we return. After the end of `Value`, the returned becomes the new `PhiNode`'s `_type`.
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/phaseX.cpp#L2150-L2164
> and
> https://github.com/openjdk/valhalla/blob/412ec882767d3ee1792d1e0f98da54ff800c60ce/src/hotspot/share/opto/node.cpp#L1127-L1133
> 
> 
> ### Verification
> On verification, `in(1)`, `in(2)` have the same value, so does `t`. But this time
> 
> _type=java/lang/Object *
> 
> and so after filtering `t` by (new) `_type` and we get
> 
> ft=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> 
> which is retuned. Verification gets angry because the new `ft` is not the same as the previous one.
> 
> ## But why?!
> ### Details on type computation
> In short, we are doing
> 
> t = typeof(in(1)) / typeof(in(2))
> ft  = t /\ _type (* IGVN *)
> ft' = t /\ ft    (* Verification *)
> 
> and observing that `ft != ft'`. It seems our lattice doesn't ensure `(a /\ b) /\ b = a /\ b` which is problematic for this kind of verfication that will just "try again and see if something change".
> 
> To me, the surprising fact was that the intersection
> 
> java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue2 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> /\
> _type=java/lang/Object * (speculative=compiler/valhalla/inlinetypes/MyValue3 (compiler/valhalla/inlinetypes/MyInterface):exact *)
> ~>
> java/lang/Object *
> 
> What happened to the speculative type? Both `MyVal...

This pull request has been closed without being integrated.

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

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

From dsimms at openjdk.org  Wed Nov 12 17:28:08 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Nov 2025 17:28:08 GMT
Subject: [lworld] Integrated: 8371686: [lworld] Realign Valhalla jcheck
 configuration to be more like mainline
In-Reply-To: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
References: <6PQLuVaXhROUiyvxGCMFhVxHMzk3zxjlU6aTy5f61ik=.929b2cd9-b4eb-4503-b0f1-7701a9d1896e@github.com>
Message-ID: <KEyt8-fFL-CvbVY2z4-w7rbyunF-dT_yUQ3Z7EijdGM=.429c2ab4-ddab-4ed8-bfef-2a5de33c07fc@github.com>

On Wed, 12 Nov 2025 12:31:46 GMT, David Simms <dsimms at openjdk.org> wrote:

> Mostly mainline conf

This pull request has now been integrated.

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

8371686: [lworld] Realign Valhalla jcheck configuration to be more like mainline

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Wed Nov 12 17:44:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 17:44:18 GMT
Subject: [lworld] RFR: [lworld] Switch JLink to not use ImageReader API
 [v10]
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <d9d1hD5cBUHg8dw1fKxUIamLCPmqOuJXvHav-4NOGGM=.84958e25-5fc7-439f-8fa3-d15656c9c7d3@github.com>

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

David Beaumont has updated the pull request incrementally with two additional commits since the last revision:

 - Copyright fix
 - Copyright fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1721/files
  - new: https://git.openjdk.org/valhalla/pull/1721/files/a27a2883..85670387

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1721&range=09
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1721&range=08-09

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

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

From dsimms at openjdk.org  Wed Nov 12 18:15:03 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 12 Nov 2025 18:15:03 GMT
Subject: [lworld] RFR: 8371731: [lworld] save_live_registers called with wrong
 arg type
Message-ID: <qkUi9aYEvCVpRcc_pvfF2V4VnhqtrI2fLL_0VGqa6IE=.6f2efc8b-86df-4d2b-ad7e-cba02b67b63d@github.com>

Use default save fpu regs

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

Commit messages:
 - 8371731: [lworld] save_live_registers called with wrong arg type

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

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

From rriggs at openjdk.org  Wed Nov 12 18:36:10 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 18:36:10 GMT
Subject: [lworld] RFR: 8371292: [lworld] Switch JLink to not use
 ImageReader API [v10]
In-Reply-To: <d9d1hD5cBUHg8dw1fKxUIamLCPmqOuJXvHav-4NOGGM=.84958e25-5fc7-439f-8fa3-d15656c9c7d3@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <d9d1hD5cBUHg8dw1fKxUIamLCPmqOuJXvHav-4NOGGM=.84958e25-5fc7-439f-8fa3-d15656c9c7d3@github.com>
Message-ID: <Ky9qt96ejUffD64crwXI7CDPMu5Oj97vH4iP92X-BIM=.8564164a-5b61-46a1-9a77-ca3e54b3cbfe@github.com>

On Wed, 12 Nov 2025 17:44:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Copyright fix
>  - Copyright fix

Marked as reviewed by rriggs (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1721#pullrequestreview-3454901418

From thartmann at openjdk.org  Wed Nov 12 18:57:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 12 Nov 2025 18:57:23 GMT
Subject: [lworld] RFR: 8371731: [lworld] save_live_registers called with
 wrong arg type
In-Reply-To: <qkUi9aYEvCVpRcc_pvfF2V4VnhqtrI2fLL_0VGqa6IE=.6f2efc8b-86df-4d2b-ad7e-cba02b67b63d@github.com>
References: <qkUi9aYEvCVpRcc_pvfF2V4VnhqtrI2fLL_0VGqa6IE=.6f2efc8b-86df-4d2b-ad7e-cba02b67b63d@github.com>
Message-ID: <iBi7LahvbkFooBYuexD81JSpJa--LqmlbZRZ0uASshE=.1123cb36-4748-43d7-9bdf-82f71982f5f6@github.com>

On Wed, 12 Nov 2025 18:08:21 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use default save fpu regs

Good and trivial (copy-paste error from x64). Thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1733#pullrequestreview-3454967475

From duke at openjdk.org  Wed Nov 12 19:41:28 2025
From: duke at openjdk.org (duke)
Date: Wed, 12 Nov 2025 19:41:28 GMT
Subject: [lworld] RFR: 8371292: [lworld] Switch JLink to not use
 ImageReader API [v10]
In-Reply-To: <d9d1hD5cBUHg8dw1fKxUIamLCPmqOuJXvHav-4NOGGM=.84958e25-5fc7-439f-8fa3-d15656c9c7d3@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
 <d9d1hD5cBUHg8dw1fKxUIamLCPmqOuJXvHav-4NOGGM=.84958e25-5fc7-439f-8fa3-d15656c9c7d3@github.com>
Message-ID: <434DtCaeiMF05IWIt3fAxriqzUuU8N40uhKDOhhOzlo=.86ae446c-079e-4f6c-ae43-4c4a16330647@github.com>

On Wed, 12 Nov 2025 17:44:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
>> 
>> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
>> 
>> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.
>
> David Beaumont has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Copyright fix
>  - Copyright fix

@david-beaumont 
Your change (at version 856703876bc03d00d344974773d4100f3d64c9c0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1721#issuecomment-3523600762

From rriggs at openjdk.org  Wed Nov 12 19:59:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Nov 2025 19:59:26 GMT
Subject: [lworld] RFR: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode [v2]
In-Reply-To: <78brypZJ-nEBGxZ_mNROUz00kqrrOYTsRvYUT819_Bg=.d2fe3ec9-4f9b-4812-8232-7d8e7555f2db@github.com>
References: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
 <78brypZJ-nEBGxZ_mNROUz00kqrrOYTsRvYUT819_Bg=.d2fe3ec9-4f9b-4812-8232-7d8e7555f2db@github.com>
Message-ID: <KSUpufuOMNyoyNnwjFnbgOfbDwj-w9-5FTtvq7YaL3Y=.98cde86e-066e-4ef7-aafc-962e0a45994b@github.com>

On Wed, 12 Nov 2025 16:06:41 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Switches package inference to handle preview resource paths.
>> 
>> Additionally:
>> * Updates unit test to use JUnit.
>> * Deletes unused code (both newly unused and previously unused).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate assert and update copyright

Marked as reviewed by rriggs (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1724#pullrequestreview-3455214942

From duke at openjdk.org  Wed Nov 12 20:01:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 12 Nov 2025 20:01:41 GMT
Subject: [lworld] Integrated: 8371292: [lworld] Switch JLink to not use
 ImageReader API
In-Reply-To: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
References: <mcB_zaHsJzE7f2uspvbRoYAluSLItUMrZNTvymif6CI=.4f5dd0f5-c1ec-4282-947d-5cc9c6839198@github.com>
Message-ID: <4UYEQ_I7jzwTp271bCWAlH1nJyX-WOpaal8dVxnZtSg=.5670e3d4-153a-4401-9a7b-c646834a4c37@github.com>

On Tue, 4 Nov 2025 23:34:54 GMT, David Beaumont <duke at openjdk.org> wrote:

> Creates a new, narrowed API explicitly for use by jlink, which view the resource entries in a jimage file without the re-mapping of names and invention of synthetic entries inherent in ImageReader.
> 
> Another good reason to express this new API as something other than ImageReader is that, to fix issues such as [JDK-8357249](https://bugs.openjdk.org/browse/JDK-8357249), we don't want to have the (System)ImageReader class used directly in jlink code. It's just the wrong abstraction and will make it harder to refactor jlink to use a non-singleton API with a controlled lifetime later. 
> 
> I've not added unit tests for the new API (yet), but the fact the PackagedModulesVsRuntimeImageLinkTest passes with preview content in the jimage file means that it's working as expected.

This pull request has now been integrated.

Changeset: 66a87cec
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/66a87cecc02e99f3de336b004c7baaba7d428f55
Stats:     438 lines in 8 files changed: 269 ins; 87 del; 82 mod

8371292: [lworld] Switch JLink to not use ImageReader API

Reviewed-by: rriggs

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

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

From dsimms at openjdk.org  Thu Nov 13 06:40:31 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 13 Nov 2025 06:40:31 GMT
Subject: [lworld] Integrated: 8371731: [lworld] save_live_registers called with
 wrong arg type
In-Reply-To: <qkUi9aYEvCVpRcc_pvfF2V4VnhqtrI2fLL_0VGqa6IE=.6f2efc8b-86df-4d2b-ad7e-cba02b67b63d@github.com>
References: <qkUi9aYEvCVpRcc_pvfF2V4VnhqtrI2fLL_0VGqa6IE=.6f2efc8b-86df-4d2b-ad7e-cba02b67b63d@github.com>
Message-ID: <pqmQqQ1QewgMo2-KRf0gmU6xtPyM87kjXnrSC_IalUI=.e62c3c74-ea5b-4d88-a919-f9d2bd8c2364@github.com>

On Wed, 12 Nov 2025 18:08:21 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use default save fpu regs

This pull request has now been integrated.

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

8371731: [lworld] save_live_registers called with wrong arg type

Reviewed-by: thartmann

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

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

From mchevalier at openjdk.org  Thu Nov 13 07:42:43 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 13 Nov 2025 07:42:43 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
Message-ID: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>

Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.

I've changed the 3 files in which I've observed some clashing speculative types at least once.

This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.

Thanks,
Marc

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

Commit messages:
 - Disable tests

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

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

From chagedorn at openjdk.org  Thu Nov 13 08:07:36 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 13 Nov 2025 08:07:36 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
Message-ID: <W51Z6qFhMN6TcA1wdu6pDk0ObiF_4qcOEAr1bscBAb4=.df4442f3-d22f-408e-bc0f-1b76b6729fc6@github.com>

On Wed, 12 Nov 2025 17:14:36 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.
> 
> I've changed the 3 files in which I've observed some clashing speculative types at least once.
> 
> This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.
> 
> Thanks,
> Marc

Marked as reviewed by chagedorn (Committer).

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 141:

> 139:  *          java.base/jdk.internal.vm.annotation
> 140:  * @requires (os.simpleArch == "x64" | os.simpleArch == "aarch64")
> 141:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=000 compiler.valhalla.inlinetypes.TestArrays 6

That looks reasonable to do.

If we are only seeing the failures in the test VMs, then an easier solution would be to directly add the flag to the framework:

 InlineTypes.getFramework()
                   .addScenarios(scenarios[Integer.parseInt(args[0])])
                   .addFlags("-XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=000")
                   .addHelperClasses(MyValue1.class, MyValue2.class, MyValue2Inline.class)
                   .start();

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

PR Review: https://git.openjdk.org/valhalla/pull/1732#pullrequestreview-3458204421
PR Review Comment: https://git.openjdk.org/valhalla/pull/1732#discussion_r2522160881

From chagedorn at openjdk.org  Thu Nov 13 09:46:34 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 13 Nov 2025 09:46:34 GMT
Subject: [lworld] RFR: 8367258: [lworld] Crash with
 -XX:+DeoptimizeNMethodBarriersALot due to wrongly skipping buffering of inline
 type receiver
Message-ID: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>

When running with `-XX:+DeoptimizeNMethodBarriersALot` (done in stress jobs), we could occasionally take the slow path in the nmethod stub entry barrier which does not directly deoptimize the nmethod but just simulate the indirection over the stubs:
https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L198-L209

In `deoptimize()`, we make sure to jump to the "handle wrong method" stub:
https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp#L149-L152

which calls into the VM to `SharedRuntime::handle_wrong_method()`. In this method, we try to reresolve the call site:
https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/runtime/sharedRuntime.cpp#L1608-L1609

We also try to find out if the call was optimized or not by setting the out-parameter `is_optimized`. However, when we find that the caller is already deoptimized (which can happen more often when additionally running with `-XX:+DeoptimizeALot`), we will not set `is_optimized`:
https://github.com/openjdk/valhalla/blob/c4030c8fbc80ff691e1d129c9ad8fabe9282969c/src/hotspot/share/runtime/sharedRuntime.cpp#L1795-L1800

This is wrongly adpated from mainline where we are only concerned about updating the IC. There it makes sense to skip the code below when the caller is already deoptimized.

#### Solution
I therefore propose to change the code to set `is_optimized`, regardless whether the caller is deoptimized or not, when the caller is scalarized and the callee has a scalarized receiver. This avoids wrongly skipping a buffer allocation.

Additional changes:
- I also removed the `is_static_call` out-parameter of `reresolve_call_site()`- we can directly set that via the `callee_method` in `handle_wrong_method()`. I added a sanity assert in `reresolve_call_site()` that we would get the same result.
- Renamed `caller_is_c1` to `caller_does_not_scalarize` in the header file which was missed in a prior renaming.
- There are two remaining issues:
  - Issues with virtual threads (tracking issue: [JDK-8370177](https://bugs.openjdk.org/browse/JDK-8370177)) -> I disabled virtual threads in the test to reduce noise.
  - Problems on AArch64 with the framepointer (tracking issue: [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151))

Thanks,
Christian

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

Commit messages:
 - 8367258: [lworld] Crash with -XX:+DeoptimizeNMethodBarriersALot due to wrongly skipping buffering of inline type receiver

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

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

From duke at openjdk.org  Thu Nov 13 12:25:24 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Nov 2025 12:25:24 GMT
Subject: [lworld] RFR: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode [v2]
In-Reply-To: <78brypZJ-nEBGxZ_mNROUz00kqrrOYTsRvYUT819_Bg=.d2fe3ec9-4f9b-4812-8232-7d8e7555f2db@github.com>
References: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
 <78brypZJ-nEBGxZ_mNROUz00kqrrOYTsRvYUT819_Bg=.d2fe3ec9-4f9b-4812-8232-7d8e7555f2db@github.com>
Message-ID: <Q0M1eI0NzWgIVl0S7j5fMdcwF68iojn0f9y5df7MrOc=.b2851828-0091-4e03-80c9-62ee1573d2bc@github.com>

On Wed, 12 Nov 2025 16:06:41 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Switches package inference to handle preview resource paths.
>> 
>> Additionally:
>> * Updates unit test to use JUnit.
>> * Deletes unused code (both newly unused and previously unused).
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove duplicate assert and update copyright

@david-beaumont 
Your change (at version e6a4f64b11ea7e8c199d06ed3d05a62f6fe8c9f8) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1724#issuecomment-3527567016

From thartmann at openjdk.org  Thu Nov 13 12:51:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 13 Nov 2025 12:51:19 GMT
Subject: [lworld] RFR: 8367258: [lworld] Crash with
 -XX:+DeoptimizeNMethodBarriersALot due to wrongly skipping buffering of inline
 type receiver
In-Reply-To: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>
References: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>
Message-ID: <JJPj_awgYveavL_8KHCT9l0rvAIrWN2UuxCkuHLJcrM=.69c28790-c638-407c-9e52-b0c6ad5d9383@github.com>

On Thu, 13 Nov 2025 09:39:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When running with `-XX:+DeoptimizeNMethodBarriersALot` (done in stress jobs), we could occasionally take the slow path in the nmethod stub entry barrier which does not directly deoptimize the nmethod but just simulate the indirection over the stubs:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L198-L209
> 
> In `deoptimize()`, we make sure to jump to the "handle wrong method" stub:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp#L149-L152
> 
> which calls into the VM to `SharedRuntime::handle_wrong_method()`. In this method, we try to reresolve the call site:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/runtime/sharedRuntime.cpp#L1608-L1609
> 
> We also try to find out if the call was optimized or not by setting the out-parameter `is_optimized`. However, when we find that the caller is already deoptimized (which can happen more often when additionally running with `-XX:+DeoptimizeALot`), we will not set `is_optimized`:
> https://github.com/openjdk/valhalla/blob/c4030c8fbc80ff691e1d129c9ad8fabe9282969c/src/hotspot/share/runtime/sharedRuntime.cpp#L1795-L1800
> 
> This is wrongly adpated from mainline where we are only concerned about updating the IC. There it makes sense to skip the code below when the caller is already deoptimized.
> 
> #### Solution
> I therefore propose to change the code to set `is_optimized`, regardless whether the caller is deoptimized or not, when the caller is scalarized and the callee has a scalarized receiver. This avoids wrongly skipping a buffer allocation.
> 
> Additional changes:
> - I also removed the `is_static_call` out-parameter of `reresolve_call_site()`- we can directly set that via the `callee_method` in `handle_wrong_method()`. I added a sanity assert in `reresolve_call_site()` that we would get the same result.
> - Renamed `caller_is_c1` to `caller_does_not_scalarize` in the header file which was missed in a prior renaming.
> - There are two remaining issues:
>   - Issues with virtual threads (tracking issue: [JDK-8370177](https://bugs.openjdk.org/browse/JDK-8370177)) -> I disabled virtual threads in the test to reduce noise.
>   - Problems on AArch64 with the framepointer (tracking issue: [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151))
> 
> Thanks,
> Christian

Nice analysis, Christian! Scary that this went unnoticed for so long. The fix looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1735#pullrequestreview-3459635052

From mchevalier at openjdk.org  Thu Nov 13 13:44:26 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 13 Nov 2025 13:44:26 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN" [v2]
In-Reply-To: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
Message-ID: <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>

> Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.
> 
> I've changed the 3 files in which I've observed some clashing speculative types at least once.
> 
> This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.
> 
> Thanks,
> Marc

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  addFlags

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1732/files
  - new: https://git.openjdk.org/valhalla/pull/1732/files/06584e48..8442e1c6

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

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

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

From mchevalier at openjdk.org  Thu Nov 13 13:44:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 13 Nov 2025 13:44:28 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN" [v2]
In-Reply-To: <W51Z6qFhMN6TcA1wdu6pDk0ObiF_4qcOEAr1bscBAb4=.df4442f3-d22f-408e-bc0f-1b76b6729fc6@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
 <W51Z6qFhMN6TcA1wdu6pDk0ObiF_4qcOEAr1bscBAb4=.df4442f3-d22f-408e-bc0f-1b76b6729fc6@github.com>
Message-ID: <IzgZ55CFhyZ8ODaJgy-zchjdvHcZiS2t3L4XolkZZzA=.144e5472-afbe-41f0-b2e6-7f149d05138f@github.com>

On Thu, 13 Nov 2025 08:04:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addFlags
>
> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestArrays.java line 141:
> 
>> 139:  *          java.base/jdk.internal.vm.annotation
>> 140:  * @requires (os.simpleArch == "x64" | os.simpleArch == "aarch64")
>> 141:  * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=000 compiler.valhalla.inlinetypes.TestArrays 6
> 
> That looks reasonable to do.
> 
> If we are only seeing the failures in the test VMs, then an easier solution would be to directly add the flag to the framework:
> 
>  InlineTypes.getFramework()
>                    .addScenarios(scenarios[Integer.parseInt(args[0])])
>                    .addFlags("-XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=000")
>                    .addHelperClasses(MyValue1.class, MyValue2.class, MyValue2Inline.class)
>                    .start();

Like so?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1732#discussion_r2523515079

From duke at openjdk.org  Thu Nov 13 15:18:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 13 Nov 2025 15:18:03 GMT
Subject: [lworld] Integrated: 8371429: [lworld] Fix package name inference for
 ResourcePoolManager for preview mode
In-Reply-To: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
References: <NW5HPGcskz372fePJGQ4blqRcxxvqy2I5Jj0AHnwdYk=.dbbee45e-9959-4808-9d23-817f78ae866d@github.com>
Message-ID: <N6XitkI-zjxt0c_xmBVrS00I-sBcMxkaUSoWQ2sVtb8=.3135516c-5152-4b96-9152-67a8dae244c4@github.com>

On Thu, 6 Nov 2025 20:45:10 GMT, David Beaumont <duke at openjdk.org> wrote:

> Switches package inference to handle preview resource paths.
> 
> Additionally:
> * Updates unit test to use JUnit.
> * Deletes unused code (both newly unused and previously unused).

This pull request has now been integrated.

Changeset: 583b5f54
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/583b5f541e9b847efe102c6b9bbe829f8e7640f6
Stats:     289 lines in 3 files changed: 94 ins; 148 del; 47 mod

8371429: [lworld] Fix package name inference for ResourcePoolManager for preview mode

Reviewed-by: rriggs

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

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

From chagedorn at openjdk.org  Thu Nov 13 15:48:30 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 13 Nov 2025 15:48:30 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN" [v2]
In-Reply-To: <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
 <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>
Message-ID: <UzIecF_tnqK1vhU5q2GbSRftkI2Szr1TO8sBAoS-mkU=.56509285-81d7-475e-96ea-b00e2c84b7b4@github.com>

On Thu, 13 Nov 2025 13:44:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.
>> 
>> I've changed the 3 files in which I've observed some clashing speculative types at least once.
>> 
>> This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addFlags

Perfect! That's quite concise, thanks for the update!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1732#pullrequestreview-3460441186

From chagedorn at openjdk.org  Fri Nov 14 07:08:16 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 14 Nov 2025 07:08:16 GMT
Subject: [lworld] RFR: 8367258: [lworld] Crash with
 -XX:+DeoptimizeNMethodBarriersALot due to wrongly skipping buffering of inline
 type receiver
In-Reply-To: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>
References: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>
Message-ID: <1a5WsDHIM7ITf6Q7G__Kh_tFYzyOgni3XKs2PxmaFjQ=.e463c78f-7f6d-4810-b49f-ec5076a7c387@github.com>

On Thu, 13 Nov 2025 09:39:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When running with `-XX:+DeoptimizeNMethodBarriersALot` (done in stress jobs), we could occasionally take the slow path in the nmethod stub entry barrier which does not directly deoptimize the nmethod but just simulate the indirection over the stubs:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L198-L209
> 
> In `deoptimize()`, we make sure to jump to the "handle wrong method" stub:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp#L149-L152
> 
> which calls into the VM to `SharedRuntime::handle_wrong_method()`. In this method, we try to reresolve the call site:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/runtime/sharedRuntime.cpp#L1608-L1609
> 
> We also try to find out if the call was optimized or not by setting the out-parameter `is_optimized`. However, when we find that the caller is already deoptimized (which can happen more often when additionally running with `-XX:+DeoptimizeALot`), we will not set `is_optimized`:
> https://github.com/openjdk/valhalla/blob/c4030c8fbc80ff691e1d129c9ad8fabe9282969c/src/hotspot/share/runtime/sharedRuntime.cpp#L1795-L1800
> 
> This is wrongly adpated from mainline where we are only concerned about updating the IC. There it makes sense to skip the code below when the caller is already deoptimized.
> 
> #### Solution
> I therefore propose to change the code to set `is_optimized`, regardless whether the caller is deoptimized or not, when the caller is scalarized and the callee has a scalarized receiver. This avoids wrongly skipping a buffer allocation.
> 
> Additional changes:
> - I also removed the `is_static_call` out-parameter of `reresolve_call_site()`- we can directly set that via the `callee_method` in `handle_wrong_method()`. I added a sanity assert in `reresolve_call_site()` that we would get the same result.
> - Renamed `caller_is_c1` to `caller_does_not_scalarize` in the header file which was missed in a prior renaming.
> - There are two remaining issues:
>   - Issues with virtual threads (tracking issue: [JDK-8370177](https://bugs.openjdk.org/browse/JDK-8370177)) -> I disabled virtual threads in the test to reduce noise.
>   - Problems on AArch64 with the framepointer (tracking issue: [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151))
> 
> Thanks,
> Christian

Thanks Tobias for your review! Yes, indeed! It could eventually have happened without stress flags even though it's quite rare.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1735#issuecomment-3531207843

From chagedorn at openjdk.org  Fri Nov 14 07:08:17 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 14 Nov 2025 07:08:17 GMT
Subject: [lworld] Integrated: 8367258: [lworld] Crash with
 -XX:+DeoptimizeNMethodBarriersALot due to wrongly skipping buffering of inline
 type receiver
In-Reply-To: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>
References: <kxKfB56Ef20JSAAoW-r_mIho2pjsY1nuk2V_4NEqrF4=.08aeed94-b56c-4bb8-aa07-f9b5bf506f61@github.com>
Message-ID: <D4vvwLZMjTTf1VG4MrMV7jDo50Hg3q0JW7rgCAxmx1I=.2e7c864e-47b5-4112-a2d1-337973a2e3ce@github.com>

On Thu, 13 Nov 2025 09:39:13 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> When running with `-XX:+DeoptimizeNMethodBarriersALot` (done in stress jobs), we could occasionally take the slow path in the nmethod stub entry barrier which does not directly deoptimize the nmethod but just simulate the indirection over the stubs:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L198-L209
> 
> In `deoptimize()`, we make sure to jump to the "handle wrong method" stub:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/cpu/x86/gc/shared/barrierSetNMethod_x86.cpp#L149-L152
> 
> which calls into the VM to `SharedRuntime::handle_wrong_method()`. In this method, we try to reresolve the call site:
> https://github.com/openjdk/valhalla/blob/a180fefdd8f427c647f3a4f3a4bc937207d1fe72/src/hotspot/share/runtime/sharedRuntime.cpp#L1608-L1609
> 
> We also try to find out if the call was optimized or not by setting the out-parameter `is_optimized`. However, when we find that the caller is already deoptimized (which can happen more often when additionally running with `-XX:+DeoptimizeALot`), we will not set `is_optimized`:
> https://github.com/openjdk/valhalla/blob/c4030c8fbc80ff691e1d129c9ad8fabe9282969c/src/hotspot/share/runtime/sharedRuntime.cpp#L1795-L1800
> 
> This is wrongly adpated from mainline where we are only concerned about updating the IC. There it makes sense to skip the code below when the caller is already deoptimized.
> 
> #### Solution
> I therefore propose to change the code to set `is_optimized`, regardless whether the caller is deoptimized or not, when the caller is scalarized and the callee has a scalarized receiver. This avoids wrongly skipping a buffer allocation.
> 
> Additional changes:
> - I also removed the `is_static_call` out-parameter of `reresolve_call_site()`- we can directly set that via the `callee_method` in `handle_wrong_method()`. I added a sanity assert in `reresolve_call_site()` that we would get the same result.
> - Renamed `caller_is_c1` to `caller_does_not_scalarize` in the header file which was missed in a prior renaming.
> - There are two remaining issues:
>   - Issues with virtual threads (tracking issue: [JDK-8370177](https://bugs.openjdk.org/browse/JDK-8370177)) -> I disabled virtual threads in the test to reduce noise.
>   - Problems on AArch64 with the framepointer (tracking issue: [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151))
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 2db9fd1a
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2db9fd1afb50bb9d30a05d3061b3d35e3690c0ac
Stats:     41 lines in 3 files changed: 15 ins; 4 del; 22 mod

8367258: [lworld] Crash with -XX:+DeoptimizeNMethodBarriersALot due to wrongly skipping buffering of inline type receiver

Reviewed-by: thartmann

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

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

From thartmann at openjdk.org  Fri Nov 14 09:11:38 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 14 Nov 2025 09:11:38 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN" [v2]
In-Reply-To: <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
 <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>
Message-ID: <5049AzxE4WgYDYbUC2RTraoNRMBhxWWBK7N4vbb6-m0=.3a1fddeb-7916-4069-8bce-b7e84d9845c8@github.com>

On Thu, 13 Nov 2025 13:44:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.
>> 
>> I've changed the 3 files in which I've observed some clashing speculative types at least once.
>> 
>> This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addFlags

Looks good to me too.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1732#pullrequestreview-3463792839

From mchevalier at openjdk.org  Fri Nov 14 09:11:39 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 14 Nov 2025 09:11:39 GMT
Subject: [lworld] RFR: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN" [v2]
In-Reply-To: <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
 <oS4EIBj4X657g1297UeuOoBe0WmFChZzeQDuc_B2ExI=.380492f5-005b-4a9d-a687-dd974cca8384@github.com>
Message-ID: <mLoncn8IfgBegKAWG0ybk8ZxYjODcnayB9Mky3WX3Rk=.0846ca76-5f80-40fe-8303-933f51052bdd@github.com>

On Thu, 13 Nov 2025 13:44:26 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.
>> 
>> I've changed the 3 files in which I've observed some clashing speculative types at least once.
>> 
>> This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.
>> 
>> Thanks,
>> Marc
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addFlags

Thanks @chhagedorn & @TobiHartmann! A real will hopefully come soon.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1732#issuecomment-3531704233

From mchevalier at openjdk.org  Fri Nov 14 09:11:40 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 14 Nov 2025 09:11:40 GMT
Subject: [lworld] Integrated: 8367245: [lworld] C2 compilation fails with
 "Missed optimization opportunity in PhaseIterGVN"
In-Reply-To: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
References: <Xet0ban_UvH3Mr8DwGYeNvglRtfeydY_s8Dul4RhkpA=.ff874493-9f6d-4de6-89f9-8f26bc1068f2@github.com>
Message-ID: <FZ9dYXM1jOLBoD-CLkLGEytmYi7vBRo9hHARt_Evp18=.4fdd0e66-bc02-47e4-a9fd-5bad6c8d4849@github.com>

On Wed, 12 Nov 2025 17:14:36 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Let's just disable the verification for now. The issue will be fixed in mainline, then reach Valhalla.
> 
> I've changed the 3 files in which I've observed some clashing speculative types at least once.
> 
> This will be reverted by https://bugs.openjdk.org/browse/JDK-8371726 once https://bugs.openjdk.org/browse/JDK-8371716 is solved.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 409f56a7
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/409f56a757145bf59ba17c9975c0dab2c01eef5b
Stats:     5 lines in 4 files changed: 4 ins; 0 del; 1 mod

8367245: [lworld] C2 compilation fails with "Missed optimization opportunity in PhaseIterGVN"

Reviewed-by: chagedorn, thartmann

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

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

From duke at openjdk.org  Fri Nov 14 12:10:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Nov 2025 12:10:33 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v2]
In-Reply-To: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
Message-ID: <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

David Beaumont 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:

 - rename marker, tweak comments
 - Merge branch 'lworld' into jdk_8368475_makefile/squashed
 - Copy value classes into preview directories for inclusion in jimage

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1727/files
  - new: https://git.openjdk.org/valhalla/pull/1727/files/e38847af..09327056

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

  Stats: 19533 lines in 544 files changed: 10949 ins; 5453 del; 3131 mod
  Patch: https://git.openjdk.org/valhalla/pull/1727.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1727/head:pull/1727

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

From duke at openjdk.org  Fri Nov 14 12:44:15 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Nov 2025 12:44:15 GMT
Subject: [lworld] RFR: 8371898: [lworld] CLONE - BasicImageReader
 getEntryNames() is stateful and cannot be called more than once
Message-ID: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>

Clone of JDK-8371898 to fix issue with getEntryNames().
Required in Valhalla to unblock JDK-8371897.

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

Commit messages:
 - Copy fix from mainline

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

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

From rriggs at openjdk.org  Fri Nov 14 15:15:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 15:15:40 GMT
Subject: [lworld] RFR: 8371898: [lworld] CLONE - BasicImageReader
 getEntryNames() is stateful and cannot be called more than once
In-Reply-To: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>
References: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>
Message-ID: <A4xBpdXrTDJga23ifS4Idiyg7GtWZiCPlodiSFxM_pA=.d259b86f-642c-4541-874c-f3d4298e0acb@github.com>

On Fri, 14 Nov 2025 12:38:07 GMT, David Beaumont <duke at openjdk.org> wrote:

> Clone of JDK-8371898 to fix issue with getEntryNames().
> Required in Valhalla to unblock JDK-8371897.

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1736#pullrequestreview-3465398774

From duke at openjdk.org  Fri Nov 14 16:47:08 2025
From: duke at openjdk.org (duke)
Date: Fri, 14 Nov 2025 16:47:08 GMT
Subject: [lworld] RFR: 8371898: [lworld] CLONE - BasicImageReader
 getEntryNames() is stateful and cannot be called more than once
In-Reply-To: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>
References: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>
Message-ID: <IFhE0Icj_p0i86aymdX50of1Cz_MrE5kXGtCY2EDSxA=.fbd629b1-0b5a-41da-9962-a69272cc5949@github.com>

On Fri, 14 Nov 2025 12:38:07 GMT, David Beaumont <duke at openjdk.org> wrote:

> Clone of JDK-8371898 to fix issue with getEntryNames().
> Required in Valhalla to unblock JDK-8371897.

@david-beaumont 
Your change (at version b7f5679dd272c7155da16be4c29cc0c5dee0d8ac) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1736#issuecomment-3533649917

From duke at openjdk.org  Fri Nov 14 16:49:30 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Nov 2025 16:49:30 GMT
Subject: [lworld] Integrated: 8371898: [lworld] CLONE - BasicImageReader
 getEntryNames() is stateful and cannot be called more than once
In-Reply-To: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>
References: <PpF4aWBIxJBjDVI8fYX008sA16dQSDeACEXi47XrBo0=.9a596e47-81f3-4c4e-913f-c75a9bf3f295@github.com>
Message-ID: <aO0U9-1HMHDsIM3gnSKjiKric5y5CaEYp1wunNGt32w=.ddf92075-3c54-4598-b9dd-ce18429c969a@github.com>

On Fri, 14 Nov 2025 12:38:07 GMT, David Beaumont <duke at openjdk.org> wrote:

> Clone of JDK-8371898 to fix issue with getEntryNames().
> Required in Valhalla to unblock JDK-8371897.

This pull request has now been integrated.

Changeset: 58d748ef
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/58d748ef27bdc9aa5ffd7c44ef657e03ca242522
Stats:     7 lines in 1 file changed: 0 ins; 1 del; 6 mod

8371898: [lworld] CLONE - BasicImageReader getEntryNames() is stateful and cannot be called more than once

Reviewed-by: rriggs

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

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

From duke at openjdk.org  Fri Nov 14 16:55:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 14 Nov 2025 16:55:14 GMT
Subject: [lworld] RFR: 8371591: [lworld] CLONE - VerifyJimage test incorrectly
 skips all tests when comparing directory structure
Message-ID: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>

Rewrite of VerifyJimage test to fix several severe issues.

This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.

Issue 1: Broken file comparison

This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.

This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.

Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.

Issue 2: Use of BasicImageReader for class file reading

A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.

The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.

Issue 3: File comparison mode was never run by default

This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.

This is a clone of https://github.com/openjdk/jdk/pull/28265

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

Commit messages:
 - Copied from mainline PR

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

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

From roger.riggs at oracle.com  Fri Nov 14 17:11:07 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 14 Nov 2025 12:11:07 -0500
Subject: CFV: New Valhalla Committer: David Beaumont
Message-ID: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>

|I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla 
Committer. |

|David is a member of the Oracle Core Libraries team.
|

Nearly 30 years of Java experience, including mobile and embedded device 
JVMs.
Class library development at Google with Guava, logging, and 
internationalization.

|David has contributed 26 commits to the Valhalla repo [4] and 19 
commits to the JDK repo [5].|

||Votes are due by 17:00 CET Monday Dec 1, 2025||

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

|For Lazy Consensus voting instructions, see [2].
|

|Regards, Roger Riggs
|

|[1] https://openjdk.org/census
[2] https://openjdk.org/projects/#committer-vote
[3] https://github.com/david-beaumont
[4] 
https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
[5] 
https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fjdk&type=commits
|

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

From chen.l.liang at oracle.com  Fri Nov 14 17:39:22 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Fri, 14 Nov 2025 17:39:22 +0000
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <SJ2PR10MB7669C01575886BEB98A02095A2CAA@SJ2PR10MB7669.namprd10.prod.outlook.com>

Vote: yes

Best regards, Chen

Confidential- Oracle Internal
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Sent: Friday, November 14, 2025 11:11 AM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: CFV: New Valhalla Committer: David Beaumont


I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla Committer.

David is a member of the Oracle Core Libraries team.

Nearly 30 years of Java experience, including mobile and embedded device JVMs.
Class library development at Google with Guava, logging, and internationalization.

David has contributed 26 commits to the Valhalla repo [4] and 19 commits to the JDK repo [5].

Votes are due by 17:00 CET Monday Dec 1, 2025

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

For Lazy Consensus voting instructions, see [2].

Regards, Roger Riggs

[1] https://openjdk.org/census
[2] https://openjdk.org/projects/#committer-vote
[3] https://github.com/david-beaumont
[4] https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
[5] https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fjdk&type=commits



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

From roger.riggs at oracle.com  Fri Nov 14 18:07:00 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 14 Nov 2025 13:07:00 -0500
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <aafa71a2-6243-466d-abed-3616fa5d4ea4@oracle.com>

Vote: Yes

On 11/14/25 12:11 PM, Roger Riggs wrote:
> |I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla 
> Committer. |
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251114/723cb5e7/attachment.htm>

From coleenp at openjdk.org  Fri Nov 14 19:12:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Nov 2025 19:12:02 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of Class
Message-ID: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>

This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
Tested with tier1-4.

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

Commit messages:
 - 8364447: [lworld] Save isIdentity in a field of Class

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

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

From rriggs at openjdk.org  Fri Nov 14 20:18:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 20:18:26 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <fzsjfFMMV7rNcTTPRJojPCdGl92QIbl0rEPsng7_S4U=.8e5ef860-c812-42d5-a655-183581e0770c@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

Java parts look good;  Thanks

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1738#pullrequestreview-3466661736

From rriggs at openjdk.org  Fri Nov 14 21:37:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 14 Nov 2025 21:37:05 GMT
Subject: [lworld] RFR: 8371897: [lworld] CLONE - VerifyJimage test
 incorrectly skips all tests when comparing directory structure
In-Reply-To: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
References: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
Message-ID: <keZA4HMPwgBEbT6RnVtOViEe83_14PWlc5clESXnxn4=.b85af26b-b9d7-473e-bfa5-cd6de37c888f@github.com>

On Fri, 14 Nov 2025 16:50:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
> 
> This is a clone of https://github.com/openjdk/jdk/pull/28265

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1737#pullrequestreview-3466897331

From vromero at openjdk.org  Sat Nov 15 00:36:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Nov 2025 00:36:38 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v3]
In-Reply-To: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
Message-ID: <NbzvFkqyEBJmymBiQr9rNx22cnlhHpeswqDTCTbKnDg=.9d710bcf-87e7-42fb-b135-156528f0a543@github.com>

> Javac is accepting this code:
> 
> 
> abstract value class ValueParent {
>     int b = 5;
> }
> 
> value class ValueClass extends ValueParent {
>     int a = b;
> }
> 
> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
> 
> TIA

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

 - fixing bug
 - Merge branch 'lworld' into JDK-8371382
 - additional test
 - 8371382: [lworld] Javac accepts field initializer that refers to a superclass field

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1728/files
  - new: https://git.openjdk.org/valhalla/pull/1728/files/e0aa3646..9ba227c5

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

  Stats: 3756 lines in 38 files changed: 1423 ins; 1110 del; 1223 mod
  Patch: https://git.openjdk.org/valhalla/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1728/head:pull/1728

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

From qamai at openjdk.org  Sat Nov 15 11:01:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 15 Nov 2025 11:01:04 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass
Message-ID: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>

Hi,

This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.

I also had to fix `GraphKit::cast_to_flat_array`, currently it incorrectly assumes that the cast is to an exact type, splitting into `cast_to_flat_array` and `cast_to_flat_array_exact` seems to make it clearer.

Please kindly review, thanks a lot.

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

Commit messages:
 - Refactor ciObjArrayKlass to align with the VM type

Changes: https://git.openjdk.org/valhalla/pull/1739/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1739&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370880
  Stats: 407 lines in 21 files changed: 165 ins; 170 del; 72 mod
  Patch: https://git.openjdk.org/valhalla/pull/1739.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1739/head:pull/1739

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

From qamai at openjdk.org  Sat Nov 15 11:05:38 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 15 Nov 2025 11:05:38 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass
In-Reply-To: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
Message-ID: <Xz7n6SdDgfcdntsVUAYZGk5t4_8whGXNTt3o161gC_w=.31055b8d-b634-4e41-9410-1a175a6e8238@github.com>

On Sat, 15 Nov 2025 10:54:41 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
> 
> I also had to fix `GraphKit::cast_to_flat_array`, currently it incorrectly assumes that the cast is to an exact type, splitting into `cast_to_flat_array` and `cast_to_flat_array_exact` seems to make it clearer.
> 
> Please kindly review, thanks a lot.

There are still a lot of refactoring to be done regarding moving elements from `ciArrayKlass` to `ciObjArrayKlass` since now it is the new common ancestor of all arrays of objects.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1739#issuecomment-3536344109

From vromero at openjdk.org  Sat Nov 15 14:28:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Nov 2025 14:28:16 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v4]
In-Reply-To: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
Message-ID: <FNtrIHPbJrn8GaI-C2lqgk771Ta441kIC3IucXQEvEU=.c67e3b10-14fe-49bf-b238-0e290da902a8@github.com>

> Javac is accepting this code:
> 
> 
> abstract value class ValueParent {
>     int b = 5;
> }
> 
> value class ValueClass extends ValueParent {
>     int a = b;
> }
> 
> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
> 
> TIA

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

 - adding test
 - Merge branch 'lworld' into JDK-8371382
 - fixing bug
 - Merge branch 'lworld' into JDK-8371382
 - additional test
 - 8371382: [lworld] Javac accepts field initializer that refers to a superclass field

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1728/files
  - new: https://git.openjdk.org/valhalla/pull/1728/files/9ba227c5..65b1b12e

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

  Stats: 798 lines in 21 files changed: 397 ins; 239 del; 162 mod
  Patch: https://git.openjdk.org/valhalla/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1728/head:pull/1728

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

From vromero at openjdk.org  Sat Nov 15 14:28:18 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Nov 2025 14:28:18 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v4]
In-Reply-To: <FNtrIHPbJrn8GaI-C2lqgk771Ta441kIC3IucXQEvEU=.c67e3b10-14fe-49bf-b238-0e290da902a8@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
 <FNtrIHPbJrn8GaI-C2lqgk771Ta441kIC3IucXQEvEU=.c67e3b10-14fe-49bf-b238-0e290da902a8@github.com>
Message-ID: <4eGmghXGr5CHtaiaSYAsVtHTn9GkA_vYv-e7DywvMVE=.ccf9ef61-205b-4e3b-805b-413e9243d0bb@github.com>

On Sat, 15 Nov 2025 14:24:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is accepting this code:
>> 
>> 
>> abstract value class ValueParent {
>>     int b = 5;
>> }
>> 
>> value class ValueClass extends ValueParent {
>>     int a = b;
>> }
>> 
>> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
>> 
>> TIA
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - adding test
>  - Merge branch 'lworld' into JDK-8371382
>  - fixing bug
>  - Merge branch 'lworld' into JDK-8371382
>  - additional test
>  - 8371382: [lworld] Javac accepts field initializer that refers to a superclass field

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1523:

> 1521:                             (!localEnv.enclClass.sym.isValueClass() &&
> 1522:                              (sym.flags_field & HASINIT) != 0 &&
> 1523:                              !isInitializer))

it is OK for a field with initializer to refer to another field with initializer, so no warning or error if we are analyzing a field initializer

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1728#discussion_r2529920759

From vromero at openjdk.org  Sat Nov 15 14:37:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 15 Nov 2025 14:37:34 GMT
Subject: [lworld] RFR: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field [v5]
In-Reply-To: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
Message-ID: <yAv4qAfXIuk8o7PrrMZaUFM4UqxAo3_hUTZn3TQRwr4=.9f90ca72-8424-43e1-a2cc-78d5be7de943@github.com>

> Javac is accepting this code:
> 
> 
> abstract value class ValueParent {
>     int b = 5;
> }
> 
> value class ValueClass extends ValueParent {
>     int a = b;
> }
> 
> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
> 
> TIA

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

  adding some documentation

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1728/files
  - new: https://git.openjdk.org/valhalla/pull/1728/files/65b1b12e..c9a1fee0

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

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

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

From vromero at openjdk.org  Sun Nov 16 21:05:35 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 16 Nov 2025 21:05:35 GMT
Subject: [lworld] Integrated: 8371382: [lworld] Javac accepts field initializer
 that refers to a superclass field
In-Reply-To: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
References: <8DJggYuV1tDG5NT1A6i-fAO3sbnKvZ-KKBEDY08OoXs=.c2957afe-63a9-4b36-8350-97e0e4b31132@github.com>
Message-ID: <4Nix5H2hLZbatdIVA3pQR_tq3HlVZSLSWN_BPMv1y2E=.ec692a21-2c33-4273-86d8-cf7044cd8716@github.com>

On Fri, 7 Nov 2025 19:07:15 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is accepting this code:
> 
> 
> abstract value class ValueParent {
>     int b = 5;
> }
> 
> value class ValueClass extends ValueParent {
>     int a = b;
> }
> 
> This is not allowed as in value classes field initializers will run in the prologue phase where references to super class fields are forbidden
> 
> TIA

This pull request has now been integrated.

Changeset: b1d14c65
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b1d14c658511cced2a860d9e2741ae89827e25ba
Stats:     40 lines in 4 files changed: 27 ins; 8 del; 5 mod

8371382: [lworld] Javac accepts field initializer that refers to a superclass field

Reviewed-by: liach

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

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

From tobias.hartmann at oracle.com  Mon Nov 17 06:29:08 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 17 Nov 2025 07:29:08 +0100
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <4127535d-b75b-49a1-9546-45a3845a883c@oracle.com>

Vote: yes

Best regards,
Tobias

On 11/14/25 6:11 PM, Roger Riggs wrote:
> |I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla Committer. |
> 
> |David is a member of the Oracle Core Libraries team.
> |
> 
> Nearly 30 years of Java experience, including mobile and embedded device JVMs.
> Class library development at Google with Guava, logging, and internationalization.
> 
> |David has contributed 26 commits to the Valhalla repo [4] and 19 commits to the JDK repo [5].|
> 
> ||Votes are due by 17:00 CET Monday Dec 1, 2025||
> 
> |Only current Valhalla Committers [1] are eligible to vote on this nomination.
> Votes must be cast in the open by replying to this mailing list. |
> 
> |For Lazy Consensus voting instructions, see [2].
> |
> 
> |Regards, Roger Riggs
> |
> 
> |[1] https://openjdk.org/census
> [2] https://openjdk.org/projects/#committer-vote
> [3] https://github.com/david-beaumont
> [4] https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
> [5] https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fjdk&type=commits
> |
> 
> 


From christian.hagedorn at oracle.com  Mon Nov 17 06:59:01 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Mon, 17 Nov 2025 07:59:01 +0100
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <91422b07-04e7-4aea-8490-13ed336934e0@oracle.com>

Vote: yes

Best regards,
Christian

On 11/14/25 18:11, Roger Riggs wrote:
> |I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla 
> Committer. |
> 
> |David is a member of the Oracle Core Libraries team.
> |
> 
> Nearly 30 years of Java experience, including mobile and embedded device 
> JVMs.
> Class library development at Google with Guava, logging, and 
> internationalization.
> 
> |David has contributed 26 commits to the Valhalla repo [4] and 19 
> commits to the JDK repo [5].|
> 
> ||Votes are due by 17:00 CET Monday Dec 1, 2025||
> 
> |Only current Valhalla Committers [1] are eligible to vote on this 
> nomination.
> Votes must be cast in the open by replying to this mailing list. |
> 
> |For Lazy Consensus voting instructions, see [2].
> |
> 
> |Regards, Roger Riggs
> |
> 
> |[1] https://openjdk.org/census
> [2] https://openjdk.org/projects/#committer-vote
> [3] https://github.com/david-beaumont
> [4] https://github.com/search?q=author%3Adavid- 
> beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
> [5] https://github.com/search?q=author%3Adavid- 
> beaumont+repo%3Aopenjdk%2Fjdk&type=commits
> |
> 
> 


From thartmann at openjdk.org  Mon Nov 17 10:16:44 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 17 Nov 2025 10:16:44 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass
In-Reply-To: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
Message-ID: <WoaHRZSqAfKJjIjx7Y2Ll6f-knSJ_hR5zF3HNgSMBw0=.d8ed7aa1-17cf-4c0d-bd35-95d9224e5deb@github.com>

On Sat, 15 Nov 2025 10:54:41 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
> 
> I also had to fix `GraphKit::cast_to_flat_array`, currently it incorrectly assumes that the cast is to an exact type, splitting into `cast_to_flat_array` and `cast_to_flat_array_exact` seems to make it clearer.
> 
> Please kindly review, thanks a lot.

Thank you for working on this, Quan-Anh! Testing looks good except for this:


compiler/valhalla/inlinetypes/TestArrayNullMarkers.java#AVF-nAVF
-XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:-DoEscapeAnalysis -XX:+AlwaysIncrementalInline

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/ci/ciMetadata.hpp:105), pid=418142, tid=418159
#  assert(is_flat_array_klass()) failed: bad cast
#
# JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-jep401ea2-2025-11-17-0811237.tobias.hartmann.valhalla2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-jep401ea2-2025-11-17-0811237.tobias.hartmann.valhalla2, mixed mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1ca876a]  TypeAryPtr::flat_layout_helper() const+0x7a

Current CompileTask:
C2:2887  380 % !b        compiler.valhalla.inlinetypes.TestArrayNullMarkers::main @ 698 (2967 bytes)

Stack: [0x00007f5639cfe000,0x00007f5639dfe000],  sp=0x00007f5639df8240,  free space=1000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1ca876a]  TypeAryPtr::flat_layout_helper() const+0x7a  (ciMetadata.hpp:105)
V  [libjvm.so+0x102a8a9]  GraphKit::get_layout_helper(Node*, int&)+0x299  (graphKit.cpp:4100)
V  [libjvm.so+0x102cd43]  GraphKit::new_array(Node*, Node*, int, Node**, bool, Node*)+0x43  (graphKit.cpp:4345)
V  [libjvm.so+0x158b712]  LibraryCallKit::inline_newArray(bool, bool)+0x242  (library_call.cpp:4904)
V  [libjvm.so+0x15b2c6a]  LibraryIntrinsic::generate(JVMState*)+0x22a  (library_call.cpp:130)
V  [libjvm.so+0xdbc50f]  Parse::do_call()+0xebf  (doCall.cpp:771)
V  [libjvm.so+0x18fee88]  Parse::do_one_bytecode()+0x4c8  (parse2.cpp:3526)
V  [libjvm.so+0x18e6007]  Parse::do_one_block()+0x357  (parse1.cpp:1703)
V  [libjvm.so+0x18e7300]  Parse::do_all_blocks()+0x130  (parse1.cpp:760)
V  [libjvm.so+0x18eae81]  Parse::Parse(JVMState*, ciMethod*, float)+0xea1  (parse1.cpp:664)
V  [libjvm.so+0x9e1975]  ParseGenerator::generate(JVMState*)+0x135  (callGenerator.cpp:99)
V  [libjvm.so+0x9e6ba3]  CallGenerator::do_late_inline_helper()+0xa03  (callGenerator.cpp:751)
V  [libjvm.so+0xbdc968]  Compile::inline_incrementally_one()+0x1b8  (compile.cpp:2614)
V  [libjvm.so+0xbde0ab]  Compile::inline_incrementally(PhaseIterGVN&)+0x38b  (compile.cpp:2707)
V  [libjvm.so+0xbe0c9e]  Compile::Optimize()+0x47e  (compile.cpp:2843)
V  [libjvm.so+0xbe45c5]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1da5  (compile.cpp:879)
V  [libjvm.so+0x9de490]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x4e0  (c2compiler.cpp:149)
V  [libjvm.so+0xbf3e20]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x780  (compileBroker.cpp:2345)
V  [libjvm.so+0xbf5680]  CompileBroker::compiler_thread_loop()+0x530  (compileBroker.cpp:1989)
V  [libjvm.so+0x118d15b]  JavaThread::thread_main_inner()+0x13b  (javaThread.cpp:772)
V  [libjvm.so+0x1c68ee6]  Thread::call_run()+0xb6  (thread.cpp:243)
V  [libjvm.so+0x1893bc8]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:883)

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

PR Review: https://git.openjdk.org/valhalla/pull/1739#pullrequestreview-3471990086

From vromero at openjdk.org  Mon Nov 17 13:58:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Nov 2025 13:58:52 GMT
Subject: [lworld] RFR: 8371356: [lworld] 'super' should be rejected in early
 construction context
Message-ID: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>

There is a bug in the algo to determine what is kosher and what is not in early construction contexts. The algo was not analyzing any static symbol. But according to the `JLS 25 15.11.2 Accessing Superclass Members using super`:


It is a compile-time error if a field access expression using the keyword super
occurs in a static context (?8.1.3) or in an early construction context (?8.8.7) of
the current class.

the previous code was checking this only for instance field accesses. The current fix corrects this bug

TIA

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

Commit messages:
 - 8371356: [lworld] 'super' should be rejected in early construction context

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

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

From vicente.romero at oracle.com  Mon Nov 17 14:15:47 2025
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 17 Nov 2025 09:15:47 -0500
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <824647ec-cf55-43e6-88c3-c2a7196d024e@oracle.com>

vote: yes

Vicente

On 11/14/25 12:11, Roger Riggs wrote:
>
> |I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla 
> Committer. |
>
> |David is a member of the Oracle Core Libraries team.
> |
>
> Nearly 30 years of Java experience, including mobile and embedded 
> device JVMs.
> Class library development at Google with Guava, logging, and 
> internationalization.
>
> |David has contributed 26 commits to the Valhalla repo [4] and 19 
> commits to the JDK repo [5].|
>
> ||Votes are due by 17:00 CET Monday Dec 1, 2025||
>
> |Only current Valhalla Committers [1] are eligible to vote on this 
> nomination.
> Votes must be cast in the open by replying to this mailing list. |
>
> |For Lazy Consensus voting instructions, see [2].
> |
>
> |Regards, Roger Riggs
> |
>
> |[1] https://openjdk.org/census
> [2] https://openjdk.org/projects/#committer-vote
> [3] https://github.com/david-beaumont
> [4] 
> https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
> [5] 
> https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fjdk&type=commits
> |
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251117/554397f7/attachment.htm>

From qamai at openjdk.org  Mon Nov 17 14:38:02 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 17 Nov 2025 14:38:02 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass [v2]
In-Reply-To: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
Message-ID: <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>

> Hi,
> 
> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
> 
> I also had to fix `GraphKit::cast_to_flat_array`, currently it incorrectly assumes that the cast is to an exact type, splitting into `cast_to_flat_array` and `cast_to_flat_array_exact` seems to make it clearer.
> 
> Please kindly review, thanks a lot.

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

  can only infer klass if exact

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1739/files
  - new: https://git.openjdk.org/valhalla/pull/1739/files/b401f2ff..be614362

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

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

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

From qamai at openjdk.org  Mon Nov 17 14:45:15 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 17 Nov 2025 14:45:15 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass [v2]
In-Reply-To: <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
 <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>
Message-ID: <lX4_IkBR-iLzWxw8dbElXa1wfG6zNvb1YUswd-FRO9Q=.e93d2c4c-254b-49e4-ba70-b1e9d5f751a4@github.com>

On Mon, 17 Nov 2025 14:38:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
>> 
>> I also had to fix `GraphKit::cast_to_flat_array`, currently it incorrectly assumes that the cast is to an exact type, splitting into `cast_to_flat_array` and `cast_to_flat_array_exact` seems to make it clearer.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   can only infer klass if exact

Thanks for your testing. Unfortunately, the issue cuts pretty deep. We have multiple potential inconsistencies when dealing with `_klass` such as when trying to obtain a flat `TypeAryPtr` from a non-flat `TypeAryPtr`. I think it can be addressed as follow-up issues. To fix the immediate crash, I choose to fix a particular issue, that is we can only compute the `_klass` if we have `klass_is_exact`.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1739#issuecomment-3542204909

From duke at openjdk.org  Mon Nov 17 16:14:13 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Nov 2025 16:14:13 GMT
Subject: [lworld] RFR: 8371897: [lworld] CLONE - VerifyJimage test
 incorrectly skips all tests when comparing directory structure
In-Reply-To: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
References: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
Message-ID: <5w7oJGX-7GmTkJvvbKYKNyZEatEX_ExOc0ikdGkQofU=.a6f5bc84-551f-439b-8071-e5c5bbadb424@github.com>

On Fri, 14 Nov 2025 16:50:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
> 
> This is a clone of https://github.com/openjdk/jdk/pull/28265

@david-beaumont 
Your change (at version a00261ae55b6d60a66a9ed35aea4b69302507e6b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1737#issuecomment-3542703346

From matsaave at openjdk.org  Mon Nov 17 16:17:27 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 17 Nov 2025 16:17:27 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes pre-registered
 unconditionally
Message-ID: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>

This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.

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

Commit messages:
 - Merge branch 'lworld' into pre_register_classes_8371826
 - 8371826: [lworld] Migrated value classes pre-registered unconditionally

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

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

From frederic.parain at oracle.com  Mon Nov 17 16:26:01 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 17 Nov 2025 11:26:01 -0500
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <87fc5f6b-c637-4f27-a1a7-fb0485282275@oracle.com>

Vote: yes

Fred

On 11/14/25 12:11, Roger Riggs wrote:
>
> |I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla 
> Committer. |
>
> |David is a member of the Oracle Core Libraries team.
> |
>
> Nearly 30 years of Java experience, including mobile and embedded 
> device JVMs.
> Class library development at Google with Guava, logging, and 
> internationalization.
>
> |David has contributed 26 commits to the Valhalla repo [4] and 19 
> commits to the JDK repo [5].|
>
> ||Votes are due by 17:00 CET Monday Dec 1, 2025||
>
> |Only current Valhalla Committers [1] are eligible to vote on this 
> nomination.
> Votes must be cast in the open by replying to this mailing list. |
>
> |For Lazy Consensus voting instructions, see [2].
> |
>
> |Regards, Roger Riggs
> |
>
> |[1] https://openjdk.org/census
> [2] https://openjdk.org/projects/#committer-vote
> [3] https://github.com/david-beaumont
> [4] 
> https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
> [5] 
> https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fjdk&type=commits
> |
>
>

From qamai at openjdk.org  Mon Nov 17 16:37:33 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 17 Nov 2025 16:37:33 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass [v2]
In-Reply-To: <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
 <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>
Message-ID: <pE7qofCDvIwCXRS3UbxfE1_D2abcvqtD0QWCVCbxDgM=.ca1bdb47-6072-463f-94ec-5bf99e3d4326@github.com>

On Mon, 17 Nov 2025 14:38:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
>> 
>> I also had to fix `GraphKit::cast_to_flat_array`, currently it incorrectly assumes that the cast is to an exact type, splitting into `cast_to_flat_array` and `cast_to_flat_array_exact` seems to make it clearer.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   can only infer klass if exact

Too bad it seems pretty hard to walk on the thin line right now. I think it is better to tighten the type system around arrays first.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1739#issuecomment-3542816500

From coleenp at openjdk.org  Mon Nov 17 17:39:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Nov 2025 17:39:35 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally
In-Reply-To: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
Message-ID: <nfdeMS7ExIRMDNLV7Uc8E4B50Y_aqNrdNgQQJ1bjSGc=.afe5d2da-5121-431b-97b5-2a2ef9db9203@github.com>

On Mon, 17 Nov 2025 16:09:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.

This looks good. Thanks for fixing it!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1741#pullrequestreview-3473853701

From liach at openjdk.org  Mon Nov 17 18:32:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 18:32:30 GMT
Subject: [lworld] RFR: 8371356: [lworld] 'super' should be rejected in
 early construction context
In-Reply-To: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
References: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
Message-ID: <iw-kWUOgg4iIGWqyxW-0cSzfNrGsarAbZ4_26FjmEsY=.c6d7f11a-1ac1-48eb-832b-0cf5b6f64414@github.com>

On Mon, 17 Nov 2025 13:51:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> There is a bug in the algo to determine what is kosher and what is not in early construction contexts. The algo was not analyzing any static symbol. But according to the `JLS 25 15.11.2 Accessing Superclass Members using super`:
> 
> 
> It is a compile-time error if a field access expression using the keyword super
> occurs in a static context (?8.1.3) or in an early construction context (?8.8.7) of
> the current class.
> 
> the previous code was checking this only for instance field accesses. The current fix corrects this bug
> 
> TIA

test/langtools/tools/javac/SuperInit/SuperInitFails.java line 282:

> 280:         class Inner9Test extends Medium {
> 281:             Inner9Test() {
> 282:                 boolean check1 = Inner9Test.super.check;

Should the test also use `Parent.super.check` and `Medium.super.check`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1740#discussion_r2535124230

From liach at openjdk.org  Mon Nov 17 18:36:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 18:36:29 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <JqokaN5SDl1PPSekKzf4kJTzibZCqZvSK-0NMx2gnHs=.21a08239-b6bd-4030-8342-a0b405416496@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

Looks good.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1738#pullrequestreview-3474056217

From fparain at openjdk.org  Mon Nov 17 18:36:30 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 17 Nov 2025 18:36:30 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <g8EPMuAN7uQqh_rzA6FojWVQ-9TNIg97sHLJyzOqstw=.07ba96be-1173-4b7e-ad40-edc5961c2ccc@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

LGTM

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1738#pullrequestreview-3474065365

From liach at openjdk.org  Mon Nov 17 18:38:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 18:38:37 GMT
Subject: [lworld] RFR: 8371897: [lworld] CLONE - VerifyJimage test
 incorrectly skips all tests when comparing directory structure
In-Reply-To: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
References: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
Message-ID: <e5EQJUXqZfZCZpjkKj5B9-WOKhA88xKiTWN66hZo-P4=.055f648a-e312-4845-b606-efaae1dee0a2@github.com>

On Fri, 14 Nov 2025 16:50:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
> 
> This is a clone of https://github.com/openjdk/jdk/pull/28265

Marked as reviewed by liach (Committer).

Looks like the timeout concern is redundant. Good to go.

test/jdk/tools/jimage/VerifyJimage.java line 149:

> 147:                 }
> 148:                 pool.shutdown();
> 149:                 if (!pool.awaitTermination(20, TimeUnit.SECONDS)) {

Beware that this may time out on debug configurations. If this doesn't time out on mainline I would assume this is ok.

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

PR Review: https://git.openjdk.org/valhalla/pull/1737#pullrequestreview-3474039283
PR Comment: https://git.openjdk.org/valhalla/pull/1737#issuecomment-3543341669
PR Review Comment: https://git.openjdk.org/valhalla/pull/1737#discussion_r2535112390

From duke at openjdk.org  Mon Nov 17 18:38:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 17 Nov 2025 18:38:38 GMT
Subject: [lworld] Integrated: 8371897: [lworld] CLONE - VerifyJimage test
 incorrectly skips all tests when comparing directory structure
In-Reply-To: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
References: <x2TWeO_k2hBWh_H-8jFTuVMeAePnKCzpzAg1ufo2eWE=.ea1b852c-e2bb-4547-909d-bb89e94f2dc2@github.com>
Message-ID: <HQWxNOJ4DhkXvCuASAqfFn_xpJBu4Yg7NOgriFIGxOM=.a4d5ebb8-4c33-447b-a810-cd9115c12c9f@github.com>

On Fri, 14 Nov 2025 16:50:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Rewrite of VerifyJimage test to fix several severe issues.
> 
> This test runs in two modes, one of which is completely broken (but claims to pass) and the other which currently works but must be made compatible with up-coming preview mode changes from Valhalla.
> 
> Issue 1: Broken file comparison
> 
> This is a mode not currently run by default, but very very broken if it is run manually. It creates incorrect entry names for looking into the jimage and then ignores non existent entries without raising a failure. This code must have been broken since the introduction of BasicImageReader and the modules system.
> 
> This is the larger part of the VerifyJimage code, and it was never going to be worth keeping much of the existing code, so I wrote a new nested class (DirectoryContentVerifier) to encapsulate it.
> 
> Importantly, this version now checks false positives and false negatives for file comparison, ensuring that "true failure" cannot be silently ignored. The set of entries in the jimage which have been handled is recorded, and a check is made that all entries have either been tested or explicitly ignored.
> 
> Issue 2: Use of BasicImageReader for class file reading
> 
> A relative small part of the original code, this mode was reading class names via BasicImageReader and attempting to load them. This approach works now, but will fail when preview mode is introduced since preview versions of classes must be loaded when the JVM is run in preview mode.
> 
> The best way to get "the current set of classes in the jimage" is to enumerate the jrt:/ file-system for the runtime image (which will account for preview mode when it's introduced). So the new code in ClassLoadingVerifier does this.
> 
> Issue 3: File comparison mode was never run by default
> 
> This is likely why the broken file comparison mode wasn't discovered for years. I added two test stanzas to VerifyJimage, so that both modes are run (if possible). Some care is needed because in CI testing there are no module directories for the file comparison mode, and this should not cause a test failure.
> 
> This is a clone of https://github.com/openjdk/jdk/pull/28265

This pull request has now been integrated.

Changeset: 63a62217
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/63a6221764f22811ee1dbe8155454d21f0ba3455
Stats:     295 lines in 1 file changed: 136 ins; 43 del; 116 mod

8371897: [lworld] CLONE - VerifyJimage test incorrectly skips all tests when comparing directory structure

Reviewed-by: rriggs, liach

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

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

From coleenp at openjdk.org  Mon Nov 17 18:56:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Nov 2025 18:56:34 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <1ysJYZ29k_pr1goTpYi4O5O1m_tqwkEKedv8r7d2n_M=.777b19e1-bd59-4bd4-9a7d-0a4368a305fe@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1738#issuecomment-3543400361

From coleenp at openjdk.org  Mon Nov 17 18:56:34 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Nov 2025 18:56:34 GMT
Subject: [lworld] Integrated: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <os-ssDpaILMghYWLBW2F2Yq_yXS1TZ5ziegR_qEsXT8=.28bbaa00-784c-470a-a1bb-670acb18e744@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: fe178a8b
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/fe178a8bea7b95e0529c037c25dc375bee1a44b5
Stats:     23 lines in 5 files changed: 11 ins; 6 del; 6 mod

8364447: [lworld] Save isIdentity in a field of Class

Reviewed-by: rriggs, liach, fparain

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

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

From forax at openjdk.org  Mon Nov 17 19:07:09 2025
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 17 Nov 2025 19:07:09 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <0C7ytcuAHDhNZrZp7_937voZ8hce-NXIzqycpD0tCw4=.b1edddcd-13d6-4d99-ae31-f38b9989fcc5@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

question ?
This information is not already available as a bit in the modifier ?
(the SUPER bit is now renamed to IDENTITY)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1738#issuecomment-3543438813

From vromero at openjdk.org  Mon Nov 17 19:16:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Nov 2025 19:16:32 GMT
Subject: [lworld] RFR: 8371356: [lworld] 'super' should be rejected in
 early construction context
In-Reply-To: <iw-kWUOgg4iIGWqyxW-0cSzfNrGsarAbZ4_26FjmEsY=.c6d7f11a-1ac1-48eb-832b-0cf5b6f64414@github.com>
References: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
 <iw-kWUOgg4iIGWqyxW-0cSzfNrGsarAbZ4_26FjmEsY=.c6d7f11a-1ac1-48eb-832b-0cf5b6f64414@github.com>
Message-ID: <h9Vy5RjVbEA61et_pdrWEn494-uGeGtULTXqVhQnwP0=.32f22138-1038-4e4b-b243-93394c96d8cf@github.com>

On Mon, 17 Nov 2025 18:29:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> There is a bug in the algo to determine what is kosher and what is not in early construction contexts. The algo was not analyzing any static symbol. But according to the `JLS 25 15.11.2 Accessing Superclass Members using super`:
>> 
>> 
>> It is a compile-time error if a field access expression using the keyword super
>> occurs in a static context (?8.1.3) or in an early construction context (?8.8.7) of
>> the current class.
>> 
>> the previous code was checking this only for instance field accesses. The current fix corrects this bug
>> 
>> TIA
>
> test/langtools/tools/javac/SuperInit/SuperInitFails.java line 282:
> 
>> 280:         class Inner9Test extends Medium {
>> 281:             Inner9Test() {
>> 282:                 boolean check1 = Inner9Test.super.check;
> 
> Should the test also use `Parent.super.check` and `Medium.super.check`?

in those cases javac already fails with:

`error: not an enclosing class: ClassName`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1740#discussion_r2535238928

From liach at openjdk.org  Mon Nov 17 19:19:42 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 19:19:42 GMT
Subject: [lworld] RFR: 8371356: [lworld] 'super' should be rejected in
 early construction context
In-Reply-To: <h9Vy5RjVbEA61et_pdrWEn494-uGeGtULTXqVhQnwP0=.32f22138-1038-4e4b-b243-93394c96d8cf@github.com>
References: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
 <iw-kWUOgg4iIGWqyxW-0cSzfNrGsarAbZ4_26FjmEsY=.c6d7f11a-1ac1-48eb-832b-0cf5b6f64414@github.com>
 <h9Vy5RjVbEA61et_pdrWEn494-uGeGtULTXqVhQnwP0=.32f22138-1038-4e4b-b243-93394c96d8cf@github.com>
Message-ID: <aMOVG5IAwWWvlWdKrWenJFCF3rWydIQ7kMWlp84dxPY=.4efd01d5-7738-4315-bcd1-e6bd87380f23@github.com>

On Mon, 17 Nov 2025 19:14:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> test/langtools/tools/javac/SuperInit/SuperInitFails.java line 282:
>> 
>>> 280:         class Inner9Test extends Medium {
>>> 281:             Inner9Test() {
>>> 282:                 boolean check1 = Inner9Test.super.check;
>> 
>> Should the test also use `Parent.super.check` and `Medium.super.check`?
>
> in those cases javac already fails with:
> 
> `error: not an enclosing class: ClassName`

I remember the original case provided uses `Interface.super.staticField`. So it's like we have this code in `Medium` instead; can we maybe make `Inner9Test` instead of `Medium` implement `Parent`?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1740#discussion_r2535246835

From vromero at openjdk.org  Mon Nov 17 19:38:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Nov 2025 19:38:16 GMT
Subject: [lworld] RFR: 8371356: [lworld] 'super' should be rejected in
 early construction context
In-Reply-To: <aMOVG5IAwWWvlWdKrWenJFCF3rWydIQ7kMWlp84dxPY=.4efd01d5-7738-4315-bcd1-e6bd87380f23@github.com>
References: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
 <iw-kWUOgg4iIGWqyxW-0cSzfNrGsarAbZ4_26FjmEsY=.c6d7f11a-1ac1-48eb-832b-0cf5b6f64414@github.com>
 <h9Vy5RjVbEA61et_pdrWEn494-uGeGtULTXqVhQnwP0=.32f22138-1038-4e4b-b243-93394c96d8cf@github.com>
 <aMOVG5IAwWWvlWdKrWenJFCF3rWydIQ7kMWlp84dxPY=.4efd01d5-7738-4315-bcd1-e6bd87380f23@github.com>
Message-ID: <DtjTMSmfK4YU8dsTmyY6LmkV_4KUmkSf3t772SyEbXU=.15aa2f62-d11f-4153-8925-dacefcee57ff@github.com>

On Mon, 17 Nov 2025 19:16:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> in those cases javac already fails with:
>> 
>> `error: not an enclosing class: ClassName`
>
> I remember the original case provided uses `Interface.super.staticField`. So it's like we have this code in `Medium` instead; can we maybe make `Inner9Test` instead of `Medium` implement `Parent`?

I couldn't reproduce the error with the original example in javac, the original example was tested on jshell, but when then the reporter went back to the original java code for which this issue was happening and the case in the JBS was the minimal standalone reproductor for the issue. Dunno what is the interaction with jshell that makes the difference though

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1740#discussion_r2535296142

From liach at openjdk.org  Mon Nov 17 19:43:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 17 Nov 2025 19:43:25 GMT
Subject: [lworld] RFR: 8371356: [lworld] 'super' should be rejected in
 early construction context
In-Reply-To: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
References: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
Message-ID: <4CSpX8Vokjg0S_ODqgN-lYi-sqf-Odw0hyz0rFtqZwU=.147937c1-55d8-4485-8bb3-6a778f0f511f@github.com>

On Mon, 17 Nov 2025 13:51:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> There is a bug in the algo to determine what is kosher and what is not in early construction contexts. The algo was not analyzing any static symbol. But according to the `JLS 25 15.11.2 Accessing Superclass Members using super`:
> 
> 
> It is a compile-time error if a field access expression using the keyword super
> occurs in a static context (?8.1.3) or in an early construction context (?8.8.7) of
> the current class.
> 
> the previous code was checking this only for instance field accesses. The current fix corrects this bug
> 
> TIA

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1740#pullrequestreview-3474307494

From heidinga at openjdk.org  Mon Nov 17 19:51:26 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 17 Nov 2025 19:51:26 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally
In-Reply-To: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
Message-ID: <Mq9-oIuSNvkcrrOzAancfZjstBeCoiiSOSxxq2e7DnU=.1b97841f-72d2-4d3b-932e-546d13860aa6@github.com>

On Mon, 17 Nov 2025 16:09:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.

looks good.  Nice find!

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1741#pullrequestreview-3474332152

From rriggs at openjdk.org  Mon Nov 17 20:47:34 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 20:47:34 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <0C7ytcuAHDhNZrZp7_937voZ8hce-NXIzqycpD0tCw4=.b1edddcd-13d6-4d99-ae31-f38b9989fcc5@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
 <0C7ytcuAHDhNZrZp7_937voZ8hce-NXIzqycpD0tCw4=.b1edddcd-13d6-4d99-ae31-f38b9989fcc5@github.com>
Message-ID: <r1lqYn5N4flak6TsnxkYz0Vb8CelPdflUapUG54ygvU=.984d7090-e435-4e6f-8fe0-e0a061a6fce1@github.com>

On Mon, 17 Nov 2025 19:03:53 GMT, R?mi Forax <forax at openjdk.org> wrote:

> question ? This information is not already available as a bit in the modifier ? (the SUPER bit is now renamed to IDENTITY)

Not quite, Coleen described the algorithm in the isue.  The Identity access flag is not sufficient to identify primitives, or arrays, or interfaces (correctly).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1738#issuecomment-3543759798

From coleenp at openjdk.org  Mon Nov 17 21:03:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 17 Nov 2025 21:03:31 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <ZPVtScjoixSeANK6mPdsXV2kWL2m48opauV9e57lODw=.4f568dc1-60b2-4092-84d1-0596ea54458a@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

Yes thanks Roger and thanks Remi for the question.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1738#issuecomment-3543819776

From rriggs at openjdk.org  Mon Nov 17 21:35:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 21:35:42 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v2]
In-Reply-To: <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
 <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>
Message-ID: <Izl2eRgUZmjHdeBcJnWwVtBf3ouplU5O0ofZV6IR07I=.1cc6a5df-c312-4184-ae04-7f86d64b778b@github.com>

On Fri, 14 Nov 2025 12:10:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont 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:
> 
>  - rename marker, tweak comments
>  - Merge branch 'lworld' into jdk_8368475_makefile/squashed
>  - Copy value classes into preview directories for inclusion in jimage

How is this change tested? 
What tests verify the configuration with "DISABLE_PREVIEW_PATCHING=true"

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

PR Comment: https://git.openjdk.org/valhalla/pull/1727#issuecomment-3543928032

From rriggs at openjdk.org  Mon Nov 17 21:45:43 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 21:45:43 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v2]
In-Reply-To: <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
 <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>
Message-ID: <LOBwemthADpn8tJkVwa6ljOcSvi1sCO-kpoOcdPthqI=.e9c23741-699c-474c-92ba-f58d5300d5db@github.com>

On Fri, 14 Nov 2025 12:10:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont 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:
> 
>  - rename marker, tweak comments
>  - Merge branch 'lworld' into jdk_8368475_makefile/squashed
>  - Copy value classes into preview directories for inclusion in jimage

Please merge with lworld so all the related commits are in place.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1727#issuecomment-3543958727

From rriggs at openjdk.org  Mon Nov 17 22:14:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Nov 2025 22:14:05 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v2]
In-Reply-To: <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
 <tTUvEKPZq95QqZSGz_Ul8PuNSt8SybOutrFUKbPb5Qc=.f1131e8a-fc5c-4679-ab67-7fa2b1be27ca@github.com>
Message-ID: <_Le3-_o7jX0pE98_KB1iAqM4sbXn0EpOnPT3jS2UgDA=.2c61bb29-eda0-4399-8d5c-8903d2d8e31d@github.com>

On Fri, 14 Nov 2025 12:10:33 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont 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:
> 
>  - rename marker, tweak comments
>  - Merge branch 'lworld' into jdk_8368475_makefile/squashed
>  - Copy value classes into preview directories for inclusion in jimage

This does the job, but its hard to confirm the results.

There should be a log message indicating that jimage is using preview classes.
Perhaps per-class logging, as is done for CDS archive or JAR file or..., indicating where the class is loaded from. That would give good visibility into class loading problems, if any.

There is an existing message in arguments.cpp for patched value classes that could be revised for enabling preview classes from jimage.

    log_info(class)("--enable-preview appending value classes for module %s: %s", module_name, entry->d_name);

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1727#pullrequestreview-3474743483
PR Comment: https://git.openjdk.org/valhalla/pull/1727#issuecomment-3544053237

From vromero at openjdk.org  Mon Nov 17 22:49:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 17 Nov 2025 22:49:38 GMT
Subject: [lworld] Integrated: 8371356: [lworld] 'super' should be rejected in
 early construction context
In-Reply-To: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
References: <Zrn04TWLmS7_JE8g27jV06JVgXEyyNZnMqgVBzBQUlg=.3ac1b954-2914-46e7-ae7f-6cc04b78aac6@github.com>
Message-ID: <hWMVaFpf9yVKhcoFcsRMYZjJyo3xDCPXBPe0IGYz82A=.3ddab4e1-ded2-4218-8e0f-bbf3ea730b92@github.com>

On Mon, 17 Nov 2025 13:51:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> There is a bug in the algo to determine what is kosher and what is not in early construction contexts. The algo was not analyzing any static symbol. But according to the `JLS 25 15.11.2 Accessing Superclass Members using super`:
> 
> 
> It is a compile-time error if a field access expression using the keyword super
> occurs in a static context (?8.1.3) or in an early construction context (?8.8.7) of
> the current class.
> 
> the previous code was checking this only for instance field accesses. The current fix corrects this bug
> 
> TIA

This pull request has now been integrated.

Changeset: e50f031e
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e50f031e8f163ec4ed350d385799cac9e091013f
Stats:     47 lines in 5 files changed: 46 ins; 0 del; 1 mod

8371356: [lworld] 'super' should be rejected in early construction context

Reviewed-by: liach

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

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

From liach at openjdk.org  Tue Nov 18 00:07:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 18 Nov 2025 00:07:41 GMT
Subject: [lworld] RFR: 8364447: [lworld] Save isIdentity in a field of
 Class
In-Reply-To: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
References: <ZXByVf_MzWz2EEAyWg-8xgLN9mDLlfq5kGadLOdgN50=.0970cf69-1677-4e33-9919-9ac900284655@github.com>
Message-ID: <wX1D5JQrltiZDBOZvYcBqIvX6M1mVv9GBvwsbl886Z4=.0c6ebb64-495d-4011-9514-2d7beaf94efc@github.com>

On Fri, 14 Nov 2025 19:04:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change saves an 'identity' field in the j.l.Class for easy checks and inlining.
> Tested with tier1-4.

What Remi suggested probably works - we do seem to inject IDENTITY to older classes in a `!support_inline_types()` check in `ClassFileParser::parse_stream` now, so something like `componentType == null && Modifier.isIdentity(classFileAccessFlags)` can work.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1738#issuecomment-3544399131

From phubner at openjdk.org  Tue Nov 18 10:15:17 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 18 Nov 2025 10:15:17 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally
In-Reply-To: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
Message-ID: <oRSDmdbeGmkEAf3oEvc7CTuNqfwNe07K_7dxVI-d4gI=.354dfd7f-de9e-440d-a250-2629f9d2e804@github.com>

On Mon, 17 Nov 2025 16:09:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.

src/hotspot/share/classfile/systemDictionary.cpp line 216:

> 214:       bool created = false;
> 215:       ClassLoaderData* cld = ClassLoaderDataGraph::find_or_create(class_loader, created);
> 216:       if (created && Arguments::enable_preview() && EnableValhalla) {

I'd like to get rid of the `EnableValhalla` while we are at it, `--enable-preview` implies `EnableValhalla`, plus this would mean one less place to remove the flag later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1741#discussion_r2537300237

From qamai at openjdk.org  Tue Nov 18 11:26:07 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 18 Nov 2025 11:26:07 GMT
Subject: [lworld] RFR: 8372075: [lworld] Information about the layout of a
 TypeAryPtr is only available if it is exact
Message-ID: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>

Hi,

The layout of a flat `TypeAryPtr` can only be obtained if it is exact. This small patch refactors `TypeAryPtr::flat_layout_helper` and similar methods to use `exact_klass()` instead of `klass()`, and add an additional condition for when we can compute `_field_offset` during `TypeAryPtr::add_field_offset_and_offset`. We can then remove the extra condition in `TypeAryPtr::compute_klass`.

Please leave your reviews, thanks a lot.

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

Commit messages:
 - details about the flat-ness of an array is only available for exact types

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

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

From thartmann at openjdk.org  Tue Nov 18 14:08:38 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 18 Nov 2025 14:08:38 GMT
Subject: [lworld] RFR: 8372075: [lworld] Information about the layout of a
 TypeAryPtr is only available if it is exact
In-Reply-To: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>
References: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>
Message-ID: <SU7bMpDjl8VYgdvGWWiXoEX_ATVxO1WkemNfAM08UcU=.88c323ba-bcde-4554-9c4e-ec8320c6a695@github.com>

On Tue, 18 Nov 2025 11:19:51 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The layout of a flat `TypeAryPtr` can only be obtained if it is exact. This small patch refactors `TypeAryPtr::flat_layout_helper` and similar methods to use `exact_klass()` instead of `klass()`, and add an additional condition for when we can compute `_field_offset` during `TypeAryPtr::add_field_offset_and_offset`. We can then remove the extra condition in `TypeAryPtr::compute_klass`.
> 
> Please leave your reviews, thanks a lot.

Nice cleanup. Looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1744#pullrequestreview-3478023783

From qamai at openjdk.org  Tue Nov 18 17:57:38 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 18 Nov 2025 17:57:38 GMT
Subject: [lworld] RFR: 8372075: [lworld] Information about the layout of a
 TypeAryPtr is only available if it is exact
In-Reply-To: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>
References: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>
Message-ID: <BSQkdVRj6THlTLyePz8q80S8rC29xztXd6gsfCvm2-o=.b4563681-c0d2-4b98-892c-a41ecd56ce5c@github.com>

On Tue, 18 Nov 2025 11:19:51 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The layout of a flat `TypeAryPtr` can only be obtained if it is exact. This small patch refactors `TypeAryPtr::flat_layout_helper` and similar methods to use `exact_klass()` instead of `klass()`, and add an additional condition for when we can compute `_field_offset` during `TypeAryPtr::add_field_offset_and_offset`. We can then remove the extra condition in `TypeAryPtr::compute_klass`.
> 
> Please leave your reviews, thanks a lot.

Thanks a lot for your review!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1744#issuecomment-3548877090

From qamai at openjdk.org  Tue Nov 18 17:57:40 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 18 Nov 2025 17:57:40 GMT
Subject: [lworld] Integrated: 8372075: [lworld] Information about the layout of
 a TypeAryPtr is only available if it is exact
In-Reply-To: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>
References: <JZbKoV2LwPTskg2JL49rKGy9DDooKO8HZPyUGBmkAIQ=.9db6f8d1-41ba-48e0-817a-2796bb6fdf8a@github.com>
Message-ID: <gq1Uvmi1sdDPMI0R0jy6JfNJyFrRxPnWlXtEgDW0Gvk=.6a60299e-a136-481c-950a-e5c4b58b51d6@github.com>

On Tue, 18 Nov 2025 11:19:51 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> The layout of a flat `TypeAryPtr` can only be obtained if it is exact. This small patch refactors `TypeAryPtr::flat_layout_helper` and similar methods to use `exact_klass()` instead of `klass()`, and add an additional condition for when we can compute `_field_offset` during `TypeAryPtr::add_field_offset_and_offset`. We can then remove the extra condition in `TypeAryPtr::compute_klass`.
> 
> Please leave your reviews, thanks a lot.

This pull request has now been integrated.

Changeset: 3e9e67f5
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3e9e67f59f3cd9c3f3bb5e870f7f64dd8453a75c
Stats:     12 lines in 1 file changed: 0 ins; 7 del; 5 mod

8372075: [lworld] Information about the layout of a TypeAryPtr is only available if it is exact

Reviewed-by: thartmann

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

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

From fparain at openjdk.org  Tue Nov 18 18:25:59 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 18 Nov 2025 18:25:59 GMT
Subject: [lworld] RFR: 8371915: [lworld] LayoutKind enum should have helper
 methods
Message-ID: <Up4Lofefl28JyymZVZi-JMmibNOp-P2k87axlF3U7Jg=.2b4b0bfb-0a99-4717-908a-6c83317b6389@github.com>

Add some helper methods to test properties of layouts in a more reliable way.

Tested with Mach5, tier 1 to 3.

Fred

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

Commit messages:
 - Add helper methods to LayoutKind

Changes: https://git.openjdk.org/valhalla/pull/1745/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371915
  Stats: 98 lines in 11 files changed: 35 ins; 43 del; 20 mod
  Patch: https://git.openjdk.org/valhalla/pull/1745.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1745/head:pull/1745

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

From matsaave at openjdk.org  Tue Nov 18 19:06:19 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 18 Nov 2025 19:06:19 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally [v2]
In-Reply-To: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
Message-ID: <vV2kfHWNF0SHiRAFQ711At7MaahN0wcEBdajXc6c8dE=.30aeb47b-2687-42de-9e68-ad75d05de4b9@github.com>

> This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Remove EnableValhalla

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1741/files
  - new: https://git.openjdk.org/valhalla/pull/1741/files/d0a2ebbb..d90a454d

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

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

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

From coleen.phillimore at oracle.com  Tue Nov 18 19:47:41 2025
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 18 Nov 2025 19:47:41 +0000
Subject: CFV: New Valhalla Committer: David Beaumont
In-Reply-To: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
References: <209d8089-28a6-4098-8fb7-0b9452894eec@oracle.com>
Message-ID: <IA1PR10MB6073C02A9E31BDA6A67671458ED6A@IA1PR10MB6073.namprd10.prod.outlook.com>

Vote: yes


Get Outlook for Mac <https://aka.ms/GetOutlookForMac>

From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Roger Riggs <roger.riggs at oracle.com>
Date: Friday, November 14, 2025 at 12:11?PM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: CFV: New Valhalla Committer: David Beaumont


I hereby nominate David Beaumont (david-beaumont [3]) to Valhalla Committer.

David is a member of the Oracle Core Libraries team.

Nearly 30 years of Java experience, including mobile and embedded device JVMs.
Class library development at Google with Guava, logging, and internationalization.

David has contributed 26 commits to the Valhalla repo [4] and 19 commits to the JDK repo [5].

Votes are due by 17:00 CET Monday Dec 1, 2025

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

For Lazy Consensus voting instructions, see [2].

Regards, Roger Riggs

[1] https://openjdk.org/census
[2] https://openjdk.org/projects/#committer-vote
[3] https://github.com/david-beaumont
[4] https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fvalhalla&type=commits
[5] https://github.com/search?q=author%3Adavid-beaumont+repo%3Aopenjdk%2Fjdk&type=commits



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

From duke at openjdk.org  Tue Nov 18 21:56:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 18 Nov 2025 21:56:57 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v3]
In-Reply-To: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
Message-ID: <gsvaP803YiJlgs8x6XUVlJuHJoIoaLJQKaoQtlxtsOg=.d1d7fe17-c6a5-4a37-886b-780d233ca997@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

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

 - Merge branch 'lworld' into jdk_8368475_makefile/squashed
 - rename marker, tweak comments
 - Merge branch 'lworld' into jdk_8368475_makefile/squashed
 - Copy value classes into preview directories for inclusion in jimage

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1727/files
  - new: https://git.openjdk.org/valhalla/pull/1727/files/09327056..291c1c74

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

  Stats: 424 lines in 16 files changed: 220 ins; 65 del; 139 mod
  Patch: https://git.openjdk.org/valhalla/pull/1727.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1727/head:pull/1727

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

From duke at openjdk.org  Tue Nov 18 22:15:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 18 Nov 2025 22:15:09 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v3]
In-Reply-To: <gsvaP803YiJlgs8x6XUVlJuHJoIoaLJQKaoQtlxtsOg=.d1d7fe17-c6a5-4a37-886b-780d233ca997@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
 <gsvaP803YiJlgs8x6XUVlJuHJoIoaLJQKaoQtlxtsOg=.d1d7fe17-c6a5-4a37-886b-780d233ca997@github.com>
Message-ID: <Q1bhwpUwLOJh-Q8jhZG9wYi2SKHXd3AGVwa1ilYrJkk=.5d63a0b4-fe59-411f-a281-13d2ac2e28f8@github.com>

On Tue, 18 Nov 2025 21:56:57 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'lworld' into jdk_8368475_makefile/squashed
>  - rename marker, tweak comments
>  - Merge branch 'lworld' into jdk_8368475_makefile/squashed
>  - Copy value classes into preview directories for inclusion in jimage

I know it's working once the system property is changed. As it stands this should have no impact other than adding some unused entries into the jimage file.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1727#issuecomment-3549641479

From phubner at openjdk.org  Wed Nov 19 09:19:41 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 19 Nov 2025 09:19:41 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally [v2]
In-Reply-To: <vV2kfHWNF0SHiRAFQ711At7MaahN0wcEBdajXc6c8dE=.30aeb47b-2687-42de-9e68-ad75d05de4b9@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
 <vV2kfHWNF0SHiRAFQ711At7MaahN0wcEBdajXc6c8dE=.30aeb47b-2687-42de-9e68-ad75d05de4b9@github.com>
Message-ID: <S9GDQCe1d9Z7Sw842uSu4hV-CXmg7Fm7wC14Ym56nwY=.46ba8fce-1b1d-475b-96ea-e9d4b1395327@github.com>

On Tue, 18 Nov 2025 19:06:19 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove EnableValhalla

Thanks for removing the flag and fixing this.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1741#pullrequestreview-3481642544

From duke at openjdk.org  Wed Nov 19 11:59:18 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 19 Nov 2025 11:59:18 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v4]
In-Reply-To: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
Message-ID: <t0D1VmmduLuaiO3gqSB3f8IVK_njCgEnJsTo7s2mQ8s=.fcef20a8-34e8-41e4-b738-34b2640e5d94@github.com>

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

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

  added notes for what needs fixing later

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1727/files
  - new: https://git.openjdk.org/valhalla/pull/1727/files/291c1c74..f3ce482f

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

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

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

From bmaillard at openjdk.org  Wed Nov 19 12:06:23 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 19 Nov 2025 12:06:23 GMT
Subject: [lworld] RFR: 8367623: [lworld] C2: Ideal Optimization on
 InlineTypeNode should not be carried out after Macro Expansion
Message-ID: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>

This PR tightens the conditions under which an optimization from `InlineTypeNode::Ideal` should be carried out. This optimization was initially reported as missed with `-XX:VerifyIterativeGVN`.

### Summary

The original failure appeared with `TestFieldNullMarkers.java` and `-XX:VerifyIterativeGVN=1110`. This test performs various allocations with value classes and other Valhalla features.

In `InlineTypeNode::Ideal`, we have the following optimization:

https://github.com/openjdk/valhalla/blob/b1d14c658511cced2a860d9e2741ae89827e25ba/src/hotspot/share/opto/inlinetypenode.cpp#L835-L853

As explained in the optimization comments, we don't want to use the base oop if it corresponds to the larval oop. This is enforced by the condition `AllocateNode::Ideal_allocation(base) == nullptr`.

In our case this is exactly what happens, and the optimization is prevented. HOwever, this changes during macro expansion. The allocate node disappears, and `AllocateNode::Ideal_allocation(base) == nullptr` becomes true. As this is not intended, there is no notification mechanism for this case and we end up with the missing optimization assert.

The conditions for this bug to reproduce are somewhat subtle. When things go well, the larval `Allocate` node is eliminated by `eliminate_allocate_node` before this problematic case shows up. However, there are cases where the `<init>` method is not inlined, and this prevents the removal of the `Allocate` node. It stays until macro expansion, and that is where things go wrong.  

In the extracted reproducer, the `<init>` method is not inlined because of unloaded signature classes, as `CompileCommand=printinlining` shows:


CompileCommand: PrintInlining *.* bool PrintInlining = true
                            @ 5   compiler.valhalla.inlinetypes.TestMissingOptUseBaseOop$MyValue::<init> (10 bytes)   failed to inline: unloaded signature classes


This could also happen for other reasons though.

### Solution

The solution is to not do this optimization after macro expansion. Adding a `phase->C->allow_macro_nodes()` check ensures that the `AllocateNode::Ideal_allocation(base)` call is relevant in the current phase and that we can use it to check if we are dealing with the larval oop.

### Testing
- [x] [GitHub Actions](https://github.com/benoitmaillard/valhalla/actions?query=branch%3AJDK-8367623)
- [ ] tier1-4, plus some internal testing

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

Commit messages:
 - Add comment to explain the inlining failure
 - Rename test, add missing stuff
 - Implement actual fix
 - Update new test
 - Add new test

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

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

From duke at openjdk.org  Wed Nov 19 12:46:47 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Nov 2025 12:46:47 GMT
Subject: [lworld] RFR: 8368475: [lworld] Add preview classes to jimage at
 make time [v4]
In-Reply-To: <t0D1VmmduLuaiO3gqSB3f8IVK_njCgEnJsTo7s2mQ8s=.fcef20a8-34e8-41e4-b738-34b2640e5d94@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
 <t0D1VmmduLuaiO3gqSB3f8IVK_njCgEnJsTo7s2mQ8s=.fcef20a8-34e8-41e4-b738-34b2640e5d94@github.com>
Message-ID: <EX2zqJlE2voZJlwCMVkkL06QI00bby6zk2tFPJvOC5M=.bdf210b8-f576-4dec-9475-799411c990ae@github.com>

On Wed, 19 Nov 2025 11:59:18 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
>> 
>> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
>> 
>> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added notes for what needs fixing later

@david-beaumont 
Your change (at version f3ce482f31e558806599f1ef7481b4ad473ba2f4) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1727#issuecomment-3552512029

From duke at openjdk.org  Wed Nov 19 12:52:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 19 Nov 2025 12:52:03 GMT
Subject: [lworld] Integrated: 8368475: [lworld] Add preview classes to jimage
 at make time
In-Reply-To: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
References: <VJrOhhVvi9HIGnRrGM_C3J4UxPNJJeZFVJra5c8kGOI=.3a2428ef-3486-4b7f-af9f-e29c42c2b88b@github.com>
Message-ID: <AQPTjOH1zpQurBxylZP_UFL_FqYvUXquyycK13dwUw4=.5449db63-7933-4f46-9d5f-14ce9f990b7f@github.com>

On Fri, 7 Nov 2025 13:51:44 GMT, David Beaumont <duke at openjdk.org> wrote:

> Copies valuetype classes for each module into corresponding "/META-INF/preview/..." sub-directories to be pulled into jimage files and processed by the new preview mode handling code.
> 
> There might be a better way to do this in terms of Makefile semantics, but this seems to work well enough and doesn't prevent the value-class JAR files being generated for patching (which is still how everyone will get value classes until the rest of the work is plumbed in).
> 
> To enable the new preview mode work, set the "DISABLE_PREVIEW_PATCHING" system property to "true".

This pull request has now been integrated.

Changeset: 8ff62c86
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8ff62c86d900e4a060993b0c619d9ecddc5aa227
Stats:     27 lines in 1 file changed: 25 ins; 0 del; 2 mod

8368475: [lworld] Add preview classes to jimage at make time

Reviewed-by: rriggs

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

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

From qamai at openjdk.org  Wed Nov 19 12:59:40 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 19 Nov 2025 12:59:40 GMT
Subject: [lworld] RFR: 8367623: [lworld] C2: Ideal Optimization on
 InlineTypeNode should not be carried out after Macro Expansion
In-Reply-To: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>
References: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>
Message-ID: <LJnsWauABAI_YzJNXzMVFAbXElf2cwZjEGWW4hCikgY=.fbaa0a7a-386e-47d3-9ec3-619034f4d70f@github.com>

On Mon, 17 Nov 2025 16:14:27 GMT, Beno?t Maillard <bmaillard at openjdk.org> wrote:

> This PR tightens the conditions under which an optimization from `InlineTypeNode::Ideal` should be carried out. This optimization was initially reported as missed with `-XX:VerifyIterativeGVN`.
> 
> ### Summary
> 
> The original failure appeared with `TestFieldNullMarkers.java` and `-XX:VerifyIterativeGVN=1110`. This test performs various allocations with value classes and other Valhalla features.
> 
> In `InlineTypeNode::Ideal`, we have the following optimization:
> 
> https://github.com/openjdk/valhalla/blob/b1d14c658511cced2a860d9e2741ae89827e25ba/src/hotspot/share/opto/inlinetypenode.cpp#L835-L853
> 
> As explained in the optimization comments, we don't want to use the base oop if it corresponds to the larval oop. This is enforced by the condition `AllocateNode::Ideal_allocation(base) == nullptr`.
> 
> In our case this is exactly what happens, and the optimization is prevented. HOwever, this changes during macro expansion. The allocate node disappears, and `AllocateNode::Ideal_allocation(base) == nullptr` becomes true. As this is not intended, there is no notification mechanism for this case and we end up with the missing optimization assert.
> 
> The conditions for this bug to reproduce are somewhat subtle. When things go well, the larval `Allocate` node is eliminated by `eliminate_allocate_node` before this problematic case shows up. However, there are cases where the `<init>` method is not inlined, and this prevents the removal of the `Allocate` node. It stays until macro expansion, and that is where things go wrong.  
> 
> In the extracted reproducer, the `<init>` method is not inlined because of unloaded signature classes, as `CompileCommand=printinlining` shows:
> 
> 
> CompileCommand: PrintInlining *.* bool PrintInlining = true
>                             @ 5   compiler.valhalla.inlinetypes.TestMissingOptUseBaseOop$MyValue::<init> (10 bytes)   failed to inline: unloaded signature classes
> 
> 
> This could also happen for other reasons though.
> 
> ### Solution
> 
> The solution is to not do this optimization after macro expansion. Adding a `phase->C->allow_macro_nodes()` check ensures that the `AllocateNode::Ideal_allocation(base)` call is relevant in the current phase and that we can use it to check if we are dealing with the larval oop.
> 
> ### Testing
> - [x] [GitHub Actions](https://github.com/benoitmaillard/valhalla/actions?query=branch%3AJDK-8367623)
> - [ ] tier1-4, plus some internal testing

Maybe we should assert that `AllocateNode::Ideal_allocation` can only be called when `C->allow_macro_nodes()` so that the result is meaningful.

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

Marked as reviewed by qamai (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1742#pullrequestreview-3482551688

From thartmann at openjdk.org  Wed Nov 19 13:04:24 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 13:04:24 GMT
Subject: [lworld] RFR: 8365895: [lworld] Four compiler tests on windows OOM
 after jdk-25+25 merge
Message-ID: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>

Re-enabling tests because the issue does not reproduce anymore.

Thanks,
Tobias

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

Commit messages:
 - Removed file
 - 8365895: [lworld] Four compiler tests on windows OOM after jdk-25+25 merge

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

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

From chagedorn at openjdk.org  Wed Nov 19 13:34:57 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Nov 2025 13:34:57 GMT
Subject: [lworld] RFR: 8365895: [lworld] Four compiler tests on windows OOM
 after jdk-25+25 merge
In-Reply-To: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>
References: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>
Message-ID: <7TCjJc84QW5DWXoYFAftCIGzKXR9M9mCjVmXCBpG7QQ=.01b52e1e-7331-4a53-921b-3a33a8fd9193@github.com>

On Wed, 19 Nov 2025 12:56:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Re-enabling tests because the issue does not reproduce anymore.
> 
> Thanks,
> Tobias

Looks good!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1746#pullrequestreview-3482738766

From thartmann at openjdk.org  Wed Nov 19 13:34:58 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 13:34:58 GMT
Subject: [lworld] RFR: 8365895: [lworld] Four compiler tests on windows OOM
 after jdk-25+25 merge
In-Reply-To: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>
References: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>
Message-ID: <3qj7taP-BVAt8eEgJk8S5P1WIUTAFE2cb6b__IOK3rc=.194d7ded-e087-43c5-bc79-fd9a97da98a7@github.com>

On Wed, 19 Nov 2025 12:56:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Re-enabling tests because the issue does not reproduce anymore.
> 
> Thanks,
> Tobias

Thanks Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1746#issuecomment-3552731166

From thartmann at openjdk.org  Wed Nov 19 13:34:59 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 13:34:59 GMT
Subject: [lworld] Integrated: 8365895: [lworld] Four compiler tests on windows
 OOM after jdk-25+25 merge
In-Reply-To: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>
References: <q-sd5L1zQECjICOHPGiDkMir4RRvN_ww51wvs88WUbs=.29f70779-a49d-4677-9679-72e1b583564a@github.com>
Message-ID: <C9OuXlkalymyrTFpnAOge9nfCq0C2tqzBHxhI1qkU5s=.aa27ce3a-e391-423b-8b33-3ada53b109f4@github.com>

On Wed, 19 Nov 2025 12:56:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Re-enabling tests because the issue does not reproduce anymore.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 51440e18
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/51440e18318d3bedd609ca1ca081f36e34f96fa2
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8365895: [lworld] Four compiler tests on windows OOM after jdk-25+25 merge

Reviewed-by: chagedorn

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

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

From thartmann at openjdk.org  Wed Nov 19 15:05:17 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 15:05:17 GMT
Subject: [lworld] RFR: 8372160: [lworld] Re-link ToDos from 8329224 to 8251971
Message-ID: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>

I'll fix [JDK-8329224](https://bugs.openjdk.org/browse/JDK-8329224) as part of [JDK-8251971](https://bugs.openjdk.org/browse/JDK-8251971). Re-linking ToDos.

Thanks,
Tobias

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

Commit messages:
 - [lworld] Re-link ToDos from 8329224 to 8251971

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

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

From chagedorn at openjdk.org  Wed Nov 19 15:05:18 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 19 Nov 2025 15:05:18 GMT
Subject: [lworld] RFR: 8372160: [lworld] Re-link ToDos from 8329224 to
 8251971
In-Reply-To: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>
References: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>
Message-ID: <cLufPLrWCoFCDLoZtuGkmU5-L3U066lX1bddTJa1sOM=.4c3e19ea-8d83-409d-819f-9a50e87dc009@github.com>

On Wed, 19 Nov 2025 14:49:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I'll fix [JDK-8329224](https://bugs.openjdk.org/browse/JDK-8329224) as part of [JDK-8251971](https://bugs.openjdk.org/browse/JDK-8251971). Re-linking ToDos.
> 
> Thanks,
> Tobias

Looks good!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1747#pullrequestreview-3483219055

From thartmann at openjdk.org  Wed Nov 19 15:05:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 15:05:19 GMT
Subject: [lworld] RFR: 8372160: [lworld] Re-link ToDos from 8329224 to
 8251971
In-Reply-To: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>
References: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>
Message-ID: <HnYqJatHSguEFQfTx_huHr7cJuCBW-lTWSK31Fu3yeo=.b65bff34-c3e2-4d49-afd6-b5a4ccd917ee@github.com>

On Wed, 19 Nov 2025 14:49:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I'll fix [JDK-8329224](https://bugs.openjdk.org/browse/JDK-8329224) as part of [JDK-8251971](https://bugs.openjdk.org/browse/JDK-8251971). Re-linking ToDos.
> 
> Thanks,
> Tobias

Thanks Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1747#issuecomment-3553206190

From thartmann at openjdk.org  Wed Nov 19 15:07:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 19 Nov 2025 15:07:19 GMT
Subject: [lworld] Integrated: 8372160: [lworld] Re-link ToDos from 8329224 to
 8251971
In-Reply-To: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>
References: <10EZvj72DRtIJXFdVooN0hZjHXTTcGXRsZEZIM1X-EU=.4a53e13f-0aa8-4169-a4af-d84469df0ebd@github.com>
Message-ID: <MCkW55k8AOegvxliQRo569YzK_uAh4buwBLuNf93y8U=.f95ac653-6cee-4d59-a096-6ed1e4deceaf@github.com>

On Wed, 19 Nov 2025 14:49:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I'll fix [JDK-8329224](https://bugs.openjdk.org/browse/JDK-8329224) as part of [JDK-8251971](https://bugs.openjdk.org/browse/JDK-8251971). Re-linking ToDos.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

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

8372160: [lworld] Re-link ToDos from 8329224 to 8251971

Reviewed-by: chagedorn

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

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

From matsaave at openjdk.org  Wed Nov 19 15:11:56 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 19 Nov 2025 15:11:56 GMT
Subject: [lworld] RFR: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally [v2]
In-Reply-To: <nfdeMS7ExIRMDNLV7Uc8E4B50Y_aqNrdNgQQJ1bjSGc=.afe5d2da-5121-431b-97b5-2a2ef9db9203@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
 <nfdeMS7ExIRMDNLV7Uc8E4B50Y_aqNrdNgQQJ1bjSGc=.afe5d2da-5121-431b-97b5-2a2ef9db9203@github.com>
Message-ID: <9Y-pBaToShLFfKafuMb5ZFUudhp7Xgh6Q7IkWZGQ_-E=.b53a3eca-4bd9-4443-8a68-4312833d3c88@github.com>

On Mon, 17 Nov 2025 17:36:28 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:
>> 
>>   Remove EnableValhalla
>
> This looks good. Thanks for fixing it!

Thanks for the reviews @coleenp @DanHeidinga and @Arraying!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1741#issuecomment-3553238772

From matsaave at openjdk.org  Wed Nov 19 15:11:58 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 19 Nov 2025 15:11:58 GMT
Subject: [lworld] Integrated: 8371826: [lworld] Migrated value classes
 pre-registered unconditionally
In-Reply-To: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
References: <vHSz-6B99ug3nH2s84S6OBQx89pd9DVBzNS83-0X9b8=.88e025d3-bbee-4245-934d-69113252d602@github.com>
Message-ID: <dvPhN9hmEaDEhdHc-koJVYr114LFBR_iDx8TT7jgZ4c=.1e422710-3884-47fa-ae3c-75c90778a5fb@github.com>

On Mon, 17 Nov 2025 16:09:42 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This patch fixes a bug where the VM tries to pre-register migrated value classes regardless of whether or not the class loader data already exists. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: 0e99563e
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0e99563e6b3c76349271f58b93c2d857005fca5d
Stats:     6 lines in 3 files changed: 2 ins; 0 del; 4 mod

8371826: [lworld] Migrated value classes pre-registered unconditionally

Reviewed-by: coleenp, heidinga, phubner

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

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

From matsaave at openjdk.org  Wed Nov 19 17:19:19 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 19 Nov 2025 17:19:19 GMT
Subject: [lworld] RFR: 8368801: [lworld] AOT warning message causes
 LoggingDeadlock2 test failure
Message-ID: <0VI1xFJ5fl0bGpXdKaCHndLEQKFSjR_ffvZse_mvHjA=.6165fc5f-25d4-4fe0-ac3d-8844504dbc58@github.com>

This test should no longer fail after merging [JDK-8364929](https://bugs.openjdk.org/browse/JDK-8364929) into lworld. This test no longer needs to be problem listed.

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

Commit messages:
 - 8368801: [lworld] AOT warning message causes LoggingDeadlock2 test failure

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

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

From lfoltan at openjdk.org  Wed Nov 19 19:01:08 2025
From: lfoltan at openjdk.org (Lois Foltan)
Date: Wed, 19 Nov 2025 19:01:08 GMT
Subject: [lworld] RFR: 8368801: [lworld] AOT warning message causes
 LoggingDeadlock2 test failure
In-Reply-To: <0VI1xFJ5fl0bGpXdKaCHndLEQKFSjR_ffvZse_mvHjA=.6165fc5f-25d4-4fe0-ac3d-8844504dbc58@github.com>
References: <0VI1xFJ5fl0bGpXdKaCHndLEQKFSjR_ffvZse_mvHjA=.6165fc5f-25d4-4fe0-ac3d-8844504dbc58@github.com>
Message-ID: <rjpbSQveuD-bbKLb4dyjtYEgD2E0TTzVvnqP8efbI80=.87ab313d-163f-4f02-8d5a-aff9350d542c@github.com>

On Wed, 19 Nov 2025 17:12:58 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> This test should no longer fail after merging [JDK-8364929](https://bugs.openjdk.org/browse/JDK-8364929) into lworld. This test no longer needs to be problem listed.

Looks good.

- Lois

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

Marked as reviewed by lfoltan (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1748#pullrequestreview-3484285647

From heidinga at openjdk.org  Wed Nov 19 21:48:34 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 19 Nov 2025 21:48:34 GMT
Subject: [lworld] RFR: 8371915: [lworld] LayoutKind enum should have helper
 methods
In-Reply-To: <Up4Lofefl28JyymZVZi-JMmibNOp-P2k87axlF3U7Jg=.2b4b0bfb-0a99-4717-908a-6c83317b6389@github.com>
References: <Up4Lofefl28JyymZVZi-JMmibNOp-P2k87axlF3U7Jg=.2b4b0bfb-0a99-4717-908a-6c83317b6389@github.com>
Message-ID: <YLb1Ih2MJmqhy1A89VRpmy5i_JFlv0JNgxmJPyslryU=.ff22c7c8-a267-40a8-908f-1fd3102fc585@github.com>

On Tue, 18 Nov 2025 18:19:00 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Add some helper methods to test properties of layouts in a more reliable way.
> 
> Tested with Mach5, tier 1 to 3.
> 
> Fred

src/hotspot/share/oops/arrayKlass.cpp line 231:

> 229:     break;
> 230:     case LayoutKind::NULLABLE_ATOMIC_FLAT:
> 231:       props = ArrayKlass::ArrayProperties::NON_ATOMIC;

Why does NULLABLE_ATOMIC_FLAT produce NON_ATOMIC?  Something, maybe just naming?, seems off here.

I know this is a refactoring of existing code and so has the same meaning but it doesn't make sense to me

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1745#discussion_r2543646279

From fparain at openjdk.org  Wed Nov 19 22:00:44 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 19 Nov 2025 22:00:44 GMT
Subject: [lworld] RFR: 8371915: [lworld] LayoutKind enum should have helper
 methods
In-Reply-To: <YLb1Ih2MJmqhy1A89VRpmy5i_JFlv0JNgxmJPyslryU=.ff22c7c8-a267-40a8-908f-1fd3102fc585@github.com>
References: <Up4Lofefl28JyymZVZi-JMmibNOp-P2k87axlF3U7Jg=.2b4b0bfb-0a99-4717-908a-6c83317b6389@github.com>
 <YLb1Ih2MJmqhy1A89VRpmy5i_JFlv0JNgxmJPyslryU=.ff22c7c8-a267-40a8-908f-1fd3102fc585@github.com>
Message-ID: <biG-TiqLl8FJMPP7SFAhCEEv2uhsmPKWpymmiZZ8QIQ=.f887342d-0eed-4109-9571-9aa02dfa10f3@github.com>

On Wed, 19 Nov 2025 21:37:46 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Add some helper methods to test properties of layouts in a more reliable way.
>> 
>> Tested with Mach5, tier 1 to 3.
>> 
>> Fred
>
> src/hotspot/share/oops/arrayKlass.cpp line 231:
> 
>> 229:     break;
>> 230:     case LayoutKind::NULLABLE_ATOMIC_FLAT:
>> 231:       props = ArrayKlass::ArrayProperties::NON_ATOMIC;
> 
> Why does NULLABLE_ATOMIC_FLAT produce NON_ATOMIC?  Something, maybe just naming?, seems off here.
> 
> I know this is a refactoring of existing code and so has the same meaning but it doesn't make sense to me

Good catch!
I've copied/pasted this code when refactoring without verifying it.
It doesn't make sense to me either.
For LayoutKind::NULLABLE_ATOMIC_FLAT the method should return ArrayKlass::ArrayProperties::DEFAULT.
Let me fix this and run some tests.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1745#discussion_r2543690075