From mchevalier at openjdk.org  Mon Dec  1 07:42:25 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 1 Dec 2025 07:42:25 GMT
Subject: [lworld] RFR: 8371993: [lworld] Aarch64: save bad values instead
 of rfp and lr above the extension space [v4]
In-Reply-To: <w5nM7xA-IDQgk5b_8UKLDprlEvIXu2XKMrzZmoFMMr0=.83a5e2ae-a71d-47fa-b1b4-129f1075720f@github.com>
References: <r-daAZFoql9YnLBiyz78wmD4XrE5IGeLtZ_dC6F_DYk=.e0d8a031-1b45-4215-994c-777c1cd0fe54@github.com>
 <w5nM7xA-IDQgk5b_8UKLDprlEvIXu2XKMrzZmoFMMr0=.83a5e2ae-a71d-47fa-b1b4-129f1075720f@github.com>
Message-ID: <pARrxV9Mjc7_MOnhEeBiFeKpOf1I4tvDmlTvrX4KhAc=.5cb3a11a-7a5d-472b-ba0e-5c04b70f7092@github.com>

On Fri, 28 Nov 2025 15:49:25 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Related lore: https://github.com/openjdk/valhalla/pull/1540 & https://github.com/openjdk/valhalla/pull/1751. Please, go check those up if you miss the context.
>> 
>> As we established in [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751, LR2 and FP2 are not reliable (resp. not patched for deopt and not known by deopt code, not updated by GC). Since reading them is probably fine, but maybe not, it is risky to leave reasonable value there. In debug, I suggest we store a magic but recognizable value to make more obvious one read the wrong copy, actually, we don't really need LR2 and FP2 to contain lr and rfp, we mostly need it to make space between the stack extension and the proper frame to pretend it is like a scalarized call.
>> 
>> What I propose here is similar to zapping unused space freed by the GC: when `ZapUnusedHeapArea`, that is `trueInDebug`, we zap the heap not to read something good-looking when we have a wrong pointer.
>> 
>> https://github.com/openjdk/valhalla/blob/1144cb4c5183c69a74aa0211f7ead5ac388ee41d/src/hotspot/share/runtime/globals.hpp#L482-L483
>> 
>> https://github.com/openjdk/valhalla/blob/1144cb4c5183c69a74aa0211f7ead5ac388ee41d/src/hotspot/share/gc/serial/serialFullGC.cpp#L371-L373
>> 
>> What I'm not sure about:
>> - should I make the `save_fake_rfp_lr` an argument also in product build, just unused, to avoid the slightly ugly `NOT_PRODUCT(COMMA save_fake_rfp_lr)`?
>> - how should I name `save_fake_rfp_lr`? I think it is clear, but not great.
>> - I've introduced a new value to zap registers, that looks special, but that is not what `badHeapWord` to avoid confusion. Any opinion on the variable name and the magic value? I intend to reuse it to zap other registers (the caller-saved ones).
>> - is there an easier way to write a 64-bit immediate in a register in Aarch64?! I found movptr, but it asserts the immediate is an address and so, that it is actually only 48-bits. I've wrote my own, because I couldn't find another example pointing me to an existing implementation of that, but I've probably missed something.
>> 
>> I've also elected not to make a flag but just to make mandatory to write these magic value in debug mode. I don't think it's worth a flag, as I see little benefit in not doing it: the performance cost is surely very marginal. Also, adding a flag, even develop, also implies some commitment (might end up in some tests or scripts), make sure it works to turn it on and off... Not ...
>
> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fewer macro

Thanks @mhaessig and @TobiHartmann for reviews and good ideas.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1764#issuecomment-3595046542

From mchevalier at openjdk.org  Mon Dec  1 07:42:27 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 1 Dec 2025 07:42:27 GMT
Subject: [lworld] Integrated: 8371993: [lworld] Aarch64: save bad values
 instead of rfp and lr above the extension space
In-Reply-To: <r-daAZFoql9YnLBiyz78wmD4XrE5IGeLtZ_dC6F_DYk=.e0d8a031-1b45-4215-994c-777c1cd0fe54@github.com>
References: <r-daAZFoql9YnLBiyz78wmD4XrE5IGeLtZ_dC6F_DYk=.e0d8a031-1b45-4215-994c-777c1cd0fe54@github.com>
Message-ID: <oHpvWrThzBuWNHQBAL3zMu40x60o9mtqH_rYQ9dT4CA=.087a8426-e545-48f4-8f04-8366d5c2e158@github.com>

On Thu, 27 Nov 2025 21:04:28 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Related lore: https://github.com/openjdk/valhalla/pull/1540 & https://github.com/openjdk/valhalla/pull/1751. Please, go check those up if you miss the context.
> 
> As we established in [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751, LR2 and FP2 are not reliable (resp. not patched for deopt and not known by deopt code, not updated by GC). Since reading them is probably fine, but maybe not, it is risky to leave reasonable value there. In debug, I suggest we store a magic but recognizable value to make more obvious one read the wrong copy, actually, we don't really need LR2 and FP2 to contain lr and rfp, we mostly need it to make space between the stack extension and the proper frame to pretend it is like a scalarized call.
> 
> What I propose here is similar to zapping unused space freed by the GC: when `ZapUnusedHeapArea`, that is `trueInDebug`, we zap the heap not to read something good-looking when we have a wrong pointer.
> 
> https://github.com/openjdk/valhalla/blob/1144cb4c5183c69a74aa0211f7ead5ac388ee41d/src/hotspot/share/runtime/globals.hpp#L482-L483
> 
> https://github.com/openjdk/valhalla/blob/1144cb4c5183c69a74aa0211f7ead5ac388ee41d/src/hotspot/share/gc/serial/serialFullGC.cpp#L371-L373
> 
> What I'm not sure about:
> - should I make the `save_fake_rfp_lr` an argument also in product build, just unused, to avoid the slightly ugly `NOT_PRODUCT(COMMA save_fake_rfp_lr)`?
> - how should I name `save_fake_rfp_lr`? I think it is clear, but not great.
> - I've introduced a new value to zap registers, that looks special, but that is not what `badHeapWord` to avoid confusion. Any opinion on the variable name and the magic value? I intend to reuse it to zap other registers (the caller-saved ones).
> - is there an easier way to write a 64-bit immediate in a register in Aarch64?! I found movptr, but it asserts the immediate is an address and so, that it is actually only 48-bits. I've wrote my own, because I couldn't find another example pointing me to an existing implementation of that, but I've probably missed something.
> 
> I've also elected not to make a flag but just to make mandatory to write these magic value in debug mode. I don't think it's worth a flag, as I see little benefit in not doing it: the performance cost is surely very marginal. Also, adding a flag, even develop, also implies some commitment (might end up in some tests or scripts), make sure it works to turn it on and off... Not terrible complications, but still ...

This pull request has now been integrated.

Changeset: acb511a9
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/acb511a9f5c7b750b41e1ce77aab3d1a59613097
Stats:     38 lines in 4 files changed: 18 ins; 16 del; 4 mod

8371993: [lworld] Aarch64: save bad values instead of rfp and lr above the extension space

Reviewed-by: mhaessig, thartmann

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

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

From forax at univ-mlv.fr  Mon Dec  1 18:54:05 2025
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 1 Dec 2025 19:54:05 +0100 (CET)
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
Message-ID: <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Bruno Eberhard" <bruno.eberhard at pop.ch>
> To: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Wednesday, November 26, 2025 10:43:30 AM
> Subject: Valhalla breaks minimal-j framework

> Hi,
> 
> I really like the concepts and the gains you make with Valhalla. But it
> breaks some essential points of my framework called ?minimal-j? (on
> https://github.com/BrunoEberhard/minimal-j ). I would kindly ask if you
> can provide a replacement for what is not possible in Valhalla anymore.
> 
> Let me show the problem and then propose a solution. In the minimal
> design all fields of a class representing a business entity (only those)
> are public. No getter or setter. Then a static constant $ is defined
> like this:
> 
>  public class Person {
>	public static final Person $ = Keys.of(Person.class);
> 
>	@NotEmpty
>	public Integer number;
> 
>	@Size(100)
>	@Searched
>	@NotEmpty
>	public String name;
>	
>	public final Address address = new Address();
> }
> 
> With the $ constant there is a reference to the fields of the class.
> With theses references a UI can be specified:
> 
>	var form = new Form<Person>();
>	form.line($.number);
>	form.line($.name);
>	form.line($.address.city);
> 
> Or a query to the persistence layer can be formulated:
> 
>	Backend.find(Person.class, By.field($.name, "Bruno"));
>	Backend.find(Person.class, By.field($.address.zip, 8000));
> 
> In the background the framework fills the fields of the $ constant with
> values that are later used to identify which field should be used. For
> this identity is vital. Things like "new String(..)" and "new
> Integer(..)" is used to make $.number unique.
> 
> If Integers loose their identity this is now longer feasable.
> 
> A possible replacement for this trick would be references to fields.
> Best in this way:
> 
>	Backend.find(Person.class, By.field(Person::name, "Bruno"));
> 
> Person::name should result in a java.lang.reflect.Field
> 
>	Backend.find(Person.class, By.field(Person::address::zip, 8000));
> 
> Here Person::address::zip should result in a java.lang.reflect.Field[]
> or in a new class containing chained Fields.
> 
> Of course I could instead write getter and setter and the use
> Person::getName . But Person::getAddress::getZip doesn't work. And I
> would really like not to have getter and setter (for which I have to
> check all names and parameters are correct). Lombok or Kotlin hide
> getter and setter. But I don't really like hiding something. Especially
> if it is not really needed.
> 
> So if it is possible to add this construct to the java language it would
> make me really happy. Otherwise I would never be able to use a Java
> version which contains Valhalle for this kind of framework.

Integers, and others are marked as value-based classes
(https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/doc-files/ValueBased.html)
since quite some time, so your framework is currently violating this non-enforced spec.

I don't blame you, not at all, i've done the same in ASM at some point in time, but we have to fix the errors of the past ; Integer should be a lightweight boxing with no identity guarantee ; because it improve 99.9% of the existing codes.

I've seen a mocking framework having the same issue a lot time ago before and after Integers where cached.

They moved to a representation using interfaces + dynamic proxies instead of classes.

public interface Person {
  public static final Person $ = Keys.of(Person.class);
    
  @NotEmpty
  public int number();

  @Size(100)
  @Searched
  @NotEmpty
  public String name();

  public final Address address();
}

with the information being stored out of the line in ThreadLocal (I believe you can now use ScopeValue for that)
instead of using a special return value.

On the positive side, you do not have to use Integer anymore, you can use int (see numbers()),
on the negative side, it's obviously not backward compatible with your existing framework. 

> 
> regards

regards,
R?mi

From ethan at mccue.dev  Mon Dec  1 19:04:20 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 1 Dec 2025 14:04:20 -0500
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>

Can you elaborate more on how form.line($.address.city); uses the identity
of city?

How does Backend.find(Person.class, By.field($.address.zip, 8000)); figure
out that $.address.zip refers to the corresponding field in Address?

On Mon, Dec 1, 2025 at 1:56?PM Remi Forax <forax at univ-mlv.fr> wrote:

> ----- Original Message -----
> > From: "Bruno Eberhard" <bruno.eberhard at pop.ch>
> > To: "valhalla-dev" <valhalla-dev at openjdk.org>
> > Sent: Wednesday, November 26, 2025 10:43:30 AM
> > Subject: Valhalla breaks minimal-j framework
>
> > Hi,
> >
> > I really like the concepts and the gains you make with Valhalla. But it
> > breaks some essential points of my framework called ?minimal-j? (on
> > https://github.com/BrunoEberhard/minimal-j ). I would kindly ask if you
> > can provide a replacement for what is not possible in Valhalla anymore.
> >
> > Let me show the problem and then propose a solution. In the minimal
> > design all fields of a class representing a business entity (only those)
> > are public. No getter or setter. Then a static constant $ is defined
> > like this:
> >
> >  public class Person {
> >       public static final Person $ = Keys.of(Person.class);
> >
> >       @NotEmpty
> >       public Integer number;
> >
> >       @Size(100)
> >       @Searched
> >       @NotEmpty
> >       public String name;
> >
> >       public final Address address = new Address();
> > }
> >
> > With the $ constant there is a reference to the fields of the class.
> > With theses references a UI can be specified:
> >
> >       var form = new Form<Person>();
> >       form.line($.number);
> >       form.line($.name);
> >       form.line($.address.city);
> >
> > Or a query to the persistence layer can be formulated:
> >
> >       Backend.find(Person.class, By.field($.name, "Bruno"));
> >       Backend.find(Person.class, By.field($.address.zip, 8000));
> >
> > In the background the framework fills the fields of the $ constant with
> > values that are later used to identify which field should be used. For
> > this identity is vital. Things like "new String(..)" and "new
> > Integer(..)" is used to make $.number unique.
> >
> > If Integers loose their identity this is now longer feasable.
> >
> > A possible replacement for this trick would be references to fields.
> > Best in this way:
> >
> >       Backend.find(Person.class, By.field(Person::name, "Bruno"));
> >
> > Person::name should result in a java.lang.reflect.Field
> >
> >       Backend.find(Person.class, By.field(Person::address::zip, 8000));
> >
> > Here Person::address::zip should result in a java.lang.reflect.Field[]
> > or in a new class containing chained Fields.
> >
> > Of course I could instead write getter and setter and the use
> > Person::getName . But Person::getAddress::getZip doesn't work. And I
> > would really like not to have getter and setter (for which I have to
> > check all names and parameters are correct). Lombok or Kotlin hide
> > getter and setter. But I don't really like hiding something. Especially
> > if it is not really needed.
> >
> > So if it is possible to add this construct to the java language it would
> > make me really happy. Otherwise I would never be able to use a Java
> > version which contains Valhalle for this kind of framework.
>
> Integers, and others are marked as value-based classes
> (
> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/doc-files/ValueBased.html
> )
> since quite some time, so your framework is currently violating this
> non-enforced spec.
>
> I don't blame you, not at all, i've done the same in ASM at some point in
> time, but we have to fix the errors of the past ; Integer should be a
> lightweight boxing with no identity guarantee ; because it improve 99.9% of
> the existing codes.
>
> I've seen a mocking framework having the same issue a lot time ago before
> and after Integers where cached.
>
> They moved to a representation using interfaces + dynamic proxies instead
> of classes.
>
> public interface Person {
>   public static final Person $ = Keys.of(Person.class);
>
>   @NotEmpty
>   public int number();
>
>   @Size(100)
>   @Searched
>   @NotEmpty
>   public String name();
>
>   public final Address address();
> }
>
> with the information being stored out of the line in ThreadLocal (I
> believe you can now use ScopeValue for that)
> instead of using a special return value.
>
> On the positive side, you do not have to use Integer anymore, you can use
> int (see numbers()),
> on the negative side, it's obviously not backward compatible with your
> existing framework.
>
> >
> > regards
>
> regards,
> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251201/07aeec71/attachment-0001.htm>

From ethan at mccue.dev  Mon Dec  1 19:37:57 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 1 Dec 2025 14:37:57 -0500
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
Message-ID: <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>

One more question: How does the code today work around things like the
small integer cache?

On Mon, Dec 1, 2025 at 2:04?PM Ethan McCue <ethan at mccue.dev> wrote:

> Can you elaborate more on how form.line($.address.city); uses the
> identity of city?
>
> How does Backend.find(Person.class, By.field($.address.zip, 8000)); figure
> out that $.address.zip refers to the corresponding field in Address?
>
> On Mon, Dec 1, 2025 at 1:56?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> ----- Original Message -----
>> > From: "Bruno Eberhard" <bruno.eberhard at pop.ch>
>> > To: "valhalla-dev" <valhalla-dev at openjdk.org>
>> > Sent: Wednesday, November 26, 2025 10:43:30 AM
>> > Subject: Valhalla breaks minimal-j framework
>>
>> > Hi,
>> >
>> > I really like the concepts and the gains you make with Valhalla. But it
>> > breaks some essential points of my framework called ?minimal-j? (on
>> > https://github.com/BrunoEberhard/minimal-j ). I would kindly ask if you
>> > can provide a replacement for what is not possible in Valhalla anymore.
>> >
>> > Let me show the problem and then propose a solution. In the minimal
>> > design all fields of a class representing a business entity (only those)
>> > are public. No getter or setter. Then a static constant $ is defined
>> > like this:
>> >
>> >  public class Person {
>> >       public static final Person $ = Keys.of(Person.class);
>> >
>> >       @NotEmpty
>> >       public Integer number;
>> >
>> >       @Size(100)
>> >       @Searched
>> >       @NotEmpty
>> >       public String name;
>> >
>> >       public final Address address = new Address();
>> > }
>> >
>> > With the $ constant there is a reference to the fields of the class.
>> > With theses references a UI can be specified:
>> >
>> >       var form = new Form<Person>();
>> >       form.line($.number);
>> >       form.line($.name);
>> >       form.line($.address.city);
>> >
>> > Or a query to the persistence layer can be formulated:
>> >
>> >       Backend.find(Person.class, By.field($.name, "Bruno"));
>> >       Backend.find(Person.class, By.field($.address.zip, 8000));
>> >
>> > In the background the framework fills the fields of the $ constant with
>> > values that are later used to identify which field should be used. For
>> > this identity is vital. Things like "new String(..)" and "new
>> > Integer(..)" is used to make $.number unique.
>> >
>> > If Integers loose their identity this is now longer feasable.
>> >
>> > A possible replacement for this trick would be references to fields.
>> > Best in this way:
>> >
>> >       Backend.find(Person.class, By.field(Person::name, "Bruno"));
>> >
>> > Person::name should result in a java.lang.reflect.Field
>> >
>> >       Backend.find(Person.class, By.field(Person::address::zip, 8000));
>> >
>> > Here Person::address::zip should result in a java.lang.reflect.Field[]
>> > or in a new class containing chained Fields.
>> >
>> > Of course I could instead write getter and setter and the use
>> > Person::getName . But Person::getAddress::getZip doesn't work. And I
>> > would really like not to have getter and setter (for which I have to
>> > check all names and parameters are correct). Lombok or Kotlin hide
>> > getter and setter. But I don't really like hiding something. Especially
>> > if it is not really needed.
>> >
>> > So if it is possible to add this construct to the java language it would
>> > make me really happy. Otherwise I would never be able to use a Java
>> > version which contains Valhalle for this kind of framework.
>>
>> Integers, and others are marked as value-based classes
>> (
>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/doc-files/ValueBased.html
>> )
>> since quite some time, so your framework is currently violating this
>> non-enforced spec.
>>
>> I don't blame you, not at all, i've done the same in ASM at some point in
>> time, but we have to fix the errors of the past ; Integer should be a
>> lightweight boxing with no identity guarantee ; because it improve 99.9% of
>> the existing codes.
>>
>> I've seen a mocking framework having the same issue a lot time ago before
>> and after Integers where cached.
>>
>> They moved to a representation using interfaces + dynamic proxies instead
>> of classes.
>>
>> public interface Person {
>>   public static final Person $ = Keys.of(Person.class);
>>
>>   @NotEmpty
>>   public int number();
>>
>>   @Size(100)
>>   @Searched
>>   @NotEmpty
>>   public String name();
>>
>>   public final Address address();
>> }
>>
>> with the information being stored out of the line in ThreadLocal (I
>> believe you can now use ScopeValue for that)
>> instead of using a special return value.
>>
>> On the positive side, you do not have to use Integer anymore, you can use
>> int (see numbers()),
>> on the negative side, it's obviously not backward compatible with your
>> existing framework.
>>
>> >
>> > regards
>>
>> regards,
>> R?mi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251201/ae6b6745/attachment.htm>

From bruno.eberhard at pop.ch  Mon Dec  1 19:51:16 2025
From: bruno.eberhard at pop.ch (Bruno Eberhard)
Date: Mon, 1 Dec 2025 20:51:16 +0100
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
Message-ID: <94fe8814-b3d8-4e3a-a943-ebda0c8bc5cf@pop.ch>

The Keys.of(Class) method goes recursively through all the fields and 
sets unique values to the fields. The values are stored in a Map in the 
Keys class and identify the fields / properties:

private static final Map<Object, Property> properties = new 
IdentityHashMap<>();

Note that if the Address class has its own $ constant then the values 
there would be different. So Address.$.zip has a different identity than 
Person.$.address.zip.

These are all just tricks to emulate the missing construct 
"Person::name" or "Person::address::zip" . I would gladly do it in a 
more legal way. Also it gets really messy with enums. And yes I cannot 
use int with this. Also not boolean which is the bigger issue. Still 
it's really nice to use the $ constant when implementing applications.


Am 01.12.2025 um 20:04 schrieb Ethan McCue:
> Can you elaborate more on how form.line($.address.city);?uses the 
> identity of city?
> 
> How does Backend.find(Person.class, By.field($.address.zip, 
> 8000));?figure out that $.address.zip?refers to the corresponding field 
> in Address?
> 
>      >
>      >? public class Person {
>      >? ? ? ?public static final Person $ = Keys.of(Person.class);
>      >
>      >? ? ? ?@NotEmpty
>      >? ? ? ?public Integer number;
>      >
>      >? ? ? ?@Size(100)
>      >? ? ? ?@Searched
>      >? ? ? ?@NotEmpty
>      >? ? ? ?public String name;
>      >
>      >? ? ? ?public final Address address = new Address();
>      > }
>      >
>      > With the $ constant there is a reference to the fields of the class.

From bruno.eberhard at pop.ch  Mon Dec  1 19:56:53 2025
From: bruno.eberhard at pop.ch (Bruno Eberhard)
Date: Mon, 1 Dec 2025 20:56:53 +0100
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
Message-ID: <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>

Am 01.12.2025 um 20:37 schrieb Ethan McCue:
> One more question: How does the code today work around things like the 
> small integer cache?
It allocates for each field a "new Integer(0)". As long as Integer have 
an identity two of these values are distinguishable and can serve as 
different keys in a IdentityHashMap .

From rotanolexandr842 at gmail.com  Mon Dec  1 20:05:20 2025
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Mon, 1 Dec 2025 22:05:20 +0200
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
Message-ID: <CAL5bRt_PADwqQ+5BvDK6gZ8s1jiQTmTHkO+zOtzwJZETsS+Xnw@mail.gmail.com>

Usually problems that you describe are solved with custom data structures
to reflect path + some annotation processing for generating metamodels with
methods that yield this paths. This also involves a pretty high level of
generics juggling, with various numbers of generics depending on strictness
of constraints you want to enforce (my query framework over hibernate, for
example, has Path<ROOT, PARENT, TARGET> as base, with number of params
reaching 5 for some of the most specialized paths. This is complex and not
pretty, but is a most common solution for your problem

On Mon, Dec 1, 2025, 21:59 Bruno Eberhard <bruno.eberhard at pop.ch> wrote:

> Am 01.12.2025 um 20:37 schrieb Ethan McCue:
> > One more question: How does the code today work around things like the
> > small integer cache?
> It allocates for each field a "new Integer(0)". As long as Integer have
> an identity two of these values are distinguishable and can serve as
> different keys in a IdentityHashMap .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251201/fb208933/attachment.htm>

From ethan at mccue.dev  Mon Dec  1 20:10:20 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 1 Dec 2025 15:10:20 -0500
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
Message-ID: <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>

I think I'm understanding. So $ has the same type as the source class, but
each field on it is initialized to something with a unique identity, their
values aren't important, their identity is.

The ways out of this are code generation - make your own $ where everything
is a FieldRef<T> - but that has its own downsides.

  @Minimal
  public class Person {
        public static final Person$ $ = Keys.of(Person$.class);

        @NotEmpty
        public Integer number;

        @Size(100)
        @Searched
        @NotEmpty
        public String name;

        public final Address address = new Address();
  }

It is very possible to make this generate a matching Person$ structure, but
that comes with obvious downsides.

Another option is to generically disallow any value types as fields. This
means custom wrappers for things like Integer, LocalDate, etc. including
custom "zero value" logic to get your unique instance.

  public class Person {
        public static final Person $ = Keys.of(Person.class);

        @NotEmpty
        public minimalj.I32 number;

        @Size(100)
        @Searched
        @NotEmpty
        public String name;

        public final Address address = new Address();
}

Another other option is to start to make use of the instance value, not
just instance identity. Right now all your Integers are 0. Why not have an
AtomicInteger that counts up and use that to give unique Integer instances?


     private static final AtomicInteger i = new AtomicInteger();
     private static final AtomicLong l = new AtomicLong();

    @SuppressWarnings({ "unchecked", "rawtypes" })
    private static Object createKey(Class<?> clazz, String fieldName,
Class<?> declaringClass) {
    if (clazz == String.class) {
        return new String(fieldName);
    } else if (clazz == Integer.class) {
        return new Integer(i.getAndIncrement());
    } else if (clazz == Long.class) {
        return new Long(l.getAndIncrement());

On Mon, Dec 1, 2025 at 2:56?PM Bruno Eberhard <bruno.eberhard at pop.ch> wrote:

> Am 01.12.2025 um 20:37 schrieb Ethan McCue:
> > One more question: How does the code today work around things like the
> > small integer cache?
> It allocates for each field a "new Integer(0)". As long as Integer have
> an identity two of these values are distinguishable and can serve as
> different keys in a IdentityHashMap .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251201/5ea9d23f/attachment.htm>

From bruno.eberhard at pop.ch  Mon Dec  1 20:36:00 2025
From: bruno.eberhard at pop.ch (Bruno Eberhard)
Date: Mon, 1 Dec 2025 21:36:00 +0100
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
Message-ID: <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>

Am 01.12.2025 um 21:10 schrieb Ethan McCue:
> I think I'm understanding. So $?has the same type as the source class, 
> but each field on it is initialized to something with a unique identity, 
> their values aren't important, their identity is.

Exactly.

You pretty much got all my ideas around the problem right.

1) code generation

I simply don't like code generation. It makes setup of projects 
difficult. It easily breaks because of some wrong paths or forgotten 
re-generate. Has to integrate in IDEs.

2) special field classes

Using the normal classes is so much more natural. No need to convert.

3) Use values instead of always "new Integer(0)".

Yes this works. For almost all supported classes like: String, Integer, 
Long, LocalDate, LocalDateTime, LocalTime, BigDecimal.

For Boolean and Enum I would have to use the second solution.


I started with the framework with java 8. Never thought at that time 
this would become a problem.


From ethan at mccue.dev  Mon Dec  1 21:00:43 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 1 Dec 2025 16:00:43 -0500
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
 <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
Message-ID: <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>

On that note, i'd say you have somewhat of a bigger problem w.r.t. enums

	@SuppressWarnings({ "rawtypes", "unchecked", "restriction" })
	public static <T extends Enum<T>> T createEnum(Class<T> clazz, String name) {
		try {
			Constructor constructorToCall =
Enum.class.getDeclaredConstructor(String.class, Integer.TYPE);
			sun.reflect.ReflectionFactory f =
sun.reflect.ReflectionFactory.getReflectionFactory();
			Constructor c = f.newConstructorForSerialization(clazz, constructorToCall);
			T e = (T) c.newInstance(name, Integer.MAX_VALUE);
			return e;
		} catch (Exception x) {
			throw new RuntimeException(x);

As with all things in jdk.unsupported, I can't help but wonder if
there are any VM level invariants you run afoul of by making extra
enum instances.

My first stab at #2 is to add something like this

    record Field<T>(T value) {}

And start making value types require wrapping. Or instead of providing
your own type special case the idiom of "record with single component
for adding identity to a field that otherwise wouldn't have it." Or go
a little crazy and make a Field that distinguishes between when its
being used as an actual value holder or as a unique sentinel.
public sealed abstract class Field<T> {
    public abstract T get();

    public abstract void set(T value);

    public static <T> Field<T> withInitialValue(T value) {
        return new Field.Actual<>(value);
    }

    // Maybe encode the path?
    public static <T> Field<T> reference(String name) {
        return new Ref<>(name);
    }

    private static final class Actual<T> extends Field<T> {
        private T value;

        Actual(T value) {
            this.value = value;
        }

        @Override
        public T get() {
            return value;
        }

        @Override
        public void set(T value) {
            this.value = value;
        }

        @Override
        public String toString() {
            return "Field[" + value + "]";
        }
    }

    private static final class Ref<T> extends Field<T> {
        private String name;

        Ref(String name) {
            this.name = name;
        }

        @Override
        public T get() {
            throw new IllegalStateException("Cannot get a ref");
        }

        @Override
        public void set(T value) {
            throw new IllegalStateException("Cannot set a ref");
        }

        @Override
        public String toString() {
            return "Field[ref=#" + name + "]";
        }
    }
}

I think it's also worth asking - do you have any usage statistics on
your library? (Maven central used to offer download stats, etc.) If
you are going to be broken anyways it is probably useful to know the
blast radius.


On Mon, Dec 1, 2025 at 3:36?PM Bruno Eberhard <bruno.eberhard at pop.ch> wrote:

> Am 01.12.2025 um 21:10 schrieb Ethan McCue:
> > I think I'm understanding. So $ has the same type as the source class,
> > but each field on it is initialized to something with a unique identity,
> > their values aren't important, their identity is.
>
> Exactly.
>
> You pretty much got all my ideas around the problem right.
>
> 1) code generation
>
> I simply don't like code generation. It makes setup of projects
> difficult. It easily breaks because of some wrong paths or forgotten
> re-generate. Has to integrate in IDEs.
>
> 2) special field classes
>
> Using the normal classes is so much more natural. No need to convert.
>
> 3) Use values instead of always "new Integer(0)".
>
> Yes this works. For almost all supported classes like: String, Integer,
> Long, LocalDate, LocalDateTime, LocalTime, BigDecimal.
>
> For Boolean and Enum I would have to use the second solution.
>
>
> I started with the framework with java 8. Never thought at that time
> this would become a problem.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251201/0904ceb3/attachment.htm>

From roger.riggs at oracle.com  Mon Dec  1 21:08:05 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 1 Dec 2025 16:08:05 -0500
Subject: Result: New Valhalla Committer: David Beaumont
Message-ID: <dac42d02-6997-4d9b-8a08-2cec22bcbab2@oracle.com>

Voting for David Beaumont [1] is now closed.

Yes: 7
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Roger Riggs

[1] 
https://mail.openjdk.org/pipermail/valhalla-dev/2025-November/016188.html


From ethan at mccue.dev  Tue Dec  2 04:50:38 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Mon, 1 Dec 2025 23:50:38 -0500
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <d308ae42-62b4-48f1-8131-f793c9a3fd35@pop.ch>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
 <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
 <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>
 <d308ae42-62b4-48f1-8131-f793c9a3fd35@pop.ch>
Message-ID: <CA+NR86iupnyK6ec5rDzSB4m=kJrvFU3fkE218H8YydmUm40Kfw@mail.gmail.com>

There is a parallel thread going on which touches on similar things - there
people are wanting "record component references."

I adapted the code from
https://github.com/rilindbicaj/fluentmapper/blob/main/fluentmapper-provider/src/main/java/dev/bici/fluentmapper/provider/expression/parser/ExpressionParser.java
to use the new classfile api + work for a quick demo of the approach.

Basically, you can get at the code in the body of a lambda via some
serialization hackery. The degree to which this is actually supported is to
me unknown.

import java.io.IOException;
import java.io.Serializable;
import java.io.UncheckedIOException;
import java.lang.classfile.ClassFile;
import java.lang.classfile.ClassModel;
import java.lang.classfile.instruction.FieldInstruction;
import java.lang.invoke.SerializedLambda;
import java.lang.reflect.Field;
import java.util.ArrayList;
import java.util.List;

public final class FieldReference {
    private final Class<?> root;
    private final List<Field> fields;

    private FieldReference(Class<?> root, List<Field> fields) {
        this.root = root;
        this.fields = fields;
    }


    public Class<?> root() {
        return root;
    }

    public List<Field> fields() {
        return fields;
    }

    private static SerializedLambda toSerializedLambda(Expression<?, ?>
expression) {
        try {
            var writeReplaceMethod =
expression.getClass().getDeclaredMethod("writeReplace");
            writeReplaceMethod.setAccessible(true);

            return (SerializedLambda) writeReplaceMethod.invoke(expression);
        } catch (ReflectiveOperationException e) {
            throw new IllegalArgumentException("Could not extract
SerializedLambda from the provided expression;", e);
        }
    }

    public static <T> FieldReference of(Class<T> klass, Expression<T, ?>
expression) {
        // TODO: This work can likely be cached.
        var serializedLambda = toSerializedLambda(expression);
        var containingClass = serializedLambda.getImplClass();
        var lambdaSignature = serializedLambda.getImplMethodName();

        // TODO: Unsure if this is the right class loader to use
        var classLoader = klass.getClassLoader();

        byte[] classBytes;
        try (var classResource = classLoader.getResourceAsStream(
                containingClass.replace('.', '/') + ".class"
        )) {
            if (classResource == null) {
                throw new IllegalArgumentException("Could not find
class-file resource in class loader");
            }

            classBytes = classResource.readAllBytes();
        } catch (IOException e) {
            throw new UncheckedIOException(e);
        }

        ClassModel classModel = ClassFile.of().parse(classBytes);

        var methodModel = classModel.methods().stream()
                .filter(method ->
lambdaSignature.equals(method.methodName().toString()))
                .findFirst()
                .orElseThrow(() -> new IllegalArgumentException("Could not
find the implementing method for the expression lambda"));
        var code = methodModel.code().orElseThrow();

        // TODO: This could use a lot of prechecks
        var fields = new ArrayList<Field>();

        Class<?> lastType = klass;
        for (var element : code.elementList()) {
            if (element instanceof FieldInstruction fieldInstruction) {
                try {
                    fields.add(

lastType.getDeclaredField(fieldInstruction.field().name().toString())
                    );


                    // TODO: This is almost certainly not sound
                    if
(fieldInstruction.typeSymbol().packageName().isEmpty()) {
                        lastType = classLoader.loadClass(
                                fieldInstruction.typeSymbol().displayName()
                        );
                    }
                    else {
                        lastType = classLoader.loadClass(
                                fieldInstruction.typeSymbol().packageName()
+ "."
                                        +
fieldInstruction.typeSymbol().displayName()
                        );
                    }

                } catch (NoSuchFieldException e) {
                    throw new IllegalArgumentException("Inaccessable
field", e);
                } catch (ClassNotFoundException e) {
                    throw new RuntimeException(e);
                }
            }
        }


        return new FieldReference(klass, List.copyOf(fields));
    }


    @FunctionalInterface
    public interface Expression<A, B> extends Serializable {
        B get(A a);
    }


    @Override
    public String toString() {
        return "FieldReference[" +
                "root=" + root.getName() +
                ", fields=" + fields.stream().map(Field::getName).toList() +
                ']';
    }
}

And you can use all of that with a lambda that only accesses fields to
emulate "field references."

class A {
    String aa;
    B b;
}

class B {
    C c;
}

 class C {
    String v;
    D d;
}

 class D {
    E e;
}

 class E {
    F f;
}

 class F {
    G g;
}

 class G {
    String v;
}

public class Test {
    public static void main(String[] args) {
        var refA = FieldReference.of(A.class, a -> a.aa);
        IO.println(refA);
        var refB = FieldReference.of(A.class, a -> a.b.c.d);
        IO.println(refB);
    }
}

FieldReference[root=A, fields=[aa]]
FieldReference[root=A, fields=[b, c, d]]

So that is one approach to look into.


On Mon, Dec 1, 2025, 8:38?PM Bruno Eberhard <bruno.eberhard at pop.ch> wrote:

> Am 01.12.2025 um 22:00 schrieb Ethan McCue:
> > On that note, i'd say you have somewhat of a bigger problem w.r.t. enums
> > [..]
> > As with all things in jdk.unsupported, I can't help but wonder if there
> > are any VM level invariants you run afoul of by making extra enum
> > instances.
>
> I don't know about the VM internals. I did never run into problems with
> these extra enums.
>
> > My first stab at #2 is to add something like this record [..]
> Thank you for your input. I have to try this.
>
> > I think it's also worth asking - do you have any usage statistics on
> > your library? (Maven central used to offer download stats, etc.) If you
> > are going to be broken anyways it is probably useful to know the blast
> > radius.
>
> Very good point. As far as I know minimal-j is only used by me for a
> smaller and one bigger App. In the bigger App ( An ERP called
> lisheane.ch , currently only available in german ) I invested quite some
> time. I would have to rewrite parts of it.
>
> So the world will not be standing still if minimal-j doesn't work
> anymore or has to be changed.
>
> I would still like the idea of field references ( Person::name ,
> Person::address::city ) in the java language as equivalent for the $
> constant. It is really nice to use. But I don't have the knowledge how
> to add it to the language or how to propose the feature.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251201/617b9788/attachment.htm>

From mchevalier at openjdk.org  Tue Dec  2 08:26:47 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 2 Dec 2025 08:26:47 GMT
Subject: [lworld] RFR: 8367553: [lworld]
 compiler/valhalla/inlinetypes/TestNullableArrays.java fails with segfault in
 C1 compiled code on aarch64
Message-ID: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>

Seems that it was just [JDK-8367151: [lworld] CorrectlyRestoreRfp.java triggers "bad oop found" during deoptimization](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751. When I checked first if it still reproduces, https://github.com/openjdk/valhalla/pull/1751 wasn't integrated yet. And after investigation, it turned out to be the same issue. And after integration of the said PR, the problem didn't show again under much more extensive testing than what was enough to reproduce before.

In more details, the case I investigated was mostly in `test76_verifier` (occasionally in `test78_verifier`)
https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L2100-L2120

that is C1-compiled. During a call to C2-compiled `verify`:
https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L1145-L1153

an oop is passed in rfp. Sometimes, the GC moves the object during the execution of `verify`, it updated the wrong copy of RFP on the stack. Then `verify` hits an uncommon trap, and in the process picks the wrong `rfp` by exactly the same mechanism as in [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151). Later in `test76_verify`, the content of rfp, that now contains a wrong oop, is used, garbage is read, segfault.

The fact that is goes through an uncommon trap makes it a slightly different flavor than what I've seen before. Also, not I should have taken my own advice, and use SerialGC, it would have saved me some complications!

I suggest we just un-problem list now.

Thanks,
Marc

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

Commit messages:
 - un-ProblemList

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

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

From mchevalier at openjdk.org  Tue Dec  2 08:40:50 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 2 Dec 2025 08:40:50 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
Message-ID: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>

In
https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116

we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.

To keep the test robust, I prefered to expect the exact amount, and not something like

@IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
@IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })

Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).

To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.

Thanks,
Marc

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

Commit messages:
 - Fix it

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

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

From phubner at openjdk.org  Tue Dec  2 08:56:16 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 2 Dec 2025 08:56:16 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
Message-ID: <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>

On Tue, 2 Dec 2025 08:34:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116
> 
> we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.
> 
> To keep the test robust, I prefered to expect the exact amount, and not something like
> 
> @IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
> @IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })
> 
> Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).
> 
> To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.
> 
> Thanks,
> Marc

Thanks for doing this! I left some comments on the feature flag since I'm working on that right now.

test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java line 108:

> 106:     // could not be eliminated.
> 107:     @Test
> 108:     @IR(applyIf = {"enable-valhalla", "false"}, phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "2" })

With `EnableValhalla` being removed in favour of `--enable-preview`, I think it would make sense if we transition to a preview on/off state rather than the fine-grained one we have right now.

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

PR Review: https://git.openjdk.org/valhalla/pull/1767#pullrequestreview-3528932060
PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580224094

From phubner at openjdk.org  Tue Dec  2 08:56:17 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 2 Dec 2025 08:56:17 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
 <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
Message-ID: <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>

On Tue, 2 Dec 2025 08:50:02 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> In
>> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116
>> 
>> we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.
>> 
>> To keep the test robust, I prefered to expect the exact amount, and not something like
>> 
>> @IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
>> @IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })
>> 
>> Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).
>> 
>> To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.
>> 
>> Thanks,
>> Marc
>
> test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java line 108:
> 
>> 106:     // could not be eliminated.
>> 107:     @Test
>> 108:     @IR(applyIf = {"enable-valhalla", "false"}, phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "2" })
> 
> With `EnableValhalla` being removed in favour of `--enable-preview`, I think it would make sense if we transition to a preview on/off state rather than the fine-grained one we have right now.

FWIW there's also `jdk.internal.misc.PreviewFeatures` that can be used to check if preview features are enabled at runtime.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580232418

From thartmann at openjdk.org  Tue Dec  2 09:03:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 2 Dec 2025 09:03:19 GMT
Subject: [lworld] RFR: 8367553: [lworld]
 compiler/valhalla/inlinetypes/TestNullableArrays.java fails with segfault in
 C1 compiled code on aarch64
In-Reply-To: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>
References: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>
Message-ID: <Sge-kYnbT-Pw1s4zBWZiH8voksE3PDxqRc-RotWqug0=.9ef3a256-f14d-498a-8ffb-a2f42e89b1de@github.com>

On Tue, 2 Dec 2025 08:19:32 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Seems that it was just [JDK-8367151: [lworld] CorrectlyRestoreRfp.java triggers "bad oop found" during deoptimization](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751. When I checked first if it still reproduces, https://github.com/openjdk/valhalla/pull/1751 wasn't integrated yet. And after investigation, it turned out to be the same issue. And after integration of the said PR, the problem didn't show again under much more extensive testing than what was enough to reproduce before.
> 
> In more details, the case I investigated was mostly in `test76_verifier` (occasionally in `test78_verifier`)
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L2100-L2120
> 
> that is C1-compiled. During a call to C2-compiled `verify`:
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L1145-L1153
> 
> an oop is passed in rfp. Sometimes, the GC moves the object during the execution of `verify`, it updated the wrong copy of RFP on the stack. Then `verify` hits an uncommon trap, and in the process picks the wrong `rfp` by exactly the same mechanism as in [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151). Later in `test76_verify`, the content of rfp, that now contains a wrong oop, is used, garbage is read, segfault.
> 
> The fact that is goes through an uncommon trap makes it a slightly different flavor than what I've seen before. Also, not I should have taken my own advice, and use SerialGC, it would have saved me some complications!
> 
> I suggest we just un-problem list now.
> 
> Thanks,
> Marc

Thanks for the thorough investigation. Looks good to me!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1766#pullrequestreview-3528977692

From mchevalier at openjdk.org  Tue Dec  2 09:11:27 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 2 Dec 2025 09:11:27 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
 <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
 <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>
Message-ID: <NiO71N5OycKL85Ylw0n99Z-kPHUfQ2mwpcmFWLzodpg=.8a771833-e831-4410-8217-c67ffcfc77a4@github.com>

On Tue, 2 Dec 2025 08:52:47 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java line 108:
>> 
>>> 106:     // could not be eliminated.
>>> 107:     @Test
>>> 108:     @IR(applyIf = {"enable-valhalla", "false"}, phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "2" })
>> 
>> With `EnableValhalla` being removed in favour of `--enable-preview`, I think it would make sense if we transition to a preview on/off state rather than the fine-grained one we have right now.
>
> FWIW there's also `jdk.internal.misc.PreviewFeatures` that can be used to check if preview features are enabled at runtime.

PreviewFeatures.isEnabled() is internal and not accessible without adding some `@module` in each IR test. That seems like an excessive burden.

Doing it more fine-grained was on purpose. @TobiHartmann an opinion? I tihnk it can make a mess with other project repos, but I don't remember the exact scenario.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580286898

From phubner at openjdk.org  Tue Dec  2 09:18:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 2 Dec 2025 09:18:31 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <NiO71N5OycKL85Ylw0n99Z-kPHUfQ2mwpcmFWLzodpg=.8a771833-e831-4410-8217-c67ffcfc77a4@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
 <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
 <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>
 <NiO71N5OycKL85Ylw0n99Z-kPHUfQ2mwpcmFWLzodpg=.8a771833-e831-4410-8217-c67ffcfc77a4@github.com>
Message-ID: <F8-1E2mZVb6SzWb3NcgRyB7g17PzLeWTd6HV5TIaaLQ=.ff1cbed9-0294-4704-ac00-2225ccf3c24a@github.com>

On Tue, 2 Dec 2025 09:08:49 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> FWIW there's also `jdk.internal.misc.PreviewFeatures` that can be used to check if preview features are enabled at runtime.
>
> PreviewFeatures.isEnabled() is internal and not accessible without adding some `@module` in each IR test. That seems like an excessive burden.
> 
> Doing it more fine-grained was on purpose. @TobiHartmann an opinion? I tihnk it can make a mess with other project repos, but I don't remember the exact scenario.

Right, adding it to every test doesn't feel like the way to go! I'm not too fussed about it, it was just a suggestion, feel free to disregard ;)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580308726

From mchevalier at openjdk.org  Tue Dec  2 09:23:31 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Tue, 2 Dec 2025 09:23:31 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <F8-1E2mZVb6SzWb3NcgRyB7g17PzLeWTd6HV5TIaaLQ=.ff1cbed9-0294-4704-ac00-2225ccf3c24a@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
 <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
 <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>
 <NiO71N5OycKL85Ylw0n99Z-kPHUfQ2mwpcmFWLzodpg=.8a771833-e831-4410-8217-c67ffcfc77a4@github.com>
 <F8-1E2mZVb6SzWb3NcgRyB7g17PzLeWTd6HV5TIaaLQ=.ff1cbed9-0294-4704-ac00-2225ccf3c24a@github.com>
Message-ID: <sfrObDEuxsPWokHfcyrC0BOWCNyDHxa0jyRFZImWl48=.97a7deb4-7bdd-42f9-973a-5d564b891fe8@github.com>

On Tue, 2 Dec 2025 09:15:22 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> PreviewFeatures.isEnabled() is internal and not accessible without adding some `@module` in each IR test. That seems like an excessive burden.
>> 
>> Doing it more fine-grained was on purpose. @TobiHartmann an opinion? I tihnk it can make a mess with other project repos, but I don't remember the exact scenario.
>
> Right, adding it to every test doesn't feel like the way to go! I'm not too fussed about it, it was just a suggestion, feel free to disregard ;)

I think it might not be doable indeed.

There is still the question of `"enable-valhalla", "true"` or `"enable-preview", "true"`. While the first version was to do an `enable-preview` (up to the difficulties of testing it...), after discussion with @TobiHartmann, `enable-valhalla` had upsides, which I fear I don't remember.

If we change the name to `enable-preview`, the way we check it might be... confusing, but fine for now. Also, the current solution makes it easier to update tests in the future when Valhalla won't be preview anymore.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580328491

From thartmann at openjdk.org  Tue Dec  2 09:31:31 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 2 Dec 2025 09:31:31 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
Message-ID: <IZJFlX_UWAAo33s2NHEZWxalMWAa1Yl9UdvWv9C5ry4=.3b4ea45c-6665-4dc6-9e84-62503367a091@github.com>

On Tue, 2 Dec 2025 08:34:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116
> 
> we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.
> 
> To keep the test robust, I prefered to expect the exact amount, and not something like
> 
> @IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
> @IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })
> 
> Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).
> 
> To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.
> 
> Thanks,
> Marc

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1767#pullrequestreview-3529110629

From thartmann at openjdk.org  Tue Dec  2 09:31:32 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 2 Dec 2025 09:31:32 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <sfrObDEuxsPWokHfcyrC0BOWCNyDHxa0jyRFZImWl48=.97a7deb4-7bdd-42f9-973a-5d564b891fe8@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
 <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
 <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>
 <NiO71N5OycKL85Ylw0n99Z-kPHUfQ2mwpcmFWLzodpg=.8a771833-e831-4410-8217-c67ffcfc77a4@github.com>
 <F8-1E2mZVb6SzWb3NcgRyB7g17PzLeWTd6HV5TIaaLQ=.ff1cbed9-0294-4704-ac00-2225ccf3c24a@github.com>
 <sfrObDEuxsPWokHfcyrC0BOWCNyDHxa0jyRFZImWl48=.97a7deb4-7bdd-42f9-973a-5d564b891fe8@github.com>
Message-ID: <n6RvOY9lWdqGWTz69VcLBWALM4Kva8aUfdkpV6O-e0g=.2995fb5b-3e53-492e-b8f6-25d1d694eefd@github.com>

On Tue, 2 Dec 2025 09:20:57 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> Right, adding it to every test doesn't feel like the way to go! I'm not too fussed about it, it was just a suggestion, feel free to disregard ;)
>
> I think it might not be doable indeed.
> 
> There is still the question of `"enable-valhalla", "true"` or `"enable-preview", "true"`. While the first version was to do an `enable-preview` (up to the difficulties of testing it...), after discussion with @TobiHartmann, `enable-valhalla` had upsides, which I fear I don't remember.
> 
> If we change the name to `enable-preview`, the way we check it might be... confusing, but fine for now. Also, the current solution makes it easier to update tests in the future when Valhalla won't be preview anymore.

I think `enable-valhalla` is good for now. `PreviewFeatures.isEnabled()` can not be used from within the IR framework and `enable-preview` is not really what we are checking (we are checking if boxing classes were migrated, which is Valhalla specific). We can still rename the flag if needed later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580357275

From phubner at openjdk.org  Tue Dec  2 09:31:33 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 2 Dec 2025 09:31:33 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <n6RvOY9lWdqGWTz69VcLBWALM4Kva8aUfdkpV6O-e0g=.2995fb5b-3e53-492e-b8f6-25d1d694eefd@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
 <WePVOSsEBrAlt0F-pa9UpoVtk4Rktrzi1ahNTJGnem8=.14a40c1b-8e43-439f-b159-f71cb1d0d40a@github.com>
 <a20pKxef_YeDgBEyJaLXYquYb7HEJwVCLRZLds5D9dw=.60b35a1c-f5f8-46ad-b2b7-2c657e45a393@github.com>
 <NiO71N5OycKL85Ylw0n99Z-kPHUfQ2mwpcmFWLzodpg=.8a771833-e831-4410-8217-c67ffcfc77a4@github.com>
 <F8-1E2mZVb6SzWb3NcgRyB7g17PzLeWTd6HV5TIaaLQ=.ff1cbed9-0294-4704-ac00-2225ccf3c24a@github.com>
 <sfrObDEuxsPWokHfcyrC0BOWCNyDHxa0jyRFZImWl48=.97a7deb4-7bdd-42f9-973a-5d564b891fe8@github.com>
 <n6RvOY9lWdqGWTz69VcLBWALM4Kva8aUfdkpV6O-e0g=.2995fb5b-3e53-492e-b8f6-25d1d694eefd@github.com>
Message-ID: <vxu5FejvWeEBc-rQzEYMMZOucWF1tfuCQlFTeDlrZAw=.a38239e5-2a47-401a-bee2-76b86b4a930e@github.com>

On Tue, 2 Dec 2025 09:29:13 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I think it might not be doable indeed.
>> 
>> There is still the question of `"enable-valhalla", "true"` or `"enable-preview", "true"`. While the first version was to do an `enable-preview` (up to the difficulties of testing it...), after discussion with @TobiHartmann, `enable-valhalla` had upsides, which I fear I don't remember.
>> 
>> If we change the name to `enable-preview`, the way we check it might be... confusing, but fine for now. Also, the current solution makes it easier to update tests in the future when Valhalla won't be preview anymore.
>
> I think `enable-valhalla` is good for now. `PreviewFeatures.isEnabled()` can not be used from within the IR framework and `enable-preview` is not really what we are checking (we are checking if boxing classes were migrated, which is Valhalla specific). We can still rename the flag if needed later.

If the current solution makes it easier to update post-preview I'm all for it!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1767#discussion_r2580358136

From chagedorn at openjdk.org  Tue Dec  2 09:50:17 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 2 Dec 2025 09:50:17 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
Message-ID: <3qydd5cgXDHZlD981ztbP5-NJmvcEURn-MuJBvxsPmY=.a5c71dc7-50df-42d2-8a2e-6a12bfd5cc10@github.com>

On Tue, 2 Dec 2025 08:34:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116
> 
> we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.
> 
> To keep the test robust, I prefered to expect the exact amount, and not something like
> 
> @IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
> @IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })
> 
> Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).
> 
> To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.
> 
> Thanks,
> Marc

That looks reasonable to do, good!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1767#pullrequestreview-3529192154

From bruno.eberhard at pop.ch  Tue Dec  2 01:38:19 2025
From: bruno.eberhard at pop.ch (Bruno Eberhard)
Date: Tue, 2 Dec 2025 02:38:19 +0100
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
 <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
 <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>
Message-ID: <d308ae42-62b4-48f1-8131-f793c9a3fd35@pop.ch>

Am 01.12.2025 um 22:00 schrieb Ethan McCue:
> On that note, i'd say you have somewhat of a bigger problem w.r.t. enums
> [..]
> As with all things in jdk.unsupported, I can't help but wonder if there 
> are any VM level invariants you run afoul of by making extra enum 
> instances. 

I don't know about the VM internals. I did never run into problems with 
these extra enums.

> My first stab at #2 is to add something like this record [..]
Thank you for your input. I have to try this.

> I think it's also worth asking - do you have any usage statistics on 
> your library? (Maven central used to offer download stats, etc.) If you 
> are going to be broken anyways it is probably useful to know the blast 
> radius.

Very good point. As far as I know minimal-j is only used by me for a 
smaller and one bigger App. In the bigger App ( An ERP called 
lisheane.ch , currently only available in german ) I invested quite some 
time. I would have to rewrite parts of it.

So the world will not be standing still if minimal-j doesn't work 
anymore or has to be changed.

I would still like the idea of field references ( Person::name , 
Person::address::city ) in the java language as equivalent for the $ 
constant. It is really nice to use. But I don't have the knowledge how 
to add it to the language or how to propose the feature.

From coleen.phillimore at oracle.com  Tue Dec  2 14:11:49 2025
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 2 Dec 2025 14:11:49 +0000
Subject: =?utf-8?B?UmU6IENGVjogTmV3IFZhbGhhbGxhIENvbW1pdHRlcjogUGF1bCBIw7xibmVy?=
In-Reply-To: <SA2PR10MB445935229DD6ADAB767E8EB59AD0A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445935229DD6ADAB767E8EB59AD0A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB60733D06FA2916D683E43F428ED8A@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 David Simms <david.simms at oracle.com>
Date: Monday, November 24, 2025 at 6:23?AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Paul H?bner

I hereby nominate Paul H?bner [1] to Valhalla Committer

Paul is a member of the HotSpot Runtime team at Oracle, an OpenJDK author, with contributions to both jdk [2] and valhalla [3] project repositories. This includes a number of significant changes (not just in terms resulting of code, but extensive testing):

  * https://github.com/openjdk/valhalla/pull/1552
  * https://github.com/openjdk/valhalla/pull/1578
  * https://github.com/openjdk/valhalla/pull/1588
  * https://github.com/openjdk/valhalla/pull/1666
  * https://github.com/openjdk/valhalla/pull/1682
  * https://github.com/openjdk/valhalla/pull/1710
  * https://github.com/openjdk/valhalla/pull/1713
  * https://github.com/openjdk/valhalla/pull/1752

Votes are due by December 8th, 2025, 1200Z.

Only current Valhalla Committers [4] 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 [5].

David Simms

[1] https://openjdk.org/census#phubner
[2] https://github.com/openjdk/jdk/commits?author=Arraying
[3] https://github.com/openjdk/valhalla/commits?author=Arraying
[4] https://openjdk.org/census
[5] https://openjdk.org/projects/#committer-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251202/19934e02/attachment-0001.htm>

From stuefe at openjdk.org  Tue Dec  2 15:01:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 2 Dec 2025 15:01:10 GMT
Subject: [lworld] RFR: 8372856: [lworld] link error in release build for
 oops/test_flatArrayOop.cpp
Message-ID: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>

Simple error with a trivial fix. In release builds, `flatArrayOopDesc::value_at_addr` may be inlined, causing the non-inlined function not to exist and resulting in link errors if a call site does not include the inline hpp.

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

Commit messages:
 - fix

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

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

From fparain at openjdk.org  Tue Dec  2 15:01:11 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 2 Dec 2025 15:01:11 GMT
Subject: [lworld] RFR: 8372856: [lworld] link error in release build for
 oops/test_flatArrayOop.cpp
In-Reply-To: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
References: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
Message-ID: <kjsWUN5kfW9jsFw7vtuVG2v2Eth1GXjIz4aQwf5f5sA=.39a60a89-d72b-4501-aeda-23401c0c90dc@github.com>

On Tue, 2 Dec 2025 06:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Simple error with a trivial fix. In release builds, `flatArrayOopDesc::value_at_addr` may be inlined, causing the non-inlined function not to exist and resulting in link errors if a call site does not include the inline hpp.

LGTM.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1765#pullrequestreview-3530505333

From ethan at mccue.dev  Tue Dec  2 15:35:44 2025
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 2 Dec 2025 10:35:44 -0500
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86iupnyK6ec5rDzSB4m=kJrvFU3fkE218H8YydmUm40Kfw@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
 <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
 <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>
 <d308ae42-62b4-48f1-8131-f793c9a3fd35@pop.ch>
 <CA+NR86iupnyK6ec5rDzSB4m=kJrvFU3fkE218H8YydmUm40Kfw@mail.gmail.com>
Message-ID: <CA+NR86i4YZiVTf6W43g8yUWOGr+1tt8CTJdsjb7DY2Si6vKL7A@mail.gmail.com>

        var form = new Form<Person>();
        form.line(() -> $.number);
        form.line(() -> $.name);
        form.line(() -> $.address.city);


        Backend.find(Person.class, By.field(() -> $.name, "Bruno"));
        Backend.find(Person.class, By.field(() -> $.address.zip, 8000));

This might be all that is needed - forgiving the perf difference, general
hackiness, etc.

On Mon, Dec 1, 2025 at 11:50?PM Ethan McCue <ethan at mccue.dev> wrote:

> There is a parallel thread going on which touches on similar things -
> there people are wanting "record component references."
>
> I adapted the code from
> https://github.com/rilindbicaj/fluentmapper/blob/main/fluentmapper-provider/src/main/java/dev/bici/fluentmapper/provider/expression/parser/ExpressionParser.java
> to use the new classfile api + work for a quick demo of the approach.
>
> Basically, you can get at the code in the body of a lambda via some
> serialization hackery. The degree to which this is actually supported is to
> me unknown.
>
> import java.io.IOException;
> import java.io.Serializable;
> import java.io.UncheckedIOException;
> import java.lang.classfile.ClassFile;
> import java.lang.classfile.ClassModel;
> import java.lang.classfile.instruction.FieldInstruction;
> import java.lang.invoke.SerializedLambda;
> import java.lang.reflect.Field;
> import java.util.ArrayList;
> import java.util.List;
>
> public final class FieldReference {
>     private final Class<?> root;
>     private final List<Field> fields;
>
>     private FieldReference(Class<?> root, List<Field> fields) {
>         this.root = root;
>         this.fields = fields;
>     }
>
>
>     public Class<?> root() {
>         return root;
>     }
>
>     public List<Field> fields() {
>         return fields;
>     }
>
>     private static SerializedLambda toSerializedLambda(Expression<?, ?>
> expression) {
>         try {
>             var writeReplaceMethod =
> expression.getClass().getDeclaredMethod("writeReplace");
>             writeReplaceMethod.setAccessible(true);
>
>             return (SerializedLambda)
> writeReplaceMethod.invoke(expression);
>         } catch (ReflectiveOperationException e) {
>             throw new IllegalArgumentException("Could not extract
> SerializedLambda from the provided expression;", e);
>         }
>     }
>
>     public static <T> FieldReference of(Class<T> klass, Expression<T, ?>
> expression) {
>         // TODO: This work can likely be cached.
>         var serializedLambda = toSerializedLambda(expression);
>         var containingClass = serializedLambda.getImplClass();
>         var lambdaSignature = serializedLambda.getImplMethodName();
>
>         // TODO: Unsure if this is the right class loader to use
>         var classLoader = klass.getClassLoader();
>
>         byte[] classBytes;
>         try (var classResource = classLoader.getResourceAsStream(
>                 containingClass.replace('.', '/') + ".class"
>         )) {
>             if (classResource == null) {
>                 throw new IllegalArgumentException("Could not find
> class-file resource in class loader");
>             }
>
>             classBytes = classResource.readAllBytes();
>         } catch (IOException e) {
>             throw new UncheckedIOException(e);
>         }
>
>         ClassModel classModel = ClassFile.of().parse(classBytes);
>
>         var methodModel = classModel.methods().stream()
>                 .filter(method ->
> lambdaSignature.equals(method.methodName().toString()))
>                 .findFirst()
>                 .orElseThrow(() -> new IllegalArgumentException("Could not
> find the implementing method for the expression lambda"));
>         var code = methodModel.code().orElseThrow();
>
>         // TODO: This could use a lot of prechecks
>         var fields = new ArrayList<Field>();
>
>         Class<?> lastType = klass;
>         for (var element : code.elementList()) {
>             if (element instanceof FieldInstruction fieldInstruction) {
>                 try {
>                     fields.add(
>
> lastType.getDeclaredField(fieldInstruction.field().name().toString())
>                     );
>
>
>                     // TODO: This is almost certainly not sound
>                     if
> (fieldInstruction.typeSymbol().packageName().isEmpty()) {
>                         lastType = classLoader.loadClass(
>                                 fieldInstruction.typeSymbol().displayName()
>                         );
>                     }
>                     else {
>                         lastType = classLoader.loadClass(
>
> fieldInstruction.typeSymbol().packageName() + "."
>                                         +
> fieldInstruction.typeSymbol().displayName()
>                         );
>                     }
>
>                 } catch (NoSuchFieldException e) {
>                     throw new IllegalArgumentException("Inaccessable
> field", e);
>                 } catch (ClassNotFoundException e) {
>                     throw new RuntimeException(e);
>                 }
>             }
>         }
>
>
>         return new FieldReference(klass, List.copyOf(fields));
>     }
>
>
>     @FunctionalInterface
>     public interface Expression<A, B> extends Serializable {
>         B get(A a);
>     }
>
>
>     @Override
>     public String toString() {
>         return "FieldReference[" +
>                 "root=" + root.getName() +
>                 ", fields=" + fields.stream().map(Field::getName).toList()
> +
>                 ']';
>     }
> }
>
> And you can use all of that with a lambda that only accesses fields to
> emulate "field references."
>
> class A {
>     String aa;
>     B b;
> }
>
> class B {
>     C c;
> }
>
>  class C {
>     String v;
>     D d;
> }
>
>  class D {
>     E e;
> }
>
>  class E {
>     F f;
> }
>
>  class F {
>     G g;
> }
>
>  class G {
>     String v;
> }
>
> public class Test {
>     public static void main(String[] args) {
>         var refA = FieldReference.of(A.class, a -> a.aa);
>         IO.println(refA);
>         var refB = FieldReference.of(A.class, a -> a.b.c.d);
>         IO.println(refB);
>     }
> }
>
> FieldReference[root=A, fields=[aa]]
> FieldReference[root=A, fields=[b, c, d]]
>
> So that is one approach to look into.
>
>
> On Mon, Dec 1, 2025, 8:38?PM Bruno Eberhard <bruno.eberhard at pop.ch> wrote:
>
>> Am 01.12.2025 um 22:00 schrieb Ethan McCue:
>> > On that note, i'd say you have somewhat of a bigger problem w.r.t. enums
>> > [..]
>> > As with all things in jdk.unsupported, I can't help but wonder if there
>> > are any VM level invariants you run afoul of by making extra enum
>> > instances.
>>
>> I don't know about the VM internals. I did never run into problems with
>> these extra enums.
>>
>> > My first stab at #2 is to add something like this record [..]
>> Thank you for your input. I have to try this.
>>
>> > I think it's also worth asking - do you have any usage statistics on
>> > your library? (Maven central used to offer download stats, etc.) If you
>> > are going to be broken anyways it is probably useful to know the blast
>> > radius.
>>
>> Very good point. As far as I know minimal-j is only used by me for a
>> smaller and one bigger App. In the bigger App ( An ERP called
>> lisheane.ch , currently only available in german ) I invested quite some
>> time. I would have to rewrite parts of it.
>>
>> So the world will not be standing still if minimal-j doesn't work
>> anymore or has to be changed.
>>
>> I would still like the idea of field references ( Person::name ,
>> Person::address::city ) in the java language as equivalent for the $
>> constant. It is really nice to use. But I don't have the knowledge how
>> to add it to the language or how to propose the feature.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251202/fd5c1417/attachment-0001.htm>

From bruno.eberhard at pop.ch  Tue Dec  2 16:32:25 2025
From: bruno.eberhard at pop.ch (Bruno Eberhard)
Date: Tue, 2 Dec 2025 17:32:25 +0100
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <CA+NR86i4YZiVTf6W43g8yUWOGr+1tt8CTJdsjb7DY2Si6vKL7A@mail.gmail.com>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
 <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
 <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>
 <d308ae42-62b4-48f1-8131-f793c9a3fd35@pop.ch>
 <CA+NR86iupnyK6ec5rDzSB4m=kJrvFU3fkE218H8YydmUm40Kfw@mail.gmail.com>
 <CA+NR86i4YZiVTf6W43g8yUWOGr+1tt8CTJdsjb7DY2Si6vKL7A@mail.gmail.com>
Message-ID: <8e56afe0-3990-4915-8980-f6fae22cc6d9@pop.ch>

Yes, I also thought of that. Forms and queries already know the class of 
the business object. This could lead to an advantage over my current 
solution because right now it is possible to use fields of a wrong $ 
constant. And this really happened sometimes.

Thank you very much for your ideas. I will need some time to work this 
all out. Maybe I will contact you outside of this mailing list as it's 
getting a little bit offtopic.

Am 02.12.2025 um 16:35 schrieb Ethan McCue:
>  ? ? ? ? var form = new Form<Person>();
>  ? ? ? ? form.line(() -> $.number);
>  ? ? ? ? form.line(() -> $.name);
>  ? ? ? ? form.line(() -> $.address.city);
> 
> 
>  ? ? ? ? Backend.find(Person.class, By.field(() -> $.name, "Bruno"));
>  ? ? ? ? Backend.find(Person.class, By.field(() ->?$.address.zip, 8000));
> 
> This might be all that is needed - forgiving the perf difference, 
> general hackiness, etc.
> 

From brian.goetz at oracle.com  Tue Dec  2 16:49:26 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 2 Dec 2025 16:49:26 +0000
Subject: Valhalla breaks minimal-j framework
In-Reply-To: <8e56afe0-3990-4915-8980-f6fae22cc6d9@pop.ch>
References: <bc084c6c-5a03-41a9-aa75-e2d397ab2fb6@pop.ch>
 <1477593174.52378522.1764615245813.JavaMail.zimbra@univ-eiffel.fr>
 <CA+NR86gejGz_UJmDDBAKDWV7XBia_eUUVYt9O+O4=gV7PNM_5w@mail.gmail.com>
 <CA+NR86h-Aobsv6hcptXTrMT-JA-shOs2yrTx1Vx=-UiX-_77pw@mail.gmail.com>
 <b64965b8-c7de-4f97-88ef-d1d934835e7c@pop.ch>
 <CA+NR86i+zh6a63j=4b5OOgrXNa8Eak6kaWMS9=OhWr18TE1ejA@mail.gmail.com>
 <8f1def9e-2073-4602-93b5-01697a0bcb76@pop.ch>
 <CA+NR86gJF3K-t_ii5kTnVjhGoTxmC38-J5E9VehJL+i8ksU8CQ@mail.gmail.com>
 <d308ae42-62b4-48f1-8131-f793c9a3fd35@pop.ch>
 <CA+NR86iupnyK6ec5rDzSB4m=kJrvFU3fkE218H8YydmUm40Kfw@mail.gmail.com>
 <CA+NR86i4YZiVTf6W43g8yUWOGr+1tt8CTJdsjb7DY2Si6vKL7A@mail.gmail.com>
 <8e56afe0-3990-4915-8980-f6fae22cc6d9@pop.ch>
Message-ID: <55D7972E-072F-4284-9872-6A6664CD56A0@oracle.com>

Just a quick reminder that this conversation is getting pretty far afield for valhalla-dev.  

> On Dec 2, 2025, at 11:32 AM, Bruno Eberhard <bruno.eberhard at pop.ch> wrote:
> 
> Yes, I also thought of that. Forms and queries already know the class of the business object. This could lead to an advantage over my current solution because right now it is possible to use fields of a wrong $ constant. And this really happened sometimes.
> 
> Thank you very much for your ideas. I will need some time to work this all out. Maybe I will contact you outside of this mailing list as it's getting a little bit offtopic.
> 
> Am 02.12.2025 um 16:35 schrieb Ethan McCue:
>>         var form = new Form<Person>();
>>         form.line(() -> $.number);
>>         form.line(() -> $.name);
>>         form.line(() -> $.address.city);
>>         Backend.find(Person.class, By.field(() -> $.name, "Bruno"));
>>         Backend.find(Person.class, By.field(() -> $.address.zip, 8000));
>> This might be all that is needed - forgiving the perf difference, general hackiness, etc.


From amenkov at openjdk.org  Tue Dec  2 16:55:30 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 2 Dec 2025 16:55:30 GMT
Subject: [lworld] RFR: 8372304: [lworld] Test
 serviceability/jvmti/valhalla/HeapDump/HeapDump.java fails in product build
In-Reply-To: <eFf-E01joO2-Bjm_O8kN-EO70fR7nWhubkUgv0crNqI=.1559e978-7381-48d2-85a2-d413692f0192@github.com>
References: <eFf-E01joO2-Bjm_O8kN-EO70fR7nWhubkUgv0crNqI=.1559e978-7381-48d2-85a2-d413692f0192@github.com>
Message-ID: <Cq4SCvdgKNiSU4ySbf6ijR4av0Z9AGY7QP6gYLTLKB8=.fbfce966-3f2b-4c65-9517-11dddbb00584@github.com>

On Thu, 20 Nov 2025 22:20:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test executes subprocess with `-XX:+PrintInlineLayout` and `-XX:+PrintFlatArrayLayout` arguments. These are diagnostic arguments, require `-XX:+UnlockDiagnosticVMOptions` to unlock.

Looking for review from (C)ommitter

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

PR Comment: https://git.openjdk.org/valhalla/pull/1754#issuecomment-3603023970

From fparain at openjdk.org  Tue Dec  2 20:21:41 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 2 Dec 2025 20:21:41 GMT
Subject: [lworld] RFR: 8372955: [lworld] The alternate substitutability method
 doesn't increment the offset when iterating over segments
Message-ID: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>

Fix missing offset increment in the alternate substitutability test method.

The unit tests forces the use of the alternate substitutability test method because the legacy method has another issue of its own with some of the tests (see JDK-8372729)

Fred

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

Commit messages:
 - Remove trailing whitespaces
 - Fix formating
 - Fix offset increment in alt substitutability method

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

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

From liach at openjdk.org  Tue Dec  2 20:30:48 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 20:30:48 GMT
Subject: [lworld] RFR: 8372955: [lworld] The alternate substitutability
 method doesn't increment the offset when iterating over segments
In-Reply-To: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
References: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
Message-ID: <bAjdx4QMF3VDVh2j-WAwyiuzNURAn4YyOg7CwAVtra4=.28b15269-ec97-43a0-b03e-68db65934a1d@github.com>

On Tue, 2 Dec 2025 19:06:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix missing offset increment in the alternate substitutability test method.
> 
> The unit tests forces the use of the alternate substitutability test method because the legacy method has another issue of its own with some of the tests (see JDK-8372729)
> 
> Fred

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1769#pullrequestreview-3531988863

From rriggs at openjdk.org  Tue Dec  2 20:37:32 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Dec 2025 20:37:32 GMT
Subject: [lworld] RFR: 8372955: [lworld] The alternate substitutability
 method doesn't increment the offset when iterating over segments
In-Reply-To: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
References: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
Message-ID: <IbD6YA69lHlDNeFvd879vSXP3WIQ0DvhcM0Gsc3exB8=.4929df76-d17a-4105-885f-5649960b350a@github.com>

On Tue, 2 Dec 2025 19:06:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix missing offset increment in the alternate substitutability test method.
> 
> The unit tests forces the use of the alternate substitutability test method because the legacy method has another issue of its own with some of the tests (see JDK-8372729)
> 
> Fred

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1769#pullrequestreview-3532009691

From liach at openjdk.org  Tue Dec  2 20:44:12 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 Dec 2025 20:44:12 GMT
Subject: [lworld] RFR: 8372619: [lworld] Use Character caches in
 --enable-preview
In-Reply-To: <DGPn-SjD_aOaTwJpjb9g8jurL9M_zLfrYY7jtIb-M80=.191de0b7-e368-48d8-be52-df35861a2539@github.com>
References: <DGPn-SjD_aOaTwJpjb9g8jurL9M_zLfrYY7jtIb-M80=.191de0b7-e368-48d8-be52-df35861a2539@github.com>
Message-ID: <8TbCLdlrxXITypOp4bfoORrkyRV2Qo4HOXPu6dnzJCc=.07904009-f598-4bab-91f5-aca65b6eaecb@github.com>

On Wed, 26 Nov 2025 19:07:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Re-enable Character.cache with or without --enable-preview.
> A more complete removal of the Character cache needs some Hotspot changes.

C2 has some weird code around its type system around autoboxing cache indeed.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1763#pullrequestreview-3532030365

From stuefe at openjdk.org  Wed Dec  3 06:50:22 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 3 Dec 2025 06:50:22 GMT
Subject: [lworld] RFR: 8372856: [lworld] link error in release build for
 oops/test_flatArrayOop.cpp
In-Reply-To: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
References: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
Message-ID: <ArEPb4f0SPh_d2WAxmjdqnYeRMGM6aoS1FZJgBTJ0xU=.3c2911b8-67f8-4ed8-a728-64ee301be4ad@github.com>

On Tue, 2 Dec 2025 06:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Simple error with a trivial fix. In release builds, `flatArrayOopDesc::value_at_addr` may be inlined, causing the non-inlined function not to exist and resulting in link errors if a call site does not include the inline hpp.

For some reason, GHAs won't run for me in my valhalla fork. I opted in on GHAs for the fork. I also expected the usual mail/message from Skara Bot to invite me, but I've gotten nothing so far.

Other than that, this issue is so trivial that I may just push the fix if there are no objections.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1765#issuecomment-3605344087

From mchevalier at openjdk.org  Wed Dec  3 08:23:32 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Dec 2025 08:23:32 GMT
Subject: [lworld] RFR: 8367553: [lworld]
 compiler/valhalla/inlinetypes/TestNullableArrays.java fails with segfault in
 C1 compiled code on aarch64
In-Reply-To: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>
References: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>
Message-ID: <ewtVPGCT2AJ9L7DI-Fi-6B9OAmzI_bCrBvttMw3sDsA=.b7059765-4377-4100-b077-f39a08d14866@github.com>

On Tue, 2 Dec 2025 08:19:32 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Seems that it was just [JDK-8367151: [lworld] CorrectlyRestoreRfp.java triggers "bad oop found" during deoptimization](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751. When I checked first if it still reproduces, https://github.com/openjdk/valhalla/pull/1751 wasn't integrated yet. And after investigation, it turned out to be the same issue. And after integration of the said PR, the problem didn't show again under much more extensive testing than what was enough to reproduce before.
> 
> In more details, the case I investigated was mostly in `test76_verifier` (occasionally in `test78_verifier`)
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L2100-L2120
> 
> that is C1-compiled. During a call to C2-compiled `verify`:
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L1145-L1153
> 
> an oop is passed in rfp. Sometimes, the GC moves the object during the execution of `verify`, it updated the wrong copy of RFP on the stack. Then `verify` hits an uncommon trap, and in the process picks the wrong `rfp` by exactly the same mechanism as in [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151). Later in `test76_verify`, the content of rfp, that now contains a wrong oop, is used, garbage is read, segfault.
> 
> The fact that is goes through an uncommon trap makes it a slightly different flavor than what I've seen before. Also, I should have taken my own advice, and use SerialGC, it would have saved me some complications!
> 
> I suggest we just un-problem list now.
> 
> Thanks,
> Marc

Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1766#issuecomment-3605613746

From mchevalier at openjdk.org  Wed Dec  3 08:26:26 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Dec 2025 08:26:26 GMT
Subject: [lworld] Integrated: 8367553: [lworld]
 compiler/valhalla/inlinetypes/TestNullableArrays.java fails with segfault in
 C1 compiled code on aarch64
In-Reply-To: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>
References: <4rJJYfbKYZ6llInIoellqwgkFmBKi3MN_rb8rWSRVKw=.f50ad5a8-5a22-4d8c-9f75-397400b427ab@github.com>
Message-ID: <a_eXjUpI7Ksb-llKnRz8Jv-kd9olIFxsFNpqOLQusZc=.e0048fe8-4596-48fe-8cf6-9cbb61d33297@github.com>

On Tue, 2 Dec 2025 08:19:32 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Seems that it was just [JDK-8367151: [lworld] CorrectlyRestoreRfp.java triggers "bad oop found" during deoptimization](https://bugs.openjdk.org/browse/JDK-8367151)/https://github.com/openjdk/valhalla/pull/1751. When I checked first if it still reproduces, https://github.com/openjdk/valhalla/pull/1751 wasn't integrated yet. And after investigation, it turned out to be the same issue. And after integration of the said PR, the problem didn't show again under much more extensive testing than what was enough to reproduce before.
> 
> In more details, the case I investigated was mostly in `test76_verifier` (occasionally in `test78_verifier`)
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L2100-L2120
> 
> that is C1-compiled. During a call to C2-compiled `verify`:
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestNullableArrays.java#L1145-L1153
> 
> an oop is passed in rfp. Sometimes, the GC moves the object during the execution of `verify`, it updated the wrong copy of RFP on the stack. Then `verify` hits an uncommon trap, and in the process picks the wrong `rfp` by exactly the same mechanism as in [JDK-8367151](https://bugs.openjdk.org/browse/JDK-8367151). Later in `test76_verify`, the content of rfp, that now contains a wrong oop, is used, garbage is read, segfault.
> 
> The fact that is goes through an uncommon trap makes it a slightly different flavor than what I've seen before. Also, I should have taken my own advice, and use SerialGC, it would have saved me some complications!
> 
> I suggest we just un-problem list now.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 36847ef9
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/36847ef9be5ea1a60b2291f99832f730dccd74af
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8367553: [lworld] compiler/valhalla/inlinetypes/TestNullableArrays.java fails with segfault in C1 compiled code on aarch64

Reviewed-by: thartmann

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

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

From mchevalier at openjdk.org  Wed Dec  3 08:43:45 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Dec 2025 08:43:45 GMT
Subject: [lworld] RFR: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
Message-ID: <DXGZn_rirVVXHvVKpM_7-SUrW__YDQCfu0nGggT089I=.0cb2c3b9-2003-46d4-bff1-3963d3749759@github.com>

On Tue, 2 Dec 2025 08:34:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116
> 
> we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.
> 
> To keep the test robust, I prefered to expect the exact amount, and not something like
> 
> @IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
> @IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })
> 
> Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).
> 
> To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.
> 
> Thanks,
> Marc

Thanks all!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1767#issuecomment-3605686742

From mchevalier at openjdk.org  Wed Dec  3 08:47:48 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 3 Dec 2025 08:47:48 GMT
Subject: [lworld] Integrated: 8372697: [lworld]
 compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java
 fails with --enable-preview
In-Reply-To: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
References: <D38QKGs6qvo2lkaJljQmnsdADbWn0NRQlUCoShuj_9I=.e69f74da-e090-4185-b8f7-b15deff47576@github.com>
Message-ID: <rP_I4DCIX3N_5qEeXobVx697cVBzVkxr-K6xPPQSUlw=.58b2f349-657f-4829-8215-8216a4429b67@github.com>

On Tue, 2 Dec 2025 08:34:50 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> In
> https://github.com/openjdk/valhalla/blob/acb511a9f5c7b750b41e1ce77aab3d1a59613097/test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java#L98-L116
> 
> we have 2 allocations: `Iter` and `Integer`. Scalar replacement allows to eliminate the allocation of `Iter`, but we still had the allocation of `Integer`. With value classes, we can also save the allocation of `Integer` since it is a value class. Adapting expectations is enough.
> 
> To keep the test robust, I prefered to expect the exact amount, and not something like
> 
> @IR(phase = { CompilePhase.PHASEIDEAL_BEFORE_EA }, counts = { IRNode.ALLOC, "<= 2" })
> @IR(phase = { CompilePhase.ITER_GVN_AFTER_ELIMINATION }, counts = { IRNode.ALLOC, "<= 1" })
> 
> Since that would allow the respective counts 1 and 1 (for instance, if `Integer` allocation is being removed as a value class, but `Iter` is not because EA would be broken with Valhalla).
> 
> To allow the test to work precisely with and without Valhalla, I propose a fake flag `enable-valhalla` that checks whether `Integer` is a value class. I preferred that over more generally "enable-preview" because it lacks granularity with respect to other preview features, and `PreviewFeatures.isEnabled()` is internal and not accessible anyway. It's a little hack, but I think the usage is very natural. It would be good if @chhagedorn could take a look at it.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: 428522c5
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/428522c56bfe58f7a554ebb37ffa27822ee43d68
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8372697: [lworld] compiler/c2/irTests/scalarReplacement/ScalarReplacementWithGCBarrierTests.java fails with --enable-preview

Reviewed-by: thartmann, chagedorn

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

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

From fparain at openjdk.org  Wed Dec  3 13:50:36 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 3 Dec 2025 13:50:36 GMT
Subject: [lworld] RFR: 8372955: [lworld] The alternate substitutability
 method doesn't increment the offset when iterating over segments
In-Reply-To: <bAjdx4QMF3VDVh2j-WAwyiuzNURAn4YyOg7CwAVtra4=.28b15269-ec97-43a0-b03e-68db65934a1d@github.com>
References: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
 <bAjdx4QMF3VDVh2j-WAwyiuzNURAn4YyOg7CwAVtra4=.28b15269-ec97-43a0-b03e-68db65934a1d@github.com>
Message-ID: <626LQ7QOgV3VoOaXjt1pCzpFuGxNmixDdlc-jHeDzZI=.1246fcb5-d1f1-427e-9814-c6c8cbd39d76@github.com>

On Tue, 2 Dec 2025 20:27:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Fix missing offset increment in the alternate substitutability test method.
>> 
>> The unit tests forces the use of the alternate substitutability test method because the legacy method has another issue of its own with some of the tests (see JDK-8372729)
>> 
>> Fred
>
> Marked as reviewed by liach (Committer).

Thanks @liach @RogerRiggs for your reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1769#issuecomment-3606939747

From fparain at openjdk.org  Wed Dec  3 13:50:37 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 3 Dec 2025 13:50:37 GMT
Subject: [lworld] Integrated: 8372955: [lworld] The alternate substitutability
 method doesn't increment the offset when iterating over segments
In-Reply-To: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
References: <Kcgb8q3mHj680I9MZ_57iHywvD_KujAIsPgLKkkOJRc=.65af540e-9728-4000-81d8-bf48d183faca@github.com>
Message-ID: <u1UyftRE7QwTyB2TDi2sFASZztPAJgWkXyrNiCzqNtA=.3247e518-b9b0-4394-a3d6-9f8c999aa59f@github.com>

On Tue, 2 Dec 2025 19:06:15 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Fix missing offset increment in the alternate substitutability test method.
> 
> The unit tests forces the use of the alternate substitutability test method because the legacy method has another issue of its own with some of the tests (see JDK-8372729)
> 
> Fred

This pull request has now been integrated.

Changeset: 702e6102
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/702e61026f2b3ddf9a4980a753bb4f770fb1a674
Stats:     206 lines in 2 files changed: 206 ins; 0 del; 0 mod

8372955: [lworld] The alternate substitutability method doesn't increment the offset when iterating over segments

Reviewed-by: liach, rriggs

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

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

From rriggs at openjdk.org  Wed Dec  3 17:16:34 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 Dec 2025 17:16:34 GMT
Subject: [lworld] Integrated: 8372619: [lworld] Use Character caches in
 --enable-preview
In-Reply-To: <DGPn-SjD_aOaTwJpjb9g8jurL9M_zLfrYY7jtIb-M80=.191de0b7-e368-48d8-be52-df35861a2539@github.com>
References: <DGPn-SjD_aOaTwJpjb9g8jurL9M_zLfrYY7jtIb-M80=.191de0b7-e368-48d8-be52-df35861a2539@github.com>
Message-ID: <ImJrK0c6aqajDCa6k5A3TkIEa2PSQHz-HHXLkz0Nmzg=.13b1cb03-d694-47d3-a23a-4ac85c7653e4@github.com>

On Wed, 26 Nov 2025 19:07:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Re-enable Character.cache with or without --enable-preview.
> A more complete removal of the Character cache needs some Hotspot changes.

This pull request has now been integrated.

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

8372619: [lworld] Use Character caches in --enable-preview

Reviewed-by: liach

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

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

From qamai at openjdk.org  Thu Dec  4 06:38:06 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 4 Dec 2025 06:38:06 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v3]
In-Reply-To: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
Message-ID: <sj6K_zrFrSPIMaMAzhMNlvLE1PjUMDcXgPRdVgMkgc8=.a6043148-e888-4cf8-ad67-699bf7329aa1@github.com>

> Hi,
> 
> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
> 
> Please take a look and leave your reviews, thanks a lot.

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

 - whitespace
 - fix more issues
 - Merge branch 'lworld' into AryKlassPtrfactory
 - Fix test failures
 - Tighten the type system around array properties and fix related issues

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

Changes: https://git.openjdk.org/valhalla/pull/1755/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1755&range=02
  Stats: 486 lines in 20 files changed: 193 ins; 130 del; 163 mod
  Patch: https://git.openjdk.org/valhalla/pull/1755.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1755/head:pull/1755

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

From qamai at openjdk.org  Thu Dec  4 06:44:24 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 4 Dec 2025 06:44:24 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v3]
In-Reply-To: <sj6K_zrFrSPIMaMAzhMNlvLE1PjUMDcXgPRdVgMkgc8=.a6043148-e888-4cf8-ad67-699bf7329aa1@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <sj6K_zrFrSPIMaMAzhMNlvLE1PjUMDcXgPRdVgMkgc8=.a6043148-e888-4cf8-ad67-699bf7329aa1@github.com>
Message-ID: <TP679zkOleSoCirQzce0o-OdPAoJ1WsuVKgYTR9eDXc=.d94e43ae-7d68-42ea-b5c8-90ceab5f6d33@github.com>

On Thu, 4 Dec 2025 06:38:06 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - whitespace
>  - fix more issues
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix test failures
>  - Tighten the type system around array properties and fix related issues

I have fixed the first and the third issue.

The first one is because while we process a `MergeMemNode`, the IGVN can kill other nodes, including yet-to-process `MergeMemNode`s, just skipping dead nodes, then.

The third one is kind of interesting. When creating a refined `ObjArrayKlass`, we fall back to ref array if the corresponding flat layout is not present, which means that if the element type is not a `LooselyConsistentValue`, `ValueClass::newNullRestrictedNonAtomicArray` will make a ref array. This seems counter-intuitive, it should have fallen back to a null-restricted atomic array instead. This kind of falling back also makes reasoning about arrays easier, as we will have fewer states to think about. It also makes the logic more intuitive, because it raised my eyebrows when `ciObjArrayKlass::make` creates a ref (and obviously atomic) array when asked for a non-atomic array, but a flat (and also atomic) array when asked for an atomic array. As a result, I think it is reasonable to adapt `ValueClass::newNullRestrictedNonAtomicArray` to return a null-restricted atomic array when the non-atomic layout is not present.

Unfortunately, I have not been able to reproduce or had any clue about the second issue :(

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

PR Comment: https://git.openjdk.org/valhalla/pull/1755#issuecomment-3610546439

From stuefe at openjdk.org  Thu Dec  4 09:13:48 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 09:13:48 GMT
Subject: [lworld] RFR: 8372856: [lworld] link error in release build for
 oops/test_flatArrayOop.cpp
In-Reply-To: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
References: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
Message-ID: <1_bAv8cGuMz22m0iWbU3f2LvLXnftugomGxg5vN8LxM=.2c7a324f-a860-4c3f-8dd1-918814512880@github.com>

On Tue, 2 Dec 2025 06:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Simple error with a trivial fix. In release builds, `flatArrayOopDesc::value_at_addr` may be inlined, causing the non-inlined function not to exist and resulting in link errors if a call site does not include the inline hpp.

Hearing no objections, I'll push now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1765#issuecomment-3611006790

From duke at openjdk.org  Thu Dec  4 09:13:49 2025
From: duke at openjdk.org (duke)
Date: Thu, 4 Dec 2025 09:13:49 GMT
Subject: [lworld] RFR: 8372856: [lworld] link error in release build for
 oops/test_flatArrayOop.cpp
In-Reply-To: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
References: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
Message-ID: <aj8STxvKsqaQNL0q6fHR2DEfbuiRMfwV-kouIwtG0aQ=.b35f8b89-3c8f-4e36-bd32-260b46a7dafb@github.com>

On Tue, 2 Dec 2025 06:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Simple error with a trivial fix. In release builds, `flatArrayOopDesc::value_at_addr` may be inlined, causing the non-inlined function not to exist and resulting in link errors if a call site does not include the inline hpp.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1765#issuecomment-3611015346

From stuefe at openjdk.org  Thu Dec  4 13:11:32 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 4 Dec 2025 13:11:32 GMT
Subject: [lworld] Integrated: 8372856: [lworld] link error in release build for
 oops/test_flatArrayOop.cpp
In-Reply-To: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
References: <05bETVUlsJiC4dUb4VrgiQZe4XJVgyMl7m6QTyXOMgE=.0f81cec9-294d-4c13-b059-bc5f9003d7e2@github.com>
Message-ID: <6s4tlzsv7gPm4vBmGhNDp32e-Nq5Byvo9gzifAti4V8=.2b1e66a3-8346-4f71-957e-ae8a0bff32a5@github.com>

On Tue, 2 Dec 2025 06:21:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Simple error with a trivial fix. In release builds, `flatArrayOopDesc::value_at_addr` may be inlined, causing the non-inlined function not to exist and resulting in link errors if a call site does not include the inline hpp.

This pull request has now been integrated.

Changeset: a291a5dd
Author:    Thomas Stuefe <stuefe at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a291a5dd845cb25aa59987c95ca7c72c066cd4e7
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8372856: [lworld] link error in release build for oops/test_flatArrayOop.cpp

Reviewed-by: fparain

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

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

From thartmann at openjdk.org  Thu Dec  4 15:27:04 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 4 Dec 2025 15:27:04 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v3]
In-Reply-To: <TP679zkOleSoCirQzce0o-OdPAoJ1WsuVKgYTR9eDXc=.d94e43ae-7d68-42ea-b5c8-90ceab5f6d33@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <sj6K_zrFrSPIMaMAzhMNlvLE1PjUMDcXgPRdVgMkgc8=.a6043148-e888-4cf8-ad67-699bf7329aa1@github.com>
 <TP679zkOleSoCirQzce0o-OdPAoJ1WsuVKgYTR9eDXc=.d94e43ae-7d68-42ea-b5c8-90ceab5f6d33@github.com>
Message-ID: <KCVaKC8uXPo7DNZLjxEsL7f4jSyHW6HAReMe39YXqmo=.79e2792c-2ee5-45d4-b303-316f2e3897f4@github.com>

On Thu, 4 Dec 2025 06:41:33 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - whitespace
>>  - fix more issues
>>  - Merge branch 'lworld' into AryKlassPtrfactory
>>  - Fix test failures
>>  - Tighten the type system around array properties and fix related issues
>
> I have fixed the first and the third issue.
> 
> The first one is because while we process a `MergeMemNode`, the IGVN can kill other nodes, including yet-to-process `MergeMemNode`s, just skipping dead nodes, then.
> 
> The third one is kind of interesting. When creating a refined `ObjArrayKlass`, we fall back to ref array if the corresponding flat layout is not present, which means that if the element type is not a `LooselyConsistentValue`, `ValueClass::newNullRestrictedNonAtomicArray` will make a ref array. This seems counter-intuitive, it should have fallen back to a null-restricted atomic array instead. This kind of falling back also makes reasoning about arrays easier, as we will have fewer states to think about. It also makes the logic more intuitive, because it raised my eyebrows when `ciObjArrayKlass::make` creates a ref (and obviously atomic) array when asked for a non-atomic array, but a flat (and also atomic) array when asked for an atomic array. As a result, I think it is reasonable to adapt `ValueClass::newNullRestrictedNonAtomicArray` to return a null-restricted atomic array when the non-atomic layout is not present.
> 
> Unfortunately, I have not been able to reproduce or had any clue about the second issue :(

Thanks for the updates @merykitty. Looks better now but I still see these:


compiler/valhalla/inlinetypes/TestLWorld.java
-XX:+UnlockDiagnosticVMOptions -XX:ForceNonTearable=*

Custom Run Test: @Run: runFlatArrayInexactLoadAndStore - @Tests: {testFlatArrayInexactObjectStore,testFlatArrayInexactObjectLoad,testFlatArrayInexactAbstractValueClassStore,testFlatArrayInexactAbstractValueClassLoad}:
compiler.lib.ir_framework.shared.TestRunException: There was an error while invoking @Run method static void compiler.valhalla.inlinetypes.TestLWorld.runFlatArrayInexactLoadAndStore()
	at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:162)
	at compiler.lib.ir_framework.test.AbstractTest.run(AbstractTest.java:105)
	at compiler.lib.ir_framework.test.CustomRunTest.run(CustomRunTest.java:89)
	at compiler.lib.ir_framework.test.TestVM.runTests(TestVM.java:869)
	at compiler.lib.ir_framework.test.TestVM.start(TestVM.java:256)
	at compiler.lib.ir_framework.test.TestVM.main(TestVM.java:169)
Caused by: java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at compiler.lib.ir_framework.test.CustomRunTest.invokeTest(CustomRunTest.java:159)
	... 5 more
Caused by: java.lang.RuntimeException: assertEquals expected: compiler.valhalla.inlinetypes.TestLWorld$SubValueClassWithInt at 66aaf14d but was: compiler.valhalla.inlinetypes.TestLWorld$SubValueClassWithInt at 66aaf143
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:208)
	at jdk.test.lib.Asserts.assertEquals(Asserts.java:195)
	at jdk.test.lib.Asserts.assertEQ(Asserts.java:172)
	at compiler.valhalla.inlinetypes.TestLWorld.runFlatArrayInexactLoadAndStore(TestLWorld.java:4754)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	... 7 more


These ones might be unrelated to your changes but I haven't seen them without:


runtime/valhalla/inlinetypes/AcmpTest.java
-XX:-UseCompressedOops -XX:+UseG1GC -XX:InitiatingHeapOccupancyPercent=0 -Xmx20m -Xmn1m -XX:G1HeapRegionSize=1m -XX:-ReduceInitialCardMarks

java.lang.OutOfMemoryError: Java heap space
	at java.base/java.util.Arrays.copyOf(Arrays.java:3514)
	at java.base/java.util.Arrays.copyOf(Arrays.java:3479)
	at java.base/java.util.ArrayList.grow(ArrayList.java:238)
	at java.base/java.util.ArrayList.grow(ArrayList.java:245)
	at java.base/java.util.ArrayList.add(ArrayList.java:484)
	at java.base/java.util.ArrayList.add(ArrayList.java:497)
	at runtime.valhalla.inlinetypes.AcmpTest.generateTestCases(AcmpTest.java:184)
	at runtime.valhalla.inlinetypes.AcmpTest.main(AcmpTest.java:199)
	at java.base/java.lang.invoke.LambdaForm$DMH/0x0000000026080c00.invokeStatic(LambdaForm$DMH)
	at java.base/java.lang.invoke.LambdaForm$MH/0x0000000026083000.invoke(LambdaForm$MH)
	at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.runWith(Thread.java:1487)
	at java.base/java.lang.Thread.run(Thread.java:1474)



serviceability/jvmti/valhalla/Heapwalking/ValueHeapwalkingTest.java	
-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true

#  Internal Error (workspace/open/src/hotspot/share/ci/ciMetadata.hpp:112), pid=2968284, tid=2968304
#  assert(is_inlinetype()) failed: bad cast
#
# JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-jep401ea2-2025-12-04-0955402.tobias.hartmann.valhallatesting)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-jep401ea2-2025-12-04-0955402.tobias.hartmann.valhallatesting, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x74cb72]  Type::inline_klass() const+0x152

Current CompileTask:
C2:12976 3041    b        ValueHeapwalkingTest::createValue2Array (49 bytes)

Stack: [0x00007fcdaf6f8000,0x00007fcdaf7f8000],  sp=0x00007fcdaf7f2b70,  free space=1002k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x74cb72]  Type::inline_klass() const+0x152  (ciMetadata.hpp:112)
V  [libjvm.so+0x1698c3d]  PhaseMacroExpand::value_from_mem(Node*, Node*, BasicType, Type const*, TypeOopPtr const*, AllocateNode*)+0x5dd  (macro.cpp:548)
V  [libjvm.so+0x169a1e5]  PhaseMacroExpand::inline_type_from_mem(ciInlineKlass*, TypeAryPtr const*, int, int, bool, AllocateNode*, SafePointNode*)+0x1a5  (macro.cpp:640)
V  [libjvm.so+0x169a0f3]  PhaseMacroExpand::inline_type_from_mem(ciInlineKlass*, TypeAryPtr const*, int, int, bool, AllocateNode*, SafePointNode*)+0xb3  (macro.cpp:630)
V  [libjvm.so+0x169a9a8]  PhaseMacroExpand::add_array_elems_to_safepoint(AllocateNode*, TypeAryPtr const*, SafePointNode*, Unique_Node_List*)+0x1e8  (macro.cpp:967)
V  [libjvm.so+0x169b868]  PhaseMacroExpand::create_scalarized_object_description(AllocateNode*, SafePointNode*, Unique_Node_List*)+0x2e8  (macro.cpp:1114)
V  [libjvm.so+0x169d8f6]  PhaseMacroExpand::scalar_replacement(AllocateNode*, GrowableArray<SafePointNode*>&)+0x286  (macro.cpp:1146)
V  [libjvm.so+0x169e1a8]  PhaseMacroExpand::eliminate_allocate_node(AllocateNode*)+0x1c8  (macro.cpp:1405)
V  [libjvm.so+0x169ee89]  PhaseMacroExpand::eliminate_macro_nodes(bool)+0x7c9  (macro.cpp:3095)
V  [libjvm.so+0xbe5ae4]  Compile::Optimize()+0xe14  (compile.cpp:2933)
V  [libjvm.so+0xbe8a35]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1d95  (compile.cpp:879)
V  [libjvm.so+0x9ddf70]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x4c0  (c2compiler.cpp:149)
V  [libjvm.so+0xbf8280]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x780  (compileBroker.cpp:2345)
V  [libjvm.so+0xbf9ae0]  CompileBroker::compiler_thread_loop()+0x530  (compileBroker.cpp:1989)
V  [libjvm.so+0x119c77b]  JavaThread::thread_main_inner()+0x13b  (javaThread.cpp:777)
V  [libjvm.so+0x1c7c0b6]  Thread::call_run()+0xb6  (thread.cpp:242)
V  [libjvm.so+0x18a2ef8]  thread_native_entry(Thread*)+0x118  (os_linux.cpp:879)


Unfortunately, the failures with `compiler/valhalla/inlinetypes/TestArrayNullMarkers.java#nAVF` also still reproduces but only on Linux AArch64 and with `-XX:+IgnoreUnrecognizedVMOptions -XX:-TieredCompilation -XX:-DoEscapeAnalysis -XX:+AlwaysIncrementalInline`. Here are the replay and hs_err files, maybe they help:
[hs_err_pid1353592.log](https://github.com/user-attachments/files/23937516/hs_err_pid1353592.log)
[replay_pid1353592.log](https://github.com/user-attachments/files/23937517/replay_pid1353592.log)

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

PR Comment: https://git.openjdk.org/valhalla/pull/1755#issuecomment-3612785988

From vromero at openjdk.org  Thu Dec  4 18:53:16 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Dec 2025 18:53:16 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in compact
 constructors
Message-ID: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>

there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,

TIA

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

Commit messages:
 - adding test
 - Merge branch 'lworld' into JDK-8370634
 - 8370634: [lworld] super should not be allowed in compact constructors

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

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

From liach at openjdk.org  Thu Dec  4 19:10:58 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Dec 2025 19:10:58 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in
 compact constructors
In-Reply-To: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
Message-ID: <lu-9o-QsPGSm4E0dZdHSSuKQ8Ad5VdpIYH0UUImpeT0=.be3f2db9-6dce-4f12-9085-66b60fa0721a@github.com>

On Thu, 4 Dec 2025 18:31:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,
> 
> TIA

I recommend adding a positive test to ensure a normal canonical constructor of a record can call super as well.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1770#pullrequestreview-3541648349

From vromero at openjdk.org  Thu Dec  4 19:24:13 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Dec 2025 19:24:13 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in
 compact constructors [v2]
In-Reply-To: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
Message-ID: <lu9tq6L-At3iiJ1B_wqiWg5jSUlvvpCBvkDoRWj9t1Q=.bfbf0865-a71b-4a7d-af7c-b49a8d652d58@github.com>

> there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,
> 
> 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/1770/files
  - new: https://git.openjdk.org/valhalla/pull/1770/files/6d36b2aa..a6c7a537

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

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

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

From liach at openjdk.org  Thu Dec  4 19:26:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Dec 2025 19:26:30 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in
 compact constructors [v2]
In-Reply-To: <lu9tq6L-At3iiJ1B_wqiWg5jSUlvvpCBvkDoRWj9t1Q=.bfbf0865-a71b-4a7d-af7c-b49a8d652d58@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
 <lu9tq6L-At3iiJ1B_wqiWg5jSUlvvpCBvkDoRWj9t1Q=.bfbf0865-a71b-4a7d-af7c-b49a8d652d58@github.com>
Message-ID: <TCNjlRbc-gcx4ecST2RxgEp0aXkp4HWIj_aI_vuIOk0=.181c17b2-03fb-4890-b5dd-3d0fd13298d5@github.com>

On Thu, 4 Dec 2025 19:24:13 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional test

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1770#pullrequestreview-3541713669

From vromero at openjdk.org  Thu Dec  4 19:39:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Dec 2025 19:39:46 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in
 compact constructors [v3]
In-Reply-To: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
Message-ID: <CAQRgMsNQsWwJiWszvtTGwYBE7k0SxZdY6MOV-0vCYM=.18aabe45-bf67-44af-a216-5c3cfd0440a4@github.com>

> there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,
> 
> TIA

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

  another test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1770/files
  - new: https://git.openjdk.org/valhalla/pull/1770/files/a6c7a537..1ac8c5da

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

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

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

From vromero at openjdk.org  Thu Dec  4 19:39:49 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Dec 2025 19:39:49 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in
 compact constructors [v2]
In-Reply-To: <TCNjlRbc-gcx4ecST2RxgEp0aXkp4HWIj_aI_vuIOk0=.181c17b2-03fb-4890-b5dd-3d0fd13298d5@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
 <lu9tq6L-At3iiJ1B_wqiWg5jSUlvvpCBvkDoRWj9t1Q=.bfbf0865-a71b-4a7d-af7c-b49a8d652d58@github.com>
 <TCNjlRbc-gcx4ecST2RxgEp0aXkp4HWIj_aI_vuIOk0=.181c17b2-03fb-4890-b5dd-3d0fd13298d5@github.com>
Message-ID: <L_LhAOgTWCBTZnqkA2h3FI-t3EEbs_QWMsKmABFaZys=.a3ee5612-f897-4c67-9b9a-67d0c37d13a7@github.com>

On Thu, 4 Dec 2025 19:23:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional test
>
> Marked as reviewed by liach (Committer).

@liach done, thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1770#issuecomment-3614028902

From liach at openjdk.org  Thu Dec  4 19:50:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Dec 2025 19:50:27 GMT
Subject: [lworld] RFR: 8370634: [lworld] super should not be allowed in
 compact constructors [v3]
In-Reply-To: <CAQRgMsNQsWwJiWszvtTGwYBE7k0SxZdY6MOV-0vCYM=.18aabe45-bf67-44af-a216-5c3cfd0440a4@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
 <CAQRgMsNQsWwJiWszvtTGwYBE7k0SxZdY6MOV-0vCYM=.18aabe45-bf67-44af-a216-5c3cfd0440a4@github.com>
Message-ID: <Zkbz3JMfPRWJCUrukJ4vKvtucQRErmGuIfMEcsH-5GE=.d8c88856-a5e6-4690-bad2-7d7d7217d2ef@github.com>

On Thu, 4 Dec 2025 19:39:46 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another test

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1770#pullrequestreview-3541811548

From rriggs at openjdk.org  Thu Dec  4 22:08:33 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 Dec 2025 22:08:33 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening
Message-ID: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>

This test failing with VM options prompted a refatoring and cleanup of the test (and renaming to be more appropriate).
The test is re-enabled with a 4 combinations of command line flags.

Refactored test to verify that hashcode changed with each change to a field. Previously, the test tried to compute the hashCode for the value class. That was fragile in the presence of the VM changing the layout information. Check the hashCodes are equal for objects that are `.equals`. Renamed to 'ValueObjectMethodsTest`.

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

Commit messages:
 - JDK-8357373: [lworld] jdk/valhalla/valuetypes/ObjectMethods.java fails with -XX:+UseAtomicValueFlattening

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

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

From vromero at openjdk.org  Thu Dec  4 22:26:06 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 4 Dec 2025 22:26:06 GMT
Subject: [lworld] Integrated: 8370634: [lworld] super should not be allowed in
 compact constructors
In-Reply-To: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
References: <3YD0qTlOR1DN-oKV7aaWVCzqONDspVNHTa3Dvtqbi_I=.4fdd184b-fb42-47ef-b583-d8556408b965@github.com>
Message-ID: <QwunRGiAsIf8xzumsPtKZx1ULpx5M7MFos7unzC7xfM=.cee8dfaf-3cb5-4733-89b5-8b171866cf8d@github.com>

On Thu, 4 Dec 2025 18:31:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> there is a bug in lworld and due to it javac accepts records with compact constructors that contain invocations to the super constructor. This is not allowed by the spec. This PR is fixing this issue,
> 
> TIA

This pull request has now been integrated.

Changeset: 36f43f74
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/36f43f74f2d714b3188fc8cc833dd2e41a268720
Stats:     36 lines in 2 files changed: 35 ins; 0 del; 1 mod

8370634: [lworld] super should not be allowed in compact constructors

Reviewed-by: liach

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

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

From liach at openjdk.org  Thu Dec  4 22:32:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Dec 2025 22:32:33 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening
In-Reply-To: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
Message-ID: <OnX2loOyM3OECSb2wO0rq5NCRHALYLIbcyPRAYdhNZ4=.e2fc15db-2571-46cc-8fbd-6d3913ebcd33@github.com>

On Thu, 4 Dec 2025 22:02:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This test failing with VM options prompted a refatoring and cleanup of the test (and renaming to be more appropriate).
> The test is re-enabled with a 4 combinations of command line flags.
> 
> Refactored test to verify that hashcode changed with each change to a field. Previously, the test tried to compute the hashCode for the value class. That was fragile in the presence of the VM changing the layout information. Check the hashCodes are equal for objects that are `.equals`. Renamed to 'ValueObjectMethodsTest`.

test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java line 282:

> 280:         assertTrue(objects.size() > 1, "More than one object is required: " + objects);
> 281: 
> 282:         long count = objects.stream().map(Object::hashCode).distinct().count();

Suggestion:

        long count = objects.stream().map(System::identityHashCode).distinct().count();

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1771#discussion_r2590805399

From rriggs at openjdk.org  Thu Dec  4 22:38:39 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 Dec 2025 22:38:39 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening [v2]
In-Reply-To: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
Message-ID: <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>

> This test failing with VM options prompted a refatoring and cleanup of the test (and renaming to be more appropriate).
> The test is re-enabled with a 4 combinations of command line flags.
> 
> Refactored test to verify that hashcode changed with each change to a field. Previously, the test tried to compute the hashCode for the value class. That was fragile in the presence of the VM changing the layout information. Check the hashCodes are equal for objects that are `.equals`. Renamed to 'ValueObjectMethodsTest`.

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

  Correct check for identityHashCode

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1771/files
  - new: https://git.openjdk.org/valhalla/pull/1771/files/e8be456c..cf21f7d4

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

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

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

From liach at openjdk.org  Thu Dec  4 22:55:04 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 Dec 2025 22:55:04 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening [v2]
In-Reply-To: <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
 <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>
Message-ID: <XHg5b6hMOrjVOP6lOaddPyC23h0j6Na9uCkptwpmrWI=.9c000c93-ceb5-4ade-8594-23d6e4591db2@github.com>

On Thu, 4 Dec 2025 22:38:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This test failing with VM options prompted a refatoring and cleanup of the test (and renaming to be more appropriate).
>> The test is re-enabled with a 4 combinations of command line flags.
>> 
>> Refactored test to verify that hashcode changed with each change to a field. Previously, the test tried to compute the hashCode for the value class. That was fragile in the presence of the VM changing the layout information. Check the hashCodes are equal for objects that are `.equals`. Renamed to 'ValueObjectMethodsTest`.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct check for identityHashCode

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1771#pullrequestreview-3542463959

From qamai at openjdk.org  Fri Dec  5 07:31:35 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 5 Dec 2025 07:31:35 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v4]
In-Reply-To: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
Message-ID: <r9nYnq-nBZy-X33e9RLewoi-MGqgJ3E_vti_5gSYPlI=.f1aa6138-182b-4dd1-b14c-a7df7efb0d85@github.com>

> Hi,
> 
> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
> 
> Please take a look and leave your reviews, thanks a lot.

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

 - Merge branch 'lworld' into AryKlassPtrfactory
 - Fix Parse::array_store and PhaseMacroNode::value_from_mem
 - whitespace
 - fix more issues
 - Merge branch 'lworld' into AryKlassPtrfactory
 - Fix test failures
 - Tighten the type system around array properties and fix related issues

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

Changes: https://git.openjdk.org/valhalla/pull/1755/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1755&range=03
  Stats: 496 lines in 21 files changed: 196 ins; 131 del; 169 mod
  Patch: https://git.openjdk.org/valhalla/pull/1755.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1755/head:pull/1755

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

From qamai at openjdk.org  Fri Dec  5 07:48:32 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 5 Dec 2025 07:48:32 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v4]
In-Reply-To: <r9nYnq-nBZy-X33e9RLewoi-MGqgJ3E_vti_5gSYPlI=.f1aa6138-182b-4dd1-b14c-a7df7efb0d85@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <r9nYnq-nBZy-X33e9RLewoi-MGqgJ3E_vti_5gSYPlI=.f1aa6138-182b-4dd1-b14c-a7df7efb0d85@github.com>
Message-ID: <EIEDRZtF03_Y8wGa0LJvHgsp3BDkF3ZPeiJ-UCw4dEk=.3b7abb08-b553-4afe-8208-fda87ec7c661@github.com>

On Fri, 5 Dec 2025 07:31:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix Parse::array_store and PhaseMacroNode::value_from_mem
>  - whitespace
>  - fix more issues
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix test failures
>  - Tighten the type system around array properties and fix related issues

Thanks Tobias, the first issue is due to a wrong `if` in `Parse::array_store` which skips the whole `if (!array_type->is_not_flat())` if the array is null-free. The second issue is that the `AllocateNode::InitValue` of an `AllocateArrayNode` is the output of the call to `Class::new_instance`, which is of type `j.l.Object`, we should bail out if we cannot see through the value object, then. For the OOM, on my machine both lworld and this branch fail with `-Xmx20m` and pass with `-Xmx21m`. Seems like it is on the edge there.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1755#issuecomment-3615669911

From vyazici at openjdk.org  Fri Dec  5 08:48:23 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 5 Dec 2025 08:48:23 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening [v2]
In-Reply-To: <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
 <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>
Message-ID: <Bqq2Z8R_-f3hFlmom9OfLCwIdOZAn-BLo_TsHMtz-0Y=.320a2bf9-4047-4fa1-9c1a-c113a357528a@github.com>

On Thu, 4 Dec 2025 22:38:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This test failing with VM options prompted a refatoring and cleanup of the test (and renaming to be more appropriate).
>> The test is re-enabled with a 4 combinations of command line flags.
>> 
>> Refactored test to verify that hashcode changed with each change to a field. Previously, the test tried to compute the hashCode for the value class. That was fragile in the presence of the VM changing the layout information. Check the hashCodes are equal for objects that are `.equals`. Renamed to 'ValueObjectMethodsTest`.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct check for identityHashCode

test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java line 253:

> 251:         Line l3 = new Line(0, 9, 2, 3);
> 252:         Line l4 = new Line(0, 1, 9, 3);
> 253:         Line l5 = new Line(0, 1, 2, 9);

Random thought: Would it be a good idea to randomize the content to increase coverage over time? For example,

    var r = new java.util.Random();
    var coordinates = Stream
            .generate(() -> List.of(r.nextInt(), r.nextInt()))
            .distinct()
            .limit(4)
            .toList();
    int i = 0;
    var p1 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1)); i++;
    var p2 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1)); i++;
    var p3 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1)); i++;
    var p4 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1));

test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java line 280:

> 278:     @MethodSource("hashcodeTests")
> 279:     public void testHashCode(List<Object> objects) {
> 280:         assertTrue(objects.size() > 1, "More than one object is required: " + objects);

_Nit:_ I doubt if displaying `[]` will contribute much to the diagnostics context.

Suggestion:

        assertFalse(objects.isEmpty(), "More than one object is required");

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1771#discussion_r2591865591
PR Review Comment: https://git.openjdk.org/valhalla/pull/1771#discussion_r2591872272

From dsimms at openjdk.org  Fri Dec  5 10:24:05 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 5 Dec 2025 10:24:05 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <-Myo6kl36C9ij2VbJTv_Y1pFY8yHUi_JclEf0xDBIxU=.06651a72-9a09-4dc8-8f4f-8b1d16a87aaf@github.com>

Merge jdk-26+24

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

Commit messages:
 - Needless objArrayHandle
 - Merge branch 'lworld' into lworld_merge_jdk_26_24
 - Merge tag 'jdk-26+24' into lworld_merge_jdk_26_24
 - 8367292: VectorAPI: Optimize VectorMask.fromLong/toLong() for SVE
 - 8370467: BorderFactory.createBevelBorder and createSoftBevelBorder throws NPE for null highlight and shadow
 - 8371339: Illegal pattern char 'B' with locale.providers as HOST on macOS for Taiwanese
 - 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence
 - 8371365: Update javax/swing/JFileChooser/bug4759934.java to use Util.findComponent()
 - 8371645: BasicImageReader getEntryNames() is stateful and cannot be called more than once
 - 8341039: compiler/cha/TypeProfileFinalMethod.java fails with assertEquals expected: 0 but was: 2
 - ... and 81 more: https://git.openjdk.org/valhalla/compare/bf9315f6...8a1acb2d

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

Changes: https://git.openjdk.org/valhalla/pull/1772/files
  Stats: 167721 lines in 962 files changed: 113168 ins; 26224 del; 28329 mod
  Patch: https://git.openjdk.org/valhalla/pull/1772.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1772/head:pull/1772

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

From thartmann at openjdk.org  Fri Dec  5 14:23:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 5 Dec 2025 14:23:21 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v4]
In-Reply-To: <r9nYnq-nBZy-X33e9RLewoi-MGqgJ3E_vti_5gSYPlI=.f1aa6138-182b-4dd1-b14c-a7df7efb0d85@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <r9nYnq-nBZy-X33e9RLewoi-MGqgJ3E_vti_5gSYPlI=.f1aa6138-182b-4dd1-b14c-a7df7efb0d85@github.com>
Message-ID: <jCTHKrg-QzhPOOcNPtgCdJpjt5RXT4TP-meR-6_plHE=.3994d6ef-4df8-4261-9998-aae60f6c2642@github.com>

On Fri, 5 Dec 2025 07:31:35 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
>> 
>> Please take a look and leave your reviews, thanks a lot.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix Parse::array_store and PhaseMacroNode::value_from_mem
>  - whitespace
>  - fix more issues
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix test failures
>  - Tighten the type system around array properties and fix related issues

Thanks Quan-Anh! That fixed all issues except for the `should only visit bottom memory` problem with  `compiler/valhalla/inlinetypes/TestArrayNullMarkers.java`. Any information that I can provide to help with the investigation of that one?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1755#issuecomment-3617119653

From rriggs at openjdk.org  Fri Dec  5 14:31:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Dec 2025 14:31:01 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening [v2]
In-Reply-To: <Bqq2Z8R_-f3hFlmom9OfLCwIdOZAn-BLo_TsHMtz-0Y=.320a2bf9-4047-4fa1-9c1a-c113a357528a@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
 <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>
 <Bqq2Z8R_-f3hFlmom9OfLCwIdOZAn-BLo_TsHMtz-0Y=.320a2bf9-4047-4fa1-9c1a-c113a357528a@github.com>
Message-ID: <Y9ax59-h7wFK8RqHFxRhWDwLYcMpcPPDbl1a5SEXTlM=.def59f98-cb28-4f72-b750-f9a364ea8847@github.com>

On Fri, 5 Dec 2025 08:43:40 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct check for identityHashCode
>
> test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java line 253:
> 
>> 251:         Line l3 = new Line(0, 9, 2, 3);
>> 252:         Line l4 = new Line(0, 1, 9, 3);
>> 253:         Line l5 = new Line(0, 1, 2, 9);
> 
> Random thought: Would it be a good idea to randomize the content to increase coverage over time? For example,
> 
>     var r = new java.util.Random();
>     var coordinates = Stream
>             .generate(() -> List.of(r.nextInt(), r.nextInt()))
>             .distinct()
>             .limit(4)
>             .toList();
>     int i = 0;
>     var p1 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1)); i++;
>     var p2 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1)); i++;
>     var p3 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1)); i++;
>     var p4 = new Point(coordinates.get(i).get(0), coordinates.get(i).get(1));

There is very little incremental value in that and it raises the complexity of the test, also needed more setup to document the random seed so it can be reproduced.
The test is intended to ensure that a change to each value individually causes a change in the hashCode.
Additional random values would do the same.

> test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java line 280:
> 
>> 278:     @MethodSource("hashcodeTests")
>> 279:     public void testHashCode(List<Object> objects) {
>> 280:         assertTrue(objects.size() > 1, "More than one object is required: " + objects);
> 
> _Nit:_ I doubt if displaying `[]` will contribute much to the diagnostics context.
> 
> Suggestion:
> 
>         assertFalse(objects.isEmpty(), "More than one object is required");

Every little bit helps.  
(`isEmpty` is not equivalent to `>1`)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1771#discussion_r2592882965
PR Review Comment: https://git.openjdk.org/valhalla/pull/1771#discussion_r2592887565

From vyazici at openjdk.org  Fri Dec  5 14:34:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 5 Dec 2025 14:34:03 GMT
Subject: [lworld] RFR: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening [v2]
In-Reply-To: <Y9ax59-h7wFK8RqHFxRhWDwLYcMpcPPDbl1a5SEXTlM=.def59f98-cb28-4f72-b750-f9a364ea8847@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
 <-N9MzoPHbrcHEXuAmkttmAtwG7ryqNMSQxXy_7P1Ok4=.f7496464-f6cd-4a05-826d-efde796cf72a@github.com>
 <Bqq2Z8R_-f3hFlmom9OfLCwIdOZAn-BLo_TsHMtz-0Y=.320a2bf9-4047-4fa1-9c1a-c113a357528a@github.com>
 <Y9ax59-h7wFK8RqHFxRhWDwLYcMpcPPDbl1a5SEXTlM=.def59f98-cb28-4f72-b750-f9a364ea8847@github.com>
Message-ID: <UZd_nLH7b_IwHnWKFYe71Ujj9aJLEkunxOHYhRINQTc=.5f501c48-6d45-40f7-8792-b5beaf709b76@github.com>

On Fri, 5 Dec 2025 14:28:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/valhalla/valuetypes/ValueObjectMethodsTest.java line 280:
>> 
>>> 278:     @MethodSource("hashcodeTests")
>>> 279:     public void testHashCode(List<Object> objects) {
>>> 280:         assertTrue(objects.size() > 1, "More than one object is required: " + objects);
>> 
>> _Nit:_ I doubt if displaying `[]` will contribute much to the diagnostics context.
>> 
>> Suggestion:
>> 
>>         assertFalse(objects.isEmpty(), "More than one object is required");
>
> Every little bit helps.  
> (`isEmpty` is not equivalent to `>1`)

You're right, nevermind.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1771#discussion_r2592896967

From rriggs at openjdk.org  Fri Dec  5 14:41:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Dec 2025 14:41:58 GMT
Subject: [lworld] Integrated: 8357373: [lworld]
 jdk/valhalla/valuetypes/ObjectMethods.java fails with
 -XX:+UseAtomicValueFlattening
In-Reply-To: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
References: <qfU2IUuyR5gvkUUslEx28-ZluESbcqKgmw9Mdi5cFjM=.86515625-54ec-4014-abc9-b310738e84c0@github.com>
Message-ID: <Yf1gYBYOEcfYIMXcLetvM2RYFUV5SDKe9JhdNLtVwKE=.111378f1-b029-48ae-bf84-71faf4c81987@github.com>

On Thu, 4 Dec 2025 22:02:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This test failing with VM options prompted a refatoring and cleanup of the test (and renaming to be more appropriate).
> The test is re-enabled with a 4 combinations of command line flags.
> 
> Refactored test to verify that hashcode changed with each change to a field. Previously, the test tried to compute the hashCode for the value class. That was fragile in the presence of the VM changing the layout information. Check the hashCodes are equal for objects that are `.equals`. Renamed to 'ValueObjectMethodsTest`.

This pull request has now been integrated.

Changeset: 3455c56c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3455c56c83741104e1405c2de6a62c76eea3b46c
Stats:     687 lines in 2 files changed: 354 ins; 333 del; 0 mod

8357373: [lworld] jdk/valhalla/valuetypes/ObjectMethods.java fails with -XX:+UseAtomicValueFlattening

Reviewed-by: liach

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

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

From rriggs at openjdk.org  Fri Dec  5 21:31:09 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 Dec 2025 21:31:09 GMT
Subject: [lworld] RFR: 8370714: [lworld] Reimplement System.identityHashCode
 for Value Objects
Message-ID: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>

The alternate hashcode compution is enabled when the alternate subsitutability method is enabled with: `-XX:+UseAltSubstitutabilityMethod`. 
The IdentityHashCode is computed using the map of field offsets and sizes from Unsafe. 
The basis of hashCode is the the hashCode of the object's class mixing in the value of each primitive field and the hashCode of each reference.

The changes to Hotspot invoke the original or the alternate Java method based on the VM `UseAltSubstitutabilityMethod` command line flag.

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

Commit messages:
 - 8370714: [lworld] Reimplement System.identityHashCode for Value Objects

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

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

From liach at openjdk.org  Sat Dec  6 00:53:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 Dec 2025 00:53:25 GMT
Subject: [lworld] RFR: 8370714: [lworld] Reimplement
 System.identityHashCode for Value Objects
In-Reply-To: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>
References: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>
Message-ID: <9n2Tr-vuLks2KWcdEmDedyrfG4B-tZYr80Q9b50Fi3w=.16b4db2b-583d-4546-b26f-c2ce12832d0c@github.com>

On Fri, 5 Dec 2025 21:24:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The alternate hashcode compution is enabled when the alternate subsitutability method is enabled with: `-XX:+UseAltSubstitutabilityMethod`. 
> The IdentityHashCode is computed using the map of field offsets and sizes from Unsafe. 
> The basis of hashCode is the the hashCode of the object's class mixing in the values from the memory where the fields are placed and the hashCode of each reference.
> 
> The changes to Hotspot invoke the original or the alternate Java method based on the VM `UseAltSubstitutabilityMethod` command line flag.

Ok

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1773#pullrequestreview-3546806156

From qamai at openjdk.org  Sat Dec  6 13:39:11 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 6 Dec 2025 13:39:11 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v5]
In-Reply-To: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
Message-ID: <gFicQ2aOaYNVw-LMESC5Mhfs1YPXaZKuRqNMNK2LPOw=.81dc155f-be70-4e00-b94d-a49c99674881@github.com>

> Hi,
> 
> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
> 
> 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:

  fix NarrowMemProj

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1755/files
  - new: https://git.openjdk.org/valhalla/pull/1755/files/98612e38..4e927135

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

  Stats: 88 lines in 3 files changed: 55 ins; 20 del; 13 mod
  Patch: https://git.openjdk.org/valhalla/pull/1755.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1755/head:pull/1755

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

From duke at openjdk.org  Sat Dec  6 15:33:25 2025
From: duke at openjdk.org (duke)
Date: Sat, 6 Dec 2025 15:33:25 GMT
Subject: [lworld] Withdrawn: 8367792: [lworld] Remove the Unsafe remnants of
 old valhalla prototypes
In-Reply-To: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
References: <N7HyU1ANTe9oLhagcyakbu63zK6A02yRFYxNTM80OaI=.89a03745-842d-4648-8433-28733f92142f@github.com>
Message-ID: <qdGyliZIkanrS--fxKBzZlIWAMDBNrGILNUEtuVAeWk=.05884456-dddc-4044-8ac9-3e1c169bfbfb@github.com>

On Tue, 16 Sep 2025 22:08:30 GMT, Chen Liang <liach at openjdk.org> wrote:

> There are some remnants from previous iterations of value objects in Unsafe. We should aim to remove them for cleaner code in the future.

This pull request has been closed without being integrated.

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

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

From qamai at openjdk.org  Sat Dec  6 17:12:36 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 6 Dec 2025 17:12:36 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
Message-ID: <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>

> Hi,
> 
> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
> 
> 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:

  Should not clone MergeMem

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1755/files
  - new: https://git.openjdk.org/valhalla/pull/1755/files/4e927135..2df30c7c

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

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

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

From qamai at openjdk.org  Sat Dec  6 17:18:37 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 6 Dec 2025 17:18:37 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
Message-ID: <7Gc3_Hy4qmLZ5M79ibdU8ffWg34dSNsyimyhfKMxrIc=.cbb9bfeb-a6b6-41d0-9821-a7094c017e97@github.com>

On Sat, 6 Dec 2025 17:12:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
>> 
>> 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:
> 
>   Should not clone MergeMem

I did not actually manage to reproduce the issue, but inserting a verification that inputs of a `TypePtr::BOTTOM` `Phi` must also be `TypePtr::BOTTOM` revealed what seems to be the issue. It is that we construct the graph incorrectly for an allocation of a flat array, we need to create a `NarrowMemProj`, then split that proj when the slices of flat arrays are split. Currently, the memory state is set to the raw memory input of the `InitializeNode` instead. Could you please test again if the issue is now fixed?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1755#issuecomment-3620716819

From dsimms at openjdk.org  Mon Dec  8 08:23:35 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 8 Dec 2025 08:23:35 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <-Myo6kl36C9ij2VbJTv_Y1pFY8yHUi_JclEf0xDBIxU=.06651a72-9a09-4dc8-8f4f-8b1d16a87aaf@github.com>
References: <-Myo6kl36C9ij2VbJTv_Y1pFY8yHUi_JclEf0xDBIxU=.06651a72-9a09-4dc8-8f4f-8b1d16a87aaf@github.com>
Message-ID: <rj_3uvFuPoH9Gg-ZKiv0y2WBUf0VDKCZPmwRo60M9_Q=.103b7cb8-471a-4cbd-abe9-efb546e7c5ae@github.com>

On Fri, 5 Dec 2025 10:16:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-26+24

This pull request has now been integrated.

Changeset: dfdfc712
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dfdfc7123aa160bdc6d8e1088459a1c59c7d498d
Stats:     167721 lines in 962 files changed: 113168 ins; 26224 del; 28329 mod

Merge

Merge jdk-26+24

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

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

From chagedorn at openjdk.org  Mon Dec  8 08:48:22 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 08:48:22 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues
In-Reply-To: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
Message-ID: <N4JH60i4U_-ljCLdvFolYRXuZlhyDbMGCroZlw2IX10=.53e7a8b8-44b1-4173-aece-43cfca7f72ce@github.com>

On Mon, 8 Dec 2025 08:13:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
> 
> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
> 
> Here is a high-level overview of the changes:
> - `FlatInArray` enum to define a lattice for `flat_in_array`:
> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
> 
> #### Testing:
> - t1-4 + valhalla-comp-stress
> 
> Thanks for your feedback,
> Christian

src/hotspot/share/ci/ciInlineKlass.cpp line 41:

> 39: 
> 40: // Are arrays containing an instance of this value class always flat?
> 41: bool ciInlineKlass::is_always_flat_in_array() const {

Used for `compute_flat_in_array()`.

src/hotspot/share/ci/ciInstanceKlass.cpp line 708:

> 706:   if (!is_exact) {
> 707:     // Not exact, check if this is a valid super for an inline klass
> 708:     GUARDED_VM_ENTRY(

Is now called from more paths over `compute_flat_in_array()`. As a result, hit assert during testing because thread was already in VM state - changed to `GUARDED_VM_ENTRY`.

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

> 51:   bool unrelated_classes = false;
> 52:   // Handle inline type arrays
> 53:   if (subk->flat_in_array() && superk->not_flat_in_array_inexact()) {

The following logic was hidden in `not_flat_in_array_inexact()` and not completely accurate. Improved now.

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

> 1066:     // 2)
> 1067:     tty->print("mt_dual meet this_dual= "); t2this        ->dump(); tty->cr();
> 1068:     tty->cr();

Since I hit the assert a few times while working on this patch, I added some more printing code for easier debugging. I guess it could also be useful in the future.

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

> 3209:       if (!Verbose) {
> 3210:         break;
> 3211:       }

Can be discussed which state we want to dump by default. It might be too verbose to always dump the exact state.

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

> 4167:          "cannot have constants with non-loaded klass");
> 4168:   assert(!klass()->maybe_flat_in_array() || flat_in_array, "Should be flat in array");
> 4169:   assert(!flat_in_array || can_be_inline_type(), "Only inline types can be flat in array");

Is now checked with `compute_flat_in_array()`.

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

> 4266:   if (flat_in_array == Uninitialized) {
> 4267:     flat_in_array = compute_flat_in_array(ik, xk);
> 4268:   }

We use the special `Uninitialized` state to mark that we should compute the flat in array property from the information we got. `Uninitialized` has no other use.

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

> 4515: 
> 4516: template<class T> TypePtr::MeetResult TypePtr::meet_instptr(PTR& ptr, const TypeInterfaces*& interfaces, const T* this_type, const T* other_type,
> 4517:                                                             ciKlass*& res_klass, bool& res_xk, bool& res_flat_in_array) {

This method now becomes much simpler without handling the meet of flat in array.

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

> 4531:     bool res_xk = false;
> 4532:     const Type* res;
> 4533:     MeetResult kind = meet_instptr(ptr, interfaces, this, tinst, res_klass, res_xk);

I removed the meet of flat in array from `meet_instptr()` into a separate `meet_flat_in_array()` to simplify the logic.

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

> 4742: const Type* TypeInstPtr::xdual() const {
> 4743:   return new TypeInstPtr(dual_ptr(), klass(), _interfaces, klass_is_exact(), const_oop(), dual_offset(),
> 4744:                          dual_flat_in_array(_flat_in_array), dual_instance_id(), dual_speculative(), dual_inline_depth());

Take proper dual for `_flat_in_array`.

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

> 4834:   }
> 4835:   return TypeOopPtr::empty();
> 4836: }

Since we have now a proper `TopFlat` element in the lattice, we can introduce an `empty()` method to check if the type is above the centerline and thus empty.

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

> 4876: }
> 4877: 
> 4878: const TypeInstPtr *TypeInstPtr::cast_to_maybe_flat_in_array() const {

Used by `flatten_alias_type()`.

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

> 5393:     case Constant:
> 5394:     case NotNull:
> 5395:     case BotPTR: { // Fall down to object klass

Required to add braces, otherwise, this does not build.

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

> 6223:   if (flat_in_array() && !klass()->is_inlinetype()) {
> 6224:     st->print(" (flat in array)");
> 6225:   }

Now done in `TypeInstKlassPtr::dump2()`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597494142
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597503433
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597511101
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597514427
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597519218
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597521681
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597525113
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597532200
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597529087
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597535200
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597539928
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597541428
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597559003
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597560905

From chagedorn at openjdk.org  Mon Dec  8 08:48:12 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 08:48:12 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property into
 proper lattice in type system to address remaining issues
Message-ID: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>

This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".

To simplify the review and to better understand what the changes are, I added code comments directly in the PR.

Here is a high-level overview of the changes:
- `FlatInArray` enum to define a lattice for `flat_in_array`:
https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
- Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
- Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
- In `flatten_alias_type()`, we flatten to "maybe flat in array".

#### Testing:
- t1-4 + valhalla-comp-stress

Thanks for your feedback,
Christian

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

Commit messages:
 - add comment
 - 8332406: [lworld] C2: Turn flat in array property into proper lattice in type system to address remaining issues

Changes: https://git.openjdk.org/valhalla/pull/1774/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1774&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332406
  Stats: 528 lines in 11 files changed: 286 ins; 145 del; 97 mod
  Patch: https://git.openjdk.org/valhalla/pull/1774.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1774/head:pull/1774

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

From chagedorn at openjdk.org  Mon Dec  8 08:55:23 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 08:55:23 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v2]
In-Reply-To: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
Message-ID: <m7FR51Ces6jeU9dHiCIfMjzfhTmd9QdFV3JBKe5dk9Y=.340f5f8b-81df-4f42-a40b-8b64bfc10c4d@github.com>

> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
> 
> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
> 
> Here is a high-level overview of the changes:
> - `FlatInArray` enum to define a lattice for `flat_in_array`:
> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
> 
> #### Testing:
> - t1-4 + valhalla-comp-stress
> 
> Thanks for your feedback,
> Christian

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

  update description

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1774/files
  - new: https://git.openjdk.org/valhalla/pull/1774/files/6b1930c7..bf5f2fe4

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

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

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

From thartmann at openjdk.org  Mon Dec  8 09:37:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 8 Dec 2025 09:37:33 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v2]
In-Reply-To: <m7FR51Ces6jeU9dHiCIfMjzfhTmd9QdFV3JBKe5dk9Y=.340f5f8b-81df-4f42-a40b-8b64bfc10c4d@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <m7FR51Ces6jeU9dHiCIfMjzfhTmd9QdFV3JBKe5dk9Y=.340f5f8b-81df-4f42-a40b-8b64bfc10c4d@github.com>
Message-ID: <EifXcUpxUtdWIh5W0Pp2kcBq9Qqt7PHJIHy5mB5rDMg=.05767b07-c2fc-4cac-a478-2f07415dad47@github.com>

On Mon, 8 Dec 2025 08:55:23 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
>> 
>> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
>> 
>> Here is a high-level overview of the changes:
>> - `FlatInArray` enum to define a lattice for `flat_in_array`:
>> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
>> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
>> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
>> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
>> 
>> #### Testing:
>> - t1-4 + valhalla-comp-stress
>> 
>> Thanks for your feedback,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update description

Very nice! I only added a few minor comments. Great, that this code is finally cleaned up.

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

> 2844: };
> 2845: 
> 2846: const char *const TypePtr::flat_in_array_msg[Uninitialized] = {

Suggestion:

const char* const TypePtr::flat_in_array_msg[Uninitialized] = {

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

> 3152:       assert(can_be_inline_type(), "only value objects can be flat in array");
> 3153:       assert(!instance_klass->is_inlinetype() || instance_klass->as_inline_klass()->is_always_flat_in_array(),
> 3154:              "a value object is only marked flat in array if it proven to be always flat in array");

Suggestion:

             "a value object is only marked flat in array if it's proven to be always flat in array");

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

> 4569:   // centerline and or-ed above it.  (N.B. Constants are always exact.)
> 4570: 
> 4571:   // Flat in Array property _flat_in_array.

Nice, that this is gone now :slightly_smiling_face:

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

> 5402:         // below the centerline when the superclass is exact. We need
> 5403:         // to do the same here.
> 5404:         //

Suggestion:

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

> 6270: 
> 6271: uint TypeInstKlassPtr::hash(void) const {
> 6272:   return klass()->hash() + TypeKlassPtr::hash() + (uint)_flat_in_array;

You might want to use `static_cast<uint>` here, similar to `TypeInstPtr::hash`.

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

> 1329:   virtual bool maybe_null() const { return meet_ptr(Null) == ptr(); }
> 1330: 
> 1331:   static FlatInArray dual_flat_in_array(FlatInArray flat_in_array) {

I think this should be a non-static method so that you can access the `_flat_in_array` field directly.

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

> 2048:   virtual bool eq(const Type *t) const;
> 2049: 
> 2050: 

Suggestion:

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1774#pullrequestreview-3550862668
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597656075
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597657401
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597669879
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597788559
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597710620
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597688028
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597783100

From chagedorn at openjdk.org  Mon Dec  8 09:45:59 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 09:45:59 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v3]
In-Reply-To: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
Message-ID: <QGG_fGcJ-bYAweB1d50veuywwUtJmiDAAYMsHt04M8c=.0b398229-15c9-4195-b668-1c7e7de459c7@github.com>

> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
> 
> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
> 
> Here is a high-level overview of the changes:
> - `FlatInArray` enum to define a lattice for `flat_in_array`:
> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
> 
> #### Testing:
> - t1-4 + valhalla-comp-stress
> 
> Thanks for your feedback,
> Christian

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

  Apply suggestions from code review
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1774/files
  - new: https://git.openjdk.org/valhalla/pull/1774/files/bf5f2fe4..5e896316

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

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

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

From chagedorn at openjdk.org  Mon Dec  8 09:57:12 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 09:57:12 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v4]
In-Reply-To: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
Message-ID: <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>

> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
> 
> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
> 
> Here is a high-level overview of the changes:
> - `FlatInArray` enum to define a lattice for `flat_in_array`:
> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
> 
> #### Testing:
> - t1-4 + valhalla-comp-stress
> 
> Thanks for your feedback,
> Christian

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

  review Tobias

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1774/files
  - new: https://git.openjdk.org/valhalla/pull/1774/files/5e896316..e9fe5628

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

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

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

From chagedorn at openjdk.org  Mon Dec  8 09:57:14 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 09:57:14 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v3]
In-Reply-To: <QGG_fGcJ-bYAweB1d50veuywwUtJmiDAAYMsHt04M8c=.0b398229-15c9-4195-b668-1c7e7de459c7@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <QGG_fGcJ-bYAweB1d50veuywwUtJmiDAAYMsHt04M8c=.0b398229-15c9-4195-b668-1c7e7de459c7@github.com>
Message-ID: <D4w3wPS_qbAYI1rlezSu5RBb3DWKtentBbX8mfqUmRY=.5b973b41-4fd8-48a2-a67b-5c471be9e502@github.com>

On Mon, 8 Dec 2025 09:45:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
>> 
>> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
>> 
>> Here is a high-level overview of the changes:
>> - `FlatInArray` enum to define a lattice for `flat_in_array`:
>> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
>> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
>> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
>> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
>> 
>> #### Testing:
>> - t1-4 + valhalla-comp-stress
>> 
>> Thanks for your feedback,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Thanks Tobias for your review! I pushed updates to address your comments.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1774#issuecomment-3626020256

From chagedorn at openjdk.org  Mon Dec  8 09:57:16 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 09:57:16 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v2]
In-Reply-To: <EifXcUpxUtdWIh5W0Pp2kcBq9Qqt7PHJIHy5mB5rDMg=.05767b07-c2fc-4cac-a478-2f07415dad47@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <m7FR51Ces6jeU9dHiCIfMjzfhTmd9QdFV3JBKe5dk9Y=.340f5f8b-81df-4f42-a40b-8b64bfc10c4d@github.com>
 <EifXcUpxUtdWIh5W0Pp2kcBq9Qqt7PHJIHy5mB5rDMg=.05767b07-c2fc-4cac-a478-2f07415dad47@github.com>
Message-ID: <uMyNfH2jhd2kAB4p0LRGVKzO_pQCT4HIriYdLg1fHoo=.918d35e3-6df3-4381-801b-fb469d606e31@github.com>

On Mon, 8 Dec 2025 09:09:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update description
>
> src/hotspot/share/opto/type.cpp line 6272:
> 
>> 6270: 
>> 6271: uint TypeInstKlassPtr::hash(void) const {
>> 6272:   return klass()->hash() + TypeKlassPtr::hash() + (uint)_flat_in_array;
> 
> You might want to use `static_cast<uint>` here, similar to `TypeInstPtr::hash`.

Right, updated!

> src/hotspot/share/opto/type.hpp line 1331:
> 
>> 1329:   virtual bool maybe_null() const { return meet_ptr(Null) == ptr(); }
>> 1330: 
>> 1331:   static FlatInArray dual_flat_in_array(FlatInArray flat_in_array) {
> 
> I think this should be a non-static method so that you can access the `_flat_in_array` field directly.

Good idea! Updated.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597884162
PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2597884125

From thartmann at openjdk.org  Mon Dec  8 10:21:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 8 Dec 2025 10:21:29 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v4]
In-Reply-To: <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
Message-ID: <0ZgYerpjegVDRiCKQnQw-RLovLsbKJtEQJwmkSC5xLc=.a58b7d26-4810-48db-847a-0259adc0dffc@github.com>

On Mon, 8 Dec 2025 09:57:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
>> 
>> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
>> 
>> Here is a high-level overview of the changes:
>> - `FlatInArray` enum to define a lattice for `flat_in_array`:
>> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
>> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
>> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
>> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
>> 
>> #### Testing:
>> - t1-4 + valhalla-comp-stress
>> 
>> Thanks for your feedback,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review Tobias

Thanks. Looks good!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1774#pullrequestreview-3551251029

From chagedorn at openjdk.org  Mon Dec  8 10:25:26 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 8 Dec 2025 10:25:26 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v4]
In-Reply-To: <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
Message-ID: <3Kry3TSzHp8FyPp72AgtHc9Z29QLqvILuCUwwnovHrY=.76330f4d-0c0f-4526-b3f7-2e9dd2bd8c38@github.com>

On Mon, 8 Dec 2025 09:57:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
>> 
>> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
>> 
>> Here is a high-level overview of the changes:
>> - `FlatInArray` enum to define a lattice for `flat_in_array`:
>> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
>> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
>> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
>> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
>> 
>> #### Testing:
>> - t1-4 + valhalla-comp-stress
>> 
>> Thanks for your feedback,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review Tobias

Thanks Tobias!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1774#issuecomment-3626144251

From thartmann at openjdk.org  Mon Dec  8 11:33:33 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 8 Dec 2025 11:33:33 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
Message-ID: <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>

On Sat, 6 Dec 2025 17:12:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
>> 
>> 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:
> 
>   Should not clone MergeMem

All tests pass now - great work! Thanks for this major effort in cleaning up the logic around arrays. This is tricky to review but I did a pass and added some comments.

src/hotspot/share/ci/ciObjArrayKlass.cpp line 201:

> 199:     ciInstanceKlass* ik = base->as_instance_klass();
> 200:     // Even though MyValue is final, [LMyValue is only exact if the array
> 201:     // is null-free due to null-free [LMyValue <: null-able [LMyValue.

There are some more occurrences of `// Even though MyValue is final, [LMyValue is only exact if the array` in the code, should those be updated as well?

src/hotspot/share/opto/compile.cpp line 1418:

> 1416:       // Bottom array (meet of int[] and byte[] for example), accesses to it will be done with
> 1417:       // Unsafe. This should alias with all arrays. For now just leave it as it is (this is
> 1418:       // incorrect!).

Is there a tracking bug for this?

src/hotspot/share/opto/compile.cpp line 1485:

> 1483:               cast_to_ptr_type(TypePtr::BotPTR)->
> 1484:               cast_to_exactness(false)->
> 1485:               with_offset(offset);

These changes are difficult to review because it's not immediately clear what changed semantically. For example, where did this line go?

src/hotspot/share/opto/compile.cpp line 1998:

> 1996:   if (_inline_type_nodes.length() == 0) {
> 1997:     // keep the graph canonical
> 1998:     igvn.optimize();

Why is this needed?

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

> 4628:         auto process_narrow_proj = [&](NarrowMemProjNode* proj) {
> 4629:           const TypePtr* adr_type = proj->adr_type();
> 4630:           const TypePtr* new_adr_type = tinst->with_offset(adr_type->offset());

Should this use `TypeAryPtr::add_field_offset_and_offset`?

Similar code also has a comment

      // In the case of a flat inline type array, each field has its
      // own slice so we need to extract the field being accessed from
      // the address computation

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

> 546:           }
> 547:           if (!init_value->is_InlineType()) {
> 548:             return nullptr;

How can this happen?

src/hotspot/share/opto/memnode.cpp line 1355:

> 1353:       Node* init_value = ld_alloc->in(AllocateNode::InitValue);
> 1354:       if (init_value != nullptr) {
> 1355:         // TODO 8350865 Scalar replacement does not work well for flat arrays.

Can you re-enable the tests in `TestArrays.java` marked with `// TODO 8350865 Scalar replacement does not work well for flat arrays` now? There are a few more places in the code marked with `// TODO 8350865 Scalar replacement ...` as well. We might just want to leave this to [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) though.

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

> 677:   TypeAryPtr::LONGS   = TypeAryPtr::make(TypePtr::BotPTR, TypeAry::make(TypeLong::LONG     ,TypeInt::POS, false, false, true, true, true), ciTypeArrayKlass::make(T_LONG),   true,  Offset::bottom);
> 678:   TypeAryPtr::FLOATS  = TypeAryPtr::make(TypePtr::BotPTR, TypeAry::make(Type::FLOAT        ,TypeInt::POS, false, false, true, true, true), ciTypeArrayKlass::make(T_FLOAT),  true,  Offset::bottom);
> 679:   TypeAryPtr::DOUBLES = TypeAryPtr::make(TypePtr::BotPTR, TypeAry::make(Type::DOUBLE       ,TypeInt::POS, false, false, true, true, true), ciTypeArrayKlass::make(T_DOUBLE), true,  Offset::bottom);

Could we use default arguments here?

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

> 6684:     k = ciObjArrayKlass::make(k->element_klass(), true);
> 6685:   } else {
> 6686:     k = ciObjArrayKlass::make(k->element_klass(), false);

You can just use `k = ciObjArrayKlass::make(k->element_klass(), refined);` here (couldn't directly suggest that change because there's an unmodified line in-between).

src/hotspot/share/prims/jvm.cpp line 493:

> 491:   } else {
> 492:     props = ArrayKlass::ArrayProperties::NULL_RESTRICTED;
> 493:   }

Suggestion:

  ArrayKlass::ArrayProperties props = ArrayKlass::ArrayProperties::NULL_RESTRICTED;
  if (vk->has_non_atomic_layout()) {
    props |= ArrayKlass::ArrayProperties::NON_ATOMIC;
  }


Maybe double-check, if my suggestion even compiles :slightly_smiling_face: 

Regarding:

> When creating a refined ObjArrayKlass, we fall back to ref array if the corresponding flat layout is not present, which means that if the element type is not a LooselyConsistentValue, ValueClass::newNullRestrictedNonAtomicArray will make a ref array. This seems counter-intuitive, it should have fallen back to a null-restricted atomic array instead.

I tend to agree but this is still debatable. @fparain Thoughts?

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

PR Review: https://git.openjdk.org/valhalla/pull/1755#pullrequestreview-3551098324
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598238554
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597949776
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597955310
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597897503
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597971076
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597911813
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597996905
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597919984
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598022672
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2597849855

From qamai at openjdk.org  Mon Dec  8 12:19:25 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 12:19:25 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
 <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
Message-ID: <w8u-QzWAoRxsXZCIT5ygiLz8hUeDxBs2LeaUuqci5hE=.a3509567-1d9c-41bf-9e01-ea8e3044def4@github.com>

On Mon, 8 Dec 2025 10:13:18 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Should not clone MergeMem
>
> src/hotspot/share/opto/compile.cpp line 1418:
> 
>> 1416:       // Bottom array (meet of int[] and byte[] for example), accesses to it will be done with
>> 1417:       // Unsafe. This should alias with all arrays. For now just leave it as it is (this is
>> 1418:       // incorrect!).
> 
> Is there a tracking bug for this?

Yes it is this one https://bugs.openjdk.org/browse/JDK-8331133

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598402483

From qamai at openjdk.org  Mon Dec  8 12:46:33 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 12:46:33 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
 <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
Message-ID: <bzuXxGjQJ-TQkNpf_dKcAALrBGqEG_RUSKJSpWbiDc8=.39f38f95-b000-4e76-b0d7-83cd17224228@github.com>

On Mon, 8 Dec 2025 09:56:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Should not clone MergeMem
>
> src/hotspot/share/opto/compile.cpp line 1998:
> 
>> 1996:   if (_inline_type_nodes.length() == 0) {
>> 1997:     // keep the graph canonical
>> 1998:     igvn.optimize();
> 
> Why is this needed?

It is because the other return path canonicalizes the graph, so it makes more sense for this path to do so, too. It is also that analyzing the memory graph in `adjust_flat_array_access_aliases` requires a canonical graph, or else we may encounter an `AddP` that has its type not yet computed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598486249

From qamai at openjdk.org  Mon Dec  8 13:19:38 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 13:19:38 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
 <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
Message-ID: <D3pAUa7ADG7U5bcI51mLwSq0oOy8Qgyc0vItYHwUbQw=.dba024b4-371a-4aca-a13e-9503d8128c9d@github.com>

On Mon, 8 Dec 2025 10:18:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Should not clone MergeMem
>
> src/hotspot/share/opto/escape.cpp line 4630:
> 
>> 4628:         auto process_narrow_proj = [&](NarrowMemProjNode* proj) {
>> 4629:           const TypePtr* adr_type = proj->adr_type();
>> 4630:           const TypePtr* new_adr_type = tinst->with_offset(adr_type->offset());
> 
> Should this use `TypeAryPtr::add_field_offset_and_offset`?
> 
> Similar code also has a comment
> 
>       // In the case of a flat inline type array, each field has its
>       // own slice so we need to extract the field being accessed from
>       // the address computation

It is equivalent, but since this is about mirroring the offset part from the old slice (without instance id) to the new slice, I think it is more trivial what is happening using `with_offset`.

> src/hotspot/share/opto/macro.cpp line 548:
> 
>> 546:           }
>> 547:           if (!init_value->is_InlineType()) {
>> 548:             return nullptr;
> 
> How can this happen?

`LibraryCallKit::inline_newArray` does not type check `init_val`, so if it is untyped (for example, the return value of `Class::new_instance`), then it will not be an `InlineTypeNode`.

> src/hotspot/share/opto/type.cpp line 679:
> 
>> 677:   TypeAryPtr::LONGS   = TypeAryPtr::make(TypePtr::BotPTR, TypeAry::make(TypeLong::LONG     ,TypeInt::POS, false, false, true, true, true), ciTypeArrayKlass::make(T_LONG),   true,  Offset::bottom);
>> 678:   TypeAryPtr::FLOATS  = TypeAryPtr::make(TypePtr::BotPTR, TypeAry::make(Type::FLOAT        ,TypeInt::POS, false, false, true, true, true), ciTypeArrayKlass::make(T_FLOAT),  true,  Offset::bottom);
>> 679:   TypeAryPtr::DOUBLES = TypeAryPtr::make(TypePtr::BotPTR, TypeAry::make(Type::DOUBLE       ,TypeInt::POS, false, false, true, true, true), ciTypeArrayKlass::make(T_DOUBLE), true,  Offset::bottom);
> 
> Could we use default arguments here?

Yes, we can, but I feel that being explicit here would be better, as this combination will only make sense as the default for primitive arrays. What do you think?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598594733
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598602175
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598609202

From qamai at openjdk.org  Mon Dec  8 13:50:30 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 13:50:30 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
 <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
Message-ID: <ZcJS3ZcX2wD4tU6yRHn-GjNGJJCp6ZZcZCVkCn8LLT0=.adbce6c5-fc04-4580-bdb3-e4cde57c3a8d@github.com>

On Mon, 8 Dec 2025 11:27:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Should not clone MergeMem
>
> src/hotspot/share/ci/ciObjArrayKlass.cpp line 201:
> 
>> 199:     ciInstanceKlass* ik = base->as_instance_klass();
>> 200:     // Even though MyValue is final, [LMyValue is only exact if the array
>> 201:     // is null-free due to null-free [LMyValue <: null-able [LMyValue.
> 
> There are some more occurrences of `// Even though MyValue is final, [LMyValue is only exact if the array` in the code, should those be updated as well?

I did not touch those places yet, so I have not updated those comments, I will clean those up in follow-up PRs.

> src/hotspot/share/opto/compile.cpp line 1485:
> 
>> 1483:               cast_to_ptr_type(TypePtr::BotPTR)->
>> 1484:               cast_to_exactness(false)->
>> 1485:               with_offset(offset);
> 
> These changes are difficult to review because it's not immediately clear what changed semantically. For example, where did this line go?

Yeah, it is pretty messy, this particular part canonicalizes the `TypeAryPtr` to `TypePtr::BotPTR`, `klass_is_exact == false`, `speculative == nullptr` if:

- `ptr()` is `NotNull`
- `klass_is_exact == true`, this includes `ptr() == Constant`, which means that it also erases `Constant` to `BotPTR`
- `speculative != nullptr`

As a result, it effectively erases `NotNull` and `Constant` to `BotPTR`, removes `speculative`, and tries casting the array to `klass_is_exact == false`. It is trivial that the refactored version does the first 2 actions, for casting the array to `klass_is_exact == false`, the new version does it for arrays of oops, primitive arrays are always `klass_is_exact`, and flat arrays is also `klass_is_exact`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598709229
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598702135

From stefank at openjdk.org  Mon Dec  8 14:23:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 8 Dec 2025 14:23:44 GMT
Subject: [lworld] RFR: 8373259: [lworld] Remove BufferedValueClosure
Message-ID: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>

BufferedValueClosure is dead code in the lworld branch. I propose that we remove it.

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

Commit messages:
 - 8373259: [lworld] Remove BufferedValueClosure

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

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

From qamai at openjdk.org  Mon Dec  8 14:25:24 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 14:25:24 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v4]
In-Reply-To: <jCTHKrg-QzhPOOcNPtgCdJpjt5RXT4TP-meR-6_plHE=.3994d6ef-4df8-4261-9998-aae60f6c2642@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <r9nYnq-nBZy-X33e9RLewoi-MGqgJ3E_vti_5gSYPlI=.f1aa6138-182b-4dd1-b14c-a7df7efb0d85@github.com>
 <jCTHKrg-QzhPOOcNPtgCdJpjt5RXT4TP-meR-6_plHE=.3994d6ef-4df8-4261-9998-aae60f6c2642@github.com>
Message-ID: <497GaTaZebo2izB-1ZPhTkjyP-1EHuMvuFkK2l1t9SQ=.236577a7-2da8-4d4a-ab3c-92625c7d099a@github.com>

On Fri, 5 Dec 2025 14:20:46 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge branch 'lworld' into AryKlassPtrfactory
>>  - Fix Parse::array_store and PhaseMacroNode::value_from_mem
>>  - whitespace
>>  - fix more issues
>>  - Merge branch 'lworld' into AryKlassPtrfactory
>>  - Fix test failures
>>  - Tighten the type system around array properties and fix related issues
>
> Thanks Quan-Anh! That fixed all issues except for the `should only visit bottom memory` problem with  `compiler/valhalla/inlinetypes/TestArrayNullMarkers.java`. Any information that I can provide to help with the investigation of that one?

@TobiHartmann Thanks a lot for your reviews, I think I have addressed your suggestions and concerns.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1755#issuecomment-3627174798

From qamai at openjdk.org  Mon Dec  8 14:25:22 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 14:25:22 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v7]
In-Reply-To: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
Message-ID: <SfcINvWme5_u3Uiizn6FF4i0jdleWYtdm8VBXfN9lKU=.3affd2a9-30de-40ac-a31b-424c1d981f19@github.com>

> Hi,
> 
> This PR fixes various issues with `TypeAryPtr` and `TypeAryKlassPtr`. It starts with me trying to tighten the properties (`flat`, `null_free`, etc) of these classes, then fixing all the revealed issues until there are no crashes or wrong results left.
> 
> 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:

  reviews

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1755/files
  - new: https://git.openjdk.org/valhalla/pull/1755/files/2df30c7c..39dba467

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

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

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

From qamai at openjdk.org  Mon Dec  8 14:25:26 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 8 Dec 2025 14:25:26 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v7]
In-Reply-To: <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <pDniX7RdZ3nr-qP7S_f_Z152ZI-JDDyRbKmXq70Ckjw=.bfd2d25e-a547-4270-b7fe-89c846e2af0d@github.com>
 <p-avVM7ynmszUj4aCiog2feCrmpltXegL9bTO_eVGR8=.54b7dfa6-1e54-4bba-81a4-0af07c782d01@github.com>
Message-ID: <QRbiq0lIB1BywCwWn-i0CbPx0ri-XBpGOYaUMZ7M9ao=.53c5945a-4c73-4c83-8b15-8b8d2074bee7@github.com>

On Mon, 8 Dec 2025 10:24:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> src/hotspot/share/opto/memnode.cpp line 1355:
> 
>> 1353:       Node* init_value = ld_alloc->in(AllocateNode::InitValue);
>> 1354:       if (init_value != nullptr) {
>> 1355:         // TODO 8350865 Scalar replacement does not work well for flat arrays.
> 
> Can you re-enable the tests in `TestArrays.java` marked with `// TODO 8350865 Scalar replacement does not work well for flat arrays` now? There are a few more places in the code marked with `// TODO 8350865 Scalar replacement ...` as well. We might just want to leave this to [JDK-8350865](https://bugs.openjdk.org/browse/JDK-8350865) though.

Simply re-enabling the tests results in failures of scenario 2 due to the returned oop being kept alive. I will need to look into this a little further.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2598828728

From fparain at openjdk.org  Mon Dec  8 14:32:39 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Dec 2025 14:32:39 GMT
Subject: [lworld] RFR: 8373259: [lworld] Remove BufferedValueClosure
In-Reply-To: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
References: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
Message-ID: <hdslJ6XdaZ5zadisqdkCAwkJgs8ycjO5AGwd72UXa1M=.543436ea-fa2d-4727-887e-32ae375afa2c@github.com>

On Mon, 8 Dec 2025 14:17:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> BufferedValueClosure is dead code in the lworld branch. I propose that we remove it.

Looks good to me.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1776#pullrequestreview-3552365447

From david.simms at oracle.com  Mon Dec  8 14:50:36 2025
From: david.simms at oracle.com (David Simms)
Date: Mon, 8 Dec 2025 15:50:36 +0100
Subject: =?UTF-8?Q?Result=3A_CFV=3A_New_Valhalla_Committer=3A_Paul_H=C3=BCbn?=
 =?UTF-8?Q?er?=
Message-ID: <b3009992-d898-426d-89a4-0f75618788f1@oracle.com>

|Voting for *Paul H?bner* [1] is now closed. Yes: *9* Veto: 0 Abstain: 
*0* According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. *David Simms* [1] 
https://mail.openjdk.org/pipermail/valhalla-dev/2025-November/016086.html|

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

From david.simms at oracle.com  Mon Dec  8 15:00:17 2025
From: david.simms at oracle.com (David Simms)
Date: Mon, 8 Dec 2025 16:00:17 +0100
Subject: =?UTF-8?Q?CFV=3A_New_Valhalla_Committer=3A_Paul_H=C3=BCbner_=28corr?=
 =?UTF-8?Q?ection=29?=
Message-ID: <9b285548-18af-49f0-ad74-87851e35a2fb@oracle.com>

|Voting for *Paul H?bner* [1] is now closed. Yes: *9* Veto: 0 Abstain: 
*0* According to the Bylaws definition of Lazy Consensus, this is 
sufficient to approve the nomination. *David Simms* [1] 
https://mail.openjdk.org/pipermail/valhalla-dev/2025-November/016324.html 
/(Resent; reference [1] was incorrect)|


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

From fparain at openjdk.org  Mon Dec  8 15:04:49 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Dec 2025 15:04:49 GMT
Subject: [lworld] RFR: 8370714: [lworld] Reimplement
 System.identityHashCode for Value Objects
In-Reply-To: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>
References: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>
Message-ID: <hS7CUPpRg7ZvVKDnhRa44WKkH045mTLfQ_0FOR0VaHk=.ffac9937-01bb-45fe-8dd8-eb62a31c8903@github.com>

On Fri, 5 Dec 2025 21:24:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The alternate hashcode compution is enabled when the alternate subsitutability method is enabled with: `-XX:+UseAltSubstitutabilityMethod`. 
> The IdentityHashCode is computed using the map of field offsets and sizes from Unsafe. 
> The basis of hashCode is the the hashCode of the object's class mixing in the values from the memory where the fields are placed and the hashCode of each reference.
> 
> The changes to Hotspot invoke the original or the alternate Java method based on the VM `UseAltSubstitutabilityMethod` command line flag.

LGTM

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1773#pullrequestreview-3552517701

From heidinga at openjdk.org  Mon Dec  8 15:06:54 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 8 Dec 2025 15:06:54 GMT
Subject: [lworld] RFR: 8373259: [lworld] Remove BufferedValueClosure
In-Reply-To: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
References: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
Message-ID: <VElwoxKJAeEZ8sE9vvqCMMEzLSjBRxj_tAbUl6yusbE=.2dacd965-26e6-45be-b88d-207730c01d38@github.com>

On Mon, 8 Dec 2025 14:17:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> BufferedValueClosure is dead code in the lworld branch. I propose that we remove it.

looks good

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1776#pullrequestreview-3552528438

From rriggs at openjdk.org  Mon Dec  8 15:20:12 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 Dec 2025 15:20:12 GMT
Subject: [lworld] Integrated: 8370714: [lworld] Reimplement
 System.identityHashCode for Value Objects
In-Reply-To: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>
References: <QPwuIcu7JPUPU4Qr1DMbCYhGAysowuAN1_OrRLutEtA=.0e3e5e5e-c37a-462b-a58c-09fac6cad0e9@github.com>
Message-ID: <YsSVRNfF_ZDKXVe3Ym_XUmdfq6YHtjKHrLauofv5lR4=.cade9288-8dbb-40f0-ae74-0d4894888fe1@github.com>

On Fri, 5 Dec 2025 21:24:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The alternate hashcode compution is enabled when the alternate subsitutability method is enabled with: `-XX:+UseAltSubstitutabilityMethod`. 
> The IdentityHashCode is computed using the map of field offsets and sizes from Unsafe. 
> The basis of hashCode is the the hashCode of the object's class mixing in the values from the memory where the fields are placed and the hashCode of each reference.
> 
> The changes to Hotspot invoke the original or the alternate Java method based on the VM `UseAltSubstitutabilityMethod` command line flag.

This pull request has now been integrated.

Changeset: 9f73e019
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9f73e0195931e6840b8cbc442f0a6c0e81bbe8a2
Stats:     85 lines in 7 files changed: 71 ins; 0 del; 14 mod

8370714: [lworld] Reimplement System.identityHashCode for Value Objects

Reviewed-by: liach, fparain

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

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

From liach at openjdk.org  Mon Dec  8 17:02:15 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 8 Dec 2025 17:02:15 GMT
Subject: [lworld] RFR: 8368274: [lworld] Unsafe.compareAndExchangeFlatValue()
 wrongly assumes padding bytes are the same for identical value objects
Message-ID: <JGvTSpQP6kkT6WmA-V08z1sfWcsrgiGI74Fqi7kRkdw=.bcf40ff9-0274-4f26-852d-44b3b144cf52@github.com>

Use the raw value get as witness, because the flat value get may ignore garbage value and cause infinite loop as a result. Waiting for a test case.

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

Commit messages:
 - A test
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into fix/unsafe-flat-cas
 - Attempt to fix garbage cas

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

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

From fparain at openjdk.org  Mon Dec  8 19:03:05 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Dec 2025 19:03:05 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v4]
In-Reply-To: <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
Message-ID: <PqppRUNGXvYg2u2teXCH32oS4k_Y5BTtvdb29IfEwoI=.5df00741-f322-4ef7-af1c-8bcf4ec2c1a3@github.com>

On Mon, 8 Dec 2025 09:57:12 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
>> 
>> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
>> 
>> Here is a high-level overview of the changes:
>> - `FlatInArray` enum to define a lattice for `flat_in_array`:
>> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
>> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
>> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
>> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
>> 
>> #### Testing:
>> - t1-4 + valhalla-comp-stress
>> 
>> Thanks for your feedback,
>> Christian
>
> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review Tobias

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

> 308:   }
> 309: 
> 310:   // An instance is always flat in an array if we have all layouts.

This is true in the current implementation, but this could change in the future if the flattening policies are modified or new APIs to create reference arrays are added.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2599780041

From fparain at openjdk.org  Mon Dec  8 20:28:34 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 8 Dec 2025 20:28:34 GMT
Subject: [lworld] RFR: 8373284: [lworld] More tests could be rewritten with
 LayoutKindHelper
Message-ID: <pCvwrvqIID5Pd9RPKoqepiIVtAnsRZGfVQmzZN_By5k=.49107e02-04f7-44ba-964a-afd0a89aee7a@github.com>

More tests rewritten with LayoutKindHelper methods.

Tested with Mach5 tier1-3

Fred

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

Commit messages:
 - More tests rewritten with LayoutKindHelper

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

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

From vromero at openjdk.org  Tue Dec  9 02:44:32 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 9 Dec 2025 02:44:32 GMT
Subject: [lworld] RFR: 8370635: [lworld] TypeName.super.[TypeArguments]
 Identifier cannot occur in prologue
Message-ID: <ISVu0y7wlBVEChq83o1rjIve4McK94c27Xlil_hWZjs=.3d73b3e9-7b6b-49db-b93b-262db7cce760@github.com>

Code like:

class Test {
    static boolean testMethod() { return true; }
    Test() {}
    Test(int a) {
        Test.this.testMethod();
        this();
    }
}


or:


class Super {
    static <T> void m() {}
}

class Test extends Super {
    Test() {
        Test.super.<String>m();
        super();
    }
}


shouldn't be allowed in prologue. Javac was not checking static method invocations in the prologue correctly. This fix should solve this issue,

TIA

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

Commit messages:
 - updates
 - Merge branch 'lworld' into JDK-8370635
 - 8370635: [lworld] TypeName.super.[TypeArguments] Identifier cannot occur in prologue

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

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

From chagedorn at openjdk.org  Tue Dec  9 07:30:09 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 07:30:09 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v5]
In-Reply-To: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
Message-ID: <H7afHRbfmpB4-jcnkTHwAqUQDXH6ff3egAKFuSxyy6o=.3912c6f3-e1fb-41be-9a8a-2785439af263@github.com>

> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
> 
> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
> 
> Here is a high-level overview of the changes:
> - `FlatInArray` enum to define a lattice for `flat_in_array`:
> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
> 
> #### Testing:
> - t1-4 + valhalla-comp-stress
> 
> Thanks for your feedback,
> Christian

Christian Hagedorn 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 seven additional commits since the last revision:

 - review Frederic
 - Merge branch 'lworld' into flat-in-array-rework
 - review Tobias
 - Apply suggestions from code review
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - update description
 - add comment
 - 8332406: [lworld] C2: Turn flat in array property into proper lattice in type system to address remaining issues

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1774/files
  - new: https://git.openjdk.org/valhalla/pull/1774/files/e9fe5628..e8faec1f

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

  Stats: 169917 lines in 995 files changed: 114545 ins; 26925 del; 28447 mod
  Patch: https://git.openjdk.org/valhalla/pull/1774.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1774/head:pull/1774

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

From thartmann at openjdk.org  Tue Dec  9 07:30:10 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 9 Dec 2025 07:30:10 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v5]
In-Reply-To: <H7afHRbfmpB4-jcnkTHwAqUQDXH6ff3egAKFuSxyy6o=.3912c6f3-e1fb-41be-9a8a-2785439af263@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <H7afHRbfmpB4-jcnkTHwAqUQDXH6ff3egAKFuSxyy6o=.3912c6f3-e1fb-41be-9a8a-2785439af263@github.com>
Message-ID: <TGPuIHwMvrTxi8yzl6RAOhk-dWWmzMRzda0S2KHELcg=.9cdc0a44-e8f4-4455-a9a4-7579d3cae840@github.com>

On Tue, 9 Dec 2025 07:27:08 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
>> 
>> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
>> 
>> Here is a high-level overview of the changes:
>> - `FlatInArray` enum to define a lattice for `flat_in_array`:
>> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
>> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
>> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
>> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
>> 
>> #### Testing:
>> - t1-4 + valhalla-comp-stress
>> 
>> Thanks for your feedback,
>> Christian
>
> Christian Hagedorn 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 seven additional commits since the last revision:
> 
>  - review Frederic
>  - Merge branch 'lworld' into flat-in-array-rework
>  - review Tobias
>  - Apply suggestions from code review
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - update description
>  - add comment
>  - 8332406: [lworld] C2: Turn flat in array property into proper lattice in type system to address remaining issues

Marked as reviewed by thartmann (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1774#pullrequestreview-3555862194

From chagedorn at openjdk.org  Tue Dec  9 07:30:13 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 07:30:13 GMT
Subject: [lworld] RFR: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues [v4]
In-Reply-To: <PqppRUNGXvYg2u2teXCH32oS4k_Y5BTtvdb29IfEwoI=.5df00741-f322-4ef7-af1c-8bcf4ec2c1a3@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
 <lI_GhezOdol2L6gdx-KIyjmmUZ7a891zFk-JClW3sIs=.59a53dfd-14ac-4c70-8b0a-fe764e88951d@github.com>
 <PqppRUNGXvYg2u2teXCH32oS4k_Y5BTtvdb29IfEwoI=.5df00741-f322-4ef7-af1c-8bcf4ec2c1a3@github.com>
Message-ID: <0no5voAXqUh0wAj53g6OYvVW_099d5uC01FwWJp3ZwI=.474c637d-c2ad-41e9-8d02-b5128dbb2c92@github.com>

On Mon, 8 Dec 2025 18:59:08 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review Tobias
>
> src/hotspot/share/oops/inlineKlass.cpp line 310:
> 
>> 308:   }
>> 309: 
>> 310:   // An instance is always flat in an array if we have all layouts.
> 
> This is true in the current implementation, but this could change in the future if the flattening policies are modified or new APIs to create reference arrays are added.

Thanks Frederic for the hint. I updated the comment to reflect that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1774#discussion_r2601396784

From chagedorn at openjdk.org  Tue Dec  9 07:30:14 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 9 Dec 2025 07:30:14 GMT
Subject: [lworld] Integrated: 8332406: [lworld] C2: Turn flat in array property
 into proper lattice in type system to address remaining issues
In-Reply-To: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
References: <Ajhl2sgfgRrWpfHlY9-DmJuy2-qq5n2pnXYmsj7gNLY=.ca865db2-9629-4da5-8893-d9084e643e54@github.com>
Message-ID: <eBbFBF3DCnBv02a7VhXKLPDMNgrSDb1WQFQkoS6eYg8=.6b7c828c-3e42-4d52-bc39-cc8cf80b8700@github.com>

On Mon, 8 Dec 2025 08:13:34 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch turns the boolean flag `_flat_in_array` into a new `FlatInArray` enum to properly define a (Boolean) lattice. This mainly allows us to cleanly represent "maybe flat in array" and "not flat in array". The dedicated top element is the dual of "maybe flat in array".
> 
> To simplify the review and to better understand what the changes are, I added code comments directly in the PR.
> 
> Here is a high-level overview of the changes:
> - `FlatInArray` enum to define a lattice for `flat_in_array`:
> https://github.com/openjdk/valhalla/blob/6b1930c7b9a359223a998d0086a1326a9d7905e7/src/hotspot/share/opto/type.hpp#L1182-L1199
> - Updated `meet` operations accordingly. Needed to be careful when doing the meet above the centerline.
> - Added single `compute_flat_in_array()` method to properly compute the `flat_in_array` property from the information we have when we need to set flat in array newly (this was no properly done before).
> - In `flatten_alias_type()`, we flatten to "maybe flat in array".
> 
> #### Testing:
> - t1-4 + valhalla-comp-stress
> 
> Thanks for your feedback,
> Christian

This pull request has now been integrated.

Changeset: a826fbd0
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a826fbd06ab41c483f59c06fed1757fae8c3a183
Stats:     530 lines in 11 files changed: 288 ins; 141 del; 101 mod

8332406: [lworld] C2: Turn flat in array property into proper lattice in type system to address remaining issues

Reviewed-by: thartmann

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

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

From stefank at openjdk.org  Tue Dec  9 10:39:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 10:39:30 GMT
Subject: [lworld] RFR: 8373259: [lworld] Remove BufferedValueClosure
In-Reply-To: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
References: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
Message-ID: <nJrUz7Sfd9msihNuHZcpYxluPjxs5DLElgpotHaG5y4=.1cdaca88-c7e5-4b4d-bc4a-d251cec350e1@github.com>

On Mon, 8 Dec 2025 14:17:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> BufferedValueClosure is dead code in the lworld branch. I propose that we remove it.

Thanks for reviewing! I guess this will need to be sponsored to get in.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1776#issuecomment-3631511678

From duke at openjdk.org  Tue Dec  9 10:39:30 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Dec 2025 10:39:30 GMT
Subject: [lworld] RFR: 8373259: [lworld] Remove BufferedValueClosure
In-Reply-To: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
References: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
Message-ID: <DX-DLtguz_f90GYSUr-Bkf7K_paoIq1AwSC_VJCcHDc=.fa8989e4-87fb-4c7b-b037-63e6ecfbd5a8@github.com>

On Mon, 8 Dec 2025 14:17:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> BufferedValueClosure is dead code in the lworld branch. I propose that we remove it.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1776#issuecomment-3631518110

From stefank at openjdk.org  Tue Dec  9 12:19:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 12:19:25 GMT
Subject: [lworld] Integrated: 8373259: [lworld] Remove BufferedValueClosure
In-Reply-To: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
References: <8NfeW_gZYmT1TUHD0H84NjKnqjCN2Hh5mJe-fogAHX8=.da1a969c-7dc0-42fb-a0d6-28bbfe45b242@github.com>
Message-ID: <N0nsnQ0vms9L2xSydkqo48Rpoy58vJ8mkz2ykQE5KBM=.bfc084ff-1e75-422d-a77c-4e39293720cf@github.com>

On Mon, 8 Dec 2025 14:17:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> BufferedValueClosure is dead code in the lworld branch. I propose that we remove it.

This pull request has now been integrated.

Changeset: cfd3a727
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cfd3a727c8d55dfcc26f247448191605b6574c31
Stats:     26 lines in 3 files changed: 0 ins; 24 del; 2 mod

8373259: [lworld] Remove BufferedValueClosure

Reviewed-by: fparain, heidinga

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

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

From stefank at openjdk.org  Tue Dec  9 12:28:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 12:28:05 GMT
Subject: [lworld] RFR: 8373346: [lworld] Link error on x64 with minimal build
Message-ID: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>

Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

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

Commit messages:
 - Fix minimal x86

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

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

From stefank at openjdk.org  Tue Dec  9 12:36:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 12:36:11 GMT
Subject: [lworld] RFR: 8373347: [lworld] Minor cleanups in the memory directory
Message-ID: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>

There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

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

Commit messages:
 - 8373347: [lworld] Minor cleanups in the memory directory

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

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

From phubner at openjdk.org  Tue Dec  9 12:41:40 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 9 Dec 2025 12:41:40 GMT
Subject: [lworld] RFR: 8373347: [lworld] Minor cleanups in the memory
 directory
In-Reply-To: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
References: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
Message-ID: <rzV31fVvA1N7_mT_p_HxfcgUXDkp7iNkWtZJReNasxY=.0c451aed-d41a-4557-bac7-f63feef35ef2@github.com>

On Tue, 9 Dec 2025 12:29:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

LGTM, although maybe someone knows the historic reason of why we had `do_oop_no_buffering` to begin with.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1781#pullrequestreview-3557201046

From phubner at openjdk.org  Tue Dec  9 13:04:29 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 9 Dec 2025 13:04:29 GMT
Subject: [lworld] RFR: 8373346: [lworld] Link error on x64 with minimal
 build
In-Reply-To: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
References: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
Message-ID: <U4PloHXaP7ngmOmjOn2jkT00fVz_KS4V0hCFL1V-LWo=.8e9b7f95-a47f-4058-9959-cec259ac1fa0@github.com>

On Tue, 9 Dec 2025 12:22:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

Marked as reviewed by phubner (Author).

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

PR Review: https://git.openjdk.org/valhalla/pull/1780#pullrequestreview-3557309972

From heidinga at openjdk.org  Tue Dec  9 14:02:49 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 9 Dec 2025 14:02:49 GMT
Subject: [lworld] RFR: 8373346: [lworld] Link error on x64 with minimal
 build
In-Reply-To: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
References: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
Message-ID: <H67MyKd9EGm5SVxFnxpvDU-OuxaPM15QuEoQdzSFP8s=.cfbdb785-fee7-49aa-a700-ae949abb0d1c@github.com>

On Tue, 9 Dec 2025 12:22:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

looks good

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1780#pullrequestreview-3557616157

From fparain at openjdk.org  Tue Dec  9 14:27:39 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 9 Dec 2025 14:27:39 GMT
Subject: [lworld] RFR: 8373346: [lworld] Link error on x64 with minimal
 build
In-Reply-To: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
References: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
Message-ID: <OT7Vs4tCln9wkbtniAwHVU2pNx9J0L4vKE7ULZTQ9w0=.02583db8-15bd-410b-bd55-b8a0ee1560b1@github.com>

On Tue, 9 Dec 2025 12:22:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1780#pullrequestreview-3557734360

From fparain at openjdk.org  Tue Dec  9 15:34:03 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 9 Dec 2025 15:34:03 GMT
Subject: [lworld] RFR: 8373347: [lworld] Minor cleanups in the memory
 directory
In-Reply-To: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
References: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
Message-ID: <bISbnDcnoZkz1MMMqDheljoPW2mgsxjvBkXnEyfK094=.914b9509-e962-4ab3-bdbf-6e52b90e28df@github.com>

On Tue, 9 Dec 2025 12:29:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1781#pullrequestreview-3558088887

From fparain at openjdk.org  Tue Dec  9 15:41:08 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 9 Dec 2025 15:41:08 GMT
Subject: [lworld] RFR: 8373347: [lworld] Minor cleanups in the memory
 directory
In-Reply-To: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
References: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
Message-ID: <LU7M_Gk-Zg9bse0TBru3TGQYvlCKP3X4Txo5RBmOV_c=.5cfb9b7a-4cbc-4494-9a86-9e5fe00b25cc@github.com>

On Tue, 9 Dec 2025 12:29:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

It is a remain of an experiment to use a small thread-local area to store buffered values, which are often short lived, with a kind of automatic reclamation based on frame exits (I'm simplifying here). The idea was to avoid filling the Java heap with those buffered values. It worked but performance was bad. Browsing interpreter frames to find which values in this thread-local area were still alive was expensive, and the ratio cost/amount_of_memory_freed was not good. At the end, the Java heap GC was more efficient to handle those short lived buffered values, especially with generational GCs.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1781#issuecomment-3632909644

From liach at openjdk.org  Tue Dec  9 17:17:10 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 Dec 2025 17:17:10 GMT
Subject: [lworld] RFR: 8370635: [lworld] TypeName.super.[TypeArguments]
 Identifier cannot occur in prologue
In-Reply-To: <ISVu0y7wlBVEChq83o1rjIve4McK94c27Xlil_hWZjs=.3d73b3e9-7b6b-49db-b93b-262db7cce760@github.com>
References: <ISVu0y7wlBVEChq83o1rjIve4McK94c27Xlil_hWZjs=.3d73b3e9-7b6b-49db-b93b-262db7cce760@github.com>
Message-ID: <GCWKq6othcpxWjeU7Vh4a87Im2b9WW-89bwbJ1JgfJ0=.1ca6cebc-6ebd-4308-ba7c-c15511275f25@github.com>

On Tue, 9 Dec 2025 02:38:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Code like:
> 
> class Test {
>     static boolean testMethod() { return true; }
>     Test() {}
>     Test(int a) {
>         Test.this.testMethod();
>         this();
>     }
> }
> 
> 
> or:
> 
> 
> class Super {
>     static <T> void m() {}
> }
> 
> class Test extends Super {
>     Test() {
>         Test.super.<String>m();
>         super();
>     }
> }
> 
> 
> shouldn't be allowed in prologue. Javac was not checking static method invocations in the prologue correctly. This fix should solve this issue,
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1575:

> 1573:                     sym.isMemberOf(env.enclClass.sym, types) &&
> 1574:                     ((sym.flags() & STATIC) == 0 ||
> 1575:                     (sym.kind == MTH && tree instanceof JCFieldAccess))) {

Is there a reason we only restrict MTH? We can write code like:

class A { static int a = 5; }
class B extends A { B() { IO.println(B.super.a); } }

Wonder if we should block `B.super.a` style stuff in early construction.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1779#discussion_r2603567019

From stefank at openjdk.org  Tue Dec  9 19:25:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 19:25:20 GMT
Subject: [lworld] RFR: 8373346: [lworld] Linking error on x64 with minimal
 build
In-Reply-To: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
References: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
Message-ID: <g1Qr0TzQbHdZ5sWhWTIBfxoDBNn7IpKcPbnnrqPOHw0=.96850d54-c574-429c-b3f5-41d24418835e@github.com>

On Tue, 9 Dec 2025 12:22:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

Thanks for the reviews. This passed tier1 testing.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1780#issuecomment-3633905660

From stefank at openjdk.org  Tue Dec  9 19:25:22 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 19:25:22 GMT
Subject: [lworld] RFR: 8373347: [lworld] Minor cleanups in the memory
 directory
In-Reply-To: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
References: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
Message-ID: <WdoZL-XGTzohSqNp2brzNYhH1f4mKFRzQpCb6kFihBc=.374639c0-d316-403b-b37e-87724d39816b@github.com>

On Tue, 9 Dec 2025 12:29:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

Thanks for the reviews. This passed tier1 testing.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1781#issuecomment-3633905184

From duke at openjdk.org  Tue Dec  9 19:25:22 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Dec 2025 19:25:22 GMT
Subject: [lworld] RFR: 8373347: [lworld] Minor cleanups in the memory
 directory
In-Reply-To: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
References: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
Message-ID: <njnLQSRlM-pll21GKFNgKVFR5OkrN_VS1yNuT9X0oVg=.2efe2252-1ed7-4ac8-b425-b2c5ba6e22d6@github.com>

On Tue, 9 Dec 2025 12:29:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

@stefank 
Your change (at version 1fb37c3c64c33ac46721bcb83dcb05bef196dbf0) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1781#issuecomment-3633908053

From duke at openjdk.org  Tue Dec  9 19:28:20 2025
From: duke at openjdk.org (duke)
Date: Tue, 9 Dec 2025 19:28:20 GMT
Subject: [lworld] RFR: 8373346: [lworld] Linking error on x64 with minimal
 build
In-Reply-To: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
References: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
Message-ID: <QnGbNNtBNN-lpQnD0uN0joaubW5L-DSR5iQuc0hi9mU=.3279d752-41e0-402d-92e3-ff1530a7a919@github.com>

On Tue, 9 Dec 2025 12:22:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

@stefank 
Your change (at version 35ca87305d8053d11cb6a38966b4ac8a187fb901) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1780#issuecomment-3633915975

From stefank at openjdk.org  Tue Dec  9 20:16:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 20:16:05 GMT
Subject: [lworld] Integrated: 8373347: [lworld] Minor cleanups in the memory
 directory
In-Reply-To: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
References: <eRFurA1hkTSZD8Ke1xQZdYLqzoTEA9sXqxTTY8bApxo=.35f5d936-db0e-4c32-9fa2-6c7c05460dfe@github.com>
Message-ID: <1t2OLMFWBm0uLMRjyY54v7ILaE6BAVSwQ_uOrdyO3s0=.add9c663-3814-4824-ac94-986692932bb8@github.com>

On Tue, 9 Dec 2025 12:29:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There are a few left-over blank line changes, redundant includes, and unused code in the memory/ directory. I suggest that we clean those out to make it nicer to review the patch.

This pull request has now been integrated.

Changeset: 6e156743
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6e156743392d1df7d9656028a0bf7b4de93492d5
Stats:     9 lines in 6 files changed: 1 ins; 7 del; 1 mod

8373347: [lworld] Minor cleanups in the memory directory

Reviewed-by: phubner, fparain

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

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

From stefank at openjdk.org  Tue Dec  9 20:16:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 9 Dec 2025 20:16:09 GMT
Subject: [lworld] Integrated: 8373346: [lworld] Linking error on x64 with
 minimal build
In-Reply-To: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
References: <GD5hwBWwdYaKz5euaWRKrDJiIh3EBToZ_FyLovVfYnY=.153d89b4-be85-4815-b7dd-f26ee1964924@github.com>
Message-ID: <2VWbmckODZ8VG17j2a2SiPEKE0fJgWqZmnmZQ-qDlx8=.d8459ec4-b1c0-41e6-9add-3b150de7bd4f@github.com>

On Tue, 9 Dec 2025 12:22:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Minimal builds on x86 fail because some new functions have been defined inside a COMPILER2_OR_JVMCI block. I've moved the code so that the three `clear_mem` functions are kept together and alone in their COMPILER2_OR_JVMCI block.

This pull request has now been integrated.

Changeset: 30ef92b2
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/30ef92b23a8cde9306e36c089c09ec669d3c4d20
Stats:     142 lines in 1 file changed: 71 ins; 71 del; 0 mod

8373346: [lworld] Linking error on x64 with minimal build

Reviewed-by: phubner, heidinga, fparain

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

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

From mcimadamore at openjdk.org  Tue Dec  9 22:31:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 Dec 2025 22:31:51 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <YuqiAa8y2jzTeP9Rringmcsz6mhOxJm4N6giyTAIpeI=.6c4c42f9-ac9f-49d9-87cb-79652f171439@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 819:

> 817: 
> 818:     MULTIRELEASE("--multi-release", "opt.arg.multi-release", "opt.multi-release", HIDDEN, FILEMANAGER),
> 819:     PREVIEWMODE("--preview-mode", "opt.arg.preview-mode", "opt.preview-mode", HIDDEN, FILEMANAGER),

I'm not 100% sure as to why we're adding a new preview option here -- javac already has `--enable-preview` -- what is the new option for? Seems to be only used by the file manager. Can't the file manager use `--enable-preview` ? @david-beaumont  or @lahodaj  please clarify

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2604579597

From dfenacci at openjdk.org  Wed Dec 10 08:31:10 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 10 Dec 2025 08:31:10 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph
Message-ID: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>

# Issue
A few test failed intermittently with -Xcomp on Mac due to an unschedulable graph in C2:
- valhalla/valuetypes/WeakReferenceTest.java
- valhalla/valuetypes/ProxyTest.java
- valhalla/valuetypes/ObjectNewInstance.java
- valhalla/valuetypes/ObjectMethodsViaCondy.java

# Causes

The origin of the issue seems to be coming from strength reduction (`process_late_inline_calls_no_inline`) where we replace virtual and MH calls with direct calls. 
https://github.com/dafedafe/valhalla/blob/75e2dd95df5d847d7d6e35a23016d22705681cf4/src/hotspot/share/opto/compile.cpp#L3072
If the return type of the methods are not loaded, we add a call to runtime's `store_inline_type_fields_to_buf` right after the actual method call, to save the scalarized return into a oop. This happens first for the caller at parse time and then for the callee when strength-reducing the virtual call to a direct one. The return projections of the inline fields of the call are added to `store_inline_type_fields_to_buf` and its oop projection is then added as input to the other `store_inline_type_fields_to_buf` which fundamentally leaves the graph around it in an awkward state.

If this happens in combination with loop unswitching it can lead to a graph not being schedulable, which is what happens in the failure of this issue, where we have:
* a virtual call with a following `store_inline_type_fields_to_buf` (1) in a loop.
* the loop undergoes unswitching, which creates 2 copies of the body (including a copy of the virtual call). All outputs of the new virtual call are phi-d with the one of the other path as input of the `store_inline_type_fields_to_buf`.
* the new copy of the virtual call is later replaced with a direct call: the creation of the new direct call adds a `store_inline_type_fields_to_buf` (2) right after the direct call. All the inline type return values of the call being inlined are removed, so the phis now only have one input and are removed by a later GVN pass.
<img width="600" alt="Screenshot 2025-11-26 at 10 33 51" src="https://github.com/user-attachments/assets/35e947c2-350e-414f-9d44-72559d480a88" />

* this creates an issue later during GCM since the `store_inline_type_fields_to_buf` (1) call is logically not dominated by any of the 2 sides of the unswitched loop and lands in a separate dominance path of the arguments whose phis have been removed (which are still dominated by the original virtual call).

# Solution

The issue happens only when strength-reducing to a direct call and the return type is not loaded. So, there seems to be 2 conceivable fixes: either we avoid strength-reduction if the type is not loaded or we avoid creating the second `store_inline_type_fields_to_buf` and rewire the output projections of the strength-reduced call to the output of the projections of the original virtual call.
By choosing the first solution we potentially skip a useful optimization (in particular if the return value is always null, which  won't trigger the deoptimization). So, the rewiring solution seems to be the best option in this case.

# Testing
* repeated testing with failing tests (same conditions)
* replay of failing compilations
* Tier 1-3

Unfortunately creating a regression test that would consistently trigger the specific issue with unloaded return type and strength-reduction to direct call has proven to be unviable.

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

Commit messages:
 - JDK-8369045: remove new line
 - Revert "JDK-8369045: add bool for rt_loaded"
 - JDK-8369045: add comment
 - JDK-8369045: add bool for rt_loaded
 - JDK-8369045:  replace result projections instead of no strength reduction
 - JDK-8369045: [lworld] valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph

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

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

From bmaillard at openjdk.org  Wed Dec 10 09:04:58 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 10 Dec 2025 09:04:58 GMT
Subject: [lworld] RFR: 8367623: [lworld] C2: Ideal Optimization on
 InlineTypeNode should not be carried out after Macro Expansion
In-Reply-To: <LJnsWauABAI_YzJNXzMVFAbXElf2cwZjEGWW4hCikgY=.fbaa0a7a-386e-47d3-9ec3-619034f4d70f@github.com>
References: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>
 <LJnsWauABAI_YzJNXzMVFAbXElf2cwZjEGWW4hCikgY=.fbaa0a7a-386e-47d3-9ec3-619034f4d70f@github.com>
Message-ID: <mN232SjqKPLRDzYc7iM2t8sNDzYf_aAP27wc1_qR6Zc=.e83193d1-a92e-4467-a1c6-4cad65d584e0@github.com>

On Wed, 19 Nov 2025 12:54:57 GMT, Quan Anh Mai <qamai 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)
>> - [x] 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.

Thank you for your review @merykitty. Regarding your comment, I filed [JDK-8373397](https://bugs.openjdk.org/browse/JDK-8373397).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1742#issuecomment-3636053503

From duke at openjdk.org  Wed Dec 10 09:08:03 2025
From: duke at openjdk.org (duke)
Date: Wed, 10 Dec 2025 09:08:03 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: <NXA7ItJvRSLSYDDnGE4e5RpmGwYct0hiY8V_j_rjKX4=.619ba447-ddfa-440f-b7df-0f293b1da968@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)
> - [x] tier1-4, plus some internal testing

@benoitmaillard 
Your change (at version 43b3674317f344ddd301c7623f657b2eaf05f16b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1742#issuecomment-3636062867

From bmaillard at openjdk.org  Wed Dec 10 09:51:22 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Wed, 10 Dec 2025 09:51:22 GMT
Subject: [lworld] RFR: 8367623: [lworld] C2: Ideal Optimization on
 InlineTypeNode should not be carried out after Macro Expansion [v2]
In-Reply-To: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>
References: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>
Message-ID: <jrv8DmFGOanyrTFXd9EWc9tCKknnE8cOfothVV_zHD0=.f75eb0a6-cc83-4f17-bf36-989388cfefa4@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)
> - [x] tier1-4, plus some internal testing

Beno?t Maillard has updated the pull request incrementally with one additional commit since the last revision:

  Add missing number
  
  Add bug reference for missed optimization in InlineType.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1742/files
  - new: https://git.openjdk.org/valhalla/pull/1742/files/43b36743..77836405

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

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 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 david.simms at oracle.com  Wed Dec 10 09:58:18 2025
From: david.simms at oracle.com (David Simms)
Date: Wed, 10 Dec 2025 10:58:18 +0100
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
Message-ID: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>

|I hereby nominate Axel Boldt-Christmas to Valhalla Committer. ||Axel is a member of Oracle's Garbage Collection team with over 100 
commits in jdk master [1]. Votes are due by December 24th, 2025, 1200z. 
Only current Valhalla Committers [2] 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 [3]. David Simms [1] 
https://github.com/search?q=committer-name%3A%22Axel+Boldt-Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits 
[2] https://openjdk.org/census [3] 
https://openjdk.org/projects/#committer-vote|




From david.simms at oracle.com  Wed Dec 10 09:58:22 2025
From: david.simms at oracle.com (David Simms)
Date: Wed, 10 Dec 2025 10:58:22 +0100
Subject: CFV: New Valhalla Committer: Stefan Karlsson
Message-ID: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>

|I hereby nominate Stefan Karlsson to Valhalla Committer. Stefan is a 
long time member of the OpenJDK project, with over 700 commits ||in jdk master ||[1]. Votes are due by December 24th, 2025, 1200z. Only current Valhalla 
Committers [2] 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 [3]. David Simms [1] 
https://github.com/search?q=committer-name%3A%22Stefan+Karlsson%22+repo%3Aopenjdk%2Fjdk+&type=commits 
[2] https://openjdk.org/census [3] 
https://openjdk.org/projects/#committer-vote|



From mcimadamore at openjdk.org  Wed Dec 10 10:14:03 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 10:14:03 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <YuqiAa8y2jzTeP9Rringmcsz6mhOxJm4N6giyTAIpeI=.6c4c42f9-ac9f-49d9-87cb-79652f171439@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <YuqiAa8y2jzTeP9Rringmcsz6mhOxJm4N6giyTAIpeI=.6c4c42f9-ac9f-49d9-87cb-79652f171439@github.com>
Message-ID: <SiURh9XFrX8u0Sp7SHOWSCTT6SQhtVNZyPdj3L7otNg=.34879805-0fa4-4ead-851c-5b08cb96a923@github.com>

On Tue, 9 Dec 2025 22:29:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove note about StableValue (not possible)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 819:
> 
>> 817: 
>> 818:     MULTIRELEASE("--multi-release", "opt.arg.multi-release", "opt.multi-release", HIDDEN, FILEMANAGER),
>> 819:     PREVIEWMODE("--preview-mode", "opt.arg.preview-mode", "opt.preview-mode", HIDDEN, FILEMANAGER),
> 
> I'm not 100% sure as to why we're adding a new preview option here -- javac already has `--enable-preview` -- what is the new option for? Seems to be only used by the file manager. Can't the file manager use `--enable-preview` ? @david-beaumont  or @lahodaj  please clarify

OK, I see -- this is an "hidden" option, just used internally by javac to communicate to the file manager whether preview mode should be enabled or not. I now see the same pattern being used as that for multirelease jars.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606014344

From dsimms at openjdk.org  Wed Dec 10 10:16:58 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Dec 2025 10:16:58 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <wdqGkIg_Z5N9zmniEC9RfFkjVl3xiVgl7sBDOZ81BSc=.2f9e1bc1-9b82-497b-9067-9dcde1eb6199@github.com>

Merge tag 'jdk-26+25' into lworld_merge_jdk_26_25
Added tag jdk-26+25 for changeset 2acd8776

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

Commit messages:
 - Merge tag 'jdk-26+25' into lworld_merge_jdk_26_25
 - 8371440: jpackage should exit with an error if it finds multiple matching signing certificates
 - 8372118: Test tools/jpackage/macosx/DmgContentTest.java failed
 - 8371944: AOT configuration is corrupted when app closes System.out
 - 8369187: Add wrapper for <new> that forbids use of global allocation and deallocation functions
 - 8371923: Update LockFreeStack for Atomic<T>
 - 8343316: Review and update tests using explicit provider names
 - 8363980: [macos] Add JDK specific keys/values to Info.plist of embedded runtime
 - 8371674: C2 fails with Missed optimization opportunity in PhaseIterGVN for MoveL2D
 - 8357728: Avoid caching synthesized names in synthesized parameters
 - ... and 108 more: https://git.openjdk.org/valhalla/compare/30ef92b2...a1012946

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

Changes: https://git.openjdk.org/valhalla/pull/1783/files
  Stats: 28770 lines in 502 files changed: 18355 ins; 7131 del; 3284 mod
  Patch: https://git.openjdk.org/valhalla/pull/1783.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1783/head:pull/1783

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

From jlahoda at openjdk.org  Wed Dec 10 10:18:18 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Dec 2025 10:18:18 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <SiURh9XFrX8u0Sp7SHOWSCTT6SQhtVNZyPdj3L7otNg=.34879805-0fa4-4ead-851c-5b08cb96a923@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <YuqiAa8y2jzTeP9Rringmcsz6mhOxJm4N6giyTAIpeI=.6c4c42f9-ac9f-49d9-87cb-79652f171439@github.com>
 <SiURh9XFrX8u0Sp7SHOWSCTT6SQhtVNZyPdj3L7otNg=.34879805-0fa4-4ead-851c-5b08cb96a923@github.com>
Message-ID: <uVgKp0J6ksemp-GBGo_B9Tw72o7iGNP5xq6lN1ci0Y8=.8cca3608-f154-463c-972f-6c9231b3e3e5@github.com>

On Wed, 10 Dec 2025 10:11:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 819:
>> 
>>> 817: 
>>> 818:     MULTIRELEASE("--multi-release", "opt.arg.multi-release", "opt.multi-release", HIDDEN, FILEMANAGER),
>>> 819:     PREVIEWMODE("--preview-mode", "opt.arg.preview-mode", "opt.preview-mode", HIDDEN, FILEMANAGER),
>> 
>> I'm not 100% sure as to why we're adding a new preview option here -- javac already has `--enable-preview` -- what is the new option for? Seems to be only used by the file manager. Can't the file manager use `--enable-preview` ? @david-beaumont  or @lahodaj  please clarify
>
> OK, I see -- this is an "hidden" option, just used internally by javac to communicate to the file manager whether preview mode should be enabled or not. I now see the same pattern being used as that for multirelease jars.

Yes - we need a separate option, as (AFAIK) the current framework does not allow options to be used both for and outside of file managers.

We more or less need to send the preview mode using an option/`handleOption`, as the file manager may be a file manager provided by the user, and only delegate to `JavacFileManager`. That's the same reason why `--multi-release` is used for file managers.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606029197

From jlahoda at openjdk.org  Wed Dec 10 10:31:57 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Dec 2025 10:31:57 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <PiUyFc_cztnUEZvJJ7EjYfNkGLd87AYgkYdrBDJI0t0=.a09e2702-6a03-4375-aa58-d7908db2d7f7@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 1587:

> 1585:                 }  else if (proxy.type.tsym == syms.valueBasedType.tsym && sym.kind == TYP) {
> 1586:                     sym.flags_field |= VALUE_BASED;
> 1587:                 }  else if (!DISABLE_PREVIEW_PATCHING

Currently, the migrated value classes are marked with `@jdk.internal.MigratedValueClass` (or the corresponding javac-internal annotation). And this code will mark such classes as value-based, even if the original classfile is not the preview classfile. This has a similar real-world effect as reading the appropriate preview class, but this annotation is AFAIK only temporary. So if the new approach is enabled, we disable the special handling of the annotation, and rely on reading the appropriate preview class. This is to see the eventual effect of enabling the support for preview classes inside JRT FS, and abandoning migrated value class.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606081171

From mcimadamore at openjdk.org  Wed Dec 10 10:38:01 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 10:38:01 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <Qs5axX9MmWza7rIuaNdu31L5H8RLHf7yWXbNWw-f9RI=.633c5e79-5b7b-4e7a-bcfe-019e04a7e15a@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 88:

> 86: 
> 87:         // Synchronized by FileSystemResources.class, NOT instance.
> 88:         private final Set<JRTIndex> owners = new HashSet<>();

This seems like a ref counter -- e.g. we want to keep track of how many JRTIndex instances there are that point at the same underlying resources. This seems sensible, and doing it this way seems better than using a refcount, so that you can check that the guy who did the close is the same as that who did the open.

Since there's only one set for both modes, correctness currently hinges (I think) on the fact that JRTIndex does *not* override equals/hashCode. This means that, if the same client opens two indices, one for preview, one for non-preview, you will see two distinct entries in the set (because the comparison is an identity comparison).

We might want to leave a comment about this "hidden" dependencies. Or, we could split the owner set in two. If we do the latter, we might improve the "already opened" check -- so that we can say "index already opened _in mode XYZ_"

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606100908

From david.simms at oracle.com  Wed Dec 10 10:41:12 2025
From: david.simms at oracle.com (David Simms)
Date: Wed, 10 Dec 2025 10:41:12 +0000
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
Message-ID: <SA2PR10MB4459503AD667F250B3B71E9D9AA0A@SA2PR10MB4459.namprd10.prod.outlook.com>


Vote: yes

________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Wednesday, 10 December 2025 10:58
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas

|I hereby nominate Axel Boldt-Christmas to Valhalla Committer. ||Axel is a member of Oracle's Garbage Collection team with over 100
commits in jdk master [1]. Votes are due by December 24th, 2025, 1200z.
Only current Valhalla Committers [2] 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 [3]. David Simms [1]
https://github.com/search?q=committer-name%3A%22Axel+Boldt-Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits
[2] https://openjdk.org/census [3]
https://openjdk.org/projects/#committer-vote|




Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251210/9f2db735/attachment.htm>

From david.simms at oracle.com  Wed Dec 10 10:41:37 2025
From: david.simms at oracle.com (David Simms)
Date: Wed, 10 Dec 2025 10:41:37 +0000
Subject: CFV: New Valhalla Committer: Stefan Karlsson
In-Reply-To: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
References: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
Message-ID: <SA2PR10MB4459012B1641C0EB02ABA31C9AA0A@SA2PR10MB4459.namprd10.prod.outlook.com>

Vote: yes

________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Wednesday, 10 December 2025 10:58
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Stefan Karlsson

|I hereby nominate Stefan Karlsson to Valhalla Committer. Stefan is a
long time member of the OpenJDK project, with over 700 commits ||in jdk master ||[1]. Votes are due by December 24th, 2025, 1200z. Only current Valhalla
Committers [2] 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 [3]. David Simms [1]
https://github.com/search?q=committer-name%3A%22Stefan+Karlsson%22+repo%3Aopenjdk%2Fjdk+&type=commits
[2] https://openjdk.org/census [3]
https://openjdk.org/projects/#committer-vote|



Confidential- Oracle Internal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251210/ae36eef5/attachment-0001.htm>

From jlahoda at openjdk.org  Wed Dec 10 10:44:21 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Dec 2025 10:44:21 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <PamE2OIDMXDCW20GQU3Xr5jiIdxMNDyMQFRI9XtU2nM=.9a89a569-3622-491d-8a24-0afb572c8317@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <PamE2OIDMXDCW20GQU3Xr5jiIdxMNDyMQFRI9XtU2nM=.9a89a569-3622-491d-8a24-0afb572c8317@github.com>
Message-ID: <3CLg-4Umco2-hXsTgxgB41tDbjMfD15FbpITJjB9xCA=.8f88691b-589b-41a1-bcb4-5b4262fe7952@github.com>

On Tue, 25 Nov 2025 14:53:43 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 note about StableValue (not possible)
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1:
> 
>> 1: /*
> 
> I don't know anything about this code per se, this is all Jan's work.

This adds a support for a different version of classfiles when running with preview in `ct.sym`. This is modeled as a new version (`@`). We only support preview for the most current version, so a single preview version ought to be enough.

I.e., inside `ct.sym`, 27 will be modeled as `R`, and the preview for 27 will be `@`. Classfiles that are unchanged between 27 and 27-preview will not be duplicates, in the same way classfiles that are common between 26 and 27 are shared and not duplicated.

(Overall, we may need change the encoding inside `ct.sym`, as we will run out of letters in ~4 years, but that's separate from the effort here.)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606118482

From mcimadamore at openjdk.org  Wed Dec 10 10:44:22 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 10:44:22 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <UqOHr36X3MIfhVlHWyMoClpGnW_3gdypz0iH7bZ04sI=.789ba367-28ac-4d92-a43d-e9011621d888@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <3o6rehCKk-ugP6M7_1AoiASVlTji_vLXyQxijP_iZOk=.93319185-66fc-4463-91da-aaf760925cb4@github.com>
 <UqOHr36X3MIfhVlHWyMoClpGnW_3gdypz0iH7bZ04sI=.789ba367-28ac-4d92-a43d-e9011621d888@github.com>
Message-ID: <Mq9UPiqWZAab9x9-xDC_mQhaGOES15IwOXjBrcYXNo0=.debeef0a-0a84-4d75-890b-94addcdead5d@github.com>

On Tue, 25 Nov 2025 15:30:51 GMT, David Beaumont <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 317:
>> 
>>> 315:     public void close() throws IOException {
>>> 316:         // Release is atomic and succeeds at most once.
>>> 317:         if (!sharedResources.release(this)) {
>> 
>> This exception may be contentious. Please speak up if you don't like it.
>> It's here to track any accidental double-closing of the index, and did catch one case already.
>> Since this is an internal class it feels like we should be able to track and eliminate any double close events, but it is a runtime exception in complex code, so I'm happy to remove it or maybe replace it with logging of some kind.
>> Please speak up if you have opinions.
>
> Also, nulling out "sharedResources" during close() for better GC cleanup is doable, but not completely trivial, since it adds "post-closure" failure modes that didn't exist before.
> I do think that *somewhere* we should be detaching the index for garbage collection, but maybe all its users are sufficiently well scoped that it's unlikely to matter.

In general, I prefer to err on the side of correctness (as you did here). Given all allocation of JRTIndex go through the factory (and the shared file system resources), if we detect something suspicious it likely means there's an issue somewhere. Now, we could argue if this should be a crash or not -- but if it's not then we'll likely never know about it.

Note -- javac has a class to do some assertion checks -- see com.sun.tools.javac.util.Assert.

So this could also be rewritten as:


Assert.check(sharedResources.release(this), "Already closed");

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606126565

From dsimms at openjdk.org  Wed Dec 10 10:49:42 2025
From: dsimms at openjdk.org (David Simms)
Date: Wed, 10 Dec 2025 10:49:42 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <wdqGkIg_Z5N9zmniEC9RfFkjVl3xiVgl7sBDOZ81BSc=.2f9e1bc1-9b82-497b-9067-9dcde1eb6199@github.com>
References: <wdqGkIg_Z5N9zmniEC9RfFkjVl3xiVgl7sBDOZ81BSc=.2f9e1bc1-9b82-497b-9067-9dcde1eb6199@github.com>
Message-ID: <yuOgpSa5Hy8NcGInk5RT9xm2NHZpLKMGMLUG1FPwNWU=.6e28b016-f4be-45df-9689-448c5a6712ae@github.com>

On Wed, 10 Dec 2025 10:07:03 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+25' into lworld_merge_jdk_26_25
> Added tag jdk-26+25 for changeset 2acd8776

This pull request has now been integrated.

Changeset: 96dd7488
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/96dd74886e25131a2a7ee854761983f37df93dca
Stats:     28770 lines in 502 files changed: 18355 ins; 7131 del; 3284 mod

Merge

Merge jdk-26+25

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

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

From mcimadamore at openjdk.org  Wed Dec 10 10:53:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 10:53:52 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <BFxPYa4_ecuG4IvX0eEcUN4agELrJk8oc5hGT0-826w=.c2ca422e-4912-4867-8e1a-a3840d706d9e@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java line 1:

> 1: /*

Most of the changes in this files are stylistic. I'd strongly recommend (in the future) to separate those out, so that the "meat" of the PR is more self-evident. After all, filing multiple PRs is cheap :-)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606164130

From mcimadamore at openjdk.org  Wed Dec 10 10:57:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 10:57:50 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <yCZkBFuAp4JCxUW6xswYiuIlNtwlx3WtyNZZkyL4mGI=.dbd2b5df-ab96-43b3-8103-2f094c2917b2@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java line 151:

> 149: 
> 150:     private void addCloseable(Closeable c) {
> 151:         synchronized (closeables) {

Here and elsewhere -- I'm not sure about `synchronized`. In general, javac operates under the assumption of "single threaded-ness" -- but I see around the file manager code that `synchronized` seems to be used. I'll leave this to @lahodaj

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606178947

From mcimadamore at openjdk.org  Wed Dec 10 11:13:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 11:13:51 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <QxeGDxOY3Aj-doX42krGcwQ9JNlHGMUGiZSAIAuV71g=.0a028384-5fd5-4d71-bdd5-bcacdccb0db3@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 139:

> 137:         /** Close underlying shared resources once no users exist (called exactly once). */
> 138:         private synchronized void close() throws IOException {
> 139:             assert !isClosed;

This should also use `Assert.check(isClosed)`. 
In fact, perhaps it might be worth pulling this check out in some `ensureOpen` method, and call that method whenever you need.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606223110

From mcimadamore at openjdk.org  Wed Dec 10 11:13:53 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 11:13:53 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <3HjsRShWk4GgyWcUBMgIHn2JPTNRkboWiWrFO94UD0o=.6453c17b-e8d1-49aa-88dd-55e64b4240ea@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <3HjsRShWk4GgyWcUBMgIHn2JPTNRkboWiWrFO94UD0o=.6453c17b-e8d1-49aa-88dd-55e64b4240ea@github.com>
Message-ID: <4z2sS2JZrAcPXtp5S4waExd-4nn1f_w1zieD6PSbuWI=.63f38ea6-2697-4b30-b991-a32b1afcfe8d@github.com>

On Tue, 25 Nov 2025 15:32:51 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 note about StableValue (not possible)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 147:
> 
>> 145: 
>> 146:         synchronized Entry getEntry(RelativeDirectory rd) throws IOException {
>> 147:             if (isClosed) {
> 
> One other example of a new exception, not previously possible. This is rather unavoidable post-closure, and feels like IOException is the appropriate response (as opposed to the IllegalStateException proposed in close()).

I'm not too sure. It seems a case of calling an operation when the object is in a bad state. So, ISE or an assertion error seems also legitimate.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606227492

From mcimadamore at openjdk.org  Wed Dec 10 11:23:50 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 11:23:50 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
Message-ID: <Aj_dHr3n7JVAVnVYy-jKnRYYaTWGnWa7Q8xwr64523c=.2d7f83b0-5e83-4af9-9ef5-6afe340d99d8@github.com>

On Tue, 25 Nov 2025 15:57:56 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Plumbing for javac flags, mostly inspired by/copied from test commits made by @lahodaj .
>> 
>> There are several things here, mostly entangled, so it's a bit tricky to try splitting this out, but it would be possible if people wanted.
>> 
>> The biggest "refactoing" part of this PR is "src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java" which now has a properly controlled lifecycle and disposed its resources correctly. Prior to this, the class used a non-closeable JRT file-system reference, which leads to "persistent open file" issues such as JDK-8357249.
>> 
>> This *does* mean that if compilation and the runtime have the same preview mode, then a 2nd JRT file system to the same jimage file is "opened", *but* the file system itself is lightweight, non-caching and both of them will use the underlying SharedImageReader (which is where nodes are cached etc.) so it really shouldn't be an issue (I will make sure javac benchmarks are checked however).
>> 
>> The benefit of this is that now, the shared index (which does do some caching) is correctly tracked across all users, and will be closed when the last user closes the lightweight wrapper instance.
>> 
>> A lot of the smaller "spot fix" changes in this PR were just copied by me, or at least inspired directly by Jan's work, so I may have missed some semantic subtlety in the code I'm not familiar with. Please evaluate that carefully.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove note about StableValue (not possible)

Overall the changes seem sensible. I leff some comments on possible ways to make code (esp. error checking) more javac-like. Take those as optional suggestions.
The work for making JRTIndex closeable seems good, and the logic to detect double closure etc. seems robust.

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

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1761#pullrequestreview-3562051310

From mcimadamore at openjdk.org  Wed Dec 10 11:23:51 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 Dec 2025 11:23:51 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <tN10koJZsg16rVElVBFkJSxAGP5gru2Y9_AOqBGtn-M=.f0b614ff-e99d-435e-9c33-632f2906bd30@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <tN10koJZsg16rVElVBFkJSxAGP5gru2Y9_AOqBGtn-M=.f0b614ff-e99d-435e-9c33-632f2906bd30@github.com>
Message-ID: <UI_0aPvD3u9QlTBJDmZ8-MchF9LUTBo3BGh26-D275Q=.7dc717c6-4316-4aa3-803d-f77c7f9b852f@github.com>

On Tue, 25 Nov 2025 17:03:57 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 note about StableValue (not possible)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 341:
> 
>> 339: 
>> 340:     public boolean isInJRT(FileObject fo) {
>> 341:         if (fo instanceof PathFileObject pathFileObject) {
> 
> This is surprisingly subtle and needs someone much more familiar with javac, FileObject and other things to look at. This method is used exactly once in ClassFinder to see if the path of a FileObject "came from" the JRT index.
> 
> Previously any FileObject created with a path that come from the global jrt file system would cause this to return "true". Now, it might not, because preview mode and non-preview mode no longer share a file system instance.
> 
> This feels correct in the sense that "the two classes could have different content in different modes", but it's bad if anyone wants flags for a class that wasn't changed by preview mode. In that case, the code will now fail to do anything (whereas before it would):
> 
> --------
> 
>     long getSupplementaryFlags(ClassSymbol c) {
>         if (jrtIndex == null || !jrtIndex.isInJRT(c.classfile) || c.name == names.module_info) {
>             return 0;
>         }
>         ...
>     }
> 
> --------
> 
> So it's not at all clear to me if this is an issue or not. If ClassSymbols for classes in the JRT image which get passed to getSupplementaryFlags() always come from **this index instance**, then it should be okay, but otherwise it's subtly broken. It depends how people can define ClassSymbol instances, and what control they have over the paths of the file objects they use.

My feeling here is that this shouldn't matter.

First, I think the method seems consistent -- e.g. `isInJRT` is an instance method on a JRTIndex, and returns true if the provided file is defined in the file system backing _that specific_ JRTIndex. Which seems correct.

Second, in reality there's only one ClassFinder per javac instantiation. Which means the class finder will either run in preview mode or not -- effectively only seeing one type of file system. In other words, I don't think it's possible for javac to witness different classfiles for the same symbol.

This might be possible in cases like combo tests, where we try to reuse the existing compilation context for multiple compilation rounds (which allows us to run thousands of javac compilation in seconds). But in that test framework, whenever a "sensitive" option is detected, javac dutifully marks its context as "not good for reuse", and so it throws it away and creates a new one (and a new classfinder).

But, @lahodaj  please chime in too

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606254293

From christian.hagedorn at oracle.com  Wed Dec 10 13:00:31 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Wed, 10 Dec 2025 14:00:31 +0100
Subject: CFV: New Valhalla Committer: Stefan Karlsson
In-Reply-To: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
References: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
Message-ID: <b74b03f0-cb67-40b3-9a65-3e8ba8b0ae41@oracle.com>

Vote: yes

Best regards,
Christian

On 12/10/25 10:58, David Simms wrote:
> |I hereby nominate Stefan Karlsson to Valhalla Committer. Stefan is a 
> long time member of the OpenJDK project, with over 700 commits ||in jdk 
> master ||[1]. Votes are due by December 24th, 2025, 1200z. Only current 
> Valhalla Committers [2] 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 [3]. David Simms [1] https:// 
> github.com/search?q=committer- 
> name%3A%22Stefan+Karlsson%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] 
> https://openjdk.org/census [3] https://openjdk.org/projects/#committer- 
> vote|
> 
> 


From christian.hagedorn at oracle.com  Wed Dec 10 13:00:52 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Wed, 10 Dec 2025 14:00:52 +0100
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
Message-ID: <1b66764b-5dfb-4b2d-8d4b-742c1aa98da4@oracle.com>

Vote: yes

Best regards,
Christian

On 12/10/25 10:58, David Simms wrote:
> |I hereby nominate Axel Boldt-Christmas to Valhalla Committer. ||Axel is 
> a member of Oracle's Garbage Collection team with over 100 commits in 
> jdk master [1]. Votes are due by December 24th, 2025, 1200z. Only 
> current Valhalla Committers [2] 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 [3]. David Simms [1] https:// 
> github.com/search?q=committer-name%3A%22Axel+Boldt- 
> Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits [2] https://openjdk.org/ 
> census [3] https://openjdk.org/projects/#committer-vote|
> 
> 
> 


From frederic.parain at oracle.com  Wed Dec 10 13:16:38 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 10 Dec 2025 08:16:38 -0500
Subject: CFV: New Valhalla Committer: Stefan Karlsson
In-Reply-To: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
References: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
Message-ID: <e25ac4ce-ebd5-4236-ac54-fc8ab2241ca2@oracle.com>

Vote: yes

Fred

On 12/10/25 04:58, David Simms wrote:
> |I hereby nominate Stefan Karlsson to Valhalla Committer. Stefan is a 
> long time member of the OpenJDK project, with over 700 commits ||in 
> jdk master ||[1]. Votes are due by December 24th, 2025, 1200z. Only 
> current Valhalla Committers [2] 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 [3]. David Simms [1] 
> https://github.com/search?q=committer-name%3A%22Stefan+Karlsson%22+repo%3Aopenjdk%2Fjdk+&type=commits 
> [2] https://openjdk.org/census [3] 
> https://openjdk.org/projects/#committer-vote|
>
>

From frederic.parain at oracle.com  Wed Dec 10 13:16:59 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 10 Dec 2025 08:16:59 -0500
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
Message-ID: <aee9eb57-4f73-43a9-a8df-e016f8de116c@oracle.com>

Vote: yes

Fred

On 12/10/25 04:58, David Simms wrote:
> |I hereby nominate Axel Boldt-Christmas to Valhalla Committer. ||Axel 
> is a member of Oracle's Garbage Collection team with over 100 commits 
> in jdk master [1]. Votes are due by December 24th, 2025, 1200z. Only 
> current Valhalla Committers [2] 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 [3]. David Simms [1] 
> https://github.com/search?q=committer-name%3A%22Axel+Boldt-Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits 
> [2] https://openjdk.org/census [3] 
> https://openjdk.org/projects/#committer-vote|
>
>
>

From jlahoda at openjdk.org  Wed Dec 10 13:47:56 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 10 Dec 2025 13:47:56 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <UI_0aPvD3u9QlTBJDmZ8-MchF9LUTBo3BGh26-D275Q=.7dc717c6-4316-4aa3-803d-f77c7f9b852f@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <tN10koJZsg16rVElVBFkJSxAGP5gru2Y9_AOqBGtn-M=.f0b614ff-e99d-435e-9c33-632f2906bd30@github.com>
 <UI_0aPvD3u9QlTBJDmZ8-MchF9LUTBo3BGh26-D275Q=.7dc717c6-4316-4aa3-803d-f77c7f9b852f@github.com>
Message-ID: <vYyWFJsHzgmMHrg-80S0IfhKfrzdP2FIRHpJwtk3J9E=.8b10b2f1-c8f0-4c36-b6ed-510b532ccf89@github.com>

On Wed, 10 Dec 2025 11:19:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 341:
>> 
>>> 339: 
>>> 340:     public boolean isInJRT(FileObject fo) {
>>> 341:         if (fo instanceof PathFileObject pathFileObject) {
>> 
>> This is surprisingly subtle and needs someone much more familiar with javac, FileObject and other things to look at. This method is used exactly once in ClassFinder to see if the path of a FileObject "came from" the JRT index.
>> 
>> Previously any FileObject created with a path that come from the global jrt file system would cause this to return "true". Now, it might not, because preview mode and non-preview mode no longer share a file system instance.
>> 
>> This feels correct in the sense that "the two classes could have different content in different modes", but it's bad if anyone wants flags for a class that wasn't changed by preview mode. In that case, the code will now fail to do anything (whereas before it would):
>> 
>> --------
>> 
>>     long getSupplementaryFlags(ClassSymbol c) {
>>         if (jrtIndex == null || !jrtIndex.isInJRT(c.classfile) || c.name == names.module_info) {
>>             return 0;
>>         }
>>         ...
>>     }
>> 
>> --------
>> 
>> So it's not at all clear to me if this is an issue or not. If ClassSymbols for classes in the JRT image which get passed to getSupplementaryFlags() always come from **this index instance**, then it should be okay, but otherwise it's subtly broken. It depends how people can define ClassSymbol instances, and what control they have over the paths of the file objects they use.
>
> My feeling here is that this shouldn't matter.
> 
> First, I think the method seems consistent -- e.g. `isInJRT` is an instance method on a JRTIndex, and returns true if the provided file is defined in the file system backing _that specific_ JRTIndex. Which seems correct.
> 
> Second, in reality there's only one ClassFinder per javac instantiation. Which means the class finder will either run in preview mode or not -- effectively only seeing one type of file system. In other words, I don't think it's possible for javac to witness different classfiles for the same symbol.
> 
> This might be possible in cases like combo tests, where we try to reuse the existing compilation context for multiple compilation rounds (which allows us to run thousands of javac compilation in seconds). But in that test framework, whenever a "sensitive" option is detected, javac dutifully marks its context as "not good for reuse", and so it throws it away and creates a new one (and a new classfinder).
> 
> But, @lahodaj  please chime in too

In practice, as long as the `JavacFileManager` and `ClassFinder` agree on the `JRTIndex` instance (which they should), then it should be fine checking that the file originates in the one specific instance of JRT FS that is held by the `JRTIndex`. If the file manager is not a JavacFileManager, `jrtIndex` will be `null`, so custom file managers are ruled out here, I think.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2606723491

From lois.foltan at oracle.com  Wed Dec 10 14:25:42 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 10 Dec 2025 14:25:42 +0000
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
Message-ID: <BLAPR10MB5156BFA68FB65BE4D2FA40A28AA0A@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: Wednesday, December 10, 2025 at 4:58?AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas

|I hereby nominate Axel Boldt-Christmas to Valhalla Committer. ||Axel is a member of Oracle's Garbage Collection team with over 100
commits in jdk master [1]. Votes are due by December 24th, 2025, 1200z.
Only current Valhalla Committers [2] 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 [3]. David Simms [1]
https://github.com/search?q=committer-name%3A%22Axel+Boldt-Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits
[2] https://openjdk.org/census [3]
https://openjdk.org/projects/#committer-vote|



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

From lois.foltan at oracle.com  Wed Dec 10 14:26:04 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 10 Dec 2025 14:26:04 +0000
Subject: CFV: New Valhalla Committer: Stefan Karlsson
In-Reply-To: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
References: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
Message-ID: <BLAPR10MB5156FB8C25C62F35A58833658AA0A@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: Wednesday, December 10, 2025 at 4:58?AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Stefan Karlsson

|I hereby nominate Stefan Karlsson to Valhalla Committer. Stefan is a
long time member of the OpenJDK project, with over 700 commits ||in jdk master ||[1]. Votes are due by December 24th, 2025, 1200z. Only current Valhalla
Committers [2] 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 [3]. David Simms [1]
https://github.com/search?q=committer-name%3A%22Stefan+Karlsson%22+repo%3Aopenjdk%2Fjdk+&type=commits
[2] https://openjdk.org/census [3]
https://openjdk.org/projects/#committer-vote|


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

From fparain at openjdk.org  Wed Dec 10 15:40:20 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 10 Dec 2025 15:40:20 GMT
Subject: [lworld] RFR: 8372304: [lworld] Test
 serviceability/jvmti/valhalla/HeapDump/HeapDump.java fails in product build
In-Reply-To: <eFf-E01joO2-Bjm_O8kN-EO70fR7nWhubkUgv0crNqI=.1559e978-7381-48d2-85a2-d413692f0192@github.com>
References: <eFf-E01joO2-Bjm_O8kN-EO70fR7nWhubkUgv0crNqI=.1559e978-7381-48d2-85a2-d413692f0192@github.com>
Message-ID: <TZjVi8dXUugXISMNWDiyW0CJx1IBjUc56Kfd14lGZE8=.8b2164e9-caf9-467a-878a-9bfba76ff98e@github.com>

On Thu, 20 Nov 2025 22:20:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test executes subprocess with `-XX:+PrintInlineLayout` and `-XX:+PrintFlatArrayLayout` arguments. These are diagnostic arguments, require `-XX:+UnlockDiagnosticVMOptions` to unlock.

Marked as reviewed by fparain (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1754#pullrequestreview-3563182326

From chen.l.liang at oracle.com  Wed Dec 10 17:18:25 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 10 Dec 2025 17:18:25 +0000
Subject: CFV: New Valhalla Committer: Stefan Karlsson
In-Reply-To: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
References: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
Message-ID: <CH3PR10MB7677AFB6B281F32A5DDCAE0FA2A0A@CH3PR10MB7677.namprd10.prod.outlook.com>

Vote: yes
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Wednesday, December 10, 2025 3:58 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Stefan Karlsson

|I hereby nominate Stefan Karlsson to Valhalla Committer. Stefan is a
long time member of the OpenJDK project, with over 700 commits ||in jdk master ||[1]. Votes are due by December 24th, 2025, 1200z. Only current Valhalla
Committers [2] 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 [3]. David Simms [1]
https://github.com/search?q=committer-name%3A%22Stefan+Karlsson%22+repo%3Aopenjdk%2Fjdk+&type=commits
[2] https://openjdk.org/census [3]
https://openjdk.org/projects/#committer-vote|


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

From chen.l.liang at oracle.com  Wed Dec 10 17:18:33 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Wed, 10 Dec 2025 17:18:33 +0000
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
Message-ID: <CH3PR10MB767739054BF8EB6C69B70934A2A0A@CH3PR10MB7677.namprd10.prod.outlook.com>

Vote: yes

Confidential- Oracle Internal
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Wednesday, December 10, 2025 3:58 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas

|I hereby nominate Axel Boldt-Christmas to Valhalla Committer. ||Axel is a member of Oracle's Garbage Collection team with over 100
commits in jdk master [1]. Votes are due by December 24th, 2025, 1200z.
Only current Valhalla Committers [2] 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 [3]. David Simms [1]
https://github.com/search?q=committer-name%3A%22Axel+Boldt-Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits
[2] https://openjdk.org/census [3]
https://openjdk.org/projects/#committer-vote|



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

From coleenp at openjdk.org  Wed Dec 10 17:30:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Dec 2025 17:30:20 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes
Message-ID: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>

This fixes three crashes in when heap dumping is enabled with Matias's patch.
Tested with tier1-3, that doesn't exactly turn on valhalla and some --enable-valhalla testing locally.

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

Commit messages:
 - 8373442: [lworld] Fix CDS heap dumping crashes

Changes: https://git.openjdk.org/valhalla/pull/1784/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1784&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373442
  Stats: 83 lines in 8 files changed: 47 ins; 15 del; 21 mod
  Patch: https://git.openjdk.org/valhalla/pull/1784.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1784/head:pull/1784

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

From iklam at openjdk.org  Wed Dec 10 18:10:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 18:10:41 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes
In-Reply-To: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
References: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
Message-ID: <Jnkn-G9Sxf3uhlrLmTlWBXVmzGTA5YjXMaDNGN5WiLQ=.3f8896ec-69fe-4e02-bab2-aa59e2bc9a0f@github.com>

On Wed, 10 Dec 2025 17:23:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This fixes three crashes in when heap dumping is enabled with Matias's patch.
> Tested with tier1-3, that doesn't exactly turn on valhalla and some --enable-valhalla testing locally.

src/hotspot/share/cds/aotStreamedHeapWriter.cpp line 393:

> 391:   narrowKlass nk = ArchiveBuilder::current()->get_requested_narrow_klass(src_klass);
> 392: 
> 393:   markWord mw = Arguments::enable_preview() ? src_klass->prototype_header() : markWord::prototype();

Why is `Arguments::enable_preview()` check necessary here but not in aotMappedHeapWriter.cpp??

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1784#discussion_r2607657822

From amenkov at openjdk.org  Wed Dec 10 18:47:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 10 Dec 2025 18:47:37 GMT
Subject: [lworld] Integrated: 8372304: [lworld] Test
 serviceability/jvmti/valhalla/HeapDump/HeapDump.java fails in product build
In-Reply-To: <eFf-E01joO2-Bjm_O8kN-EO70fR7nWhubkUgv0crNqI=.1559e978-7381-48d2-85a2-d413692f0192@github.com>
References: <eFf-E01joO2-Bjm_O8kN-EO70fR7nWhubkUgv0crNqI=.1559e978-7381-48d2-85a2-d413692f0192@github.com>
Message-ID: <K2rze_c3SdC4H-5iqez2trfZXZFrNv75onZ3fvhCSZ0=.f8baefdf-3cc0-4931-98d2-1e749009fe53@github.com>

On Thu, 20 Nov 2025 22:20:16 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The test executes subprocess with `-XX:+PrintInlineLayout` and `-XX:+PrintFlatArrayLayout` arguments. These are diagnostic arguments, require `-XX:+UnlockDiagnosticVMOptions` to unlock.

This pull request has now been integrated.

Changeset: 87dc27c6
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/87dc27c6c54be07c18ab1ab53c5a58cef9be7dd8
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8372304: [lworld] Test serviceability/jvmti/valhalla/HeapDump/HeapDump.java fails in product build

Reviewed-by: phubner, fparain

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

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

From coleenp at openjdk.org  Wed Dec 10 19:22:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Dec 2025 19:22:15 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes
In-Reply-To: <Jnkn-G9Sxf3uhlrLmTlWBXVmzGTA5YjXMaDNGN5WiLQ=.3f8896ec-69fe-4e02-bab2-aa59e2bc9a0f@github.com>
References: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
 <Jnkn-G9Sxf3uhlrLmTlWBXVmzGTA5YjXMaDNGN5WiLQ=.3f8896ec-69fe-4e02-bab2-aa59e2bc9a0f@github.com>
Message-ID: <rnoCSkXOYLoS3Vc8YvWW9LuRWS2YbEaqXVbrochN4dU=.5e61d152-fec2-4c41-866e-b1a95274234a@github.com>

On Wed, 10 Dec 2025 17:51:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This fixes three crashes in when heap dumping is enabled with Matias's patch.
>> Tested with tier1-3, that doesn't exactly turn on valhalla and some --enable-valhalla testing locally.
>
> src/hotspot/share/cds/aotStreamedHeapWriter.cpp line 393:
> 
>> 391:   narrowKlass nk = ArchiveBuilder::current()->get_requested_narrow_klass(src_klass);
>> 392: 
>> 393:   markWord mw = Arguments::enable_preview() ? src_klass->prototype_header() : markWord::prototype();
> 
> Why is `Arguments::enable_preview()` check necessary here but not in aotMappedHeapWriter.cpp??

Yes, these should fail too.
Edit.  No they don't fail because they test Universe::objectArrayKlass() which is a default RefArrayKlass and that class doesn't set any special flattening or other bits in the markWord, so markWord::prototype() is okay there.  But this code is confusing and fragile and should be rewritten.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1784#discussion_r2607919708

From coleenp at openjdk.org  Wed Dec 10 20:49:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 10 Dec 2025 20:49:48 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes
In-Reply-To: <rnoCSkXOYLoS3Vc8YvWW9LuRWS2YbEaqXVbrochN4dU=.5e61d152-fec2-4c41-866e-b1a95274234a@github.com>
References: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
 <Jnkn-G9Sxf3uhlrLmTlWBXVmzGTA5YjXMaDNGN5WiLQ=.3f8896ec-69fe-4e02-bab2-aa59e2bc9a0f@github.com>
 <rnoCSkXOYLoS3Vc8YvWW9LuRWS2YbEaqXVbrochN4dU=.5e61d152-fec2-4c41-866e-b1a95274234a@github.com>
Message-ID: <AeibHrASry3zEFdA6uex1OZBYL2907nctU31hngXFOk=.eac8ee7d-670c-4814-b512-433d739eb7b8@github.com>

On Wed, 10 Dec 2025 19:17:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/cds/aotStreamedHeapWriter.cpp line 393:
>> 
>>> 391:   narrowKlass nk = ArchiveBuilder::current()->get_requested_narrow_klass(src_klass);
>>> 392: 
>>> 393:   markWord mw = Arguments::enable_preview() ? src_klass->prototype_header() : markWord::prototype();
>> 
>> Why is `Arguments::enable_preview()` check necessary here but not in aotMappedHeapWriter.cpp??
>
> Yes, these should fail too.
> Edit.  No they don't fail because they test Universe::objectArrayKlass() which is a default RefArrayKlass and that class doesn't set any special flattening or other bits in the markWord, so markWord::prototype() is okay there.  But this code is confusing and fragile and should be rewritten.

It should be refactored in mainline now that Valhalla uses Klass::_prototype_header, like COH, we should always use it unconditionally for object allocation.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1784#discussion_r2608160643

From roger.riggs at oracle.com  Wed Dec 10 22:02:25 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 10 Dec 2025 17:02:25 -0500
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
Message-ID: <d62f367a-2e74-4f29-99e8-10dfdebaf147@oracle.com>

Vote: Yes

On 12/10/25 4:58 AM, David Simms wrote:
> I hereby nominate Axel Boldt-Christmas to Valhalla Committer. 


From roger.riggs at oracle.com  Wed Dec 10 22:02:50 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 10 Dec 2025 17:02:50 -0500
Subject: CFV: New Valhalla Committer: Stefan Karlsson
In-Reply-To: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
References: <c0e84b36-b404-4299-b973-22cadc8672a1@oracle.com>
Message-ID: <1fa1f7a3-9b7c-4560-9c96-7fbb2d022737@oracle.com>

Vote: Yes

On 12/10/25 4:58 AM, David Simms wrote:
> hereby nominate Stefan Karlsson to Valhalla Committer.