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. 


From david.simms at oracle.com  Thu Dec 11 06:30:10 2025
From: david.simms at oracle.com (David Simms)
Date: Thu, 11 Dec 2025 06:30:10 +0000
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
Message-ID: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>

I hereby nominate Serguei Spitsyn to Valhalla Committer.

Serguei is a long time member of the OpenJDK project, with over 300 commits in jdk master [1].

Votes are due by Decemeber 25th, 0700z.

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%22Serguei+Spitsyn%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/20251211/56285be3/attachment.htm>

From jatinbha.cloud at gmail.com  Thu Dec 11 06:55:37 2025
From: jatinbha.cloud at gmail.com (Jatin Bhateja)
Date: Thu, 11 Dec 2025 12:25:37 +0530
Subject: CFV: New Valhalla Committer: Axel Boldt-Christmas
In-Reply-To: <SA2PR10MB4459503AD667F250B3B71E9D9AA0A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <3d3b7e9c-be7e-4b97-b690-f712e173fefc@oracle.com>
 <SA2PR10MB4459503AD667F250B3B71E9D9AA0A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <012a68ae-85b8-48fa-9887-fbe53394738f@gmail.com>

Vote: yes


Best regards,

Jatin


On 12/10/2025 4:11 PM, David Simms wrote:
>
> ------------------------------------------------------------------------
> *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 
> <https://github.com/search?q=committer-name%3A%22Axel+Boldt-Christmas%22+repo%3Aopenjdk%2Fjdk+&type=commits>
> [2] https://openjdk.org/census <https://openjdk.org/census>?[3]
> https://openjdk.org/projects/#committer-vote| 
> <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/20251211/8b7c36a9/attachment.htm>

From duke at openjdk.org  Thu Dec 11 09:23:46 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Dec 2025 09:23:46 GMT
Subject: [lworld] RFR: 8367623: [lworld] C2: Ideal Optimization on
 InlineTypeNode should not be carried out after Macro Expansion [v2]
In-Reply-To: <jrv8DmFGOanyrTFXd9EWc9tCKknnE8cOfothVV_zHD0=.f75eb0a6-cc83-4f17-bf36-989388cfefa4@github.com>
References: <4eWxkdug6_axRQcXYhisj3SOmbnHDG6wK10Yw13Dl1c=.861401d4-e66c-4757-8697-570b3e0a1748@github.com>
 <jrv8DmFGOanyrTFXd9EWc9tCKknnE8cOfothVV_zHD0=.f75eb0a6-cc83-4f17-bf36-989388cfefa4@github.com>
Message-ID: <olbLk7hz-0m74K1wki5v7tDVIAUFmTiwhvYvGocRkjM=.b74f9caa-a35d-4a8c-b01d-1b62b7a5ac2f@github.com>

On Wed, 10 Dec 2025 09:51:22 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
>
> 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.

@benoitmaillard 
Your change (at version 7783640579228b3eb0aa139725700da7d81c6ff6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1742#issuecomment-3641004425

From bmaillard at openjdk.org  Thu Dec 11 09:58:31 2025
From: bmaillard at openjdk.org (=?UTF-8?B?QmVub8OudA==?= Maillard)
Date: Thu, 11 Dec 2025 09:58:31 GMT
Subject: [lworld] Integrated: 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: <QkBzzCYCYJRsQaJhbWwvWaNk_YepBNMuXzp6FMSAC2o=.bc271f0c-18ac-4033-8adf-ec0e850438ca@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

This pull request has now been integrated.

Changeset: 651a8fe5
Author:    Beno?t Maillard <bmaillard at openjdk.org>
Committer: Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/651a8fe59e3a185dcac9c193a712481f52cf7785
Stats:     71 lines in 2 files changed: 70 ins; 0 del; 1 mod

8367623: [lworld] C2: Ideal Optimization on InlineTypeNode should not be carried out after Macro Expansion

Reviewed-by: qamai

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

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

From jsikstro at openjdk.org  Thu Dec 11 10:02:25 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Dec 2025 10:02:25 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for ParallelGC
Message-ID: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>

Hello,

The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.

In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.

Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.

I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.

After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is very rare to preserve a markWord for this reason.

Testing:

* Oracle's tier1-4

* For sanity I looked at the number of markWords being preserved before/after this change in runtime/valhalla/inlinetypes/FlatArraysTest.java. For this specific test, I can see about ~17% less preservation of markWords.
  <details>
  <summary><b>Before/after number of preserved markWords in Parallel and G1</b> (expandable section)</summary>

  ```
  -XX:+UseParallelGC -Xlog:gc=trace ... | grep "Restored ":
  Before:
  GC(0) Restored 1269 marks, occupying 20304 B
  GC(7) Restored 689 marks, occupying 11024 B
  GC(14) Restored 10 marks, occupying 160 B
  GC(28) Restored 10 marks, occupying 160 B

  After:
  GC(0) Restored 1064 marks, occupying 17024 B
  GC(7) Restored 626 marks, occupying 10016 B
  GC(14) Restored 6 marks, occupying 96 B
  GC(28) Restored 6 marks, occupying 96 B
  ```


  ```
  -XX:+UseG1GC -Xlog:gc=trace ... | grep "Restored ":
  Before:
  GC(0) Restored 1269 marks, occupying 20304 B
  GC(1) Restored 1112 marks, occupying 17792 B
  GC(7) Restored 1269 marks, occupying 20304 B
  GC(14) Restored 1270 marks, occupying 20320 B
  GC(28) Restored 1270 marks, occupying 20320 B

  After:
  GC(0) Restored 1064 marks, occupying 17024 B
  GC(1) Restored 912 marks, occupying 14592 B
  GC(7) Restored 1064 marks, occupying 17024 B
  GC(14) Restored 1065 marks, occupying 17040 B
  GC(28) Restored 1065 marks, occupying 17040 B
  ```
  </details>

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

Commit messages:
 - 8373494: [lworld] markWord preservation for ParallelGC

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

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

From jsikstro at openjdk.org  Thu Dec 11 10:02:28 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 11 Dec 2025 10:02:28 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <0RIa9mdEejJL7Qy1DLQmGUHAhQrKZmERM5nZODeURbc=.55bf0a52-419d-4ccd-98ca-89e50e095fb1@github.com>

On Thu, 11 Dec 2025 09:53:29 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is v...

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1481:

> 1479:           const bool full_header_in_current_region = cur_addr + oopDesc::header_size() <= end;
> 1480: 
> 1481:           if (EnableValhalla && !full_header_in_current_region) {

We could make this criteria even more specific by checking something like the following, but I'm not sure it's worth it since not copying the full header in the same region is pretty rare.


static bool requires_valhalla_preservation(markWord mark) {
  return EnableValhalla && (mark.is_larval_state() || mark.is_null_free_array() || mark.is_flat_array() || mark.is_inline_type());
}

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2609932921

From aboldtch at openjdk.org  Thu Dec 11 11:39:09 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 11 Dec 2025 11:39:09 GMT
Subject: [lworld] RFR: 8373506: [lworld] Disable currently unsupported builds
 in GHA
Message-ID: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>

The lworld branch does currently not support zero, Shenandoah GC nor other cpu architectures than x86_64 and aarch64.

I suggest we disable these builds from being run in GHA, to reduce noise and wasted machine hours.

Once the these specific VM configurations or features have been implemented for lworld we can reenable the actions.

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

Commit messages:
 - Disable currently unsupported build linux-x64-hs-zero in GHA
 - Disable currently unsupported cross compilation targets in GHA
 - Disable ShenandoahGC in GHA

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

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

From aboldtch at openjdk.org  Thu Dec 11 11:56:14 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 11 Dec 2025 11:56:14 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass classes
Message-ID: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>

This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 

Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 

It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).

We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

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

Commit messages:
 - Add override keyword to *Klass classes

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

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

From tobias.hartmann at oracle.com  Thu Dec 11 14:28:41 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2025 15:28:41 +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: <70b3e414-bbee-469b-b928-8a718c4350b5@oracle.com>

Vote: yes

Best regards,
Tobias

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 tobias.hartmann at oracle.com  Thu Dec 11 14:28:48 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2025 15:28:48 +0100
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <f53dd4b0-4eb5-4b7a-90e2-8fbc18240545@oracle.com>

Vote: yes

Best regards,
Tobias

On 12/11/25 07:30, David Simms wrote:
> |I hereby nominate Serguei Spitsyn to Valhalla Committer. |Serguei is a long time member of the OpenJDK project, with over 300 commits in jdk master [1].|Votes are due by Decemeber 25th, 0700z. 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%22Serguei+Spitsyn%22+repo%3Aopenjdk%2Fjdk+&type=commits <https://github.com/search?q=committer-name%3A%22Serguei+Spitsyn%22+repo%3Aopenjdk%2Fjdk+&type=commits>|[2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote|
> 
> 


From tobias.hartmann at oracle.com  Thu Dec 11 14:28:58 2025
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 11 Dec 2025 15:28:58 +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: <3d6c52cb-1b92-46d7-9056-c0e29b775e50@oracle.com>

Vote: yes

Best regards,
Tobias


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  Thu Dec 11 14:29:19 2025
From: christian.hagedorn at oracle.com (Christian Hagedorn)
Date: Thu, 11 Dec 2025 15:29:19 +0100
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <55f9aec0-cefd-4ff8-af42-2cf6f6be700c@oracle.com>

Vote: yes

Best regards,
Christian

On 12/11/25 07:30, David Simms wrote:
> |I hereby nominate Serguei Spitsyn to Valhalla Committer. |Serguei is a 
> long time member of the OpenJDK project, with over 300 commits in jdk 
> master [1].|Votes are due by Decemeber 25th, 0700z. 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%22Serguei+Spitsyn%22+repo%3Aopenjdk%2Fjdk+&type=commits 
> <https://github.com/search?q=committer- 
> name%3A%22Serguei+Spitsyn%22+repo%3Aopenjdk%2Fjdk+&type=commits>|[2] 
> https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote|
> 
> 


From phubner at openjdk.org  Thu Dec 11 14:34:45 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Dec 2025 14:34:45 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC
In-Reply-To: <0RIa9mdEejJL7Qy1DLQmGUHAhQrKZmERM5nZODeURbc=.55bf0a52-419d-4ccd-98ca-89e50e095fb1@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <0RIa9mdEejJL7Qy1DLQmGUHAhQrKZmERM5nZODeURbc=.55bf0a52-419d-4ccd-98ca-89e50e095fb1@github.com>
Message-ID: <ZAvq3llSLWdxb73khpFQRxWoMomUWUwKRdJsT29tJGQ=.542cb850-5d64-4619-b58b-1dcb75d56681@github.com>

On Thu, 11 Dec 2025 09:55:08 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1481:
> 
>> 1479:           const bool full_header_in_current_region = cur_addr + oopDesc::header_size() <= end;
>> 1480: 
>> 1481:           if (EnableValhalla && !full_header_in_current_region) {
> 
> We could make this criteria even more specific by checking something like the following, but I'm not sure it's worth it since not copying the full header in the same region is pretty rare.
> 
> 
> static bool requires_valhalla_preservation(markWord mark) {
>   return EnableValhalla && (mark.is_larval_state() || mark.is_null_free_array() || mark.is_flat_array() || mark.is_inline_type());
> }

If I understand it correctly, the version you have right now is less conservative than `requires_valhalla_preservation` which may include false positives. I think I'm inclined to checking region containment, it also makes maintainability easier down the line (if we end up changing the markWord bits).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2610484465

From thartmann at openjdk.org  Thu Dec 11 14:42:57 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Dec 2025 14:42:57 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v7]
In-Reply-To: <SfcINvWme5_u3Uiizn6FF4i0jdleWYtdm8VBXfN9lKU=.3affd2a9-30de-40ac-a31b-424c1d981f19@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <SfcINvWme5_u3Uiizn6FF4i0jdleWYtdm8VBXfN9lKU=.3affd2a9-30de-40ac-a31b-424c1d981f19@github.com>
Message-ID: <xP2SoMCErrIB4BqmNuxeawqvSpgFh1fh6OqJG1Ysp50=.6f41487d-1cb8-4fa3-83be-dccdbdcc4c22@github.com>

On Mon, 8 Dec 2025 14:25:22 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:
> 
>   reviews

Thanks for making these changes. Looks all good to me, I only wonder if we could cast `init_val` to an InlineTypeNode in LibraryCallKit::inline_newArray (see my comment)?

Let's wait for @fparain to approve the change in `src/hotspot/share/prims/jvm.cpp`.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1755#pullrequestreview-3567728238

From thartmann at openjdk.org  Thu Dec 11 14:43:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Dec 2025 14:43:01 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v7]
In-Reply-To: <ZcJS3ZcX2wD4tU6yRHn-GjNGJJCp6ZZcZCVkCn8LLT0=.adbce6c5-fc04-4580-bdb3-e4cde57c3a8d@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>
 <ZcJS3ZcX2wD4tU6yRHn-GjNGJJCp6ZZcZCVkCn8LLT0=.adbce6c5-fc04-4580-bdb3-e4cde57c3a8d@github.com>
Message-ID: <w75biPX0UT3SBYVSVl5ATiPG_xzCsD7fuLKskff0foA=.0e7c93aa-9b12-4b15-8933-5e05f6a0af2d@github.com>

On Mon, 8 Dec 2025 13:47:48 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> 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.

Sounds good, thanks!

>> 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`.

Okay, thanks for the clarifications.

>> 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.

Sounds good, thanks!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610813615
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610822568
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610833029

From thartmann at openjdk.org  Thu Dec 11 14:43:05 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Dec 2025 14:43:05 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <w8u-QzWAoRxsXZCIT5ygiLz8hUeDxBs2LeaUuqci5hE=.a3509567-1d9c-41bf-9e01-ea8e3044def4@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>
 <w8u-QzWAoRxsXZCIT5ygiLz8hUeDxBs2LeaUuqci5hE=.a3509567-1d9c-41bf-9e01-ea8e3044def4@github.com>
Message-ID: <_AUnQub310kMTCCjkX20tRzLPFqRNTdPoWGdbvSl_pM=.c230c99c-3272-4594-85b2-0d73fc8eb083@github.com>

On Mon, 8 Dec 2025 12:17:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> 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

Okay, maybe we should reference that here or at least file a Valhalla specific issue to keep track of it.

>> 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.

Makes sense, thanks!

>> 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`.

Right, I hope we now caught all the places where this adjustment is needed.

>> 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`.

Should we cast it to `InlineTypeNode` in `LibraryCallKit::inline_newArray` instead?

>> 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?

That's fine with me. We can still change it later.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610819202
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610824732
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610828692
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610832249
PR Review Comment: https://git.openjdk.org/valhalla/pull/1755#discussion_r2610835377

From lois.foltan at oracle.com  Thu Dec 11 15:31:25 2025
From: lois.foltan at oracle.com (Lois Foltan)
Date: Thu, 11 Dec 2025 15:31:25 +0000
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <BLAPR10MB5156451997DA2FBFCEAEA6368AA1A@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: Thursday, December 11, 2025 at 1:30?AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Serguei Spitsyn


I hereby nominate Serguei Spitsyn to Valhalla Committer.

Serguei is a long time member of the OpenJDK project, with over 300 commits in jdk master [1].

Votes are due by Decemeber 25th, 0700z.

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%22Serguei+Spitsyn%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/20251211/d0f5cbc3/attachment-0001.htm>

From frederic.parain at oracle.com  Thu Dec 11 15:36:43 2025
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 11 Dec 2025 10:36:43 -0500
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <13f29ca0-891d-442a-afad-93bd1eb70129@oracle.com>

Vote: yes


Fred


On 12/11/25 01:30, David Simms wrote:
> |I hereby nominate Serguei Spitsyn to Valhalla Committer. |Serguei is 
> a long time member of the OpenJDK project, with over 300 commits in 
> jdk master [1].|Votes are due by Decemeber 25th, 0700z. 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%22Serguei+Spitsyn%22+repo%3Aopenjdk%2Fjdk+&type=commits 
> <https://github.com/search?q=committer-name%3A%22Serguei+Spitsyn%22+repo%3Aopenjdk%2Fjdk+&type=commits>|[2] 
> https://openjdk.org/census [3] 
> https://openjdk.org/projects/#committer-vote|
>

From thartmann at openjdk.org  Thu Dec 11 16:05:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 11 Dec 2025 16:05:15 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <MBJo4oPmQ2YFyMFTf1AL5dN5ug_HJDsgMP4ofFKGp44=.ab760ae3-2762-4840-8f73-08045df746c5@github.com>

On Tue, 2 Dec 2025 10:36:04 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

> # 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 ca...

src/hotspot/share/opto/graphKit.cpp line 2052:

> 2050: 
> 2051:         // Don't add store to buffer call if we are strength reducing
> 2052:         if (!C->strength_reduction()) {

Can we use `_gvn.is_IterGVN() && !C->inlining_incrementally()` here instead? Assuming that whenever we call this after parsing and when not incrementally inlining, we are doing post-parse devirtualization of a call.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2611159037

From chen.l.liang at oracle.com  Thu Dec 11 16:06:00 2025
From: chen.l.liang at oracle.com (Chen Liang)
Date: Thu, 11 Dec 2025 16:06:00 +0000
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <SJ2PR10MB7669D9EA50DA83BF4E8EDCFAA2A1A@SJ2PR10MB7669.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: Thursday, December 11, 2025 12:30 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Serguei Spitsyn


I hereby nominate Serguei Spitsyn to Valhalla Committer.

Serguei is a long time member of the OpenJDK project, with over 300 commits in jdk master [1].

Votes are due by Decemeber 25th, 0700z.

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%22Serguei+Spitsyn%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/20251211/236e5af5/attachment-0001.htm>

From phubner at openjdk.org  Thu Dec 11 16:29:02 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 11 Dec 2025 16:29:02 GMT
Subject: [lworld] RFR: 8373506: [lworld] Disable currently unsupported
 builds in GHA
In-Reply-To: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>
References: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>
Message-ID: <IBmHYDtN5QKyL4J7qfN6kYzCV2MTtbX9AOqis2PxC4M=.06de1c08-a04c-4e8d-a08e-797d6228eb8d@github.com>

On Thu, 11 Dec 2025 11:32:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The lworld branch does currently not support zero, Shenandoah GC nor other cpu architectures than x86_64 and aarch64.
> 
> I suggest we disable these builds from being run in GHA, to reduce noise and wasted machine hours.
> 
> Once the these specific VM configurations or features have been implemented for lworld we can reenable the actions.

Thanks.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1786#pullrequestreview-3568288784

From liach at openjdk.org  Thu Dec 11 17:55:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Dec 2025 17:55:53 GMT
Subject: [lworld] RFR: 8373374: [lworld] Remove Unsafe.get/putValue
Message-ID: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>

Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.

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

Commit messages:
 - Remove get/putVal

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

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

From jbhateja at openjdk.org  Thu Dec 11 17:55:53 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 11 Dec 2025 17:55:53 GMT
Subject: [lworld] RFR: 8373374: [lworld] Remove Unsafe.get/putValue
In-Reply-To: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
References: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
Message-ID: <TQ2OqtwaHrLaZgffuY4AOGmJ0iuqTvGIOkym9fVabac=.65591f1a-09a3-485e-a805-45b023cbcbb2@github.com>

On Tue, 9 Dec 2025 23:21:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.

Removed my comments unrelated to this PR and moved them to following merge PR which has been updated with latest code from lworld
https://github.com/openjdk/valhalla/pull/1688

I plan to conclude this merge by next week, there are some failures, if the code changes are too many then I will open seperate follow up PRs for them instead of adding them with merge.

We don't use Unsafe.putValue/getValue in VectorAPI fallback so removing them looks fine to me. 

Best Regards

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

PR Comment: https://git.openjdk.org/valhalla/pull/1782#issuecomment-3640703615

From liach at openjdk.org  Thu Dec 11 18:00:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Dec 2025 18:00:29 GMT
Subject: [lworld] RFR: 8373374: [lworld] Remove Unsafe.get/putValue [v2]
In-Reply-To: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
References: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
Message-ID: <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>

> Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.

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

 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into cleanup/unsafe-value
 - Remove get/putVal

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1782/files
  - new: https://git.openjdk.org/valhalla/pull/1782/files/708675bc..860e902f

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

  Stats: 28844 lines in 505 files changed: 18426 ins; 7131 del; 3287 mod
  Patch: https://git.openjdk.org/valhalla/pull/1782.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1782/head:pull/1782

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

From fparain at openjdk.org  Thu Dec 11 18:27:20 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 11 Dec 2025 18:27:20 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: <aXFhG_1eHbZD8NCl8PNqbsKNu_NuZkCipLw1VlXLeJQ=.f1ae16a3-276c-49c3-9318-0bf562c2d86b@github.com>

On Mon, 8 Dec 2025 09:43: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/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?

First of all, any logic deciding the layout of an array should be in ObjArrayKlass::array_layout_selection().
We had layout logics in multiple places in the past, and they were getting out of sync very quickly.
So let's try to keep the decision logic in a single place.
The fall back to the atomic layout makes sense in this case where the array creator asked for non-atomicity but the value class author didn't opt in non-atomicity.
So the code in ObjArrayKlass::Array_layout_selection() would become:


if (is_null_restricted(properties)) {
    if (is_non_atomic(properties)) {
      // Null-restricted + non-atomic
      if (vk->maybe_flat_in_array()) {
        if (vk->has_non_atomic_layout()) {
          return ArrayDescription(FlatArrayKlassKind, properties, LayoutKind::NON_ATOMIC_FLAT);
        } else if (vk->has_atomic_layout()) {
          return ArrayDescription(FlatArrayKlassKind, properties, LayoutKind::ATOMIC_FLAT);
        }
      }
      return ArrayDescription(RefArrayKlassKind, properties, LayoutKind::REFERENCE);
    } else {

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

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

From vromero at openjdk.org  Thu Dec 11 19:16:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Dec 2025 19:16:54 GMT
Subject: Integrated: Merge lworld
Message-ID: <JJ8hw0M9qnZ_bb827wTdQLBCARSW_OWiIkKaMliVtWw=.d6610c5c-7963-4e7e-8a94-26c19c1cc2a4@github.com>

Merge branch 'lworld' into lw5_merge_lworld
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
#	src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - 8347754: [lw5] fix the order of nullness markers in signatures
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - ... and 59 more: https://git.openjdk.org/valhalla/compare/cfd3a727...e6630be9

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/valhalla/pull/1789/files
  Stats: 6804 lines in 101 files changed: 6679 ins; 5 del; 120 mod
  Patch: https://git.openjdk.org/valhalla/pull/1789.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1789/head:pull/1789

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

From vromero at openjdk.org  Thu Dec 11 19:17:00 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Dec 2025 19:17:00 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <JJ8hw0M9qnZ_bb827wTdQLBCARSW_OWiIkKaMliVtWw=.d6610c5c-7963-4e7e-8a94-26c19c1cc2a4@github.com>
References: <JJ8hw0M9qnZ_bb827wTdQLBCARSW_OWiIkKaMliVtWw=.d6610c5c-7963-4e7e-8a94-26c19c1cc2a4@github.com>
Message-ID: <ZqNzO5oka8P6bWEEooPr4MT3ACALIQ5aYAm_TVZUEoQ=.37f761dc-caee-4d6c-b23e-22277c105916@github.com>

On Thu, 11 Dec 2025 19:11:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java

This pull request has now been integrated.

Changeset: 45458b3c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/45458b3c008630720f39c6da570f1cf1853aa632
Stats:     717625 lines in 8409 files changed: 464304 ins; 172777 del; 80544 mod

Merge

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

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

From coleenp at openjdk.org  Thu Dec 11 19:23:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Dec 2025 19:23:47 GMT
Subject: [lworld] RFR: 8373284: [lworld] More tests could be rewritten with
 LayoutKindHelper
In-Reply-To: <pCvwrvqIID5Pd9RPKoqepiIVtAnsRZGfVQmzZN_By5k=.49107e02-04f7-44ba-964a-afd0a89aee7a@github.com>
References: <pCvwrvqIID5Pd9RPKoqepiIVtAnsRZGfVQmzZN_By5k=.49107e02-04f7-44ba-964a-afd0a89aee7a@github.com>
Message-ID: <X2Qp6k5v-XYsnnxnih-iNduJeG1-tiG1pByfJmfWTfE=.7673ad5b-1cd2-4b28-94ba-aeac09dc3cb3@github.com>

On Mon, 8 Dec 2025 20:22:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> More tests rewritten with LayoutKindHelper methods.
> 
> Tested with Mach5 tier1-3
> 
> Fred

Looks good!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1777#pullrequestreview-3568959856

From iklam at openjdk.org  Thu Dec 11 19:33:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 11 Dec 2025 19:33:00 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: <Yw1wiDkkEpSSvyMvWuVPuSTLMCQEFFmdb1kZk2bKaVg=.4cfd1c1a-97d9-4433-8be2-781f4542fb14@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.

Marked as reviewed by iklam (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1784#pullrequestreview-3568996687

From liach at openjdk.org  Thu Dec 11 19:46:37 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Dec 2025 19:46:37 GMT
Subject: [lworld] RFR: 8372729: [lworld] Incorrect result of acmp with flat,
 nullable value class field
Message-ID: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>

LayoutIteration is missing null markers. Added the test from tobias to SubstitutabilityTest.

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

Commit messages:
 - 8372729

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

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

From coleenp at openjdk.org  Thu Dec 11 20:02:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Dec 2025 20:02:32 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes [v2]
In-Reply-To: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
References: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
Message-ID: <P_DxYL686n0SztP0YoaW05hLPUL5YkObbeSBwleoCDk=.7f54814c-35d8-46cf-97bd-4ef7bb7e49ff@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.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Add comment that archiving flattened arrays with oops in the inline class element type is not supported.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1784/files
  - new: https://git.openjdk.org/valhalla/pull/1784/files/19437153..c01ef0a2

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 vromero at openjdk.org  Thu Dec 11 20:09:52 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Dec 2025 20:09:52 GMT
Subject: Integrated: Merge lworld
Message-ID: <DvXk7a1Pr2gCRtpyF42o5meivi-mCwRRK3Inov-_sFc=.9ea90ce3-a895-4f4f-9e92-667329088711@github.com>

Merge branch 'lworld' into lw5_merge_lworld

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - 8367623: [lworld] C2: Ideal Optimization on InlineTypeNode should not be carried out after Macro Expansion
 - 8372304: [lworld] Test serviceability/jvmti/valhalla/HeapDump/HeapDump.java fails in product build
 - Merge
 - 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
 - ... and 113 more: https://git.openjdk.org/valhalla/compare/45458b3c...7163956d

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

Changes: https://git.openjdk.org/valhalla/pull/1791/files
  Stats: 28995 lines in 511 files changed: 18498 ins; 7209 del; 3288 mod
  Patch: https://git.openjdk.org/valhalla/pull/1791.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1791/head:pull/1791

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

From vromero at openjdk.org  Thu Dec 11 20:09:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 11 Dec 2025 20:09:53 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <DvXk7a1Pr2gCRtpyF42o5meivi-mCwRRK3Inov-_sFc=.9ea90ce3-a895-4f4f-9e92-667329088711@github.com>
References: <DvXk7a1Pr2gCRtpyF42o5meivi-mCwRRK3Inov-_sFc=.9ea90ce3-a895-4f4f-9e92-667329088711@github.com>
Message-ID: <3rWwUQc0QPLpXqIzNFcjmyIJDHbUYpx6bxf2FGFVr8g=.a131ee32-9b2e-4c45-9e95-cb90ece2c63f@github.com>

On Thu, 11 Dec 2025 20:01:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld

This pull request has now been integrated.

Changeset: 097960cb
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/097960cb6880cd227c0477c332f495ea37a93ff7
Stats:     28995 lines in 511 files changed: 18498 ins; 7209 del; 3288 mod

Merge

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

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

From matsaave at openjdk.org  Thu Dec 11 20:13:01 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 11 Dec 2025 20:13:01 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes [v2]
In-Reply-To: <P_DxYL686n0SztP0YoaW05hLPUL5YkObbeSBwleoCDk=.7f54814c-35d8-46cf-97bd-4ef7bb7e49ff@github.com>
References: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
 <P_DxYL686n0SztP0YoaW05hLPUL5YkObbeSBwleoCDk=.7f54814c-35d8-46cf-97bd-4ef7bb7e49ff@github.com>
Message-ID: <Jfcjskz_85-XvqRmjeyCWSWxvpqswWf6eRB0es3uQ1Q=.195af87a-ba6c-4145-b27c-c925d076d0c2@github.com>

On Thu, 11 Dec 2025 20:02:32 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.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment that archiving flattened arrays with oops in the inline class element type is not supported.

LGTM, thanks!

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1784#pullrequestreview-3569122185

From fparain at openjdk.org  Thu Dec 11 20:16:02 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 11 Dec 2025 20:16:02 GMT
Subject: [lworld] RFR: 8373284: [lworld] More tests could be rewritten with
 LayoutKindHelper
In-Reply-To: <X2Qp6k5v-XYsnnxnih-iNduJeG1-tiG1pByfJmfWTfE=.7673ad5b-1cd2-4b28-94ba-aeac09dc3cb3@github.com>
References: <pCvwrvqIID5Pd9RPKoqepiIVtAnsRZGfVQmzZN_By5k=.49107e02-04f7-44ba-964a-afd0a89aee7a@github.com>
 <X2Qp6k5v-XYsnnxnih-iNduJeG1-tiG1pByfJmfWTfE=.7673ad5b-1cd2-4b28-94ba-aeac09dc3cb3@github.com>
Message-ID: <XJutWzBo3CafugfRE6qBimHlCEgdL5_QOFiudkJV1Ks=.23054756-efd2-4303-b069-f2050c433f0b@github.com>

On Thu, 11 Dec 2025 19:21:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> More tests rewritten with LayoutKindHelper methods.
>> 
>> Tested with Mach5 tier1-3
>> 
>> Fred
>
> Looks good!

Thanks @coleenp for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1777#issuecomment-3643611868

From fparain at openjdk.org  Thu Dec 11 20:16:03 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 11 Dec 2025 20:16:03 GMT
Subject: [lworld] Integrated: 8373284: [lworld] More tests could be rewritten
 with LayoutKindHelper
In-Reply-To: <pCvwrvqIID5Pd9RPKoqepiIVtAnsRZGfVQmzZN_By5k=.49107e02-04f7-44ba-964a-afd0a89aee7a@github.com>
References: <pCvwrvqIID5Pd9RPKoqepiIVtAnsRZGfVQmzZN_By5k=.49107e02-04f7-44ba-964a-afd0a89aee7a@github.com>
Message-ID: <79JxuiZK2dcvQRWNy-WqQRzkaQZXUSIPr4tEPIInuug=.dc220aab-2414-4ce7-b449-8b1b72b4e731@github.com>

On Mon, 8 Dec 2025 20:22:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> More tests rewritten with LayoutKindHelper methods.
> 
> Tested with Mach5 tier1-3
> 
> Fred

This pull request has now been integrated.

Changeset: 40958cc5
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/40958cc5792da12f6212ed2a15100855a3a11079
Stats:     7 lines in 2 files changed: 0 ins; 1 del; 6 mod

8373284: [lworld] More tests could be rewritten with LayoutKindHelper

Reviewed-by: coleenp

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

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

From coleenp at openjdk.org  Thu Dec 11 20:28:47 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Dec 2025 20:28:47 GMT
Subject: [lworld] RFR: 8373442: [lworld] Fix CDS heap dumping crashes [v2]
In-Reply-To: <P_DxYL686n0SztP0YoaW05hLPUL5YkObbeSBwleoCDk=.7f54814c-35d8-46cf-97bd-4ef7bb7e49ff@github.com>
References: <YEOuJkmZ8cWfBEUTfaDiZw9zbQwekjZWb_VCpLc4dqQ=.acc7288b-02b4-4724-bdbc-b992181d1b6f@github.com>
 <P_DxYL686n0SztP0YoaW05hLPUL5YkObbeSBwleoCDk=.7f54814c-35d8-46cf-97bd-4ef7bb7e49ff@github.com>
Message-ID: <p85EJQ0n3rQW__rBnQBh-aWGEtqskVR7reQX1pTES9w=.e482cbc0-d7d1-4f32-b294-76697ad61afe@github.com>

On Thu, 11 Dec 2025 20:02:32 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.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment that archiving flattened arrays with oops in the inline class element type is not supported.

Thanks for reviewing Ioi and Matias.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1784#issuecomment-3643657398

From coleenp at openjdk.org  Thu Dec 11 20:32:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 11 Dec 2025 20:32:53 GMT
Subject: [lworld] Integrated: 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: <PFppY1l8HFGWOmSh6VLzIxmbvvYnLjJu8ydefFUjK2k=.e4d4fb96-449d-4825-aa1a-6d91ee40e7a7@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.

This pull request has now been integrated.

Changeset: cf0c0c08
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cf0c0c0845b2ec54f7bf12b7420e078d6b52e5f6
Stats:     85 lines in 8 files changed: 49 ins; 15 del; 21 mod

8373442: [lworld] Fix CDS heap dumping crashes

Reviewed-by: iklam, matsaave

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

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

From roger.riggs at oracle.com  Thu Dec 11 21:28:23 2025
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 11 Dec 2025 16:28:23 -0500
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <0dfa591a-b29a-4beb-be1d-5acc6be0dc8d@oracle.com>

Vote: Yes

On 12/11/25 1:30 AM, David Simms wrote:
> |I hereby nominate Serguei Spitsyn to Valhalla Committer.|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251211/6b16bf4f/attachment-0001.htm>

From liach at openjdk.org  Thu Dec 11 22:02:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Dec 2025 22:02:44 GMT
Subject: [lworld] RFR: 8372729: [lworld] Incorrect result of acmp with
 flat, nullable value class field [v2]
In-Reply-To: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
References: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
Message-ID: <k45T77bmw9hLUBnQh08ezFaGbNY8y3ZVg4XQ7t7e91M=.10452843-0441-49c8-994a-9bf95fe1ef9d@github.com>

> LayoutIteration is missing null markers. Added the test from tobias to SubstitutabilityTest.

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

  Need to add delta

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1790/files
  - new: https://git.openjdk.org/valhalla/pull/1790/files/f5ddda7b..18e5c26f

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

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

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

From liach at openjdk.org  Thu Dec 11 22:22:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 11 Dec 2025 22:22:06 GMT
Subject: [lworld] RFR: 8372729: [lworld] Incorrect result of acmp with
 flat, nullable value class field [v3]
In-Reply-To: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
References: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
Message-ID: <kN3s4D7wTGOFoPT1Uv2GDHXgZVOik81VK-258soHLYs=.012eabc4-d8dc-4efe-a0f5-5706472fe8c3@github.com>

> LayoutIteration is missing null markers. Added the test from tobias to SubstitutabilityTest.

Chen Liang has updated the pull request incrementally with three additional commits since the last revision:

 - Improve tests
 - Fix null marker detection
 - Revert "Need to add delta"
   
   This reverts commit 18e5c26f258b0436a952275a2593a933e34dac31.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1790/files
  - new: https://git.openjdk.org/valhalla/pull/1790/files/18e5c26f..99c3c615

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

  Stats: 104 lines in 2 files changed: 77 ins; 21 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1790.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1790/head:pull/1790

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

From qamai at openjdk.org  Fri Dec 12 02:48:29 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 12 Dec 2025 02:48:29 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <aXFhG_1eHbZD8NCl8PNqbsKNu_NuZkCipLw1VlXLeJQ=.f1ae16a3-276c-49c3-9318-0bf562c2d86b@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>
 <aXFhG_1eHbZD8NCl8PNqbsKNu_NuZkCipLw1VlXLeJQ=.f1ae16a3-276c-49c3-9318-0bf562c2d86b@github.com>
Message-ID: <75LXNGzY8_fNyfvUvwY6NVCdizUS7vB_-IrBvwOFmOQ=.bd5c3e02-beb6-4b8d-a0fc-91ce16ef64a9@github.com>

On Thu, 11 Dec 2025 18:24:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> 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?
>
> First of all, any logic deciding the layout of an array should be in ObjArrayKlass::array_layout_selection().
> We had layout logics in multiple places in the past, and they were getting out of sync very quickly.
> So let's try to keep the decision logic in a single place. (Which means that the jvm.cpp code has to be modified anyway to just pass NULL_RESTRICTED | NON_ATOMIC to the array factory).
> The fall back to the atomic layout makes sense in this case where the array creator asked for non-atomicity but the value class author didn't opt in non-atomicity.
> So the code in ObjArrayKlass::Array_layout_selection() would become:
> 
> 
> if (is_null_restricted(properties)) {
>     if (is_non_atomic(properties)) {
>       // Null-restricted + non-atomic
>       if (vk->maybe_flat_in_array()) {
>         if (vk->has_non_atomic_layout()) {
>           return ArrayDescription(FlatArrayKlassKind, properties, LayoutKind::NON_ATOMIC_FLAT);
>         } else if (vk->has_atomic_layout()) {
>           return ArrayDescription(FlatArrayKlassKind, properties, LayoutKind::ATOMIC_FLAT);
>         }
>       }
>       return ArrayDescription(RefArrayKlassKind, properties, LayoutKind::REFERENCE);
>     } else {

@fparain Thanks for your review, This is not about choosing a layout, however, it is about choosing a refined class for the array that is created by `ValueClass::newNullRestrictedNonAtomicArray`. If we go with your suggestion, then the array created by this method will have a different refined type from an array created by `ValueClass::newNullRestrictedAtomicArray`, which seems dangerous because C2 may try to assume that 2 classes having the same properties should be equal. As a result, I went with this change which asserts at `ObjArrayKlass::allocate_klass_with_properties` that non-atomic is only requested when it is possible to do so, and changed the call sites that may have this property popping up. The common point of those 2 sites is `ObjArrayKlass::klass_with_properties`, so I think it is less clear whether we should normalize the properties argument there instead. What do you think?

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

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

From thartmann at openjdk.org  Fri Dec 12 06:27:23 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 12 Dec 2025 06:27:23 GMT
Subject: [lworld] RFR: 8368274: [lworld]
 Unsafe.compareAndExchangeFlatValue() wrongly assumes padding bytes are the
 same for identical value objects
In-Reply-To: <JGvTSpQP6kkT6WmA-V08z1sfWcsrgiGI74Fqi7kRkdw=.bcf40ff9-0274-4f26-852d-44b3b144cf52@github.com>
References: <JGvTSpQP6kkT6WmA-V08z1sfWcsrgiGI74Fqi7kRkdw=.bcf40ff9-0274-4f26-852d-44b3b144cf52@github.com>
Message-ID: <rpKgObt14nY8Y1c3tZR43jFslrmyWseFcR2YDahMlTk=.04b9ab37-3d3a-4227-84df-0e278710ed9b@github.com>

On Wed, 12 Nov 2025 22:02:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> 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.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestCompareAndExchange.java line 98:

> 96:     @Test
> 97:     public Object test70(Object expected, Object x) {
> 98:         return U.compareAndExchangeFlatValue(this, TEST63_VT_OFFSET, 4, SmallValue.class, expected, x);

Aren't existing tests using `compareAndExchangeFlatValue` in `test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java` sufficient? If not, I'd suggest adding your test case there.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1734#discussion_r2613077745

From jsikstro at openjdk.org  Fri Dec 12 08:44:01 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 08:44:01 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v2]
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <e42n6hLkkUe0KJoeuBYAK6_WoVrmwsyknTECPQyYq7M=.b3cd2f1d-a655-4375-9ad6-cc982d085d1c@github.com>

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is v...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback and consistency fix

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1785/files
  - new: https://git.openjdk.org/valhalla/pull/1785/files/6f10a938..42539d84

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

  Stats: 50 lines in 2 files changed: 32 ins; 10 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1785.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1785/head:pull/1785

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

From phubner at openjdk.org  Fri Dec 12 08:44:01 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 08:44:01 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v2]
In-Reply-To: <e42n6hLkkUe0KJoeuBYAK6_WoVrmwsyknTECPQyYq7M=.b3cd2f1d-a655-4375-9ad6-cc982d085d1c@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <e42n6hLkkUe0KJoeuBYAK6_WoVrmwsyknTECPQyYq7M=.b3cd2f1d-a655-4375-9ad6-cc982d085d1c@github.com>
Message-ID: <YzJKlP5Fotk-58C8RkCBwQJwR9KpePKLfS_OOVPCkyE=.4202c8c0-e612-402d-8325-efdc54f8e3fa@github.com>

On Fri, 12 Dec 2025 08:38:56 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback and consistency fix

Looks good, if this passes the tests it's a much better version than what we had before!

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3567314465

From jsikstro at openjdk.org  Fri Dec 12 08:44:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 08:44:03 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <_g6l3fbdofspwm5CeyYtFLPzd7lvhu2Pk9r_hRDXZdQ=.73cc9322-77fb-42a8-a53e-85fd736eaca3@github.com>

On Thu, 11 Dec 2025 09:53:29 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is v...

Thank you to @stefank and @kstefanj for the help on understanding the code in this area of Parallel.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1785#issuecomment-3645496185

From jsikstro at openjdk.org  Fri Dec 12 08:44:05 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 08:44:05 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v2]
In-Reply-To: <ZAvq3llSLWdxb73khpFQRxWoMomUWUwKRdJsT29tJGQ=.542cb850-5d64-4619-b58b-1dcb75d56681@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <0RIa9mdEejJL7Qy1DLQmGUHAhQrKZmERM5nZODeURbc=.55bf0a52-419d-4ccd-98ca-89e50e095fb1@github.com>
 <ZAvq3llSLWdxb73khpFQRxWoMomUWUwKRdJsT29tJGQ=.542cb850-5d64-4619-b58b-1dcb75d56681@github.com>
Message-ID: <LefxoiOXxWvfGkwgMWsYWuBkH1f03c-_UEiYjPk9I2s=.ecc8d3db-e533-4cca-92ae-b66aec9181fb@github.com>

On Thu, 11 Dec 2025 12:55:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1481:
>> 
>>> 1479:           const bool full_header_in_current_region = cur_addr + oopDesc::header_size() <= end;
>>> 1480: 
>>> 1481:           if (EnableValhalla && !full_header_in_current_region) {
>> 
>> We could make this criteria even more specific by checking something like the following, but I'm not sure it's worth it since not copying the full header in the same region is pretty rare.
>> 
>> 
>> static bool requires_valhalla_preservation(markWord mark) {
>>   return EnableValhalla && (mark.is_larval_state() || mark.is_null_free_array() || mark.is_flat_array() || mark.is_inline_type());
>> }
>
> If I understand it correctly, the version you have right now is less conservative than `requires_valhalla_preservation` which may include false positives. I think I'm inclined to checking region containment, it also makes maintainability easier down the line (if we end up changing the markWord bits).

Yes, the version I have is less conservative than it could be, and I agree that this makes the code easier to maintain.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613389856

From phubner at openjdk.org  Fri Dec 12 08:52:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 08:52:30 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v2]
In-Reply-To: <e42n6hLkkUe0KJoeuBYAK6_WoVrmwsyknTECPQyYq7M=.b3cd2f1d-a655-4375-9ad6-cc982d085d1c@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <e42n6hLkkUe0KJoeuBYAK6_WoVrmwsyknTECPQyYq7M=.b3cd2f1d-a655-4375-9ad6-cc982d085d1c@github.com>
Message-ID: <War5pdWdl5aIjKszbhX4731MrFvfUmlAOG2pe_VPQgY=.81607c3d-f8fd-4ad2-b50a-139089c68404@github.com>

On Fri, 12 Dec 2025 08:44:01 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback and consistency fix

Still looks good.

src/hotspot/share/oops/markWord.hpp line 249:

> 247:   // Should this header be preserved during GC?
> 248:   bool must_be_preserved() const {
> 249:     return (!is_unlocked() || !has_no_hash() || (EnableValhalla && is_larval_state()));

FYI: the `EnableValhalla` is not necessary and I am removing it with my changes. I guess whoever integrates last can make sure it's gone.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3570894605
PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613422039

From paul.hubner at oracle.com  Fri Dec 12 08:54:37 2025
From: paul.hubner at oracle.com (Paul Hubner)
Date: Fri, 12 Dec 2025 08:54:37 +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: <BYAPR10MB3318FC7500CD76D2DB3CA8C483AEA@BYAPR10MB3318.namprd10.prod.outlook.com>

Vote: yes

Paul



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

From paul.hubner at oracle.com  Fri Dec 12 08:56:20 2025
From: paul.hubner at oracle.com (Paul Hubner)
Date: Fri, 12 Dec 2025 08:56:20 +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: <BYAPR10MB3318319FEE4E93BECD2E830383AEA@BYAPR10MB3318.namprd10.prod.outlook.com>

Vote: yes

Paul


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

From paul.hubner at oracle.com  Fri Dec 12 08:58:45 2025
From: paul.hubner at oracle.com (Paul Hubner)
Date: Fri, 12 Dec 2025 08:58:45 +0000
Subject: CFV: New Valhalla Committer: Serguei Spitsyn
In-Reply-To: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
References: <SA2PR10MB445925421B7DB6F679EF51469AA1A@SA2PR10MB4459.namprd10.prod.outlook.com>
Message-ID: <BYAPR10MB331853D57E8CDE25AEBA4D0A83AEA@BYAPR10MB3318.namprd10.prod.outlook.com>

Vote: yes

Paul
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of David Simms <david.simms at oracle.com>
Sent: Thursday, December 11, 2025 7:30 AM
To: valhalla-dev at openjdk.java.net <valhalla-dev at openjdk.java.net>
Subject: CFV: New Valhalla Committer: Serguei Spitsyn


I hereby nominate Serguei Spitsyn to Valhalla Committer.

Serguei is a long time member of the OpenJDK project, with over 300 commits in jdk master [1].

Votes are due by Decemeber 25th, 0700z.

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%22Serguei+Spitsyn%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/20251212/c3f4a759/attachment-0001.htm>

From jsikstro at openjdk.org  Fri Dec 12 09:07:48 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 09:07:48 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is v...

Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:

 - Remove dev logging
 - Convert COH check to assert in safe_to_read_header

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1785/files
  - new: https://git.openjdk.org/valhalla/pull/1785/files/42539d84..e9d214c3

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

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

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

From aboldtch at openjdk.org  Fri Dec 12 09:20:24 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 12 Dec 2025 09:20:24 GMT
Subject: [lworld] RFR: 8373506: [lworld] Disable currently unsupported
 builds in GHA
In-Reply-To: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>
References: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>
Message-ID: <yFUD60OOjfYmJ7OsRzbvqXFNRDqhvCp5hWW5G7gBgUY=.510da53b-ad85-42db-a81c-749b07fa5d41@github.com>

On Thu, 11 Dec 2025 11:32:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The lworld branch does currently not support zero, Shenandoah GC nor other cpu architectures than x86_64 and aarch64.
> 
> I suggest we disable these builds from being run in GHA, to reduce noise and wasted machine hours.
> 
> Once the these specific VM configurations or features have been implemented for lworld we can reenable the actions.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1786#issuecomment-3645612631

From aboldtch at openjdk.org  Fri Dec 12 09:20:25 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 12 Dec 2025 09:20:25 GMT
Subject: [lworld] Integrated: 8373506: [lworld] Disable currently unsupported
 builds in GHA
In-Reply-To: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>
References: <e3uyvlSU-ED4Es32VPyo-umITTx6ZFYpKy4L8_B0U1o=.fb2ff68c-02f4-464d-bf24-4574a6c77c67@github.com>
Message-ID: <jEIc-hKMYAV93F-5hJdkoEv9w_ZSPmqIJl0ds96ubzM=.f4433161-9c70-439b-b7dc-2bd42e952a3c@github.com>

On Thu, 11 Dec 2025 11:32:47 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The lworld branch does currently not support zero, Shenandoah GC nor other cpu architectures than x86_64 and aarch64.
> 
> I suggest we disable these builds from being run in GHA, to reduce noise and wasted machine hours.
> 
> Once the these specific VM configurations or features have been implemented for lworld we can reenable the actions.

This pull request has now been integrated.

Changeset: c6706524
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c670652442e77c30112dc5f3f2415ea2c9498830
Stats:     46 lines in 5 files changed: 3 ins; 0 del; 43 mod

8373506: [lworld] Disable currently unsupported builds in GHA

Reviewed-by: phubner

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

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

From stefank at openjdk.org  Fri Dec 12 09:25:58 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 09:25:58 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy excpetion throwing out
 of GC barriers
Message-ID: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>

The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.

I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.

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

Commit messages:
 -  Move exception throwing out of GC arraycopy barriers

Changes: https://git.openjdk.org/valhalla/pull/1792/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373567
  Stats: 305 lines in 14 files changed: 81 ins; 62 del; 162 mod
  Patch: https://git.openjdk.org/valhalla/pull/1792.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1792/head:pull/1792

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

From stefank at openjdk.org  Fri Dec 12 09:25:59 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 09:25:59 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy excpetion throwing
 out of GC barriers
In-Reply-To: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
Message-ID: <5R4ZBamxRkYDQUoWP9ZRsektPTwkxEy8e11YSePhCWQ=.4be072e5-556d-42aa-9e68-5e0e30b78fb6@github.com>

On Fri, 12 Dec 2025 09:16:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
> 
> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.

If this is accepted I think we could push the usage of `OopCopyResult` changes into the openjdk/jdk and thereby shrinking the lworld patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1792#issuecomment-3645623111

From dsimms at openjdk.org  Fri Dec 12 09:31:21 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 12 Dec 2025 09:31:21 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
Message-ID: <zHQJD19pT3nAce39S1W6A9n4Z46eu8d-6oYP2M7tiUA=.9a3ced8d-5e2b-4194-b2c9-c7a37a071848@github.com>

On Fri, 12 Dec 2025 09:07:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove dev logging
>  - Convert COH check to assert in safe_to_read_header

Marked as reviewed by dsimms (Committer).

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2148:

> 2146: 
> 2147: static markWord safe_mark_prototype(HeapWord* addr, size_t words) {
> 2148:   // If the original markWord contains bits that cannot be reconstructed because

Thanks for this code comment !

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

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3571039443
PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613536535

From tschatzl at openjdk.org  Fri Dec 12 09:41:13 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 12 Dec 2025 09:41:13 GMT
Subject: [lworld] RFR: 8373510: [lworld] Remove dead code in
 ConstantPool::klass_at_impl()
Message-ID: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>

Hi all,

  please review this removal of dead code in `ConstantPool::klass_at_impl`. The first is about the local `inline_type_signature` that is never written to after initialization, and the default value just disables some code, the other is an `else if` condition that is subsumed by the previous `if`.

Testing: local compilation,:hotspot_valhalla does not show additional failures

Thanks,
  Thomas

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

Commit messages:
 - 8373510

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

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

From stefank at openjdk.org  Fri Dec 12 09:43:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 09:43:46 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
Message-ID: <WqGlAux_TvYcjZuUo9l84qtr-KeBsm0vOGBjBzSeX5I=.458edb17-7427-4d9e-b2db-22e9e0f35ad1@github.com>

On Fri, 12 Dec 2025 09:07:48 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove dev logging
>  - Convert COH check to assert in safe_to_read_header

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2147:

> 2145: }
> 2146: 
> 2147: static markWord safe_mark_prototype(HeapWord* addr, size_t words) {

Could this function be named `safe_mark_word_prototype` instead?

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2279:

> 2277:       markWord mark = safe_mark_prototype(cur_addr, remaining_words);
> 2278: 
> 2279:       closure.do_addr(cur_addr, obj_size, mark);

The fact that `do_addr` calls a function named `words_remaining()` and the current code calculates a `remaining_words` feels a bit messy and it's not immediately obvious that this is correct. Is there a reason why this can't be handled from withing the `do_addr` function?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613548668
PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613572830

From mchevalier at openjdk.org  Fri Dec 12 09:53:28 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 12 Dec 2025 09:53:28 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
Message-ID: <exHb2Ld9qdCs1WF457ElIqeIMBLFASxTvvDuQ3cB6MM=.c5593786-ab72-4d6f-b6c7-4de96326c701@github.com>

On Thu, 11 Dec 2025 11:51:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 
> 
> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 
> 
> It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).
> 
> We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

I agree that `override` (sometimes `final`) is strictly better than virtual when it applies, and that's a good direction to take.

I find unfortunate not to do that in mainline as well, the PR description explains why it's more important here, but I fear it creates opportunities for conflicts during our jdk merges. Another possible issue is when a virtual method is added on mainline, with an override that is not marked with `override`, after the jdk merge, it will fail compilation on Mac (only?) because there is a warning about inconsistent use of override on this platform (if a class has one override, all the methods that can have it must have it). While I would agree the former seems rather unlikely and easy to fix, the latter seems less crazy and more annoying as it will not show up at merge-time, or local build on Linux, for instance. Still, not hard to fix.

While problems I imagine are rather easy to solve, they might come more than once, and be an annoyance on the way of merging (that seems already painful enough as it is). I can imagine that the urgency of getting this change in valhalla justifies not to put it in mainline and wait for the next jdk merge, but is it planned to do the same in mainline soon, to avoid mentioned issues, and so mainline can also benefit from the change? If so, it would be nice to have a JBS issue to track that.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1787#issuecomment-3645741413

From sjohanss at openjdk.org  Fri Dec 12 09:55:37 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 12 Dec 2025 09:55:37 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <WqGlAux_TvYcjZuUo9l84qtr-KeBsm0vOGBjBzSeX5I=.458edb17-7427-4d9e-b2db-22e9e0f35ad1@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
 <WqGlAux_TvYcjZuUo9l84qtr-KeBsm0vOGBjBzSeX5I=.458edb17-7427-4d9e-b2db-22e9e0f35ad1@github.com>
Message-ID: <I-sJTXSxmj5x7Xvngv72b6uiwIqR5lzmUXJ6bpXDwZE=.68d38628-1a2a-405e-a0d6-9f653ee0ea1a@github.com>

On Fri, 12 Dec 2025 09:40:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove dev logging
>>  - Convert COH check to assert in safe_to_read_header
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2279:
> 
>> 2277:       markWord mark = safe_mark_prototype(cur_addr, remaining_words);
>> 2278: 
>> 2279:       closure.do_addr(cur_addr, obj_size, mark);
> 
> The fact that `do_addr` calls a function named `words_remaining()` and the current code calculates a `remaining_words` feels a bit messy and it's not immediately obvious that this is correct. Is there a reason why this can't be handled from withing the `do_addr` function?

Yes, I agree, we overlooked that we had that information inside `do_addr`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613608356

From jsikstro at openjdk.org  Fri Dec 12 09:55:38 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 09:55:38 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <I-sJTXSxmj5x7Xvngv72b6uiwIqR5lzmUXJ6bpXDwZE=.68d38628-1a2a-405e-a0d6-9f653ee0ea1a@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
 <WqGlAux_TvYcjZuUo9l84qtr-KeBsm0vOGBjBzSeX5I=.458edb17-7427-4d9e-b2db-22e9e0f35ad1@github.com>
 <I-sJTXSxmj5x7Xvngv72b6uiwIqR5lzmUXJ6bpXDwZE=.68d38628-1a2a-405e-a0d6-9f653ee0ea1a@github.com>
Message-ID: <T6mPh7rbe7f-Xpw0WuqSd5sSGnIEio17jGdQiFsw2so=.ca0d3316-656b-45bc-976c-8f5858bc87ff@github.com>

On Fri, 12 Dec 2025 09:51:51 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 2279:
>> 
>>> 2277:       markWord mark = safe_mark_prototype(cur_addr, remaining_words);
>>> 2278: 
>>> 2279:       closure.do_addr(cur_addr, obj_size, mark);
>> 
>> The fact that `do_addr` calls a function named `words_remaining()` and the current code calculates a `remaining_words` feels a bit messy and it's not immediately obvious that this is correct. Is there a reason why this can't be handled from withing the `do_addr` function?
>
> Yes, I agree, we overlooked that we had that information inside `do_addr`.

The remaining_words here are the remaining words in the "from"/"source" region, while the `words_remaining()` inside `do_addr` are the words remaining in the "to"/"destination" region. We could rename remaining_words to something like `from_words_remaining`?

The reason we can't handle this in `do_addr` is because obj_size can be larger than the words we have remaining in the from region.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613611071

From stefank at openjdk.org  Fri Dec 12 10:07:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 10:07:21 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy excpetion throwing
 out of GC barriers [v2]
In-Reply-To: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
Message-ID: <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>

> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
> 
> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.

Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:

 - Mark oop_arraycopy as nodiscard
 - Terminate OopCopyResult in oop_arraycopy_raw

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1792/files
  - new: https://git.openjdk.org/valhalla/pull/1792/files/5b4063d5..9894b597

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

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

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

From stefank at openjdk.org  Fri Dec 12 10:10:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 10:10:33 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <T6mPh7rbe7f-Xpw0WuqSd5sSGnIEio17jGdQiFsw2so=.ca0d3316-656b-45bc-976c-8f5858bc87ff@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
 <WqGlAux_TvYcjZuUo9l84qtr-KeBsm0vOGBjBzSeX5I=.458edb17-7427-4d9e-b2db-22e9e0f35ad1@github.com>
 <I-sJTXSxmj5x7Xvngv72b6uiwIqR5lzmUXJ6bpXDwZE=.68d38628-1a2a-405e-a0d6-9f653ee0ea1a@github.com>
 <T6mPh7rbe7f-Xpw0WuqSd5sSGnIEio17jGdQiFsw2so=.ca0d3316-656b-45bc-976c-8f5858bc87ff@github.com>
Message-ID: <zNh3VhimGSZcSG6T3xAB6Xz302HUtt6ySJLx0sovOJw=.f8da0c5d-761c-4fbe-bde0-8aeb772f2ff2@github.com>

On Fri, 12 Dec 2025 09:52:50 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Yes, I agree, we overlooked that we had that information inside `do_addr`.
>
> The remaining_words here are the remaining words in the "from"/"source" region, while the `words_remaining()` inside `do_addr` are the words remaining in the "to"/"destination" region. We could rename remaining_words to something like `from_words_remaining`?
> 
> The reason we can't handle this in `do_addr` is because obj_size can be larger than the words we have remaining in the from region.

Ahh. Thanks for the explanation.

I wonder if you could get rid of the confusion if you changed the code to be:

      markWord mark = safe_mark_prototype(cur_addr, end_addr);

And performed the calculation hidden iside the safe_mark_protype?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613656897

From thartmann at openjdk.org  Fri Dec 12 10:53:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 12 Dec 2025 10:53:19 GMT
Subject: [lworld] RFR: 8373374: [lworld] Remove Unsafe.get/putValue [v2]
In-Reply-To: <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>
References: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
 <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>
Message-ID: <stjH1eVwUblCRPleGFJaTjBGms-fehhimTePpVc76JQ=.8d789309-b678-4142-862d-4e770f5de0b2@github.com>

On Thu, 11 Dec 2025 18:00:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into cleanup/unsafe-value
>  - Remove get/putVal

C2 changes look good to me. Thanks!

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1782#pullrequestreview-3571332915

From jbhateja at openjdk.org  Fri Dec 12 10:56:44 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 12 Dec 2025 10:56:44 GMT
Subject: [lworld] RFR: 8373374: [lworld] Remove Unsafe.get/putValue [v2]
In-Reply-To: <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>
References: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
 <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>
Message-ID: <n-0q5xM8lh20VowAYa7kbPzZayFGuq7fVjv1QPV0Sps=.8746f3e4-1303-495d-b0f4-99ffd06bdabe@github.com>

On Thu, 11 Dec 2025 18:00:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into cleanup/unsafe-value
>  - Remove get/putVal

Marked as reviewed by jbhateja (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1782#pullrequestreview-3571344042

From jsikstro at openjdk.org  Fri Dec 12 10:59:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 10:59:55 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v3]
In-Reply-To: <zNh3VhimGSZcSG6T3xAB6Xz302HUtt6ySJLx0sovOJw=.f8da0c5d-761c-4fbe-bde0-8aeb772f2ff2@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <3gfRRvIG_15t0WUrIB-Efp-OdhqTru7M7ZzSFIBmYx4=.f7598e70-909f-4a55-94dd-d63d30533b0b@github.com>
 <WqGlAux_TvYcjZuUo9l84qtr-KeBsm0vOGBjBzSeX5I=.458edb17-7427-4d9e-b2db-22e9e0f35ad1@github.com>
 <I-sJTXSxmj5x7Xvngv72b6uiwIqR5lzmUXJ6bpXDwZE=.68d38628-1a2a-405e-a0d6-9f653ee0ea1a@github.com>
 <T6mPh7rbe7f-Xpw0WuqSd5sSGnIEio17jGdQiFsw2so=.ca0d3316-656b-45bc-976c-8f5858bc87ff@github.com>
 <zNh3VhimGSZcSG6T3xAB6Xz302HUtt6ySJLx0sovOJw=.f8da0c5d-761c-4fbe-bde0-8aeb772f2ff2@github.com>
Message-ID: <i9Knn6e2_XShJYuUv-ni5KUCenpz4GnNa_7ZLlYZGLw=.a8559626-4142-4937-ad98-7f554605a219@github.com>

On Fri, 12 Dec 2025 10:07:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The remaining_words here are the remaining words in the "from"/"source" region, while the `words_remaining()` inside `do_addr` are the words remaining in the "to"/"destination" region. We could rename remaining_words to something like `from_words_remaining`?
>> 
>> The reason we can't handle this in `do_addr` is because obj_size can be larger than the words we have remaining in the from region.
>
> Ahh. Thanks for the explanation.
> 
> I wonder if you could get rid of the confusion if you changed the code to be:
> 
>       markWord mark = safe_mark_prototype(cur_addr, end_addr);
> 
> And performed the calculation hidden iside the safe_mark_protype?

I like that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2613796316

From jsikstro at openjdk.org  Fri Dec 12 10:59:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 10:59:55 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is r...

Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:

 - Extract markWord preservation into static method
 - Don't pass words_remaining to safe_mark_word_prototype
 - Rename safe_mark_prototype to safe_mark_word_prototype

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1785/files
  - new: https://git.openjdk.org/valhalla/pull/1785/files/e9d214c3..6623c627

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

  Stats: 36 lines in 1 file changed: 19 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/1785.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1785/head:pull/1785

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

From sjohanss at openjdk.org  Fri Dec 12 11:02:43 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 12 Dec 2025 11:02:43 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
Message-ID: <yoNNBhKycvY6fn2utgIyqc9c0vbGu-8zh2djFvexD1o=.d8d0d183-a326-437c-8072-0d8b69c4d15a@github.com>

On Fri, 12 Dec 2025 10:59:55 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Extract markWord preservation into static method
>  - Don't pass words_remaining to safe_mark_word_prototype
>  - Rename safe_mark_prototype to safe_mark_word_prototype

Marked as reviewed by sjohanss (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3571361940

From stefank at openjdk.org  Fri Dec 12 12:27:22 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 12:27:22 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
Message-ID: <tQbFn2Hv6zkFB-3MV1a5-3-wNcZtTyuX-d7ANvaa9NE=.77852126-c199-4d1e-bbaa-1522363bdff9@github.com>

On Fri, 12 Dec 2025 10:59:55 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Extract markWord preservation into static method
>  - Don't pass words_remaining to safe_mark_word_prototype
>  - Rename safe_mark_prototype to safe_mark_word_prototype

This looks good to me.

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

Marked as reviewed by stefank (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3571618368

From phubner at openjdk.org  Fri Dec 12 12:27:22 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 12:27:22 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
Message-ID: <ez0ihgOGtym1VFsnhjKgMOAJoNJTKLKzjf4qoMF9_fo=.4e2b5022-292a-4b52-bb87-d62995f42487@github.com>

On Fri, 12 Dec 2025 10:59:55 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Extract markWord preservation into static method
>  - Don't pass words_remaining to safe_mark_word_prototype
>  - Rename safe_mark_prototype to safe_mark_word_prototype

Thank you! Ship it!

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3571622509

From coleenp at openjdk.org  Fri Dec 12 13:08:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 13:08:41 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
Message-ID: <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>

On Fri, 12 Dec 2025 10:59:55 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Extract markWord preservation into static method
>  - Don't pass words_remaining to safe_mark_word_prototype
>  - Rename safe_mark_prototype to safe_mark_word_prototype

Can you add a comment and move EnableValhalla into safe_to_read_header?
Thank you for fixing this properly in GC.

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1455:

> 1453:   precond(words > 0);
> 1454: 
> 1455:   const bool safe = words >= (size_t)oopDesc::header_size();

I don't know what this means.  Does header_size() include the markWord and klass pointer? ie 2 words for !UseCompactObjectHeaders? 
Is it safe if the number of words includes a klass pointer?
Can you enclose EnableValhalla in this method rather than asking in these callers?

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

Changes requested by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3571739175
PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2614144348

From phubner at openjdk.org  Fri Dec 12 13:25:44 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 13:25:44 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK,
 langtools and HotSpot tier 1 tests under --enable-preview
Message-ID: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>

Hi all,

Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.

This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).

Testing: tier1, with and without `--enable-preview`.

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

Commit messages:
 - Problemlist and fix.

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

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

From phubner at openjdk.org  Fri Dec 12 13:51:20 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 13:51:20 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v2]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <_krfPehEX32rwkCaqRweQy3UXWSM8MijxpoTo5SuGwQ=.58cf97f3-8b8b-461c-bade-5d2ca317d003@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

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

  Add one of the AOT tests.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/dc0e055e..3d138257

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

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

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

From jsikstro at openjdk.org  Fri Dec 12 14:04:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 14:04:47 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
 <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>
Message-ID: <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>

On Fri, 12 Dec 2025 13:03:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Extract markWord preservation into static method
>>  - Don't pass words_remaining to safe_mark_word_prototype
>>  - Rename safe_mark_prototype to safe_mark_word_prototype
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1455:
> 
>> 1453:   precond(words > 0);
>> 1454: 
>> 1455:   const bool safe = words >= (size_t)oopDesc::header_size();
> 
> I don't know what this means.  Does header_size() include the markWord and klass pointer? ie 2 words for !UseCompactObjectHeaders? 
> Is it safe if the number of words includes a klass pointer?
> Can you enclose EnableValhalla in this method rather than asking in these callers?

Yes, header_size() includes both markWord and Klass* and is 2 words for !UseCOH and 1 word for UseCOH. The header is safe to read if we have all of it, i.e. the full size. Otherwise it is not safe to read the Klass*, as it could be it the second word.

I'm not totally opposed to move the EnableValhalla check, but what we have right now is pretty similar to other places working with markWord's, like oopDesc::init_mark(), which I think is a plus. 

Also, moving the EnableValhalla check inside safe_to_read_header should give it another name, like (very explicit name) "need_to_read_header_and_safe". Keeping it the way it is allows a much easier refactor in the future once the EnableValhalla check is gone.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2614316220

From jsikstro at openjdk.org  Fri Dec 12 14:04:48 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 14:04:48 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
 <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>
 <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>
Message-ID: <-6xjSqFVrScWgELYvhFZUpujhJGmqVICIBoPnS_aODI=.b2fb7d09-0974-4d15-a579-f2bf20094ce5@github.com>

On Fri, 12 Dec 2025 14:02:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1455:
>> 
>>> 1453:   precond(words > 0);
>>> 1454: 
>>> 1455:   const bool safe = words >= (size_t)oopDesc::header_size();
>> 
>> I don't know what this means.  Does header_size() include the markWord and klass pointer? ie 2 words for !UseCompactObjectHeaders? 
>> Is it safe if the number of words includes a klass pointer?
>> Can you enclose EnableValhalla in this method rather than asking in these callers?
>
> Yes, header_size() includes both markWord and Klass* and is 2 words for !UseCOH and 1 word for UseCOH. The header is safe to read if we have all of it, i.e. the full size. Otherwise it is not safe to read the Klass*, as it could be it the second word.
> 
> I'm not totally opposed to move the EnableValhalla check, but what we have right now is pretty similar to other places working with markWord's, like oopDesc::init_mark(), which I think is a plus. 
> 
> Also, moving the EnableValhalla check inside safe_to_read_header should give it another name, like (very explicit name) "need_to_read_header_and_safe". Keeping it the way it is allows a much easier refactor in the future once the EnableValhalla check is gone.

Yes, header_size() includes both markWord and Klass* and is 2 words for !UseCOH and 1 word for UseCOH. The header is safe to read if we have all of it, i.e. the full size. Otherwise it is not safe to read the Klass*, as it could be it the second word.

I'm not totally opposed to move the EnableValhalla check, but what we have right now is pretty similar to other places working with markWord's, like oopDesc::init_mark(), which I think is a plus. 

Also, moving the EnableValhalla check inside safe_to_read_header should give it another name, like (very explicit name) "need_to_read_header_and_safe". Keeping it the way it is allows a much easier refactor in the future once the EnableValhalla check is gone.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2614316345

From zjx001202 at gmail.com  Fri Dec 12 15:02:23 2025
From: zjx001202 at gmail.com (Glavo)
Date: Fri, 12 Dec 2025 23:02:23 +0800
Subject: Why is it not supported to create References for value objects?
Message-ID: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>

Hi,

In the current draft of JEP 401, I saw the following statement:

> The garbage collection APIs in java.lang.ref and java.util.WeakHashMap do
not allow developers to manually manage value objects in the heap.
> Attempts to create Reference objects for value objects throw
IdentityException at run time.

We could clearly have pretended that all value objects exist forever and
are never collected, so that Reference or WeakHashMap would still work with
value objects.
Obviously, doing so would break far fewer existing codes, whereas having
them directly throw IdentityException would break a lot more code.

As an analogy, I think this is very similar to ThreadLocal on virtual
threads. Although virtual threads make many use cases of ThreadLocal
low-performance and high-memory,
Project Loom did not outright forbid users from using ThreadLocal on
virtual threads, yet Project Valhalla chose to break this (admittedly
inefficient) writing style.

I don?t understand why Project Valhalla made this choice. Has there been
any related discussion in the past? I?m really eager to know the reasoning
behind this decision.

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

From sjohanss at openjdk.org  Fri Dec 12 15:35:23 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Fri, 12 Dec 2025 15:35:23 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
Message-ID: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>

Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 

**Summary**
This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.

**Testing**
* mach5 tier1-3 (ongoing)

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

Commit messages:
 - 8373608: [lworld] Remove ObjBufferAllocator

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

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

From stefank at openjdk.org  Fri Dec 12 15:39:01 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 15:39:01 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
Message-ID: <iaVBEQeKRwScYY6dLLUZFLc8HMBVADWW2btQTCbQvn8=.4e8ff7af-7448-4334-a729-345a48311316@github.com>

On Fri, 12 Dec 2025 15:28:27 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
> 
> **Summary**
> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
> 
> **Testing**
> * mach5 tier1-3 (ongoing)

src/hotspot/share/prims/unsafe.cpp line 520:

> 518:   Handle vh(THREAD, v);
> 519:   InlineKlass* vk = InlineKlass::cast(v->klass());
> 520:   instanceOop new_value = vk->allocate_instance(CHECK_NULL);

This changes one instance in a function named Unsafe_MakePrivateBuffer. Is that also dead code now? I don't see any Java usage of that API:

$ grep -r akePrivateBuffer src/
src/hotspot/share/prims/unsafe.cpp:UNSAFE_ENTRY(jobject, Unsafe_MakePrivateBuffer(JNIEnv *env, jobject unsafe, jobject value)) {
src/hotspot/share/prims/unsafe.cpp:    {CC "makePrivateBuffer",     CC "(" OBJ ")" OBJ,      FN_PTR(Unsafe_MakePrivateBuffer)},
src/hotspot/share/classfile/vmIntrinsics.hpp:  do_name(makePrivateBuffer_name,"makePrivateBuffer")                                                                   \
src/hotspot/share/classfile/vmIntrinsics.hpp:  do_intrinsic(_makePrivateBuffer,  jdk_internal_misc_Unsafe,     makePrivateBuffer_name, object_object_signature, F_RN)   \
src/hotspot/share/classfile/vmIntrinsics.cpp:  case vmIntrinsics::_makePrivateBuffer:
src/hotspot/share/opto/doCall.cpp:  if (callee->intrinsic_id() == vmIntrinsics::_makePrivateBuffer || callee->intrinsic_id() == vmIntrinsics::_finishPrivateBuffer) {
src/hotspot/share/opto/doCall.cpp:    if (!rtype->is_void() && cg->method()->intrinsic_id() != vmIntrinsicID::_makePrivateBuffer) {
src/hotspot/share/opto/c2compiler.cpp:  case vmIntrinsics::_makePrivateBuffer:
src/hotspot/share/opto/graphKit.cpp:    // language, Unsafe::makePrivateBuffer returns an Object that is checkcast-ed to the concrete
src/hotspot/share/opto/library_call.cpp:  case vmIntrinsics::_makePrivateBuffer:        return inline_unsafe_make_private_buffer();
src/hotspot/share/opto/library_call.cpp:    C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");
src/hotspot/share/opto/library_call.cpp:    C->record_method_not_compilable("value passed to Unsafe::finishPrivateBuffer must be allocated by Unsafe::makePrivateBuffer");
src/java.base/share/classes/jdk/internal/misc/Unsafe.java:    public native <V> V makePrivateBuffer(V value);

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1794#discussion_r2614654286

From fparain at openjdk.org  Fri Dec 12 15:40:07 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Dec 2025 15:40:07 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <75LXNGzY8_fNyfvUvwY6NVCdizUS7vB_-IrBvwOFmOQ=.bd5c3e02-beb6-4b8d-a0fc-91ce16ef64a9@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>
 <aXFhG_1eHbZD8NCl8PNqbsKNu_NuZkCipLw1VlXLeJQ=.f1ae16a3-276c-49c3-9318-0bf562c2d86b@github.com>
 <75LXNGzY8_fNyfvUvwY6NVCdizUS7vB_-IrBvwOFmOQ=.bd5c3e02-beb6-4b8d-a0fc-91ce16ef64a9@github.com>
Message-ID: <sgIaQsTHC2xRSl6IroqKBkQGEcj8bKB1ENeVlfGD28o=.2637481b-3964-4cce-9883-08b2c5d9a7c5@github.com>

On Fri, 12 Dec 2025 02:45:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> First of all, any logic deciding the layout of an array should be in ObjArrayKlass::array_layout_selection().
>> We had layout logics in multiple places in the past, and they were getting out of sync very quickly.
>> So let's try to keep the decision logic in a single place. (Which means that the jvm.cpp code has to be modified anyway to just pass NULL_RESTRICTED | NON_ATOMIC to the array factory).
>> The fall back to the atomic layout makes sense in this case where the array creator asked for non-atomicity but the value class author didn't opt in non-atomicity.
>> So the code in ObjArrayKlass::Array_layout_selection() would become:
>> 
>> 
>> if (is_null_restricted(properties)) {
>>     if (is_non_atomic(properties)) {
>>       // Null-restricted + non-atomic
>>       if (vk->maybe_flat_in_array()) {
>>         if (vk->has_non_atomic_layout()) {
>>           return ArrayDescription(FlatArrayKlassKind, properties, LayoutKind::NON_ATOMIC_FLAT);
>>         } else if (vk->has_atomic_layout()) {
>>           return ArrayDescription(FlatArrayKlassKind, properties, LayoutKind::ATOMIC_FLAT);
>>         }
>>       }
>>       return ArrayDescription(RefArrayKlassKind, properties, LayoutKind::REFERENCE);
>>     } else {
>
> @fparain Thanks for your review, This is not about choosing a layout, however, it is about choosing a refined class for the array that is created by `ValueClass::newNullRestrictedNonAtomicArray`. If we go with your suggestion, then the array created by this method will have a different refined type from an array created by `ValueClass::newNullRestrictedAtomicArray`, which seems dangerous because C2 may try to assume that 2 classes having the same properties should be equal. As a result, I went with this change which asserts at `ObjArrayKlass::allocate_klass_with_properties` that non-atomic is only requested when it is possible to do so, and changed the call sites that may have this property popping up. The common point of those 2 sites is `ObjArrayKlass::klass_with_properties`, so I think it is less clear whether we should normalize the properties argument there instead. What do you think?

It has never been guaranteed, nor been a goal, to have `ValueClass::newNullRestrictedNonAtomicArray` and `ValueClass::newNullRestrictedAtomicArray` to return the same refined array class. The two factories aims are creating arrays with two different sets of properties. Depending on the characteristics of the element's class, they could have the same layout or not, but they are not the same "refinement".
Looking past JEP 401, it is likely that non-atomic flat arrays will have to consider the length of the array in the layout selection process (because of limitation on indexing inside humongous arrays), so it is possible that for a given element type and a set of nullness/atomicity properties, several refinements would exist.

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

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

From fparain at openjdk.org  Fri Dec 12 15:46:06 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Dec 2025 15:46:06 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <iaVBEQeKRwScYY6dLLUZFLc8HMBVADWW2btQTCbQvn8=.4e8ff7af-7448-4334-a729-345a48311316@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
 <iaVBEQeKRwScYY6dLLUZFLc8HMBVADWW2btQTCbQvn8=.4e8ff7af-7448-4334-a729-345a48311316@github.com>
Message-ID: <qfbxqEZtV8upZLs7r-94tvy5rkA8fcmgZwK8OK5MhRE=.2875f47e-d5de-4081-b842-bd5e1c76e7bb@github.com>

On Fri, 12 Dec 2025 15:36:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
>> 
>> **Summary**
>> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
>> 
>> **Testing**
>> * mach5 tier1-3 (ongoing)
>
> src/hotspot/share/prims/unsafe.cpp line 520:
> 
>> 518:   Handle vh(THREAD, v);
>> 519:   InlineKlass* vk = InlineKlass::cast(v->klass());
>> 520:   instanceOop new_value = vk->allocate_instance(CHECK_NULL);
> 
> This changes one instance in a function named Unsafe_MakePrivateBuffer. Is that also dead code now? I don't see any Java usage of that API:
> 
> $ grep -r akePrivateBuffer src/
> src/hotspot/share/prims/unsafe.cpp:UNSAFE_ENTRY(jobject, Unsafe_MakePrivateBuffer(JNIEnv *env, jobject unsafe, jobject value)) {
> src/hotspot/share/prims/unsafe.cpp:    {CC "makePrivateBuffer",     CC "(" OBJ ")" OBJ,      FN_PTR(Unsafe_MakePrivateBuffer)},
> src/hotspot/share/classfile/vmIntrinsics.hpp:  do_name(makePrivateBuffer_name,"makePrivateBuffer")                                                                   \
> src/hotspot/share/classfile/vmIntrinsics.hpp:  do_intrinsic(_makePrivateBuffer,  jdk_internal_misc_Unsafe,     makePrivateBuffer_name, object_object_signature, F_RN)   \
> src/hotspot/share/classfile/vmIntrinsics.cpp:  case vmIntrinsics::_makePrivateBuffer:
> src/hotspot/share/opto/doCall.cpp:  if (callee->intrinsic_id() == vmIntrinsics::_makePrivateBuffer || callee->intrinsic_id() == vmIntrinsics::_finishPrivateBuffer) {
> src/hotspot/share/opto/doCall.cpp:    if (!rtype->is_void() && cg->method()->intrinsic_id() != vmIntrinsicID::_makePrivateBuffer) {
> src/hotspot/share/opto/c2compiler.cpp:  case vmIntrinsics::_makePrivateBuffer:
> src/hotspot/share/opto/graphKit.cpp:    // language, Unsafe::makePrivateBuffer returns an Object that is checkcast-ed to the concrete
> src/hotspot/share/opto/library_call.cpp:  case vmIntrinsics::_makePrivateBuffer:        return inline_unsafe_make_private_buffer();
> src/hotspot/share/opto/library_call.cpp:    C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");
> src/hotspot/share/opto/library_call.cpp:    C->record_method_not_compilable("value passed to Unsafe::finishPrivateBuffer must be allocated by Unsafe::makePrivateBuffer");
> src/java.base/share/classes/jdk/internal/misc/Unsafe.java:    public native <V> V makePrivateBuffer(V value);

Unsafe_MakePrivateBuffer is used by the VectorAPI, which is a branch that depends on the `lworld` branch.
More details here: https://github.com/openjdk/valhalla/pull/1593

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1794#discussion_r2614678819

From dfenacci at openjdk.org  Fri Dec 12 16:08:12 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 12 Dec 2025 16:08:12 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph
In-Reply-To: <MBJo4oPmQ2YFyMFTf1AL5dN5ug_HJDsgMP4ofFKGp44=.ab760ae3-2762-4840-8f73-08045df746c5@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <MBJo4oPmQ2YFyMFTf1AL5dN5ug_HJDsgMP4ofFKGp44=.ab760ae3-2762-4840-8f73-08045df746c5@github.com>
Message-ID: <G-1DT1_1mdrTLQr9O71dlC8Sirvl41Cv8LuCqJnzGJ8=.0e733e62-d02c-4b20-8314-2fe28cf9fc24@github.com>

On Thu, 11 Dec 2025 16:01:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> # 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 ha...
>
> src/hotspot/share/opto/graphKit.cpp line 2052:
> 
>> 2050: 
>> 2051:         // Don't add store to buffer call if we are strength reducing
>> 2052:         if (!C->strength_reduction()) {
> 
> Can we use `_gvn.is_IterGVN() && !C->inlining_incrementally()` here instead? Assuming that whenever we call this after parsing and when not incrementally inlining, we are doing post-parse devirtualization of a call.

That's a possibility. I've also considered checking for `!C->inlining_incrementally() && C->late_inline_count() > 0` but I'm a bit torn between being 100% sure we are doing strength reduction but using a compile "flags" (a bit ?) and checking for other, already available, conditions (like the one you suggest), which make me a bit unsure and could potentially change in the future...
But I guess introducing a new field to `Compile` just for this should be avoided. So, let's go for `_gvn.is_IterGVN() && !C->inlining_incrementally()` ?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2614778037

From qamai at openjdk.org  Fri Dec 12 16:21:01 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 12 Dec 2025 16:21:01 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v8]
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: <Blph58-xMrl56HnXfKAV4fZU-6rVwTsIyxdYIxq9mLU=.b1a3c58e-c7da-4246-ba7f-029a539e0b83@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/39dba467..8a3da982

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

  Stats: 21 lines in 4 files changed: 6 ins; 9 del; 6 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 12 16:21:02 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 12 Dec 2025 16:21:02 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <_AUnQub310kMTCCjkX20tRzLPFqRNTdPoWGdbvSl_pM=.c230c99c-3272-4594-85b2-0d73fc8eb083@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>
 <w8u-QzWAoRxsXZCIT5ygiLz8hUeDxBs2LeaUuqci5hE=.a3509567-1d9c-41bf-9e01-ea8e3044def4@github.com>
 <_AUnQub310kMTCCjkX20tRzLPFqRNTdPoWGdbvSl_pM=.c230c99c-3272-4594-85b2-0d73fc8eb083@github.com>
Message-ID: <iQ4iwdwGc8rVJNBZYN9A5hqxedw3DtfNblYQElkoUjo=.7a9046e6-a3b8-49ef-aab3-98d6a82426e9@github.com>

On Thu, 11 Dec 2025 14:32:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Yes it is this one https://bugs.openjdk.org/browse/JDK-8331133
>
> Okay, maybe we should reference that here or at least file a Valhalla specific issue to keep track of it.

I have added a reference to the issue.

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

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

From qamai at openjdk.org  Fri Dec 12 16:21:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 12 Dec 2025 16:21:04 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <sgIaQsTHC2xRSl6IroqKBkQGEcj8bKB1ENeVlfGD28o=.2637481b-3964-4cce-9883-08b2c5d9a7c5@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>
 <aXFhG_1eHbZD8NCl8PNqbsKNu_NuZkCipLw1VlXLeJQ=.f1ae16a3-276c-49c3-9318-0bf562c2d86b@github.com>
 <75LXNGzY8_fNyfvUvwY6NVCdizUS7vB_-IrBvwOFmOQ=.bd5c3e02-beb6-4b8d-a0fc-91ce16ef64a9@github.com>
 <sgIaQsTHC2xRSl6IroqKBkQGEcj8bKB1ENeVlfGD28o=.2637481b-3964-4cce-9883-08b2c5d9a7c5@github.com>
Message-ID: <Mh5pNrcgy16s7oUJ_OA6JA6POkUBrKcTYZ8RtSlUs_E=.cd22074b-f0c9-4f9b-8cf8-130fd09764ea@github.com>

On Fri, 12 Dec 2025 15:37:37 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> @fparain Thanks for your review, This is not about choosing a layout, however, it is about choosing a refined class for the array that is created by `ValueClass::newNullRestrictedNonAtomicArray`. If we go with your suggestion, then the array created by this method will have a different refined type from an array created by `ValueClass::newNullRestrictedAtomicArray`, which seems dangerous because C2 may try to assume that 2 classes having the same properties should be equal. As a result, I went with this change which asserts at `ObjArrayKlass::allocate_klass_with_properties` that non-atomic is only requested when it is possible to do so, and changed the call sites that may have this property popping up. The common point of those 2 sites is `ObjArrayKlass::klass_with_properties`, so I think it is less clear whether we should normalize the properties argument there instead. What do you think?
>
> It has never been guaranteed, nor been a goal, to have `ValueClass::newNullRestrictedNonAtomicArray` and `ValueClass::newNullRestrictedAtomicArray` to return the same refined array class. The two factories aims are creating arrays with two different sets of properties. Depending on the characteristics of the element's class, they could have the same layout or not, but they are not the same "refinement".
> Looking past JEP 401, it is likely that non-atomic flat arrays will have to consider the length of the array in the layout selection process (because of limitation on indexing inside humongous arrays), so it is possible that for a given element type and a set of nullness/atomicity properties, several refinements would exist.

@fparain Thanks a lot for your explanation, I have made the change as you suggested.

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

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

From coleenp at openjdk.org  Fri Dec 12 16:21:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 16:21:40 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <FOnlmAu8uh7UsBpYjc2ypx41W8Hz1gr0ZiPnNqUBhe8=.cba09aa4-5b88-4a6d-9629-18063cc7aa42@github.com>

On Tue, 25 Nov 2025 13:37:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Except for EnableValhalla legacy comments that I think should be removed, this looks reasonable on it's own.  Does it pass our existing tier1-4 testing without updating problem lists ?

src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 104:

> 102:   assert_different_registers(obj, klass, len);
> 103: 
> 104:   // EnableValhalla legacy

I don't think this comment is necessary and kind of noisy everywhere, especially since there's Arguments::enable_preview() also tested.  The weird thing is that EnableValhalla is true but Arguments::enable_preview() is not always true so I see why it's good to have testing with both settings, we were exercising valhalla code even with enable-preview off.

src/hotspot/share/cds/cdsConfig.hpp line 211:

> 209: 
> 210:   // EnablePreview legacy
> 211:   static bool is_valhalla_preview() { return Arguments::enable_preview(); }

You might want to change all is_valhalla_preview() in CDS to just Arguments::enable_preview().  Or not.  Not completely necessary I guess.

test/hotspot/jtreg/serviceability/jvmti/valhalla/HeapDump/HeapDump.java line 153:

> 151: 
> 152:             // -XX:+PrintInlineLayout is debug-only arg
> 153:             LingeredApp.startApp(theApp, "--enable-preview", "-XX:+UnlockDiagnosticVMOptions",

Is there an if (debugvm) test that you need here?

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

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3568470576
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2611403488
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2611412940
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2611429239

From stefank at openjdk.org  Fri Dec 12 16:21:41 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 12 Dec 2025 16:21:41 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <hkxyBUsaB7DgfyaMjL_lbv_ZysDwJ1iMep1xF-PwYEA=.87fa141d-e53c-497a-8f15-80a02fb2f971@github.com>

On Tue, 25 Nov 2025 13:37:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Not a full review, but I think this looks good. If this is accepted you'll have to add includes of arguments.hpp to all places where you have added a call to `is_valhalla_enabled()`.

src/hotspot/share/runtime/arguments.cpp line 4005:

> 4003:     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
> 4004:   }
> 4005:   if (!Arguments::is_valhalla_enabled() || (is_interpreter_only() && !CDSConfig::is_dumping_archive() && !UseSharedSpaces)) {

Can this be just:
Suggestion:

  if (!is_valhalla_enabled() || (is_interpreter_only() && !CDSConfig::is_dumping_archive() && !UseSharedSpaces)) {

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

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3572302794
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2614606046

From phubner at openjdk.org  Fri Dec 12 16:21:43 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 16:21:43 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <hkxyBUsaB7DgfyaMjL_lbv_ZysDwJ1iMep1xF-PwYEA=.87fa141d-e53c-497a-8f15-80a02fb2f971@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <hkxyBUsaB7DgfyaMjL_lbv_ZysDwJ1iMep1xF-PwYEA=.87fa141d-e53c-497a-8f15-80a02fb2f971@github.com>
Message-ID: <n3tw3b7IV8ArqAEKd6WvJJdUW0pdw-uzqmjH4-GckqE=.4a246ac7-31fe-48a0-9fdc-3a0eef9cd6f1@github.com>

On Fri, 12 Dec 2025 15:24:16 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Not a full review, but I think this looks good. If this is accepted you'll have to add includes of arguments.hpp to all places where you have added a call to `is_valhalla_enabled()`.

Thanks for the feedback, it has been applied.

> src/hotspot/share/runtime/arguments.cpp line 4005:
> 
>> 4003:     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
>> 4004:   }
>> 4005:   if (!Arguments::is_valhalla_enabled() || (is_interpreter_only() && !CDSConfig::is_dumping_archive() && !UseSharedSpaces)) {
> 
> Can this be just:
> Suggestion:
> 
>   if (!is_valhalla_enabled() || (is_interpreter_only() && !CDSConfig::is_dumping_archive() && !UseSharedSpaces)) {

Good point.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3647195804
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2614657301

From phubner at openjdk.org  Fri Dec 12 16:21:44 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 16:21:44 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <FOnlmAu8uh7UsBpYjc2ypx41W8Hz1gr0ZiPnNqUBhe8=.cba09aa4-5b88-4a6d-9629-18063cc7aa42@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <FOnlmAu8uh7UsBpYjc2ypx41W8Hz1gr0ZiPnNqUBhe8=.cba09aa4-5b88-4a6d-9629-18063cc7aa42@github.com>
Message-ID: <wp4eO-eTu5HRVeXeD7m83mrVr6453A7NxfYHMmZfjvk=.d1c88710-7091-4b06-8656-1614d88e6598@github.com>

On Thu, 11 Dec 2025 17:13:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp line 104:
> 
>> 102:   assert_different_registers(obj, klass, len);
>> 103: 
>> 104:   // EnableValhalla legacy
> 
> I don't think this comment is necessary and kind of noisy everywhere, especially since there's Arguments::enable_preview() also tested.  The weird thing is that EnableValhalla is true but Arguments::enable_preview() is not always true so I see why it's good to have testing with both settings, we were exercising valhalla code even with enable-preview off.

Will remove.

> test/hotspot/jtreg/serviceability/jvmti/valhalla/HeapDump/HeapDump.java line 153:
> 
>> 151: 
>> 152:             // -XX:+PrintInlineLayout is debug-only arg
>> 153:             LingeredApp.startApp(theApp, "--enable-preview", "-XX:+UnlockDiagnosticVMOptions",
> 
> Is there an if (debugvm) test that you need here?

Good catch.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2614549751
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2614558311

From phubner at openjdk.org  Fri Dec 12 16:26:18 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 16:26:18 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <qfbxqEZtV8upZLs7r-94tvy5rkA8fcmgZwK8OK5MhRE=.2875f47e-d5de-4081-b842-bd5e1c76e7bb@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
 <iaVBEQeKRwScYY6dLLUZFLc8HMBVADWW2btQTCbQvn8=.4e8ff7af-7448-4334-a729-345a48311316@github.com>
 <qfbxqEZtV8upZLs7r-94tvy5rkA8fcmgZwK8OK5MhRE=.2875f47e-d5de-4081-b842-bd5e1c76e7bb@github.com>
Message-ID: <-zhQCMTK-_f1xuH0_jo8nibQLHBNJ6svhRNwiphHAcA=.1cd63dd1-bebc-43ea-9611-e3177f353fba@github.com>

On Fri, 12 Dec 2025 15:43:25 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> src/hotspot/share/prims/unsafe.cpp line 520:
>> 
>>> 518:   Handle vh(THREAD, v);
>>> 519:   InlineKlass* vk = InlineKlass::cast(v->klass());
>>> 520:   instanceOop new_value = vk->allocate_instance(CHECK_NULL);
>> 
>> This changes one instance in a function named Unsafe_MakePrivateBuffer. Is that also dead code now? I don't see any Java usage of that API:
>> 
>> $ grep -r akePrivateBuffer src/
>> src/hotspot/share/prims/unsafe.cpp:UNSAFE_ENTRY(jobject, Unsafe_MakePrivateBuffer(JNIEnv *env, jobject unsafe, jobject value)) {
>> src/hotspot/share/prims/unsafe.cpp:    {CC "makePrivateBuffer",     CC "(" OBJ ")" OBJ,      FN_PTR(Unsafe_MakePrivateBuffer)},
>> src/hotspot/share/classfile/vmIntrinsics.hpp:  do_name(makePrivateBuffer_name,"makePrivateBuffer")                                                                   \
>> src/hotspot/share/classfile/vmIntrinsics.hpp:  do_intrinsic(_makePrivateBuffer,  jdk_internal_misc_Unsafe,     makePrivateBuffer_name, object_object_signature, F_RN)   \
>> src/hotspot/share/classfile/vmIntrinsics.cpp:  case vmIntrinsics::_makePrivateBuffer:
>> src/hotspot/share/opto/doCall.cpp:  if (callee->intrinsic_id() == vmIntrinsics::_makePrivateBuffer || callee->intrinsic_id() == vmIntrinsics::_finishPrivateBuffer) {
>> src/hotspot/share/opto/doCall.cpp:    if (!rtype->is_void() && cg->method()->intrinsic_id() != vmIntrinsicID::_makePrivateBuffer) {
>> src/hotspot/share/opto/c2compiler.cpp:  case vmIntrinsics::_makePrivateBuffer:
>> src/hotspot/share/opto/graphKit.cpp:    // language, Unsafe::makePrivateBuffer returns an Object that is checkcast-ed to the concrete
>> src/hotspot/share/opto/library_call.cpp:  case vmIntrinsics::_makePrivateBuffer:        return inline_unsafe_make_private_buffer();
>> src/hotspot/share/opto/library_call.cpp:    C->record_method_not_compilable("value passed to Unsafe::makePrivateBuffer is not of a constant value type");
>> src/hotspot/share/opto/library_call.cpp:    C->record_method_not_compilable("value passed to Unsafe::finishPrivateBuffer must be allocated by Unsafe::makePrivateBuffer");
>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java:    public native <V> V makePrivateBuffer(V value);
>
> Unsafe_MakePrivateBuffer is used by the VectorAPI, which is a branch that depends on the `lworld` branch.
> More details here: https://github.com/openjdk/valhalla/pull/1593

In addition to what Fred said, we have `runtime/valhalla/inlinetypes/LarvalMarkWordTest.java` (and possibly others) which makes use of it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1794#discussion_r2614838354

From phubner at openjdk.org  Fri Dec 12 16:21:36 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 12 Dec 2025 16:21:36 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
Message-ID: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>

Hi all,

This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
* I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
* Some checks were redundant and could be removed entirely.
* I've made the `EnableValhalla` flag obsolete.
* Some tests had to be updated.

This greatly changes the semantics of tests. I've refined some test groups to make it easier.

Testing: tiers 1-4.

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

Commit messages:
 - Reviewer comments.
 - Copyright.
 - Revert "Don't synchronize on Double."
 - Accidentally changed too many enable_preview.
 - Make heap dump test require debug VM.
 - Change to arguments.
 - Use is_valhalla_enabled.
 - Remove unused file.
 - Reset problem lists.
 - Explode JDK groups and problemlist tests.
 - ... and 9 more: https://git.openjdk.org/valhalla/compare/c6706524...e8e771a9

Changes: https://git.openjdk.org/valhalla/pull/1759/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1759&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371357
  Stats: 157 lines in 55 files changed: 59 ins; 13 del; 85 mod
  Patch: https://git.openjdk.org/valhalla/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1759/head:pull/1759

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

From fparain at openjdk.org  Fri Dec 12 16:40:51 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Dec 2025 16:40:51 GMT
Subject: [lworld] RFR: 8373606: [lworld] PrintFlatArrayLayout should print
 LayoutKind and ArrayProperties
Message-ID: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>

Extend the information printed by PrintFlatArrayLayout to include LayoutKind and ArrayProperties.

Tested with Mach5 tier1

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

Commit messages:
 - Remove duplicated code
 - Add LayoutKind and ArrayProperties to PrintFlatArrayLayout

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

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

From fparain at openjdk.org  Fri Dec 12 16:48:18 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 12 Dec 2025 16:48:18 GMT
Subject: [lworld] RFR: 8373510: [lworld] Remove dead code in
 ConstantPool::klass_at_impl()
In-Reply-To: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
References: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
Message-ID: <Teg_zg7SQy3PyPbt7VdtUFB4xEbGelWrwHuQbWNXS6o=.309f198c-daae-4ba1-bae2-5b70aef0cc62@github.com>

On Thu, 11 Dec 2025 16:45:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of dead code in `ConstantPool::klass_at_impl`. The first is about the local `inline_type_signature` that is never written to after initialization, and the default value just disables some code, the other is an `else if` condition that is subsumed by the previous `if`.
> 
> Testing: local compilation,:hotspot_valhalla does not show additional failures
> 
> Thanks,
>   Thomas

Looks good to me.
Thank you.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1788#pullrequestreview-3572729263

From rriggs at openjdk.org  Fri Dec 12 17:43:19 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Dec 2025 17:43:19 GMT
Subject: [lworld] RFR: 8372729: [lworld] Incorrect result of acmp with
 flat, nullable value class field [v3]
In-Reply-To: <kN3s4D7wTGOFoPT1Uv2GDHXgZVOik81VK-258soHLYs=.012eabc4-d8dc-4efe-a0f5-5706472fe8c3@github.com>
References: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
 <kN3s4D7wTGOFoPT1Uv2GDHXgZVOik81VK-258soHLYs=.012eabc4-d8dc-4efe-a0f5-5706472fe8c3@github.com>
Message-ID: <ztwKDhaELYVmMyTV3nqwv4vfXkRD5wHraoDbIoaxCa4=.8740bdbe-69f8-4935-96e7-5e0b1b5d3b7a@github.com>

On Thu, 11 Dec 2025 22:22:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> LayoutIteration is missing null markers. Added the test from tobias to SubstitutabilityTest.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve tests
>  - Fix null marker detection
>  - Revert "Need to add delta"
>    
>    This reverts commit 18e5c26f258b0436a952275a2593a933e34dac31.

looks good.

Marked as reviewed by rriggs (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1790#pullrequestreview-3572937255
PR Review: https://git.openjdk.org/valhalla/pull/1790#pullrequestreview-3572937962

From jsikstro at openjdk.org  Fri Dec 12 18:08:27 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 12 Dec 2025 18:08:27 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
 <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>
 <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>
Message-ID: <UJE7ToNXspwRt69abj_TGmD9tvs8auVAJO-G5xuSGFY=.8d4d8b3c-a663-4da9-9554-97ed6956a41d@github.com>

On Fri, 12 Dec 2025 14:02:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1455:
>> 
>>> 1453:   precond(words > 0);
>>> 1454: 
>>> 1455:   const bool safe = words >= (size_t)oopDesc::header_size();
>> 
>> I don't know what this means.  Does header_size() include the markWord and klass pointer? ie 2 words for !UseCompactObjectHeaders? 
>> Is it safe if the number of words includes a klass pointer?
>> Can you enclose EnableValhalla in this method rather than asking in these callers?
>
> Yes, header_size() includes both markWord and Klass* and is 2 words for !UseCOH and 1 word for UseCOH. The header is safe to read if we have all of it, i.e. the full size. Otherwise it is not safe to read the Klass*, as it could be it the second word.
> 
> I'm not totally opposed to move the EnableValhalla check, but what we have right now is pretty similar to other places working with markWord's, like oopDesc::init_mark(), which I think is a plus. 
> 
> Also, moving the EnableValhalla check inside safe_to_read_header should give it another name, like (very explicit name) "need_to_read_header_and_safe". Keeping it the way it is allows a much easier refactor in the future once the EnableValhalla check is gone.

FYI, I accidentally sent my last comment twice and I deleted the other one so the mail-link got broken :)

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2615133024

From liach at openjdk.org  Fri Dec 12 18:13:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Dec 2025 18:13:21 GMT
Subject: [lworld] RFR: 8373374: [lworld] Remove Unsafe.get/putValue [v2]
In-Reply-To: <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>
References: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
 <e7WyMcXMRZhh2TfRNE3BUPSIpohpac_q-TjbU4ODcOk=.288d9dbc-70f8-41d0-a945-2f96f0ae760b@github.com>
Message-ID: <LsApbuYJD1t4m9oOBTrUo9qMfvLUL2QT7oK5GEmKW0E=.858fba97-bd28-4033-b449-f08ca16d9af2@github.com>

On Thu, 11 Dec 2025 18:00:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'lworld' of https://github.com/openjdk/valhalla into cleanup/unsafe-value
>  - Remove get/putVal

Tier 1-3 looks clear. Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1782#issuecomment-3647594896

From liach at openjdk.org  Fri Dec 12 18:13:22 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Dec 2025 18:13:22 GMT
Subject: [lworld] Integrated: 8373374: [lworld] Remove Unsafe.get/putValue
In-Reply-To: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
References: <LdsF-5E-KRU20MXHLFZ8ryBiwgJOWB6KHKHA0KN_abM=.a60337c7-1ecc-447d-aa9c-255a9ba02a1e@github.com>
Message-ID: <SFIodKK9Y_khy9nlfiyjGY5SB6h5oQG4A2_Egjcgxe0=.45c4baf2-6077-45a2-b717-30d13b6b2c1e@github.com>

On Tue, 9 Dec 2025 23:21:17 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the old Unsafe getValue and putValue, which had some performance difficulties because they are megamorphic depending on the exact layout.

This pull request has now been integrated.

Changeset: 2f2fd63d
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2f2fd63d7e320a20f13da87cb43a9979e7d19fad
Stats:     265 lines in 9 files changed: 2 ins; 239 del; 24 mod

8373374: [lworld] Remove Unsafe.get/putValue

Reviewed-by: thartmann, jbhateja

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

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

From brian.goetz at oracle.com  Fri Dec 12 18:39:12 2025
From: brian.goetz at oracle.com (Brian Goetz)
Date: Fri, 12 Dec 2025 13:39:12 -0500
Subject: Why is it not supported to create References for value objects?
In-Reply-To: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
References: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
Message-ID: <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>

Indeed, many hours of discussion went into this decision.

The basic problem is that all of the obvious answers are either 
surprising or surprisingly expensive.? We considered the following four 
approaches:

1.? Allow `new WR(value)`, which is cleared on birth.
2.? Allow `new WR(value)`, which is never cleared.
3.? Allow `new WR(value)`, which is cleared when all identities 
reachable through the value are become weakly reachable.
4.? Throw, and encourage implementations that are built on WR (such as 
WHM) to offer their own ways of dealing with values.

You can readily see how (1) would not be what anyone expects.

You are arguing for (2).? While this initially seems credible, its 
primary appeal is "yeah it's useless, but it won't break things that 
just throw everything in a WHM".? But it is actually worse than 
useless!? The purposes of WRs is to not unnecessarily pin things in 
memory.? But a WR that is never cleared does exactly that; if the 
referent holds identities, then it effectively becomes a strong reference.

(3) is a more principled answer, but is very expensive to implement, and 
its still not clear that this is what people will expect.

(4) is honest, if inconvenient.? Given that the majority of uses of WR 
are through higher-level constructs like WHM, which have more 
flexibility to choose the semantics that is right for their more 
restricted domain, it made sense to make this a WHM (and friends) 
problem than a WR problem (given that there were no good answers at the 
WR level.)

On 12/12/2025 10:02 AM, Glavo wrote:
> Hi,
>
> In the current draft of JEP 401, I saw the following statement:
>
> >?The garbage collection APIs in java.lang.ref and 
> java.util.WeakHashMap do not allow developers to manually manage value 
> objects in the heap.
> > Attempts to create Reference objects for value objects throw 
> IdentityException at run time.
>
> We could clearly have pretended that all value objects exist forever 
> and are never collected, so that Reference or WeakHashMap would still 
> work with value objects.
> Obviously, doing so would break far fewer existing codes, whereas 
> having them directly throw IdentityException would break a lot more code.
>
> As an analogy, I think this is very similar to ThreadLocal on virtual 
> threads. Although virtual threads make many use cases of ThreadLocal 
> low-performance and high-memory,
> Project Loom did not outright forbid users from using ThreadLocal on 
> virtual threads, yet Project Valhalla chose to break this (admittedly 
> inefficient) writing style.
>
> I don?t understand why Project Valhalla made this choice. Has there 
> been any related discussion in the past? I?m really eager to know the 
> reasoning behind this decision.
>
> Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251212/9bf5c767/attachment-0001.htm>

From coleenp at openjdk.org  Fri Dec 12 18:51:15 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 18:51:15 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v2]
In-Reply-To: <_krfPehEX32rwkCaqRweQy3UXWSM8MijxpoTo5SuGwQ=.58cf97f3-8b8b-461c-bade-5d2ca317d003@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <_krfPehEX32rwkCaqRweQy3UXWSM8MijxpoTo5SuGwQ=.58cf97f3-8b8b-461c-bade-5d2ca317d003@github.com>
Message-ID: <uzHJQQZaxgEaf1K8z6SH96CvifjcDMkbxX69y4oKtuo=.562dbdc0-5140-4c2e-9dab-916ef4f3b3ed@github.com>

On Fri, 12 Dec 2025 13:51:20 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add one of the AOT tests.

This looks good. Thank you for generating these lists and cross referencing to bugs.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1793#pullrequestreview-3573158384

From coleenp at openjdk.org  Fri Dec 12 19:27:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 19:27:28 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <UJE7ToNXspwRt69abj_TGmD9tvs8auVAJO-G5xuSGFY=.8d4d8b3c-a663-4da9-9554-97ed6956a41d@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
 <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>
 <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>
 <UJE7ToNXspwRt69abj_TGmD9tvs8auVAJO-G5xuSGFY=.8d4d8b3c-a663-4da9-9554-97ed6956a41d@github.com>
Message-ID: <KWRqEXZ1GE9u7dg-T2ti4qHRy01BofhymQ5U_8K1oYo=.87fb654e-a44c-4218-9661-0d0e3d72388a@github.com>

On Fri, 12 Dec 2025 18:06:10 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Yes, header_size() includes both markWord and Klass* and is 2 words for !UseCOH and 1 word for UseCOH. The header is safe to read if we have all of it, i.e. the full size. Otherwise it is not safe to read the Klass*, as it could be it the second word.
>> 
>> I'm not totally opposed to move the EnableValhalla check, but what we have right now is pretty similar to other places working with markWord's, like oopDesc::init_mark(), which I think is a plus. 
>> 
>> Also, moving the EnableValhalla check inside safe_to_read_header should give it another name, like (very explicit name) "need_to_read_header_and_safe". Keeping it the way it is allows a much easier refactor in the future once the EnableValhalla check is gone.
>
> FYI, I accidentally sent my last comment twice and I deleted the other one so the mail-link got broken :)

If you move EnableValhalla to inside safe_to_read_header(), then we'll only have to fix it once when it's only set when Arguments::is_valhalla_enabled() is set.  Right now EnablePreview is true by default.
EnableValhalla is a property that determines the answer to safe_to_read_header(), so I think it should go there.

Can you add a comment to safe_to_read_header() - the second sentence to the first paragraph above?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2615336124

From lmesnik at openjdk.org  Fri Dec 12 19:57:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 Dec 2025 19:57:24 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v2]
In-Reply-To: <_krfPehEX32rwkCaqRweQy3UXWSM8MijxpoTo5SuGwQ=.58cf97f3-8b8b-461c-bade-5d2ca317d003@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <_krfPehEX32rwkCaqRweQy3UXWSM8MijxpoTo5SuGwQ=.58cf97f3-8b8b-461c-bade-5d2ca317d003@github.com>
Message-ID: <wNVV5qNRn8_BOZ_g-v5Oqf-HONfmRKh7cPpWGChb1ss=.ea06b402-4763-4a7a-a8f5-08e40d0178a7@github.com>

On Fri, 12 Dec 2025 13:51:20 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add one of the AOT tests.

Changes requested by lmesnik (no project role).

test/jdk/ProblemList-enable-preview.txt line 40:

> 38: java/util/Collections/CheckedSetBash.java                       8372824 generic-all
> 39: jdk/internal/misc/CDS/ArchivedEnumTest.java                     8372743 generic-all
> 40: valhalla/valuetypes/ObjectMethodsViaCondy.java                  8369045 macosx-all

Should be these valhalla test in Problemlist-Xcomp.txt?

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

PR Review: https://git.openjdk.org/valhalla/pull/1793#pullrequestreview-3573386294
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2615405394

From coleenp at openjdk.org  Fri Dec 12 20:58:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Dec 2025 20:58:31 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break tests
 with inMemoryJavaCompiler
Message-ID: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>

This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.

When the jimage code is checked in, a bunch of tests fail because of this problem.

Testing with tier1-4.

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

Commit messages:
 - 8373622: [lworld] Enabling jimage changes break tests with inMemoryJavaCompiler

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

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

From zjx001202 at gmail.com  Fri Dec 12 21:16:45 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 13 Dec 2025 05:16:45 +0800
Subject: Why is it not supported to create References for value objects?
In-Reply-To: <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>
References: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
 <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>
Message-ID: <CAJL5A3kjjE64kaKjAJ6TzmM0E6V-wdw6uN_rRL4x47YtLxy0VA@mail.gmail.com>

Hi Brian,

This answer was unexpectedly simple to me.

Of course, I understand the common usage of WR. I clearly know that the
semantics I mentioned, while allowing some code to work, do not align with
the original intent of using WR in those contexts.

However, I believe throwing an exception is the worst option?far worse than
letting the WR turn into a strong reference.
This is because users have long had the obligation to handle OOM; they can
proactively trigger OOM for testing by reducing heap size or other means.
In contrast, users have never had the obligation to handle
IdentityException, nor any way to test it. As a result, an unexpected
exception could lead the program into untested code paths.
I even think throwing an exception is worse than directly letting the VM
crash, because some catch blocks might silently swallow the
IdentityException, making it much harder for users to understand why their
program behaved abnormally.

For me, a more ideal approach would be to print a warning by default when
creating a WR for a value object?at least this would make it easier for
developers to notice the issue.

Glavo

On Sat, Dec 13, 2025 at 2:39?AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Indeed, many hours of discussion went into this decision.
>
> The basic problem is that all of the obvious answers are either surprising
> or surprisingly expensive.  We considered the following four approaches:
>
> 1.  Allow `new WR(value)`, which is cleared on birth.
> 2.  Allow `new WR(value)`, which is never cleared.
> 3.  Allow `new WR(value)`, which is cleared when all identities reachable
> through the value are become weakly reachable.
> 4.  Throw, and encourage implementations that are built on WR (such as
> WHM) to offer their own ways of dealing with values.
>
> You can readily see how (1) would not be what anyone expects.
>
> You are arguing for (2).  While this initially seems credible, its primary
> appeal is "yeah it's useless, but it won't break things that just throw
> everything in a WHM".  But it is actually worse than useless!  The purposes
> of WRs is to not unnecessarily pin things in memory.  But a WR that is
> never cleared does exactly that; if the referent holds identities, then it
> effectively becomes a strong reference.
>
> (3) is a more principled answer, but is very expensive to implement, and
> its still not clear that this is what people will expect.
>
> (4) is honest, if inconvenient.  Given that the majority of uses of WR are
> through higher-level constructs like WHM, which have more flexibility to
> choose the semantics that is right for their more restricted domain, it
> made sense to make this a WHM (and friends) problem than a WR problem
> (given that there were no good answers at the WR level.)
>
> On 12/12/2025 10:02 AM, Glavo wrote:
>
> Hi,
>
> In the current draft of JEP 401, I saw the following statement:
>
> > The garbage collection APIs in java.lang.ref and java.util.WeakHashMap
> do not allow developers to manually manage value objects in the heap.
> > Attempts to create Reference objects for value objects throw
> IdentityException at run time.
>
> We could clearly have pretended that all value objects exist forever and
> are never collected, so that Reference or WeakHashMap would still work with
> value objects.
> Obviously, doing so would break far fewer existing codes, whereas having
> them directly throw IdentityException would break a lot more code.
>
> As an analogy, I think this is very similar to ThreadLocal on virtual
> threads. Although virtual threads make many use cases of ThreadLocal
> low-performance and high-memory,
> Project Loom did not outright forbid users from using ThreadLocal on
> virtual threads, yet Project Valhalla chose to break this (admittedly
> inefficient) writing style.
>
> I don?t understand why Project Valhalla made this choice. Has there been
> any related discussion in the past? I?m really eager to know the reasoning
> behind this decision.
>
> Glavo
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251213/a75cffcc/attachment.htm>

From davidalayachew at gmail.com  Fri Dec 12 22:40:10 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Fri, 12 Dec 2025 17:40:10 -0500
Subject: Why is it not supported to create References for value objects?
In-Reply-To: <CAJL5A3kjjE64kaKjAJ6TzmM0E6V-wdw6uN_rRL4x47YtLxy0VA@mail.gmail.com>
References: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
 <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>
 <CAJL5A3kjjE64kaKjAJ6TzmM0E6V-wdw6uN_rRL4x47YtLxy0VA@mail.gmail.com>
Message-ID: <CAA9v-_PPX0-UawsMiBKFx5A21xJJo71C9ioygPJPFQMOPcs-Bw@mail.gmail.com>

I don't agree that #4 is the worst option -- in fact, I think it is the
best of the 4. Though, my opinion might change with a prototype to play
with.

But regardless, I do agree that some sort of warning would be good.
Preferrably a JFR Event. Like Glavo said -- there are a lot of catch-all's
out there, so having the event **as well as** the exception sounds best to
me.

On Fri, Dec 12, 2025, 4:17?PM Glavo <zjx001202 at gmail.com> wrote:

> Hi Brian,
>
> This answer was unexpectedly simple to me.
>
> Of course, I understand the common usage of WR. I clearly know that the
> semantics I mentioned, while allowing some code to work, do not align with
> the original intent of using WR in those contexts.
>
> However, I believe throwing an exception is the worst option?far worse
> than letting the WR turn into a strong reference.
> This is because users have long had the obligation to handle OOM; they can
> proactively trigger OOM for testing by reducing heap size or other means.
> In contrast, users have never had the obligation to handle
> IdentityException, nor any way to test it. As a result, an unexpected
> exception could lead the program into untested code paths.
> I even think throwing an exception is worse than directly letting the VM
> crash, because some catch blocks might silently swallow the
> IdentityException, making it much harder for users to understand why their
> program behaved abnormally.
>
> For me, a more ideal approach would be to print a warning by default when
> creating a WR for a value object?at least this would make it easier for
> developers to notice the issue.
>
> Glavo
>
> On Sat, Dec 13, 2025 at 2:39?AM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Indeed, many hours of discussion went into this decision.
>>
>> The basic problem is that all of the obvious answers are either
>> surprising or surprisingly expensive.  We considered the following four
>> approaches:
>>
>> 1.  Allow `new WR(value)`, which is cleared on birth.
>> 2.  Allow `new WR(value)`, which is never cleared.
>> 3.  Allow `new WR(value)`, which is cleared when all identities reachable
>> through the value are become weakly reachable.
>> 4.  Throw, and encourage implementations that are built on WR (such as
>> WHM) to offer their own ways of dealing with values.
>>
>> You can readily see how (1) would not be what anyone expects.
>>
>> You are arguing for (2).  While this initially seems credible, its
>> primary appeal is "yeah it's useless, but it won't break things that just
>> throw everything in a WHM".  But it is actually worse than useless!  The
>> purposes of WRs is to not unnecessarily pin things in memory.  But a WR
>> that is never cleared does exactly that; if the referent holds identities,
>> then it effectively becomes a strong reference.
>>
>> (3) is a more principled answer, but is very expensive to implement, and
>> its still not clear that this is what people will expect.
>>
>> (4) is honest, if inconvenient.  Given that the majority of uses of WR
>> are through higher-level constructs like WHM, which have more flexibility
>> to choose the semantics that is right for their more restricted domain, it
>> made sense to make this a WHM (and friends) problem than a WR problem
>> (given that there were no good answers at the WR level.)
>>
>> On 12/12/2025 10:02 AM, Glavo wrote:
>>
>> Hi,
>>
>> In the current draft of JEP 401, I saw the following statement:
>>
>> > The garbage collection APIs in java.lang.ref and java.util.WeakHashMap
>> do not allow developers to manually manage value objects in the heap.
>> > Attempts to create Reference objects for value objects throw
>> IdentityException at run time.
>>
>> We could clearly have pretended that all value objects exist forever and
>> are never collected, so that Reference or WeakHashMap would still work with
>> value objects.
>> Obviously, doing so would break far fewer existing codes, whereas having
>> them directly throw IdentityException would break a lot more code.
>>
>> As an analogy, I think this is very similar to ThreadLocal on virtual
>> threads. Although virtual threads make many use cases of ThreadLocal
>> low-performance and high-memory,
>> Project Loom did not outright forbid users from using ThreadLocal on
>> virtual threads, yet Project Valhalla chose to break this (admittedly
>> inefficient) writing style.
>>
>> I don?t understand why Project Valhalla made this choice. Has there been
>> any related discussion in the past? I?m really eager to know the reasoning
>> behind this decision.
>>
>> Glavo
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251212/f8c6ff1a/attachment-0001.htm>

From zjx001202 at gmail.com  Fri Dec 12 23:10:23 2025
From: zjx001202 at gmail.com (Glavo)
Date: Sat, 13 Dec 2025 07:10:23 +0800
Subject: Why is it not supported to create References for value objects?
In-Reply-To: <CAA9v-_PPX0-UawsMiBKFx5A21xJJo71C9ioygPJPFQMOPcs-Bw@mail.gmail.com>
References: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
 <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>
 <CAJL5A3kjjE64kaKjAJ6TzmM0E6V-wdw6uN_rRL4x47YtLxy0VA@mail.gmail.com>
 <CAA9v-_PPX0-UawsMiBKFx5A21xJJo71C9ioygPJPFQMOPcs-Bw@mail.gmail.com>
Message-ID: <CAJL5A3mZoAUrkQ=1try2bFhowq+nUcsHXigX=Z-aWWZ3J7KjaA@mail.gmail.com>

Hi David,

I think I didn't explain myself very clearly. My ideal default behavior
would be to make WR a strong reference and print a warning.

Or, to be more specific, I hope its behavior is configurable (controlled by
a parameter similar to --illegal-native-access).
I would like it to have at least three modes of behavior:

1. allow: silently treat WR as a strong reference
2. warn: treat WR as a strong reference and emit a warning
3. deny: throw an IdentityException

The default should be behavior 1 or 2, and only in the relatively distant
future should we consider changing the default to 3.

Glavo

On Sat, Dec 13, 2025 at 6:40?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> I don't agree that #4 is the worst option -- in fact, I think it is the
> best of the 4. Though, my opinion might change with a prototype to play
> with.
>
> But regardless, I do agree that some sort of warning would be good.
> Preferrably a JFR Event. Like Glavo said -- there are a lot of catch-all's
> out there, so having the event **as well as** the exception sounds best to
> me.
>
> On Fri, Dec 12, 2025, 4:17?PM Glavo <zjx001202 at gmail.com> wrote:
>
>> Hi Brian,
>>
>> This answer was unexpectedly simple to me.
>>
>> Of course, I understand the common usage of WR. I clearly know that the
>> semantics I mentioned, while allowing some code to work, do not align with
>> the original intent of using WR in those contexts.
>>
>> However, I believe throwing an exception is the worst option?far worse
>> than letting the WR turn into a strong reference.
>> This is because users have long had the obligation to handle OOM; they
>> can proactively trigger OOM for testing by reducing heap size or other
>> means.
>> In contrast, users have never had the obligation to handle
>> IdentityException, nor any way to test it. As a result, an unexpected
>> exception could lead the program into untested code paths.
>> I even think throwing an exception is worse than directly letting the VM
>> crash, because some catch blocks might silently swallow the
>> IdentityException, making it much harder for users to understand why their
>> program behaved abnormally.
>>
>> For me, a more ideal approach would be to print a warning by default when
>> creating a WR for a value object?at least this would make it easier for
>> developers to notice the issue.
>>
>> Glavo
>>
>> On Sat, Dec 13, 2025 at 2:39?AM Brian Goetz <brian.goetz at oracle.com>
>> wrote:
>>
>>> Indeed, many hours of discussion went into this decision.
>>>
>>> The basic problem is that all of the obvious answers are either
>>> surprising or surprisingly expensive.  We considered the following four
>>> approaches:
>>>
>>> 1.  Allow `new WR(value)`, which is cleared on birth.
>>> 2.  Allow `new WR(value)`, which is never cleared.
>>> 3.  Allow `new WR(value)`, which is cleared when all identities
>>> reachable through the value are become weakly reachable.
>>> 4.  Throw, and encourage implementations that are built on WR (such as
>>> WHM) to offer their own ways of dealing with values.
>>>
>>> You can readily see how (1) would not be what anyone expects.
>>>
>>> You are arguing for (2).  While this initially seems credible, its
>>> primary appeal is "yeah it's useless, but it won't break things that just
>>> throw everything in a WHM".  But it is actually worse than useless!  The
>>> purposes of WRs is to not unnecessarily pin things in memory.  But a WR
>>> that is never cleared does exactly that; if the referent holds identities,
>>> then it effectively becomes a strong reference.
>>>
>>> (3) is a more principled answer, but is very expensive to implement, and
>>> its still not clear that this is what people will expect.
>>>
>>> (4) is honest, if inconvenient.  Given that the majority of uses of WR
>>> are through higher-level constructs like WHM, which have more flexibility
>>> to choose the semantics that is right for their more restricted domain, it
>>> made sense to make this a WHM (and friends) problem than a WR problem
>>> (given that there were no good answers at the WR level.)
>>>
>>> On 12/12/2025 10:02 AM, Glavo wrote:
>>>
>>> Hi,
>>>
>>> In the current draft of JEP 401, I saw the following statement:
>>>
>>> > The garbage collection APIs in java.lang.ref and java.util.WeakHashMap
>>> do not allow developers to manually manage value objects in the heap.
>>> > Attempts to create Reference objects for value objects throw
>>> IdentityException at run time.
>>>
>>> We could clearly have pretended that all value objects exist forever and
>>> are never collected, so that Reference or WeakHashMap would still work with
>>> value objects.
>>> Obviously, doing so would break far fewer existing codes, whereas having
>>> them directly throw IdentityException would break a lot more code.
>>>
>>> As an analogy, I think this is very similar to ThreadLocal on virtual
>>> threads. Although virtual threads make many use cases of ThreadLocal
>>> low-performance and high-memory,
>>> Project Loom did not outright forbid users from using ThreadLocal on
>>> virtual threads, yet Project Valhalla chose to break this (admittedly
>>> inefficient) writing style.
>>>
>>> I don?t understand why Project Valhalla made this choice. Has there been
>>> any related discussion in the past? I?m really eager to know the reasoning
>>> behind this decision.
>>>
>>> Glavo
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251213/e7ef0d19/attachment.htm>

From davidalayachew at gmail.com  Sat Dec 13 05:11:46 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 13 Dec 2025 00:11:46 -0500
Subject: Why is it not supported to create References for value objects?
In-Reply-To: <CAJL5A3mZoAUrkQ=1try2bFhowq+nUcsHXigX=Z-aWWZ3J7KjaA@mail.gmail.com>
References: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
 <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>
 <CAJL5A3kjjE64kaKjAJ6TzmM0E6V-wdw6uN_rRL4x47YtLxy0VA@mail.gmail.com>
 <CAA9v-_PPX0-UawsMiBKFx5A21xJJo71C9ioygPJPFQMOPcs-Bw@mail.gmail.com>
 <CAJL5A3mZoAUrkQ=1try2bFhowq+nUcsHXigX=Z-aWWZ3J7KjaA@mail.gmail.com>
Message-ID: <CAA9v-_N8H1yxzdPan0zjHhMBNskikLp1zvu07zhHb7VUtFge2Q@mail.gmail.com>

Oh I understood you the first time.

I don't think your idea is bad, I just prefer the exception idea better. My
response was to say that, even though I think sticking with
IdentityException is best, your idea about warning is good too **if done as
well as exceptions**.

Like you said, there are many people who do catch (Exception e) out there,
and this will silently give them new and potentially unwanted behaviour,
even in spite of going with #4. Hence my point -- let's also trigger a JFR
Event. That way, catch-all or not, you get notified.

On Fri, Dec 12, 2025, 6:11?PM Glavo <zjx001202 at gmail.com> wrote:

> Hi David,
>
> I think I didn't explain myself very clearly. My ideal default behavior
> would be to make WR a strong reference and print a warning.
>
> Or, to be more specific, I hope its behavior is configurable (controlled
> by a parameter similar to --illegal-native-access).
> I would like it to have at least three modes of behavior:
>
> 1. allow: silently treat WR as a strong reference
> 2. warn: treat WR as a strong reference and emit a warning
> 3. deny: throw an IdentityException
>
> The default should be behavior 1 or 2, and only in the relatively distant
> future should we consider changing the default to 3.
>
> Glavo
>
> On Sat, Dec 13, 2025 at 6:40?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> I don't agree that #4 is the worst option -- in fact, I think it is the
>> best of the 4. Though, my opinion might change with a prototype to play
>> with.
>>
>> But regardless, I do agree that some sort of warning would be good.
>> Preferrably a JFR Event. Like Glavo said -- there are a lot of catch-all's
>> out there, so having the event **as well as** the exception sounds best to
>> me.
>>
>> On Fri, Dec 12, 2025, 4:17?PM Glavo <zjx001202 at gmail.com> wrote:
>>
>>> Hi Brian,
>>>
>>> This answer was unexpectedly simple to me.
>>>
>>> Of course, I understand the common usage of WR. I clearly know that the
>>> semantics I mentioned, while allowing some code to work, do not align with
>>> the original intent of using WR in those contexts.
>>>
>>> However, I believe throwing an exception is the worst option?far worse
>>> than letting the WR turn into a strong reference.
>>> This is because users have long had the obligation to handle OOM; they
>>> can proactively trigger OOM for testing by reducing heap size or other
>>> means.
>>> In contrast, users have never had the obligation to handle
>>> IdentityException, nor any way to test it. As a result, an unexpected
>>> exception could lead the program into untested code paths.
>>> I even think throwing an exception is worse than directly letting the VM
>>> crash, because some catch blocks might silently swallow the
>>> IdentityException, making it much harder for users to understand why their
>>> program behaved abnormally.
>>>
>>> For me, a more ideal approach would be to print a warning by default
>>> when creating a WR for a value object?at least this would make it easier
>>> for developers to notice the issue.
>>>
>>> Glavo
>>>
>>> On Sat, Dec 13, 2025 at 2:39?AM Brian Goetz <brian.goetz at oracle.com>
>>> wrote:
>>>
>>>> Indeed, many hours of discussion went into this decision.
>>>>
>>>> The basic problem is that all of the obvious answers are either
>>>> surprising or surprisingly expensive.  We considered the following four
>>>> approaches:
>>>>
>>>> 1.  Allow `new WR(value)`, which is cleared on birth.
>>>> 2.  Allow `new WR(value)`, which is never cleared.
>>>> 3.  Allow `new WR(value)`, which is cleared when all identities
>>>> reachable through the value are become weakly reachable.
>>>> 4.  Throw, and encourage implementations that are built on WR (such as
>>>> WHM) to offer their own ways of dealing with values.
>>>>
>>>> You can readily see how (1) would not be what anyone expects.
>>>>
>>>> You are arguing for (2).  While this initially seems credible, its
>>>> primary appeal is "yeah it's useless, but it won't break things that just
>>>> throw everything in a WHM".  But it is actually worse than useless!  The
>>>> purposes of WRs is to not unnecessarily pin things in memory.  But a WR
>>>> that is never cleared does exactly that; if the referent holds identities,
>>>> then it effectively becomes a strong reference.
>>>>
>>>> (3) is a more principled answer, but is very expensive to implement,
>>>> and its still not clear that this is what people will expect.
>>>>
>>>> (4) is honest, if inconvenient.  Given that the majority of uses of WR
>>>> are through higher-level constructs like WHM, which have more flexibility
>>>> to choose the semantics that is right for their more restricted domain, it
>>>> made sense to make this a WHM (and friends) problem than a WR problem
>>>> (given that there were no good answers at the WR level.)
>>>>
>>>> On 12/12/2025 10:02 AM, Glavo wrote:
>>>>
>>>> Hi,
>>>>
>>>> In the current draft of JEP 401, I saw the following statement:
>>>>
>>>> > The garbage collection APIs in java.lang.ref and
>>>> java.util.WeakHashMap do not allow developers to manually manage value
>>>> objects in the heap.
>>>> > Attempts to create Reference objects for value objects throw
>>>> IdentityException at run time.
>>>>
>>>> We could clearly have pretended that all value objects exist forever
>>>> and are never collected, so that Reference or WeakHashMap would still work
>>>> with value objects.
>>>> Obviously, doing so would break far fewer existing codes, whereas
>>>> having them directly throw IdentityException would break a lot more code.
>>>>
>>>> As an analogy, I think this is very similar to ThreadLocal on virtual
>>>> threads. Although virtual threads make many use cases of ThreadLocal
>>>> low-performance and high-memory,
>>>> Project Loom did not outright forbid users from using ThreadLocal on
>>>> virtual threads, yet Project Valhalla chose to break this (admittedly
>>>> inefficient) writing style.
>>>>
>>>> I don?t understand why Project Valhalla made this choice. Has there
>>>> been any related discussion in the past? I?m really eager to know the
>>>> reasoning behind this decision.
>>>>
>>>> Glavo
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251213/44a65f8a/attachment-0001.htm>

From davidalayachew at gmail.com  Sat Dec 13 05:25:37 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 13 Dec 2025 00:25:37 -0500
Subject: Why is it not supported to create References for value objects?
In-Reply-To: <CAA9v-_N8H1yxzdPan0zjHhMBNskikLp1zvu07zhHb7VUtFge2Q@mail.gmail.com>
References: <CAJL5A3mE7VNvGwQGGV_7EkG-560yCB8HTn59Gfz0CAsUBBAV1w@mail.gmail.com>
 <cfab9c0a-ef74-482d-bf93-81df1b0eb35e@oracle.com>
 <CAJL5A3kjjE64kaKjAJ6TzmM0E6V-wdw6uN_rRL4x47YtLxy0VA@mail.gmail.com>
 <CAA9v-_PPX0-UawsMiBKFx5A21xJJo71C9ioygPJPFQMOPcs-Bw@mail.gmail.com>
 <CAJL5A3mZoAUrkQ=1try2bFhowq+nUcsHXigX=Z-aWWZ3J7KjaA@mail.gmail.com>
 <CAA9v-_N8H1yxzdPan0zjHhMBNskikLp1zvu07zhHb7VUtFge2Q@mail.gmail.com>
Message-ID: <CAA9v-_OrQ_8vOY6aH_SVFN0odMhhWB9v1kBmoZ91e_GvbiswYQ@mail.gmail.com>

And maybe I am not clear, I am saying that the idea of a toggle is not
really something I want. It feels like a bad bandaid. A WR to a value class
already is confusing, and to have a toggle, let alone one that defaults to
being permissive rather than restrictive, is worse in my eyes.

And even if it defaulted to fail, what purpose does the toggle serve?
Toggles like this make sense when we want to slowly wean a large number of
users off of some previously-acceptable behaviour. But I don't think there
were many people (of the already small number of WR users) making WR's of
Value Classes. In this case, the exception + JFR approach is the only one
thatmakes sense to me thus far. But of course, I say that without a
prototype in hand to test my claims.

On Sat, Dec 13, 2025, 12:11?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Oh I understood you the first time.
>
> I don't think your idea is bad, I just prefer the exception idea better.
> My response was to say that, even though I think sticking with
> IdentityException is best, your idea about warning is good too **if done as
> well as exceptions**.
>
> Like you said, there are many people who do catch (Exception e) out there,
> and this will silently give them new and potentially unwanted behaviour,
> even in spite of going with #4. Hence my point -- let's also trigger a JFR
> Event. That way, catch-all or not, you get notified.
>
> On Fri, Dec 12, 2025, 6:11?PM Glavo <zjx001202 at gmail.com> wrote:
>
>> Hi David,
>>
>> I think I didn't explain myself very clearly. My ideal default behavior
>> would be to make WR a strong reference and print a warning.
>>
>> Or, to be more specific, I hope its behavior is configurable (controlled
>> by a parameter similar to --illegal-native-access).
>> I would like it to have at least three modes of behavior:
>>
>> 1. allow: silently treat WR as a strong reference
>> 2. warn: treat WR as a strong reference and emit a warning
>> 3. deny: throw an IdentityException
>>
>> The default should be behavior 1 or 2, and only in the relatively distant
>> future should we consider changing the default to 3.
>>
>> Glavo
>>
>> On Sat, Dec 13, 2025 at 6:40?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>>> I don't agree that #4 is the worst option -- in fact, I think it is the
>>> best of the 4. Though, my opinion might change with a prototype to play
>>> with.
>>>
>>> But regardless, I do agree that some sort of warning would be good.
>>> Preferrably a JFR Event. Like Glavo said -- there are a lot of catch-all's
>>> out there, so having the event **as well as** the exception sounds best to
>>> me.
>>>
>>> On Fri, Dec 12, 2025, 4:17?PM Glavo <zjx001202 at gmail.com> wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> This answer was unexpectedly simple to me.
>>>>
>>>> Of course, I understand the common usage of WR. I clearly know that the
>>>> semantics I mentioned, while allowing some code to work, do not align with
>>>> the original intent of using WR in those contexts.
>>>>
>>>> However, I believe throwing an exception is the worst option?far worse
>>>> than letting the WR turn into a strong reference.
>>>> This is because users have long had the obligation to handle OOM; they
>>>> can proactively trigger OOM for testing by reducing heap size or other
>>>> means.
>>>> In contrast, users have never had the obligation to handle
>>>> IdentityException, nor any way to test it. As a result, an unexpected
>>>> exception could lead the program into untested code paths.
>>>> I even think throwing an exception is worse than directly letting the
>>>> VM crash, because some catch blocks might silently swallow the
>>>> IdentityException, making it much harder for users to understand why their
>>>> program behaved abnormally.
>>>>
>>>> For me, a more ideal approach would be to print a warning by default
>>>> when creating a WR for a value object?at least this would make it easier
>>>> for developers to notice the issue.
>>>>
>>>> Glavo
>>>>
>>>> On Sat, Dec 13, 2025 at 2:39?AM Brian Goetz <brian.goetz at oracle.com>
>>>> wrote:
>>>>
>>>>> Indeed, many hours of discussion went into this decision.
>>>>>
>>>>> The basic problem is that all of the obvious answers are either
>>>>> surprising or surprisingly expensive.  We considered the following four
>>>>> approaches:
>>>>>
>>>>> 1.  Allow `new WR(value)`, which is cleared on birth.
>>>>> 2.  Allow `new WR(value)`, which is never cleared.
>>>>> 3.  Allow `new WR(value)`, which is cleared when all identities
>>>>> reachable through the value are become weakly reachable.
>>>>> 4.  Throw, and encourage implementations that are built on WR (such as
>>>>> WHM) to offer their own ways of dealing with values.
>>>>>
>>>>> You can readily see how (1) would not be what anyone expects.
>>>>>
>>>>> You are arguing for (2).  While this initially seems credible, its
>>>>> primary appeal is "yeah it's useless, but it won't break things that just
>>>>> throw everything in a WHM".  But it is actually worse than useless!  The
>>>>> purposes of WRs is to not unnecessarily pin things in memory.  But a WR
>>>>> that is never cleared does exactly that; if the referent holds identities,
>>>>> then it effectively becomes a strong reference.
>>>>>
>>>>> (3) is a more principled answer, but is very expensive to implement,
>>>>> and its still not clear that this is what people will expect.
>>>>>
>>>>> (4) is honest, if inconvenient.  Given that the majority of uses of WR
>>>>> are through higher-level constructs like WHM, which have more flexibility
>>>>> to choose the semantics that is right for their more restricted domain, it
>>>>> made sense to make this a WHM (and friends) problem than a WR problem
>>>>> (given that there were no good answers at the WR level.)
>>>>>
>>>>> On 12/12/2025 10:02 AM, Glavo wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> In the current draft of JEP 401, I saw the following statement:
>>>>>
>>>>> > The garbage collection APIs in java.lang.ref and
>>>>> java.util.WeakHashMap do not allow developers to manually manage value
>>>>> objects in the heap.
>>>>> > Attempts to create Reference objects for value objects throw
>>>>> IdentityException at run time.
>>>>>
>>>>> We could clearly have pretended that all value objects exist forever
>>>>> and are never collected, so that Reference or WeakHashMap would still work
>>>>> with value objects.
>>>>> Obviously, doing so would break far fewer existing codes, whereas
>>>>> having them directly throw IdentityException would break a lot more code.
>>>>>
>>>>> As an analogy, I think this is very similar to ThreadLocal on virtual
>>>>> threads. Although virtual threads make many use cases of ThreadLocal
>>>>> low-performance and high-memory,
>>>>> Project Loom did not outright forbid users from using ThreadLocal on
>>>>> virtual threads, yet Project Valhalla chose to break this (admittedly
>>>>> inefficient) writing style.
>>>>>
>>>>> I don?t understand why Project Valhalla made this choice. Has there
>>>>> been any related discussion in the past? I?m really eager to know the
>>>>> reasoning behind this decision.
>>>>>
>>>>> Glavo
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251213/0d3f5b12/attachment.htm>

From dholmes at openjdk.org  Mon Dec 15 06:45:25 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 Dec 2025 06:45:25 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <n3tw3b7IV8ArqAEKd6WvJJdUW0pdw-uzqmjH4-GckqE=.4a246ac7-31fe-48a0-9fdc-3a0eef9cd6f1@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <hkxyBUsaB7DgfyaMjL_lbv_ZysDwJ1iMep1xF-PwYEA=.87fa141d-e53c-497a-8f15-80a02fb2f971@github.com>
 <n3tw3b7IV8ArqAEKd6WvJJdUW0pdw-uzqmjH4-GckqE=.4a246ac7-31fe-48a0-9fdc-3a0eef9cd6f1@github.com>
Message-ID: <myCzNY13e2NlF3R-v3T885WfyKmBUaczpRxsqBkp9GM=.08dc3018-4372-4ffd-8340-1fcef3466d35@github.com>

On Fri, 12 Dec 2025 16:07:09 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> is_valhalla_enabled

As Ioi suggested in the mainline argument.hpp PR shouldn't this be something more specific to what is actually being enabled in this preview release e.g. valueTypesConfig.hpp which defines `value_types_enabled` or some such?  IIUC for this release we are talking about JEP-401 features that are opted into when `--enable-preview` is added. But for the next release I assume there could be additional JEPs with 401 still also in preview - so `is_valhalla_enabled` is somewhat vague and doesn't identify what aspect of Valhalla a piece of code relates to.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3653729866

From stefank at openjdk.org  Mon Dec 15 08:40:23 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 08:40:23 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
Message-ID: <Um2d9SGjpXEY2FuJi0EG28zZ3whtt9kH8uaCjjeWq_I=.647aff89-0c68-4393-9cd9-bfb8860cb3ba@github.com>

On Fri, 12 Dec 2025 15:28:27 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
> 
> **Summary**
> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
> 
> **Testing**
> * mach5 tier1-3 (ongoing)

Looks good.

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

Marked as reviewed by stefank (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1794#pullrequestreview-3577030408

From stefank at openjdk.org  Mon Dec 15 08:40:24 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 08:40:24 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <-zhQCMTK-_f1xuH0_jo8nibQLHBNJ6svhRNwiphHAcA=.1cd63dd1-bebc-43ea-9611-e3177f353fba@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
 <iaVBEQeKRwScYY6dLLUZFLc8HMBVADWW2btQTCbQvn8=.4e8ff7af-7448-4334-a729-345a48311316@github.com>
 <qfbxqEZtV8upZLs7r-94tvy5rkA8fcmgZwK8OK5MhRE=.2875f47e-d5de-4081-b842-bd5e1c76e7bb@github.com>
 <-zhQCMTK-_f1xuH0_jo8nibQLHBNJ6svhRNwiphHAcA=.1cd63dd1-bebc-43ea-9611-e3177f353fba@github.com>
Message-ID: <RjRbOekcxaQZcisxycuwXIOIQ_gX5uJ-v2HcGLYAwNI=.b6fda300-4774-4ebf-a547-628ebba353de@github.com>

On Fri, 12 Dec 2025 16:23:18 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Unsafe_MakePrivateBuffer is used by the VectorAPI, which is a branch that depends on the `lworld` branch.
>> More details here: https://github.com/openjdk/valhalla/pull/1593
>
> In addition to what Fred said, we have `runtime/valhalla/inlinetypes/LarvalMarkWordTest.java` (and possibly others) which makes use of it.

OK. Let's take the larval-bit discussion seperately.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1794#discussion_r2618476429

From phubner at openjdk.org  Mon Dec 15 08:57:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 08:57:30 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <myCzNY13e2NlF3R-v3T885WfyKmBUaczpRxsqBkp9GM=.08dc3018-4372-4ffd-8340-1fcef3466d35@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <hkxyBUsaB7DgfyaMjL_lbv_ZysDwJ1iMep1xF-PwYEA=.87fa141d-e53c-497a-8f15-80a02fb2f971@github.com>
 <n3tw3b7IV8ArqAEKd6WvJJdUW0pdw-uzqmjH4-GckqE=.4a246ac7-31fe-48a0-9fdc-3a0eef9cd6f1@github.com>
 <myCzNY13e2NlF3R-v3T885WfyKmBUaczpRxsqBkp9GM=.08dc3018-4372-4ffd-8340-1fcef3466d35@github.com>
Message-ID: <dkg3BuoDqUKhwtDNJ9iIom75hvlN5O7q_uBVGuVztrM=.b472652f-1dfa-483d-b869-e0558e806361@github.com>

On Mon, 15 Dec 2025 06:42:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > is_valhalla_enabled
> 
> As Ioi suggested in the mainline argument.hpp PR shouldn't this be something more specific to what is actually being enabled in this preview release e.g. valueTypesConfig.hpp which defines `value_types_enabled` or some such? IIUC for this release we are talking about JEP-401 features that are opted into when `--enable-preview` is added. But for the next release I assume there could be additional JEPs with 401 still also in preview - so `is_valhalla_enabled` is somewhat vague and doesn't identify what aspect of Valhalla a piece of code relates to.

`is_valhalla_enabled` currently guards [JEP 401](https://openjdk.org/jeps/401) and [JEP draft strict field init](https://bugs.openjdk.org/browse/JDK-8350458). It's supposed to be a drop-in replacement for `--enable-preview` such that when reading code, it becomes clear that this is a Valhalla-related feature (and not some special EP handling in e.g., AOT). I agree that this may become ambiguous if there are multiple Valhalla JEPs in preview that offer distinct language-level features. I am moving the function to its own config, I'll see what I can do.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3654492770

From aboldtch at openjdk.org  Mon Dec 15 09:12:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 15 Dec 2025 09:12:55 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
Message-ID: <6AUOSeLZo4q1VYlVkRdy83pS-cMfb4zYJ1EW9gzNoUI=.989011af-9af5-449f-9382-64a686783dbf@github.com>

On Fri, 12 Dec 2025 10:07:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark oop_arraycopy as nodiscard
>  - Terminate OopCopyResult in oop_arraycopy_raw

I think it is more preferable having the exception code on the outside of the access layer.
Thanks for fixing this. Looks good.

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

Marked as reviewed by aboldtch (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1792#pullrequestreview-3577147457

From dfenacci at openjdk.org  Mon Dec 15 09:36:55 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 15 Dec 2025 09:36:55 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v2]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@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 ca...

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8369045: remove strength reduction flag

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1768/files
  - new: https://git.openjdk.org/valhalla/pull/1768/files/76f2e96f..ccf58125

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

  Stats: 9 lines in 3 files changed: 0 ins; 6 del; 3 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 dfenacci at openjdk.org  Mon Dec 15 09:45:18 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 15 Dec 2025 09:45:18 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v2]
In-Reply-To: <G-1DT1_1mdrTLQr9O71dlC8Sirvl41Cv8LuCqJnzGJ8=.0e733e62-d02c-4b20-8314-2fe28cf9fc24@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <MBJo4oPmQ2YFyMFTf1AL5dN5ug_HJDsgMP4ofFKGp44=.ab760ae3-2762-4840-8f73-08045df746c5@github.com>
 <G-1DT1_1mdrTLQr9O71dlC8Sirvl41Cv8LuCqJnzGJ8=.0e733e62-d02c-4b20-8314-2fe28cf9fc24@github.com>
Message-ID: <mLnduR9HuYndRggjcu307B1hYTYMkrLueuJFFLe0s_4=.b503065b-3b7a-4314-b2c7-355f5f528490@github.com>

On Fri, 12 Dec 2025 16:05:01 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> src/hotspot/share/opto/graphKit.cpp line 2052:
>> 
>>> 2050: 
>>> 2051:         // Don't add store to buffer call if we are strength reducing
>>> 2052:         if (!C->strength_reduction()) {
>> 
>> Can we use `_gvn.is_IterGVN() && !C->inlining_incrementally()` here instead? Assuming that whenever we call this after parsing and when not incrementally inlining, we are doing post-parse devirtualization of a call.
>
> That's a possibility. I've also considered checking for `!C->inlining_incrementally() && C->late_inline_count() > 0` but I'm a bit torn between being 100% sure we are doing strength reduction but using a compile "flags" (a bit ?) and checking for other, already available, conditions (like the one you suggest), which make me a bit unsure and could potentially change in the future...
> But I guess introducing a new field to `Compile` just for this should be avoided. So, let's go for `_gvn.is_IterGVN() && !C->inlining_incrementally()` ?

Fixed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2618686348

From jsikstro at openjdk.org  Mon Dec 15 10:04:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 15 Dec 2025 10:04:47 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v4]
In-Reply-To: <KWRqEXZ1GE9u7dg-T2ti4qHRy01BofhymQ5U_8K1oYo=.87fb654e-a44c-4218-9661-0d0e3d72388a@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <YkpBBn8DarxUXHwedaYPFlL_Fdi563NqpDp9Yq-9Hi8=.7bf95e7f-d653-4153-b8f2-faaaf76af4cd@github.com>
 <9YtFb7frlWni1OLjLFaRAOFoRtBu3hEWbyEkEMR5I4A=.a99c8b2a-935e-4190-95c1-e2ad686b281f@github.com>
 <z9eCZtFIvJKRdPlbb2HQi8HJOqVik8U1NZVVvexYlcI=.f0ebeffa-54d6-48ca-8ba9-a48b251d89cc@github.com>
 <UJE7ToNXspwRt69abj_TGmD9tvs8auVAJO-G5xuSGFY=.8d4d8b3c-a663-4da9-9554-97ed6956a41d@github.com>
 <KWRqEXZ1GE9u7dg-T2ti4qHRy01BofhymQ5U_8K1oYo=.87fb654e-a44c-4218-9661-0d0e3d72388a@github.com>
Message-ID: <hTQktm05JmIwjTzYDgRHBZo42TxuRVvZWENBrJUaNjg=.0804dc29-04d7-4728-99b7-b5b344dc0f98@github.com>

On Fri, 12 Dec 2025 19:25:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> EnableValhalla is a property that determines the answer to safe_to_read_header(), so I think it should go there.

I don't see EnableValhalla as something that determines the answer to safe_to_read_header(). Rather, we only need to check safe_to_read_header() if Valhalla is enabled. I think it's clearer to show at the call site that this is a Valhalla-specific concern, since checking if the header is safe to read or not isn't relevant otherwise.

I'll go ahead and add a comment to the current version of safe_to_read_header().

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1785#discussion_r2618752202

From aboldtch at openjdk.org  Mon Dec 15 10:13:11 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 15 Dec 2025 10:13:11 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <exHb2Ld9qdCs1WF457ElIqeIMBLFASxTvvDuQ3cB6MM=.c5593786-ab72-4d6f-b6c7-4de96326c701@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
 <exHb2Ld9qdCs1WF457ElIqeIMBLFASxTvvDuQ3cB6MM=.c5593786-ab72-4d6f-b6c7-4de96326c701@github.com>
Message-ID: <zxPxwxflIBiKhpHjnhlbo__cO6w7_9TDn5Lo5JSMGvI=.2fb183a6-445d-41ab-9382-6aba8639b31b@github.com>

On Fri, 12 Dec 2025 09:51:03 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> While problems I imagine are rather easy to solve, they might come more than once, and be an annoyance on the way of merging (that seems already painful enough as it is). I can imagine that the urgency of getting this change in valhalla justifies not to put it in mainline and wait for the next jdk merge, but is it planned to do the same in mainline soon, to avoid mentioned issues, and so mainline can also benefit from the change? If so, it would be nice to have a JBS issue to track that.

The plan is to push this into main line after it is in Valhalla repo. (Technically it can be done in parallel between, however i wanted buy-in here first).

>  I can imagine that the urgency of getting this change in valhalla justifies not to put it in mainline and wait for the next jdk merge

Maybe I am not understanding what you are trying to say here, but I do however not see how it is better to merge conflicting changes into mainline without a fix ready for Valhalla. In general I would say that merging into the project branch first and then breaking out patches for the upstream repo would result in less work. 

If this was just put into mainline, the next merge would not build, and resolving that would require implementing this patch (or reverting the main line patch as a part of the merge). Fairly trivial in this case, but would apply to most change sets of this nature. 

Maybe I am think about this wrong, or is missing something obvious. But to me merging changes into a downstream branch first and then upstreaming common changes seems like it would result in less work and lest amount of blockage in most cases.

>  If so, it would be nice to have a JBS issue to track that.

I agree, I should have been more clear, not just saying it should be in mainline, but that if we agree to this change it will be in mainline. Created: [JDK-8373668](https://bugs.openjdk.org/browse/JDK-8373668) / openjdk/jdk#28820

_I think in the general case this might not be the best workflow, as we should probably only upstream changes which we have found to be "stable". Right now there is an effort to reduce the 401 change set to its essentials. This involves cleaning up unnecessary vestigial parts, upstreaming stable mainline changes and finalising the Valhalla changes. Deciding that a change set is in the `upstreaming stable mainline change` category when it is introduced seems difficult. In this particular instance it does apply._

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

PR Comment: https://git.openjdk.org/valhalla/pull/1787#issuecomment-3654825459

From jsikstro at openjdk.org  Mon Dec 15 10:20:16 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 15 Dec 2025 10:20:16 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v5]
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is r...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Comment for safe check in safe_to_read_header

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1785/files
  - new: https://git.openjdk.org/valhalla/pull/1785/files/6623c627..4ac7e735

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

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

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

From stefank at openjdk.org  Mon Dec 15 10:20:16 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 10:20:16 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v5]
In-Reply-To: <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
Message-ID: <e4h6WuKZv51SACB-KfQnakovbqwgQGVlPy_e7hDXxio=.3df459b8-79cf-4cc5-b918-be3b14501915@github.com>

On Mon, 15 Dec 2025 10:17:18 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment for safe check in safe_to_read_header

Marked as reviewed by stefank (Author).

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

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3577415504

From mchevalier at openjdk.org  Mon Dec 15 10:43:20 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Mon, 15 Dec 2025 10:43:20 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
Message-ID: <O0CfmY8J_eI7KLkDQgOn5UQDRdTSE4yzLAxDj0N7Ndg=.0e5c823c-e4ff-493c-a8f6-0dfeaa997aeb@github.com>

On Thu, 11 Dec 2025 11:51:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 
> 
> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 
> 
> It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).
> 
> We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

Alright, I probably wasn't quite clear about the scenario I had in mind, but it doesn't matter too much. It sounds like we agree overall.

I've checked it builds even on Mac. I like it. Thanks!

Is there plans to put more override to other class hierarchies? It's just a bit sad it makes history (git log/blame) more messy while not being semantically very relevant.

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

Marked as reviewed by mchevalier (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1787#pullrequestreview-3577519317

From qamai at openjdk.org  Mon Dec 15 11:39:16 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 15 Dec 2025 11:39:16 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v9]
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: <InJObHVKD4xtVCS27XKvU1Q22UmamSWwrKlMCq803Yo=.bd02b68d-b8b4-49b6-b84b-e239aac57d3c@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 12 commits:

 - Merge branch 'lworld' into AryKlassPtrfactory
 - reviews
 - reviews
 - Should not clone MergeMem
 - fix NarrowMemProj
 - Merge branch 'lworld' into AryKlassPtrfactory
 - Fix Parse::array_store and PhaseMacroNode::value_from_mem
 - whitespace
 - fix more issues
 - Merge branch 'lworld' into AryKlassPtrfactory
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/2f2fd63d...84605fc1

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

Changes: https://git.openjdk.org/valhalla/pull/1755/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1755&range=08
  Stats: 590 lines in 21 files changed: 253 ins; 156 del; 181 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 15 11:39:19 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 15 Dec 2025 11:39:19 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: <01lY4nxAlQLndi95Hc8n5wxIYvWtl8-Muq2buFzhVIY=.e0be92bc-6fd1-4230-b2ff-b8ba765fc2b2@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 I think it would be great if you could do another round of testing for this PR. Thanks a lot!

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

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

From qamai at openjdk.org  Mon Dec 15 11:49:53 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 15 Dec 2025 11:49:53 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <_AUnQub310kMTCCjkX20tRzLPFqRNTdPoWGdbvSl_pM=.c230c99c-3272-4594-85b2-0d73fc8eb083@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>
 <w8u-QzWAoRxsXZCIT5ygiLz8hUeDxBs2LeaUuqci5hE=.a3509567-1d9c-41bf-9e01-ea8e3044def4@github.com>
 <_AUnQub310kMTCCjkX20tRzLPFqRNTdPoWGdbvSl_pM=.c230c99c-3272-4594-85b2-0d73fc8eb083@github.com>
Message-ID: <n02-oRScNw0uNs0Ho1HZPMs6k0wxi0WE8-Me6Kc_v9w=.9886f0ba-c76a-4272-8383-2ab4fcfbe75f@github.com>

On Thu, 11 Dec 2025 14:35:11 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> `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`.
>
> Should we cast it to `InlineTypeNode` in `LibraryCallKit::inline_newArray` instead?

I'm not sure, either. There is this TODO at `LibraryCallKit::inline_newArray`

    // TODO 8350865 Should we add a check of the init_val type (maybe in debug only + halt)?

Do you think I should insert a `checkcast` here or leave it as it is for now?

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

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

From tschatzl at openjdk.org  Mon Dec 15 12:00:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 15 Dec 2025 12:00:09 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
Message-ID: <AoP2l0ErYxiVLXFfFL_RqGnOUe06BEnu3bI9JHYMqoc=.9dc617cf-0db8-4492-bc56-d6db75d7c1ad@github.com>

On Fri, 12 Dec 2025 10:07:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark oop_arraycopy as nodiscard
>  - Terminate OopCopyResult in oop_arraycopy_raw

Marked as reviewed by tschatzl (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1792#pullrequestreview-3577784894

From dsimms at openjdk.org  Mon Dec 15 12:12:27 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 15 Dec 2025 12:12:27 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <_Twn9OgK9n0HAXL3OGorSyPiKeoqYJ5o36XKQx7aL24=.78935a20-772f-476a-9e14-1369b7d7bc7d@github.com>

Merge tag 'jdk-26+26' into lworld_merge_jdk_26_26

Added tag jdk-26+26 for changeset 847fbab7

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

Commit messages:
 - Merge jdk
 - 8352654: [REDO] nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called
 - 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code
 - 8372380: Make hs_err reporting more robust for unattached threads
 - 8350938: ResourceParsingClassHierarchyResolver inflates all Utf8 CP entries
 - 8371637: allocateNativeInternal sometimes return incorrectly aligned memory
 - 8371571: Consolidate and enhance bulk memory segment ops benchmarks
 - 8371146: C2 SuperWord: VTransform::add_speculative_check uses pre_init that is pinned after Auto_Vectorization_Check, leading to bad graph
 - 8369531: Wrong tooltip used in external class links
 - 8372055: Fragment link tag does not work in package info
 - ... and 101 more: https://git.openjdk.org/valhalla/compare/96dd7488...8d7dd33f

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

Changes: https://git.openjdk.org/valhalla/pull/1799/files
  Stats: 47377 lines in 703 files changed: 32974 ins; 9653 del; 4750 mod
  Patch: https://git.openjdk.org/valhalla/pull/1799.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1799/head:pull/1799

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

From dsimms at openjdk.org  Mon Dec 15 12:19:13 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 15 Dec 2025 12:19:13 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <_Twn9OgK9n0HAXL3OGorSyPiKeoqYJ5o36XKQx7aL24=.78935a20-772f-476a-9e14-1369b7d7bc7d@github.com>
References: <_Twn9OgK9n0HAXL3OGorSyPiKeoqYJ5o36XKQx7aL24=.78935a20-772f-476a-9e14-1369b7d7bc7d@github.com>
Message-ID: <yEChKfLeHLi0SlosBQt8PaPJ2AT1mr2i0c49MRGQ1L4=.988d79f6-495f-4f4e-b307-b64564a1acc6@github.com>

> Merge tag 'jdk-26+26' into lworld_merge_jdk_26_26
> 
> Added tag jdk-26+26 for changeset 847fbab7

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

 - Merge branch 'lworld' into lworld_merge_jdk_26_26
 - Merge jdk
   
   Merge tag 'jdk-26+26' into lworld_merge_jdk_26_26
   
   Added tag jdk-26+26 for changeset 847fbab7
 - 8352654: [REDO] nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called
   
   Reviewed-by: amenkov, sspitsyn
 - 8298432: Investigate the benefits of usage of GetPrimitiveArrayCritical in the cmm code
   
   Reviewed-by: psadhukhan, jdv, azvegint
 - 8372380: Make hs_err reporting more robust for unattached threads
   
   Reviewed-by: shade, aboldtch, kevinw
 - 8350938: ResourceParsingClassHierarchyResolver inflates all Utf8 CP entries
   
   Reviewed-by: liach, jpai
 - 8371637: allocateNativeInternal sometimes return incorrectly aligned memory
   
   Co-authored-by: Kurt Miller <kurt at openjdk.org>
   Reviewed-by: mcimadamore, jvernee
 - 8371571: Consolidate and enhance bulk memory segment ops benchmarks
   
   Reviewed-by: jvernee
 - 8371146: C2 SuperWord: VTransform::add_speculative_check uses pre_init that is pinned after Auto_Vectorization_Check, leading to bad graph
   
   Reviewed-by: roland, chagedorn
 - 8369531: Wrong tooltip used in external class links
   
   Reviewed-by: liach
 - ... and 102 more: https://git.openjdk.org/valhalla/compare/2f2fd63d...25fc7b75

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

Changes: https://git.openjdk.org/valhalla/pull/1799/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1799&range=01
  Stats: 47377 lines in 703 files changed: 32974 ins; 9653 del; 4750 mod
  Patch: https://git.openjdk.org/valhalla/pull/1799.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1799/head:pull/1799

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

From coleenp at openjdk.org  Mon Dec 15 13:58:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 13:58:52 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <xvdG_JYndOlOpfNmULqcr4Kq05NXbzsMfTWnPbCJ0UY=.418586ca-4672-4c11-afc9-ff0ee66f875a@github.com>

On Tue, 25 Nov 2025 13:37:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

This seems fine to me with or without a one line include file for is_valhalla_enabled() to test Arguments::enable_preview() or any other change for future preview or valhalla related features.  I think we can fix that for the specific situations when it happens.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3578330317

From stefank at openjdk.org  Mon Dec 15 14:53:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 14:53:05 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <yctZ4LzYxB-46j5ygKID8tVHVpDocoOhxuJ43nuz4sw=.588a631c-3a71-4bf6-a64f-ef5691ebb4d9@github.com>

On Tue, 25 Nov 2025 13:37:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Looks good minus one nit.

src/hotspot/share/opto/callnode.cpp line 1948:

> 1946:     Node* proto_adr = phase->transform(new AddPNode(klass_node, klass_node, phase->MakeConX(in_bytes(Klass::prototype_header_offset()))));
> 1947:     mark_node = LoadNode::make(*phase, control, mem, proto_adr, TypeRawPtr::BOTTOM, TypeX_X, TypeX_X->basic_type(), MemNode::unordered);
> 1948:     // EnavleValhalla legacy

Suggestion:

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

Marked as reviewed by stefank (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3578598315
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2619743262

From dsimms at openjdk.org  Mon Dec 15 15:18:30 2025
From: dsimms at openjdk.org (David Simms)
Date: Mon, 15 Dec 2025 15:18:30 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <_Twn9OgK9n0HAXL3OGorSyPiKeoqYJ5o36XKQx7aL24=.78935a20-772f-476a-9e14-1369b7d7bc7d@github.com>
References: <_Twn9OgK9n0HAXL3OGorSyPiKeoqYJ5o36XKQx7aL24=.78935a20-772f-476a-9e14-1369b7d7bc7d@github.com>
Message-ID: <v91E6qn4naIt93qomvQgvwEWCx8EhYNMxk9BlIKfOfw=.461c9932-67e3-4288-b312-d094475d8196@github.com>

On Mon, 15 Dec 2025 12:02:53 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+26' into lworld_merge_jdk_26_26
> 
> Added tag jdk-26+26 for changeset 847fbab7

This pull request has now been integrated.

Changeset: 2aa8c0df
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2aa8c0dfed85790e40c99b7ca21cb882aff711b2
Stats:     47377 lines in 703 files changed: 32974 ins; 9653 del; 4750 mod

Merge

Merge jdk-26+26

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

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

From fparain at openjdk.org  Mon Dec 15 15:26:25 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 15 Dec 2025 15:26:25 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
Message-ID: <GjBh8LrSgqxDSByg3_Rqcy6lnEEcGDGCfc873vq0BD0=.00a9aa81-4ee5-428b-8f4d-461b5db85073@github.com>

On Fri, 12 Dec 2025 10:07:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark oop_arraycopy as nodiscard
>  - Terminate OopCopyResult in oop_arraycopy_raw

Looks much cleaner!
LGTM.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1792#pullrequestreview-3578783488

From vromero at openjdk.org  Mon Dec 15 15:30:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Dec 2025 15:30:04 GMT
Subject: RFR: 8373620: [lworld] Substitute params with type j.l.r.RuntimeType
 by j.l.Class in j.l.runtime.ArrayCreation
Message-ID: <vCSX1YiBcch3UPZJ0qDBepI6koAowmwblJhxcUkZ9ns=.cf6dcaaf-8cbf-4f4a-92fb-a25d0ce785a5@github.com>

update methods in java.lang.runtime.ArrayCreation, change the arguments with type RuntimeType to java.lang.Class

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

Commit messages:
 - Merge branch 'JDK-8373620' of https://github.com/vicente-romero-oracle/valhalla into JDK-8373620
 - 8373620: [lw5] Change in java.lang.runtime.ArrayCreation API from RuntimeType to Class
 - 8373620: [lw5] Substitute params with type j.l.r.RuntimeType by j.l.Class in j.l.runtime.ArrayCreation

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

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

From vromero at openjdk.org  Mon Dec 15 15:34:11 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Dec 2025 15:34:11 GMT
Subject: RFR: 8373620: [lworld] [lw5] Substitute params with type
 j.l.r.RuntimeType by j.l.Class in j.l.runtime.ArrayCreation
In-Reply-To: <vCSX1YiBcch3UPZJ0qDBepI6koAowmwblJhxcUkZ9ns=.cf6dcaaf-8cbf-4f4a-92fb-a25d0ce785a5@github.com>
References: <vCSX1YiBcch3UPZJ0qDBepI6koAowmwblJhxcUkZ9ns=.cf6dcaaf-8cbf-4f4a-92fb-a25d0ce785a5@github.com>
Message-ID: <kvKfTuNPvfNrMWjKO-UHcR3M8ePAY7-WaiMkNYEvIJs=.6c68b4ee-84a6-4136-a80f-f3330320c427@github.com>

On Fri, 12 Dec 2025 18:44:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> update methods in java.lang.runtime.ArrayCreation, change the arguments with type RuntimeType to java.lang.Class

\touch

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

PR Comment: https://git.openjdk.org/valhalla/pull/1796#issuecomment-3656278164

From fparain at openjdk.org  Mon Dec 15 15:45:01 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 15 Dec 2025 15:45:01 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
Message-ID: <1ntGB5PVKhUWfKXVuBVbwbGC05lcetrlTojFv3B-eQs=.23beee34-221f-4318-8e5b-2d720c69df85@github.com>

On Thu, 11 Dec 2025 11:51:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 
> 
> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 
> 
> It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).
> 
> We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

Looks safer.
LGTM
Thank you.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1787#pullrequestreview-3578894666

From heidinga at openjdk.org  Mon Dec 15 15:48:08 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 15 Dec 2025 15:48:08 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
Message-ID: <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>

On Fri, 12 Dec 2025 10:07:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Mark oop_arraycopy as nodiscard
>  - Terminate OopCopyResult in oop_arraycopy_raw

src/hotspot/share/oops/access.hpp line 335:

> 333:   }
> 334: 
> 335:   [[nodiscard]]

Is it worth leaving a comment on why the `[[nodiscard]]` annotation was used here?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1792#discussion_r2619949491

From duke at openjdk.org  Mon Dec 15 15:53:50 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 15 Dec 2025 15:53:50 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <Qs5axX9MmWza7rIuaNdu31L5H8RLHf7yWXbNWw-f9RI=.633c5e79-5b7b-4e7a-bcfe-019e04a7e15a@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <Qs5axX9MmWza7rIuaNdu31L5H8RLHf7yWXbNWw-f9RI=.633c5e79-5b7b-4e7a-bcfe-019e04a7e15a@github.com>
Message-ID: <7aNk4cqeeHv4X6OaRU-7hAQ3rwJu-zWrmVDNU6t_5TY=.b9319092-96a3-4a96-bb20-edfa33ecbe81@github.com>

On Wed, 10 Dec 2025 10:34:35 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/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_"

Yes, it's "ref counting" but with non-fungeable counters. And yes, it implicitly relies on identity hashing (which should be made note of somewhere).

Splitting the owner-set into two or having a different internal key would be an option, but I think there's no reason to expect a class like JRTIndex to ever need more than system identity semantics (it's a service provider not a data object), so a comment is probably good for now.

I think JRTIndex can (and should) be made final, and I think a class-level comment should then suffice for future maintainers.

Thanks for bringing this up.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2619965833

From liach at openjdk.org  Mon Dec 15 15:56:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 15:56:18 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler
In-Reply-To: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
Message-ID: <wDXpRrFPVVOrqRR5hjHnoLN6-jloMiG-PybYjSk8_NI=.edf8c7c5-0d70-4661-b530-10def09d9538@github.com>

On Fri, 12 Dec 2025 20:53:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
> 
> When the jimage code is checked in, a bunch of tests fail because of this problem.
> 
> Testing with tier1-4.

test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 275:

> 273:                 opts.add("26");
> 274:             }
> 275:         }

if (System.getProperty("test.java.opts", "").contains("--enable-preview")
        || System.getProperty("test.enable.preview", "").equals("true")) {
        opts.add("--enable-preview");
        opts.add("-source");
        opts.add(Integer.toString(Runtime.version().feature()));
}

I recommend using `Runtime.version().feature()` instead of hardcoded version.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1797#discussion_r2619970670

From duke at openjdk.org  Mon Dec 15 16:02:48 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 15 Dec 2025 16:02:48 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <BFxPYa4_ecuG4IvX0eEcUN4agELrJk8oc5hGT0-826w=.c2ca422e-4912-4867-8e1a-a3840d706d9e@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <BFxPYa4_ecuG4IvX0eEcUN4agELrJk8oc5hGT0-826w=.c2ca422e-4912-4867-8e1a-a3840d706d9e@github.com>
Message-ID: <Hb-VfVMvt5pRQ_pK0kM7DmTqnrEAYXpX7MlhZ5fcQPo=.c4727c91-f3bc-4b2e-bf8a-8d4e216c7f33@github.com>

On Wed, 10 Dec 2025 10:51:06 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/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 :-)

Oh, for some reason it's got the reformatted version of the file I use for editing, not the "minimal diff" version I normally push. I can undo that. Sorry.

> 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

I think in the compiler you can't assume single threaded-ness, and unless this adds a deadlock risk (which I am pretty sure it doesn't) it's definitely my preference to have correctness and avoid weird bugs/failures.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2619986996
PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2619992479

From liach at openjdk.org  Mon Dec 15 16:18:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 16:18:03 GMT
Subject: [lworld] RFR: 8372729: [lworld] Incorrect result of acmp with
 flat, nullable value class field [v3]
In-Reply-To: <kN3s4D7wTGOFoPT1Uv2GDHXgZVOik81VK-258soHLYs=.012eabc4-d8dc-4efe-a0f5-5706472fe8c3@github.com>
References: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
 <kN3s4D7wTGOFoPT1Uv2GDHXgZVOik81VK-258soHLYs=.012eabc4-d8dc-4efe-a0f5-5706472fe8c3@github.com>
Message-ID: <B-7uW0njQilfOvlthDlmfz2WSE6BVCV7F3w6f5IFS40=.ea6f3f22-0c60-423d-b4f5-aa709c566c75@github.com>

On Thu, 11 Dec 2025 22:22:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> LayoutIteration is missing null markers. Added the test from tobias to SubstitutabilityTest.
>
> Chen Liang has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Improve tests
>  - Fix null marker detection
>  - Revert "Need to add delta"
>    
>    This reverts commit 18e5c26f258b0436a952275a2593a933e34dac31.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1790#issuecomment-3656481741

From liach at openjdk.org  Mon Dec 15 16:20:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 16:20:33 GMT
Subject: [lworld] Integrated: 8372729: [lworld] Incorrect result of acmp with
 flat, nullable value class field
In-Reply-To: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
References: <DEVls-ylayDrFaz6TdygQtDUew2VaHo981tRP1cLHuc=.e6411c38-0aae-4bb6-b216-b23e3459a4c2@github.com>
Message-ID: <bST5p1j_m8vxtpv3f3zmG7ncBIxbCX5L6tx6c-uN-sI=.e7d63809-bb6d-4785-adf6-b71fa6ef43d4@github.com>

On Thu, 11 Dec 2025 19:40:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> LayoutIteration is missing null markers. Added the test from tobias to SubstitutabilityTest.

This pull request has now been integrated.

Changeset: 51ff8f43
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/51ff8f43613c2d0d8ef5498f7a52c533bc4584ed
Stats:     138 lines in 3 files changed: 137 ins; 0 del; 1 mod

8372729: [lworld] Incorrect result of acmp with flat, nullable value class field

Reviewed-by: rriggs

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

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

From coleenp at openjdk.org  Mon Dec 15 16:26:55 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 16:26:55 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler
In-Reply-To: <wDXpRrFPVVOrqRR5hjHnoLN6-jloMiG-PybYjSk8_NI=.edf8c7c5-0d70-4661-b530-10def09d9538@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <wDXpRrFPVVOrqRR5hjHnoLN6-jloMiG-PybYjSk8_NI=.edf8c7c5-0d70-4661-b530-10def09d9538@github.com>
Message-ID: <dJNnMnmF0i_tVHKSp7EV5mDPtzsSgNkfl3fyeNLidG8=.fc136e83-b9fc-428d-9f18-d7c4533adb3a@github.com>

On Mon, 15 Dec 2025 15:52:56 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 275:
> 
>> 273:                 opts.add("26");
>> 274:             }
>> 275:         }
> 
> if (System.getProperty("test.java.opts", "").contains("--enable-preview")
>         || System.getProperty("test.enable.preview", "").equals("true")) {
>         opts.add("--enable-preview");
>         opts.add("-source");
>         opts.add(Integer.toString(Runtime.version().feature()));
> }
> 
> I recommend using `Runtime.version().feature()` instead of hardcoded version.

Oh okay thank you that's much nicer.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1797#discussion_r2620059768

From phubner at openjdk.org  Mon Dec 15 16:31:40 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 16:31:40 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v3]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <_4rFGKY3pJUZu8O3QqbTobzd1HpTGd7Y2zoIJQgZ6Yo=.75173d10-40f9-4176-953d-11b31d9fc6ae@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

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

  Add failing test to problemlist.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/3d138257..477e595a

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

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

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

From jlahoda at openjdk.org  Mon Dec 15 16:35:31 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 15 Dec 2025 16:35:31 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <Hb-VfVMvt5pRQ_pK0kM7DmTqnrEAYXpX7MlhZ5fcQPo=.c4727c91-f3bc-4b2e-bf8a-8d4e216c7f33@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <BFxPYa4_ecuG4IvX0eEcUN4agELrJk8oc5hGT0-826w=.c2ca422e-4912-4867-8e1a-a3840d706d9e@github.com>
 <Hb-VfVMvt5pRQ_pK0kM7DmTqnrEAYXpX7MlhZ5fcQPo=.c4727c91-f3bc-4b2e-bf8a-8d4e216c7f33@github.com>
Message-ID: <DIyRJz0ol38V2CDx20rokQPqEqEpW7J--tzWUr7uanw=.de6339a7-0e16-4c96-8884-4f72f013823b@github.com>

On Mon, 15 Dec 2025 16:00:30 GMT, David Beaumont <duke at openjdk.org> wrote:

>> 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
>
> I think in the compiler you can't assume single threaded-ness, and unless this adds a deadlock risk (which I am pretty sure it doesn't) it's definitely my preference to have correctness and avoid weird bugs/failures.

One instance of javac (i.e. one result of `ToolProvider.getSystemJavaCompiler().getTask(...)` is single-threaded, and cannot even be passed to a different thread without an external synchronization. There's no need for synchronization inside single instance of javac.

The case of file managers is a bit different: some backend data structures (like `JRTIndex` as such) are shared across various instances of file managers, and those definitely need to be synchronized. To what degree synchronization is needed here is unclear to me. The javadoc says that multi-threaded access to file managers is not required, and I don't think that concurrent use of the `JavacFileManager` from multiple instances of javac  is quite realistic (settings like multi-release or preview setting are kept in fields in the file manager, and the different instances of javac would talk past each other).

I.e. I don't think the synchronization here is really necessary. OTOH, the `JavacFileManager.getJRTIndex()` is currently synchronized, and it would seem more consistent for the `getJRTIndex()` and `closeables` to share the same synchronization approach. I would agree with Maurizio that I would mildly prefer to drop the synchronization, but I can live with the synchronization.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2620083325

From coleenp at openjdk.org  Mon Dec 15 16:37:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 16:37:41 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v5]
In-Reply-To: <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
Message-ID: <sbj7erfXG7WxZEXGBCgEIUHJjzwCaM4tZ0KjBA-jfuw=.a050b892-4f43-4355-93b2-4af15f37ecc7@github.com>

On Mon, 15 Dec 2025 10:20:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment for safe check in safe_to_read_header

Okay thanks for the comment.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1785#pullrequestreview-3579126669

From phubner at openjdk.org  Mon Dec 15 16:39:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 16:39:03 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v2]
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <pdGlZDbl1MXnQWUkefCQ8YR0f-pmlpxijD3jnagqczQ=.5b16f8c4-f748-4ea3-87ff-757d157a3158@github.com>

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:

 - Remove wrong comment.
 - Fix imports.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1759/files
  - new: https://git.openjdk.org/valhalla/pull/1759/files/e8e771a9..71f120ef

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

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

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

From phubner at openjdk.org  Mon Dec 15 16:39:06 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 16:39:06 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v2]
In-Reply-To: <yctZ4LzYxB-46j5ygKID8tVHVpDocoOhxuJ43nuz4sw=.588a631c-3a71-4bf6-a64f-ef5691ebb4d9@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <yctZ4LzYxB-46j5ygKID8tVHVpDocoOhxuJ43nuz4sw=.588a631c-3a71-4bf6-a64f-ef5691ebb4d9@github.com>
Message-ID: <uInlOvyX54yAtNF2LvC8zfMHO6F860e2QiRU3sKO8JE=.9788aaf1-825e-4760-8503-49b3e04e267c@github.com>

On Mon, 15 Dec 2025 14:48:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove wrong comment.
>>  - Fix imports.
>
> src/hotspot/share/opto/callnode.cpp line 1948:
> 
>> 1946:     Node* proto_adr = phase->transform(new AddPNode(klass_node, klass_node, phase->MakeConX(in_bytes(Klass::prototype_header_offset()))));
>> 1947:     mark_node = LoadNode::make(*phase, control, mem, proto_adr, TypeRawPtr::BOTTOM, TypeX_X, TypeX_X->basic_type(), MemNode::unordered);
>> 1948:     // EnavleValhalla legacy
> 
> Suggestion:

Good shout, I missed that thanks.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2620091976

From coleenp at openjdk.org  Mon Dec 15 16:43:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 16:43:23 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v2]
In-Reply-To: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
Message-ID: <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>

> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
> 
> When the jimage code is checked in, a bunch of tests fail because of this problem.
> 
> Testing with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix version for javac to be latest version.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1797/files
  - new: https://git.openjdk.org/valhalla/pull/1797/files/a0839689..2ae8d25e

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

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

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

From phubner at openjdk.org  Mon Dec 15 16:45:53 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 16:45:53 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v2]
In-Reply-To: <yctZ4LzYxB-46j5ygKID8tVHVpDocoOhxuJ43nuz4sw=.588a631c-3a71-4bf6-a64f-ef5691ebb4d9@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <yctZ4LzYxB-46j5ygKID8tVHVpDocoOhxuJ43nuz4sw=.588a631c-3a71-4bf6-a64f-ef5691ebb4d9@github.com>
Message-ID: <CP3LYtMk7yCHl84RnvuTccJbcDUF1R6waXz1a8764TA=.8c85af72-6e29-4324-9b8d-7ad9ba275f76@github.com>

On Mon, 15 Dec 2025 14:50:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove wrong comment.
>>  - Fix imports.
>
> Looks good minus one nit.

Thanks for the feedback, everyone. After a face-to-face discussion, we decided this shape (without explicit feature granularity or its own file) is sufficient for our current needs. Sole `--enable-preview` for Valhalla is a large change that will be delivered incrementally. This is only the start, and many subsequent changes depend on this change.  I've filed a follow-up RFE https://bugs.openjdk.org/browse/JDK-8373694, where we can devote more (non-blocking) time and discussion towards how a better way of checking may look. Ideally, @stefank's mainline changes will have made it into lworld by then too.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3656622888

From coleenp at openjdk.org  Mon Dec 15 16:53:36 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 16:53:36 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v2]
In-Reply-To: <pdGlZDbl1MXnQWUkefCQ8YR0f-pmlpxijD3jnagqczQ=.5b16f8c4-f748-4ea3-87ff-757d157a3158@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <pdGlZDbl1MXnQWUkefCQ8YR0f-pmlpxijD3jnagqczQ=.5b16f8c4-f748-4ea3-87ff-757d157a3158@github.com>
Message-ID: <2E5WiDMtV1ywJ0qXYqjIdEH61u33NG_XrB_CWD3DEhw=.2fba5bb2-e39a-4ed2-a5c3-433a6671586d@github.com>

On Mon, 15 Dec 2025 16:39:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove wrong comment.
>  - Fix imports.

Marked as reviewed by coleenp (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3579206047

From liach at openjdk.org  Mon Dec 15 17:01:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 17:01:55 GMT
Subject: RFR: 8373620: [lworld] [lw5] Substitute params with type
 j.l.r.RuntimeType by j.l.Class in j.l.runtime.ArrayCreation
In-Reply-To: <vCSX1YiBcch3UPZJ0qDBepI6koAowmwblJhxcUkZ9ns=.cf6dcaaf-8cbf-4f4a-92fb-a25d0ce785a5@github.com>
References: <vCSX1YiBcch3UPZJ0qDBepI6koAowmwblJhxcUkZ9ns=.cf6dcaaf-8cbf-4f4a-92fb-a25d0ce785a5@github.com>
Message-ID: <vBo5UksJt3yl0rMI48loJashZrl2uFaHRVHwzc325FI=.958866f2-3aef-4046-a599-b7d2c8a47556@github.com>

On Fri, 12 Dec 2025 18:44:07 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> update methods in java.lang.runtime.ArrayCreation, change the arguments with type RuntimeType to java.lang.Class

I assume you have other ways to pass the flags later.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1796#pullrequestreview-3579234230

From liach at openjdk.org  Mon Dec 15 17:06:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 17:06:33 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v2]
In-Reply-To: <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
Message-ID: <1ZAdGlZhzb7LM72RuNBNShk9a6AsaZryG3hfsPzR9Cw=.9025228d-2f1c-413c-ad4f-ed723118f96c@github.com>

On Mon, 15 Dec 2025 16:43:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix version for javac to be latest version.

lgtm

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1797#pullrequestreview-3579256197

From matsaave at openjdk.org  Mon Dec 15 17:55:57 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 15 Dec 2025 17:55:57 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v2]
In-Reply-To: <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
Message-ID: <7NgQg9QvM-HgcK5TQ-ih75IthqX4pVUDRGBtMjC0UYo=.536660a9-b969-49d6-a9b5-2fcf52fe2a0c@github.com>

On Mon, 15 Dec 2025 16:43:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix version for javac to be latest version.

LGTM!

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

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1797#pullrequestreview-3579469335

From rriggs at openjdk.org  Mon Dec 15 18:06:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Dec 2025 18:06:48 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v2]
In-Reply-To: <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
Message-ID: <OztSXhdSByuYVZfMWqStmFyhwEyHzRsmrKIKw93MCxE=.8411750a-d0a8-4ef8-8d2c-5ab7ca6bea4a@github.com>

On Mon, 15 Dec 2025 16:43:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix version for javac to be latest version.

test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 268:

> 266:             opts.add("-source");
> 267:             opts.add(Integer.toString(Runtime.version().feature()));
> 268: 

Trivially, an extra blank line.

test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 275:

> 273:                 opts.add("-source");
> 274:                 opts.add(Integer.toString(Runtime.version().feature()));
> 275: 

And another blank line.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1797#discussion_r2620352889
PR Review Comment: https://git.openjdk.org/valhalla/pull/1797#discussion_r2620356418

From jsikstro at openjdk.org  Mon Dec 15 18:46:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 15 Dec 2025 18:46:58 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v5]
In-Reply-To: <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
Message-ID: <vEOOXhDFdZk1XpIAbVz3tXDB9sKZQdx5vazChoGP3sg=.8fc74362-f363-47bb-afab-3365a4361702@github.com>

On Mon, 15 Dec 2025 10:20:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment for safe check in safe_to_read_header

Thank you everyone for the reviews and help with figuring this out. I've rerun ParallelGC specific testing on the tip of lworld which looks good.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1785#issuecomment-3657068342

From phubner at openjdk.org  Mon Dec 15 18:46:59 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 18:46:59 GMT
Subject: [lworld] RFR: 8373494: [lworld] markWord preservation for
 ParallelGC [v5]
In-Reply-To: <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
 <NB07o-b5VFgWsMjlxlSdrEmaH_zRmVHxCHD9liskVgQ=.9e79d23a-0bde-41e0-bfdd-74f93686e084@github.com>
Message-ID: <NK6tytsGyyYeSbMK-rblh2hGPRg--GEc-vR6_7qPwL0=.8ef25d64-af5f-4ba5-b1b9-4765add82b27@github.com>

On Mon, 15 Dec 2025 10:20:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
>> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
>> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
>> 
>> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
>> 
>> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
>> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
>> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
>> 
>> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
>> 
>> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a lar...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment for safe check in safe_to_read_header

Thanks.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1785#issuecomment-3657074572

From jsikstro at openjdk.org  Mon Dec 15 18:47:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 15 Dec 2025 18:47:00 GMT
Subject: [lworld] Integrated: 8373494: [lworld] markWord preservation for
 ParallelGC
In-Reply-To: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
References: <BzDVx_z7mlodbuT7ZW0ouxXqZ_ZXbvY4ElvG9dsHssk=.174a3110-0144-4e77-b774-25c00e2b8666@github.com>
Message-ID: <tOM5UVZqXzYhORNZcBqqShEGX5CyAbTUIfP44SfvTLo=.48df5638-0ad4-403f-9006-c5b16f378b8e@github.com>

On Thu, 11 Dec 2025 09:53:29 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> The Valhalla-specific bits in the markWord need to be preserved when compacting objects in Parallel. This can easily be achieved in one of two ways:
> 1) Use the markWord from the object's Klass, which contains all relevant bits. Notably, this requires access to the Klass pointer.
> 2) Use the "PreservedMark" mechanism, preserving the markWord containing all relevant bits before compacting and restoring the markWord after comapcting.
> 
> In mainline, we only ever read the markWord from the object's Klass when CompactObjectHeaders is enabled. This is perfectly fine, since CompactObjectHeaders stores the Klass pointer in the markWord and Parallel will always copy **at least** one byte of the object from the current region. All other bytes of the object may be copied in another region, in which case it is not safe to read it concurrently while another thread might compact those bytes.
> 
> Now in Valhalla we also need to access the Klass pointer to get the markWord, even though we might not be using CompactObjectHeaders, which might not always be safe to do. To get around this, [JDK-8368875](https://bugs.openjdk.org/browse/JDK-8368875) opted to always use the PreservedMark mechanism instead, by changing the criteria for a markWord being preserved. Two impacts of this change stand out:
> 1) We always preserve the markWord, even though we could be able to read the Klass pointer if the full object header was copied.
> 2) Since the change was made to oopDesc::must_be_preserved(), which is not Parallel-specific, all GCs will now preserve the markWord as well for the same criteria, which is not needed.
> 
> I propose we change the full reliance on the PreservedMark mechanism to a specific solution for Parallel, which preserves the markWord only when we are not guaranteed to be able to access the Klass pointer, and uses the Klass pointer when possible. This way we preserve markWords only when absolutely necessary, and other GCs also don't have to take the hit of preserving markWords unnecessarily.
> 
> After this change, it has become relatively uncommon to see a markWord preserved for the new "Valhalla reason." This preservation now requires an object to cross a region boundary and to only have a single word in the current region (disregarding the use of CompactObjectHeaders). I've attempted to trigger this scenario by setting a small maximum heap size (-Xmx60M) in some tests, which sometimes results in a markWord being preserved. However, with a larger maximum heap size, it is r...

This pull request has now been integrated.

Changeset: 8c0c190b
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8c0c190b38ad087f92b53752c5f81257162dca8c
Stats:     75 lines in 5 files changed: 54 ins; 15 del; 6 mod

8373494: [lworld] markWord preservation for ParallelGC

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Reviewed-by: phubner, dsimms, sjohanss, stefank, coleenp

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

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

From vromero at openjdk.org  Mon Dec 15 18:49:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Dec 2025 18:49:50 GMT
Subject: [lworld] RFR: 8370635: [lworld] TypeName.super.[TypeArguments]
 Identifier cannot occur in prologue
In-Reply-To: <GCWKq6othcpxWjeU7Vh4a87Im2b9WW-89bwbJ1JgfJ0=.1ca6cebc-6ebd-4308-ba7c-c15511275f25@github.com>
References: <ISVu0y7wlBVEChq83o1rjIve4McK94c27Xlil_hWZjs=.3d73b3e9-7b6b-49db-b93b-262db7cce760@github.com>
 <GCWKq6othcpxWjeU7Vh4a87Im2b9WW-89bwbJ1JgfJ0=.1ca6cebc-6ebd-4308-ba7c-c15511275f25@github.com>
Message-ID: <xrsRdhao7qxBQuKl-g1gfGdgqZ5Yo35RPgA39hrwlFk=.0cb68e95-90fe-4153-9997-933f8316f2ed@github.com>

On Tue, 9 Dec 2025 17:14:29 GMT, Chen Liang <liach 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.

I assume the reason is that super class initialization code, that sets the static fields in the super class, will be executed way before this super constructor invocation.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1779#discussion_r2620466408

From liach at openjdk.org  Mon Dec 15 19:02:27 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 19:02:27 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: <4fQEblSmCj4_4Kmyxu9mbCHL2Z87rDp1zczV8uuW_wQ=.3a0d9240-a8bc-4624-a2b9-5a9b01509f14@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

Sounds good, we can discuss about my case later and change if we find it necessary to change

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1779#pullrequestreview-3579684442

From phubner at openjdk.org  Mon Dec 15 19:00:39 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 19:00:39 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v4]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <d5Yw3TNiZoz_hb2fodrq8HJDXjOtX0-7zQH3B8QsJm8=.13a40d33-30a8-4b25-889a-161aa2821418@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

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

  Move some tests to Xcomp list.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/477e595a..41e370db

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

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

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

From phubner at openjdk.org  Mon Dec 15 19:00:43 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 19:00:43 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v2]
In-Reply-To: <wNVV5qNRn8_BOZ_g-v5Oqf-HONfmRKh7cPpWGChb1ss=.ea06b402-4763-4a7a-a8f5-08e40d0178a7@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <_krfPehEX32rwkCaqRweQy3UXWSM8MijxpoTo5SuGwQ=.58cf97f3-8b8b-461c-bade-5d2ca317d003@github.com>
 <wNVV5qNRn8_BOZ_g-v5Oqf-HONfmRKh7cPpWGChb1ss=.ea06b402-4763-4a7a-a8f5-08e40d0178a7@github.com>
Message-ID: <j1gGRGPfa7Lh-vvDyMBZUYnQn7k4VOxE2mJkeIQ0Y4w=.df4e7860-dd64-4df1-a01b-049fa1cd393b@github.com>

On Fri, 12 Dec 2025 19:54:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add one of the AOT tests.
>
> test/jdk/ProblemList-enable-preview.txt line 40:
> 
>> 38: java/util/Collections/CheckedSetBash.java                       8372824 generic-all
>> 39: jdk/internal/misc/CDS/ArchivedEnumTest.java                     8372743 generic-all
>> 40: valhalla/valuetypes/ObjectMethodsViaCondy.java                  8369045 macosx-all
> 
> Should be these valhalla test in Problemlist-Xcomp.txt?

Yes. Thanks for pointing it out.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620490899

From coleenp at openjdk.org  Mon Dec 15 19:03:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 19:03:35 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v3]
In-Reply-To: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
Message-ID: <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>

> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
> 
> When the jimage code is checked in, a bunch of tests fail because of this problem.
> 
> Testing with tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix blank lines.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1797/files
  - new: https://git.openjdk.org/valhalla/pull/1797/files/2ae8d25e..277f5a85

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

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

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

From coleenp at openjdk.org  Mon Dec 15 19:03:40 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 19:03:40 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v2]
In-Reply-To: <OztSXhdSByuYVZfMWqStmFyhwEyHzRsmrKIKw93MCxE=.8411750a-d0a8-4ef8-8d2c-5ab7ca6bea4a@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <9T4-I335fBfvB5x7ipQHzb22QeQlnon-s6B7igqgu2k=.5ff2ccbf-2d8a-4ac9-8598-983df4a5a17d@github.com>
 <OztSXhdSByuYVZfMWqStmFyhwEyHzRsmrKIKw93MCxE=.8411750a-d0a8-4ef8-8d2c-5ab7ca6bea4a@github.com>
Message-ID: <-xZjlSuAn9arHUbeTSeJmLIIuAJoURk95bRTjMO8W0U=.6b4346a8-cde2-4272-b3fa-516e7e9e7269@github.com>

On Mon, 15 Dec 2025 18:03:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix version for javac to be latest version.
>
> test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java line 275:
> 
>> 273:                 opts.add("-source");
>> 274:                 opts.add(Integer.toString(Runtime.version().feature()));
>> 275: 
> 
> And another blank line.

Thanks Roger for noticing these were unintentionally added.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1797#discussion_r2620501112

From liach at openjdk.org  Mon Dec 15 19:08:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 19:08:53 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v3]
In-Reply-To: <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>
Message-ID: <wuIr3M-CbdRKn2kkMawf92658KeAjajFBSjeYEmxXwU=.fba7c170-0595-4f85-b19b-8ba219bea43c@github.com>

On Mon, 15 Dec 2025 19:03:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix blank lines.

Marked as reviewed by liach (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1797#pullrequestreview-3579709939

From phubner at openjdk.org  Mon Dec 15 19:22:29 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 19:22:29 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'lworld' into JDK-8373575
 - Move some tests to Xcomp list.
 - Add failing test to problemlist.
 - Add one of the AOT tests.
 - Problemlist and fix.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/41e370db..7336f262

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

  Stats: 47855 lines in 720 files changed: 33167 ins; 9907 del; 4781 mod
  Patch: https://git.openjdk.org/valhalla/pull/1793.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1793/head:pull/1793

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

From rriggs at openjdk.org  Mon Dec 15 19:24:18 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Dec 2025 19:24:18 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v3]
In-Reply-To: <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>
Message-ID: <y_yZrt8zv67zAc3x6XZx_gALpxccYnpxx0-cyk4ze5k=.abc52c93-c071-419a-a62e-68de4c6bc79d@github.com>

On Mon, 15 Dec 2025 19:03:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix blank lines.

Thanks for the fix.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1797#pullrequestreview-3579767691

From coleenp at openjdk.org  Mon Dec 15 19:32:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 19:32:01 GMT
Subject: [lworld] RFR: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler [v3]
In-Reply-To: <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
 <DBt71fqI0psJuLrBj4wfUfVCGFup8JJqOSFWLhgUuRg=.55ddfb84-a936-444c-97c5-fd7aef47cdfa@github.com>
Message-ID: <HMln64zcfxXBlnQ1FPyi76LDH7x9U9jtwnzHmyu22VE=.d0415cd5-e30b-4198-ad00-47ea5482936e@github.com>

On Mon, 15 Dec 2025 19:03:35 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
>> 
>> When the jimage code is checked in, a bunch of tests fail because of this problem.
>> 
>> Testing with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix blank lines.

Thanks Chen, Matias and Roger.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1797#issuecomment-3657244911

From coleenp at openjdk.org  Mon Dec 15 19:32:02 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 15 Dec 2025 19:32:02 GMT
Subject: [lworld] Integrated: 8373622: [lworld] Enabling jimage changes break
 tests with inMemoryJavaCompiler
In-Reply-To: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
References: <BJEFnNtF0a8_fFfjDLfJ3M9GTGFp17PPXY6Tt1s0S5s=.aaf5d32f-2e5d-4d76-9cd1-3c1ec4bf9fda@github.com>
Message-ID: <lS8TEoy57GErMrJpfJTA9t4GnkiJ1PeplWg03OXpahE=.88e0338e-b644-4589-baf5-492cd13c7c32@github.com>

On Fri, 12 Dec 2025 20:53:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change tests the properties: java.test.opts and the property for test.enable.preview (set when test has @enablePreview), and will pass --enable-preview -source 26 to the inMemoryJavaCompiler compiler task.  I don't really like this but the alternative is to do the same thing from all the tests, and pass this down as parameters.  Better alternative ideas are welcome.
> 
> When the jimage code is checked in, a bunch of tests fail because of this problem.
> 
> Testing with tier1-4.

This pull request has now been integrated.

Changeset: e029e675
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e029e675ce00ae0b0768cef38d028ea99852fa5c
Stats:     16 lines in 1 file changed: 16 ins; 0 del; 0 mod

8373622: [lworld] Enabling jimage changes break tests with inMemoryJavaCompiler

Reviewed-by: liach, matsaave, rriggs

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

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

From vromero at openjdk.org  Mon Dec 15 19:35:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Dec 2025 19:35:38 GMT
Subject: [lworld] RFR: 8370635: [lworld] TypeName.super.[TypeArguments]
 Identifier cannot occur in prologue
In-Reply-To: <4fQEblSmCj4_4Kmyxu9mbCHL2Z87rDp1zczV8uuW_wQ=.3a0d9240-a8bc-4624-a2b9-5a9b01509f14@github.com>
References: <ISVu0y7wlBVEChq83o1rjIve4McK94c27Xlil_hWZjs=.3d73b3e9-7b6b-49db-b93b-262db7cce760@github.com>
 <4fQEblSmCj4_4Kmyxu9mbCHL2Z87rDp1zczV8uuW_wQ=.3a0d9240-a8bc-4624-a2b9-5a9b01509f14@github.com>
Message-ID: <USGGiE5sv3YI4mQyCNCC_iaqs55PocfzC6sVMMyAaI0=.37f30160-3259-4e4a-867d-737ae3d9a366@github.com>

On Mon, 15 Dec 2025 18:59:15 GMT, Chen Liang <liach 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
>
> Sounds good, we can discuss about my case later and change if we find it necessary to change

thanks @liach for the review and approval

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

PR Comment: https://git.openjdk.org/valhalla/pull/1779#issuecomment-3657261448

From vromero at openjdk.org  Mon Dec 15 19:35:39 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 15 Dec 2025 19:35:39 GMT
Subject: [lworld] Integrated: 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: <fgh6eSDIg_AvdAD2Q4Ec1xMTjrxwh_5vQia3F0t5PSo=.c940a0b9-673d-4942-9260-0f72811a119c@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

This pull request has now been integrated.

Changeset: c03121d9
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c03121d9891be4bfef3d5b7d739168e31e4dbb47
Stats:     31 lines in 4 files changed: 27 ins; 0 del; 4 mod

8370635: [lworld] TypeName.super.[TypeArguments] Identifier cannot occur in prologue

Reviewed-by: liach

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

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

From fparain at openjdk.org  Mon Dec 15 19:44:19 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 15 Dec 2025 19:44:19 GMT
Subject: [lworld] RFR: 8373706: [lworld] Layout names should be
 self-explanatory
Message-ID: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>

Renaming of layout kinds to make them self-explanatory.
Also, provides layout kind -> string methods to normalize names of layouts in all logging messages and tests.

Initially tested with tier 1-3 (re-validating after merge/minor changes).

Thank you.

Fred

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

Commit messages:
 - Make layout names should be self-explanatory

Changes: https://git.openjdk.org/valhalla/pull/1801/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373706
  Stats: 162 lines in 15 files changed: 57 ins; 17 del; 88 mod
  Patch: https://git.openjdk.org/valhalla/pull/1801.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1801/head:pull/1801

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

From phubner at openjdk.org  Mon Dec 15 19:46:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 15 Dec 2025 19:46:03 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Use the new function for the Parallel changes.
 - Merge branch 'lworld' into JDK-8371357
 - Remove wrong comment.
 - Fix imports.
 - Reviewer comments.
 - Copyright.
 - Revert "Don't synchronize on Double."
   
   This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
 - Accidentally changed too many enable_preview.
 - Make heap dump test require debug VM.
 - Change to arguments.
 - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a

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

Changes: https://git.openjdk.org/valhalla/pull/1759/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1759&range=02
  Stats: 157 lines in 56 files changed: 59 ins; 12 del; 86 mod
  Patch: https://git.openjdk.org/valhalla/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1759/head:pull/1759

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

From stefank at openjdk.org  Mon Dec 15 19:54:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 19:54:33 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
 <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>
Message-ID: <EjXgJ9usg09UqbWQ2lbL-he6r7-wKJ60ftIC0Lb6W2I=.61109383-4e2f-4036-a01a-433e80b86040@github.com>

On Mon, 15 Dec 2025 15:45:39 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Mark oop_arraycopy as nodiscard
>>  - Terminate OopCopyResult in oop_arraycopy_raw
>
> src/hotspot/share/oops/access.hpp line 335:
> 
>> 333:   }
>> 334: 
>> 335:   [[nodiscard]]
> 
> Is it worth leaving a comment on why the `[[nodiscard]]` annotation was used here?

I started to write a comment but they end up being something like:

// Make sure that the caller does not accidentally ignore the return value


which is sort-of what [[nodiscard]] means, so I'm not sure this is a good comment.

Maybe something talking about why it is important to not forget to check the return value:

The caller is responsible to throw an exception on failure


WDYT?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1792#discussion_r2620634111

From heidinga at openjdk.org  Mon Dec 15 19:54:34 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 15 Dec 2025 19:54:34 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <EjXgJ9usg09UqbWQ2lbL-he6r7-wKJ60ftIC0Lb6W2I=.61109383-4e2f-4036-a01a-433e80b86040@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
 <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>
 <EjXgJ9usg09UqbWQ2lbL-he6r7-wKJ60ftIC0Lb6W2I=.61109383-4e2f-4036-a01a-433e80b86040@github.com>
Message-ID: <STsdYcgrCg280Q53ZZAJ5Zk4y3zTdiuoyp_eDQJFSd0=.859a1be6-cc56-4efc-90c0-56c09a32c630@github.com>

On Mon, 15 Dec 2025 19:49:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The caller is responsible to throw an exception on failure

That would be perfect!  Thanks

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1792#discussion_r2620638039

From stefank at openjdk.org  Mon Dec 15 19:58:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 19:58:21 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
Message-ID: <P2M4cQmKaHQ3CM53vbP4RTcY-I0mFA4SheG093AdND8=.cea20717-16a5-4cb0-9bd2-8a55854389b6@github.com>

On Mon, 15 Dec 2025 19:46:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Use the new function for the Parallel changes.
>  - Merge branch 'lworld' into JDK-8371357
>  - Remove wrong comment.
>  - Fix imports.
>  - Reviewer comments.
>  - Copyright.
>  - Revert "Don't synchronize on Double."
>    
>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>  - Accidentally changed too many enable_preview.
>  - Make heap dump test require debug VM.
>  - Change to arguments.
>  - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a

Marked as reviewed by stefank (Author).

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

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3579895775

From dcubed at openjdk.org  Mon Dec 15 20:01:21 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 15 Dec 2025 20:01:21 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
Message-ID: <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>

On Mon, 15 Dec 2025 19:22:29 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8373575
>  - Move some tests to Xcomp list.
>  - Add failing test to problemlist.
>  - Add one of the AOT tests.
>  - Problemlist and fix.

I'm okay with these changes, but I've embedded a few questions.

test/jdk/ProblemList-Xcomp.txt line 35:

> 33: valhalla/valuetypes/ObjectNewInstance.java                      8369045 macosx-all
> 34: valhalla/valuetypes/ProxyTest.java                              8369045 macosx-all
> 35: valhalla/valuetypes/WeakReferenceTest.java                      8369045 macosx-all

Do these tests only fail with `-Xcomp` when `--enable-preview` is used?
Or do these tests only fail with `-Xcomp` in `lworld` regardless of the `--enable-preview` value?

If it's the latter case, then `ProblemList-Xcomp.txt` is the right place.

Reading through [JDK-8369045](https://bugs.openjdk.org/browse/JDK-8369045), it sounds like
`--enable-preview` is necessary so I don't think `ProblemList-Xcomp.txt` is the right place.

test/jdk/java/lang/reflect/AccessFlag/SuperAccessFlagTest.java line 28:

> 26:  * @bug 8301720
> 27:  * @summary Test expected value of SUPER AccessFlag for pre-ValueClass .class file
> 28:  * @requires !java.enablePreview

The reasons for `@requires !java.enablePreview` is clear because the summary mentions `pre-ValueClass`.

test/langtools/TEST.ROOT line 53:

> 51:     vm.continuations \
> 52:     vm.debug \
> 53:     java.enablePreview

This just requires the `java.enablePreview` property to be set to `true` or `false`.
It does not require `java.enablePreview` == `true`, correct?

test/langtools/tools/javac/AnonymousClass/AnonymousClassFlags.java line 29:

> 27:  * @summary Verify that anonymous class binaries have the correct flags set
> 28:  * @modules java.base/jdk.internal.misc
> 29:  * @requires !java.enablePreview

Why is `@requires !java.enablePreview` needed here? The test's id value is NoPreview so that might
indicate that the test doesn't support --enable-preview bits, but I had to expand the review's context
to see that id value.

test/langtools/tools/javap/T4975569.java line 30:

> 28:  * @modules jdk.jdeps/com.sun.tools.javap
> 29:  * @modules java.base/jdk.internal.misc
> 30:  * @requires !java.enablePreview

Why is  `@requires !java.enablePreview` needed here? The test's `id` value is `NoPreview` so that might
indicate that the test doesn't support `--enable-preview` bits, but I had to expand the review's context
to see that `id` value.

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

Marked as reviewed by dcubed (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1793#pullrequestreview-3579844876
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620608150
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620633275
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620627741
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620635666
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620643507

From lmesnik at openjdk.org  Mon Dec 15 20:09:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 15 Dec 2025 20:09:44 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
Message-ID: <2BViZQPMmn3uGDfxM24gDPHiTiYznnhiUXvUg-Wqo-Q=.e11b39a7-666c-418e-8f15-4696b03a0727@github.com>

On Mon, 15 Dec 2025 19:22:29 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8373575
>  - Move some tests to Xcomp list.
>  - Add failing test to problemlist.
>  - Add one of the AOT tests.
>  - Problemlist and fix.

Marked as reviewed by lmesnik (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1793#pullrequestreview-3579940575

From lmesnik at openjdk.org  Mon Dec 15 20:09:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 15 Dec 2025 20:09:46 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
Message-ID: <l8_vzNzt41oe_F9aajZDpypBYEdWWPTHLcNvYQEq-og=.b9e1561c-f2cf-4552-a134-6c96ca24aa22@github.com>

On Mon, 15 Dec 2025 19:39:16 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into JDK-8373575
>>  - Move some tests to Xcomp list.
>>  - Add failing test to problemlist.
>>  - Add one of the AOT tests.
>>  - Problemlist and fix.
>
> test/jdk/ProblemList-Xcomp.txt line 35:
> 
>> 33: valhalla/valuetypes/ObjectNewInstance.java                      8369045 macosx-all
>> 34: valhalla/valuetypes/ProxyTest.java                              8369045 macosx-all
>> 35: valhalla/valuetypes/WeakReferenceTest.java                      8369045 macosx-all
> 
> Do these tests only fail with `-Xcomp` when `--enable-preview` is used?
> Or do these tests only fail with `-Xcomp` in `lworld` regardless of the `--enable-preview` value?
> 
> If it's the latter case, then `ProblemList-Xcomp.txt` is the right place.
> 
> Reading through [JDK-8369045](https://bugs.openjdk.org/browse/JDK-8369045), it sounds like
> `--enable-preview` is necessary so I don't think `ProblemList-Xcomp.txt` is the right place.

valhalla/valutypes/ tests add `--enable-preview` so they are going to fail if executed with `-Xcomp` only.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620678648

From matsaave at openjdk.org  Mon Dec 15 20:44:12 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 15 Dec 2025 20:44:12 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping
Message-ID: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>

CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.

AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.

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

Commit messages:
 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - Properly rewrite fast_vputfield and fast_vgetfield
 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - Enable CDS heap dumping

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

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

From fparain at openjdk.org  Mon Dec 15 20:58:28 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 15 Dec 2025 20:58:28 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping
In-Reply-To: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
Message-ID: <-UxiHzaI-cZyrDW076pcH-Asv0vNFiJPOb_ui5Nz4lw=.eab9b7f1-059c-4e5a-b339-5af00ebdec43@github.com>

On Fri, 21 Nov 2025 18:49:25 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
> 
> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.

src/hotspot/share/cds/aotMetaspace.cpp line 586:

> 584:         case ztos: new_code = Bytecodes::_fast_bgetfield; break;
> 585:         case atos: {
> 586:           if (rfe->is_flat() || rfe->is_null_free_inline_type()) {

null-free getfields are not rewritten to fast_vgetfield, but to fast_agetfield, because there's no additional check on read.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1757#discussion_r2620819575

From fparain at openjdk.org  Mon Dec 15 21:04:59 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 15 Dec 2025 21:04:59 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping
In-Reply-To: <-UxiHzaI-cZyrDW076pcH-Asv0vNFiJPOb_ui5Nz4lw=.eab9b7f1-059c-4e5a-b339-5af00ebdec43@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
 <-UxiHzaI-cZyrDW076pcH-Asv0vNFiJPOb_ui5Nz4lw=.eab9b7f1-059c-4e5a-b339-5af00ebdec43@github.com>
Message-ID: <EEp1MiW9e0g9Y-R7XWbFg5Z8rpuxkfp9-e4foffD2SY=.9e4b61f0-295a-47bc-9bcb-d846f92ab47c@github.com>

On Mon, 15 Dec 2025 20:55:28 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
>> 
>> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.
>
> src/hotspot/share/cds/aotMetaspace.cpp line 586:
> 
>> 584:         case ztos: new_code = Bytecodes::_fast_bgetfield; break;
>> 585:         case atos: {
>> 586:           if (rfe->is_flat() || rfe->is_null_free_inline_type()) {
> 
> null-free getfields are not rewritten to fast_vgetfield, but to fast_agetfield, because there's no additional check on read.

Precision: null-free non-flat getfields are not rewritten to fast_vgetfield, but to fast_agetfield, because there's no additional check on read.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1757#discussion_r2620838470

From dcubed at openjdk.org  Mon Dec 15 21:14:35 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 15 Dec 2025 21:14:35 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
Message-ID: <l0I5K5P3fyg6j5SOwyNGb6ZtJJ9v-91uJTT4AyR_ZkI=.10dc115d-b2c0-40f7-9124-0b77281593b3@github.com>

On Mon, 15 Dec 2025 19:22:29 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8373575
>  - Move some tests to Xcomp list.
>  - Add failing test to problemlist.
>  - Add one of the AOT tests.
>  - Problemlist and fix.

Marked as reviewed by dcubed (Committer).

test/hotspot/jtreg/compiler/escapeAnalysis/Test8329757.java line 46:

> 44:     void q() {
> 45:         int e;
> 46:         synchronized (new Object()) {

What motivated this change?

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

PR Review: https://git.openjdk.org/valhalla/pull/1793#pullrequestreview-3580154018
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620849789

From dcubed at openjdk.org  Mon Dec 15 21:14:37 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 15 Dec 2025 21:14:37 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
Message-ID: <NkKsqusNK9MhDOQ_pPRQsdkQ1leEkUxJZ_bQJDQ9i0s=.d084484e-842f-4922-ba81-155dbbeb3fd2@github.com>

On Mon, 15 Dec 2025 19:50:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into JDK-8373575
>>  - Move some tests to Xcomp list.
>>  - Add failing test to problemlist.
>>  - Add one of the AOT tests.
>>  - Problemlist and fix.
>
> test/langtools/tools/javac/AnonymousClass/AnonymousClassFlags.java line 29:
> 
>> 27:  * @summary Verify that anonymous class binaries have the correct flags set
>> 28:  * @modules java.base/jdk.internal.misc
>> 29:  * @requires !java.enablePreview
> 
> Why is `@requires !java.enablePreview` needed here? The test's id value is NoPreview so that might
> indicate that the test doesn't support --enable-preview bits, but I had to expand the review's context
> to see that id value.

Another thought occurred to me. Perhaps add a comment line above the `@requires`:

@comment Test does not like Valhalla value classes.

or something like that. I think it would be good if we added a comment
when we use `@requires !java.enablePreview` to indicate which preview
feature is problematic.

> test/langtools/tools/javap/T4975569.java line 30:
> 
>> 28:  * @modules jdk.jdeps/com.sun.tools.javap
>> 29:  * @modules java.base/jdk.internal.misc
>> 30:  * @requires !java.enablePreview
> 
> Why is  `@requires !java.enablePreview` needed here? The test's `id` value is `NoPreview` so that might
> indicate that the test doesn't support `--enable-preview` bits, but I had to expand the review's context
> to see that `id` value.

Another thought occurred to me. Perhaps add a comment line above the `@requires`:

@comment Test does not like Valhalla value classes.

or something like that. I think it would be good if we added a comment
when we use `@requires !java.enablePreview` to indicate which preview
feature is problematic.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620862468
PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2620862839

From stefank at openjdk.org  Mon Dec 15 21:36:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 21:36:37 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v3]
In-Reply-To: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
Message-ID: <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>

> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
> 
> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Comment at nodiscard

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1792/files
  - new: https://git.openjdk.org/valhalla/pull/1792/files/9894b597..536c5836

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

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

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

From stefank at openjdk.org  Mon Dec 15 21:36:38 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 15 Dec 2025 21:36:38 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <STsdYcgrCg280Q53ZZAJ5Zk4y3zTdiuoyp_eDQJFSd0=.859a1be6-cc56-4efc-90c0-56c09a32c630@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
 <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>
 <EjXgJ9usg09UqbWQ2lbL-he6r7-wKJ60ftIC0Lb6W2I=.61109383-4e2f-4036-a01a-433e80b86040@github.com>
 <STsdYcgrCg280Q53ZZAJ5Zk4y3zTdiuoyp_eDQJFSd0=.859a1be6-cc56-4efc-90c0-56c09a32c630@github.com>
Message-ID: <DbJ7J98bPRoNEynnujWdEBNfNvUKe1sHuv_4L21RI8E=.743b485c-de8a-457b-93d1-92fc68f1f85b@github.com>

On Mon, 15 Dec 2025 19:51:28 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> I started to write a comment but they end up being something like:
>> 
>> // Make sure that the caller does not accidentally ignore the return value
>> 
>> 
>> which is sort-of what [[nodiscard]] means, so I'm not sure this is a good comment.
>> 
>> Maybe something talking about why it is important to not forget to check the return value:
>> 
>> The caller is responsible to throw an exception on failure
>> 
>> 
>> WDYT?
>
>> The caller is responsible to throw an exception on failure
> 
> That would be perfect!  Thanks

I added the last sentence but I'm a little bit uncertain about the grammar. Feel free to nit-pick if it sounds weird.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1792#discussion_r2620924424

From heidinga at openjdk.org  Mon Dec 15 22:04:59 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 15 Dec 2025 22:04:59 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v3]
In-Reply-To: <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
Message-ID: <FOd3y894FTBgPgpR3pC5oyTSzyMsczRAF2a74MCitfM=.ff0a19b9-efbd-464d-9eb7-af39abf5adc6@github.com>

On Mon, 15 Dec 2025 21:36:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment at nodiscard

looks good to me - thanks for adding the comment!

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1792#pullrequestreview-3580363881

From heidinga at openjdk.org  Mon Dec 15 22:34:17 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 15 Dec 2025 22:34:17 GMT
Subject: [lworld] RFR: 8373706: [lworld] Layout names should be
 self-explanatory
In-Reply-To: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
References: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
Message-ID: <BNQxe8FNLgsMUADaut2QAXlR41Qwau7KqZhyK-JnJrU=.0f1dbda8-f829-4d36-b9eb-df9dd6dd690f@github.com>

On Mon, 15 Dec 2025 19:39:44 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Renaming of layout kinds to make them self-explanatory.
> Also, provides layout kind -> string methods to normalize names of layouts in all logging messages and tests.
> 
> Initially tested with tier 1-3 (re-validating after merge/minor changes).
> 
> Thank you.
> 
> Fred

looks reasonable to me

src/hotspot/share/oops/layoutKind.cpp line 45:

> 43:       ShouldNotReachHere();
> 44:   }
> 45: }

Do we need a blank line at the end of the file?

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1801#pullrequestreview-3580400176
PR Review Comment: https://git.openjdk.org/valhalla/pull/1801#discussion_r2621038644

From heidinga at openjdk.org  Mon Dec 15 23:05:00 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 15 Dec 2025 23:05:00 GMT
Subject: [lworld] RFR: 8373606: [lworld] PrintFlatArrayLayout should print
 LayoutKind and ArrayProperties
In-Reply-To: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
References: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
Message-ID: <EIfD-Jbm7x5sQGBYJloxxZYNYKUAlaRBl1hd0pcEOWE=.9450b323-39a3-41db-a24a-be9d623d9b48@github.com>

On Fri, 12 Dec 2025 16:32:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Extend the information printed by PrintFlatArrayLayout to include LayoutKind and ArrayProperties.
> 
> Tested with Mach5 tier1

looks reasonable

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

Marked as reviewed by heidinga (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1795#pullrequestreview-3580511426

From dcubed at openjdk.org  Mon Dec 15 23:15:55 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 15 Dec 2025 23:15:55 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
Message-ID: <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>

On Mon, 15 Dec 2025 19:46:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Use the new function for the Parallel changes.
>  - Merge branch 'lworld' into JDK-8371357
>  - Remove wrong comment.
>  - Fix imports.
>  - Reviewer comments.
>  - Copyright.
>  - Revert "Don't synchronize on Double."
>    
>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>  - Accidentally changed too many enable_preview.
>  - Make heap dump test require debug VM.
>  - Change to arguments.
>  - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a

Generally looks good. I posted one comment where I think a logical expression is backwards.

src/hotspot/share/cds/cdsConfig.hpp line 213:

> 211:     return Arguments::enable_preview() && EnableValhalla;
> 212:   }
> 213: 

Does this file still need to include `arguments.hpp`? I'm not seeing anymore calls into `Arguments::foo`.

src/hotspot/share/cds/filemap.hpp line 175:

> 173:   bool   _has_aot_linked_classes;       // Was the CDS archive created with -XX:+AOTClassLinking
> 174:   bool   _has_full_module_graph;        // Does this CDS archive contain the full archived module graph?
> 175:   bool   _has_valhalla_patched_classes; // Is this archived dumped with --enable-preview

Nit: dropped the `?` at the end of the comment.

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

> 6146: 
> 6147:   // Determining is the class allows tearing or not (default is not)
> 6148:   if (Arguments::is_valhalla_enabled() && !_access_flags.is_identity_class()) {

Typo: L6147 (baseline): s/is the/if the/

src/hotspot/share/oops/arrayOop.hpp line 59:

> 57:   // Given a type, return true if elements of that type must be aligned to 64-bit.
> 58:   static bool element_type_should_be_aligned(BasicType type) {
> 59:     if (type == T_FLAT_ELEMENT) {

You don't need `EnableValhalla` or `Arguments::is_valhalla_enabled()` as long as all callers
of `element_type_should_be_aligned()` only pass known valid BasicType values. If any caller
passes a non-valid BasicType value as part of a "probing call", then a call with a value that
happens to match `T_FLAT_ELEMENT` by a VM with `Arguments::is_valhalla_enabled() == false`
will return `true` unexpectedly.

src/hotspot/share/oops/markWord.hpp line 134:

> 132:   // instance state
> 133:   static const int age_bits                       = 4;
> 134:   // prototype header bits (fast path instead of klass layout_helper)

Why drop the word `static` in the comment here?

src/hotspot/share/runtime/arguments.cpp line 4006:

> 4004:     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
> 4005:   }
> 4006:   if (is_valhalla_enabled() || (is_interpreter_only() && !CDSConfig::is_dumping_archive() && !UseSharedSpaces)) {

Hmmm... The original logic is `!EnableValhalla` so shouldn't this be: `!is_valhalla_enabled()`?

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

Changes requested by dcubed (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3580390993
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2621030493
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2621034967
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2621039257
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2621074984
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2621103988
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2621129557

From stefank at openjdk.org  Tue Dec 16 07:14:24 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 07:14:24 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v3]
In-Reply-To: <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
Message-ID: <fHR9EPAYiVcwwHpRGHCT7WChz3CCkstky2VBaRLxoa8=.6a1d8af1-0faa-4be3-a6dd-3ac9418b1ba3@github.com>

On Mon, 15 Dec 2025 21:36:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment at nodiscard

Thanks for all the reviews. I've run this through tier1-tier3. I'm going to integrate this and will need a sponsor to finalize the integration.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1792#issuecomment-3659135780

From duke at openjdk.org  Tue Dec 16 07:14:24 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 07:14:24 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v3]
In-Reply-To: <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
Message-ID: <PUSurh9WmejnVJyfgBwnoM_u11We04qzouNrGuqypdI=.9a12d081-dbd2-4591-b6a2-948b5930df12@github.com>

On Mon, 15 Dec 2025 21:36:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment at nodiscard

@stefank 
Your change (at version 536c58362b30c154eab1757829cd59c535b8795d) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1792#issuecomment-3659139842

From thartmann at openjdk.org  Tue Dec 16 07:26:27 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 16 Dec 2025 07:26:27 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v9]
In-Reply-To: <InJObHVKD4xtVCS27XKvU1Q22UmamSWwrKlMCq803Yo=.bd02b68d-b8b4-49b6-b84b-e239aac57d3c@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <InJObHVKD4xtVCS27XKvU1Q22UmamSWwrKlMCq803Yo=.bd02b68d-b8b4-49b6-b84b-e239aac57d3c@github.com>
Message-ID: <5hb5CSN6WEPCMwukz4j6vWGoGSNNp7V3BIme4MsDm-s=.7f2a5669-4495-4d6c-88b6-434606629a52@github.com>

On Mon, 15 Dec 2025 11:39:16 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 12 commits:
> 
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - reviews
>  - reviews
>  - Should not clone MergeMem
>  - fix NarrowMemProj
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix Parse::array_store and PhaseMacroNode::value_from_mem
>  - whitespace
>  - fix more issues
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - ... and 2 more: https://git.openjdk.org/valhalla/compare/2f2fd63d...84605fc1

Sure! It looks good but there is one failure left:


compiler/valhalla/inlinetypes/TestArrayNullMarkers.java
-Xcomp -XX:-TieredCompilation -DIgnoreCompilerControls=true
OR
-XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=0 -XX:PerMethodTrapLimit=0

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/workspace/open/src/hotspot/share/opto/escape.cpp:4276), pid=2237007, tid=2237024
#  assert(idx == alias_idx) failed: Following Phi nodes should be on the same memory slice
#
# JRE version: Java(TM) SE Runtime Environment (26.0) (fastdebug build 26-jep401ea2-2025-12-15-1150217.tobias.hartmann.valhallatesting)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 26-jep401ea2-2025-12-15-1150217.tobias.hartmann.valhallatesting, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0xe2e206]  ConnectionGraph::move_inst_mem(Node*, GrowableArray<PhiNode*>&)+0x6c6
#

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

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

From aboldtch at openjdk.org  Tue Dec 16 07:38:18 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:38:18 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
Message-ID: <miEQ5W49jGK9lrYGYJoMG3N3Yyz6-nHttBGtM59nUco=.5da9e85a-6e11-46e5-9a28-4acea5dd22d4@github.com>

On Thu, 11 Dec 2025 11:51:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 
> 
> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 
> 
> It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).
> 
> We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

Rebuilt with the lastest merge and change sets locally.  Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1787#issuecomment-3659204318

From duke at openjdk.org  Tue Dec 16 07:38:19 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 07:38:19 GMT
Subject: [lworld] RFR: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
Message-ID: <9fMGOnQ1hUQi2zxo-xcystNycg3MSSN0R50ey8KhPDU=.6f196406-6688-4ba2-8dfa-c14989187e78@github.com>

On Thu, 11 Dec 2025 11:51:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 
> 
> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 
> 
> It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).
> 
> We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1787#issuecomment-3659208665

From aboldtch at openjdk.org  Tue Dec 16 07:44:33 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:44:33 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <DbJ7J98bPRoNEynnujWdEBNfNvUKe1sHuv_4L21RI8E=.743b485c-de8a-457b-93d1-92fc68f1f85b@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
 <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>
 <EjXgJ9usg09UqbWQ2lbL-he6r7-wKJ60ftIC0Lb6W2I=.61109383-4e2f-4036-a01a-433e80b86040@github.com>
 <STsdYcgrCg280Q53ZZAJ5Zk4y3zTdiuoyp_eDQJFSd0=.859a1be6-cc56-4efc-90c0-56c09a32c630@github.com>
 <DbJ7J98bPRoNEynnujWdEBNfNvUKe1sHuv_4L21RI8E=.743b485c-de8a-457b-93d1-92fc68f1f85b@github.com>
Message-ID: <kLHQxbKbN9_eU_ajjqPhoAm_cWh5uLG_WSzJTa3BduE=.e7d35261-a60d-4207-a80a-603a47fab587@github.com>

On Mon, 15 Dec 2025 21:33:27 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>>> The caller is responsible to throw an exception on failure
>> 
>> That would be perfect!  Thanks
>
> I added the last sentence but I'm a little bit uncertain about the grammar. Feel free to nit-pick if it sounds weird.

In C++20 we can have the message be part of the attribute. `[[nodiscard("The caller is responsible to throw an exception on failure")]]`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1792#discussion_r2622152421

From aboldtch at openjdk.org  Tue Dec 16 07:44:34 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:44:34 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v2]
In-Reply-To: <kLHQxbKbN9_eU_ajjqPhoAm_cWh5uLG_WSzJTa3BduE=.e7d35261-a60d-4207-a80a-603a47fab587@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <LSPRix0bK1In9qFb1LzlTg94DL71Fk37_WuH6LySzD0=.deb35b44-691a-4a9d-b7e9-e4b90b9dd1af@github.com>
 <SX-A2gsU7-NFNQjLTfMwmvhRf2eU7lDFaEsNligQNIw=.2c9a862e-36ef-4521-b7d3-6e62ae1aaf5c@github.com>
 <EjXgJ9usg09UqbWQ2lbL-he6r7-wKJ60ftIC0Lb6W2I=.61109383-4e2f-4036-a01a-433e80b86040@github.com>
 <STsdYcgrCg280Q53ZZAJ5Zk4y3zTdiuoyp_eDQJFSd0=.859a1be6-cc56-4efc-90c0-56c09a32c630@github.com>
 <DbJ7J98bPRoNEynnujWdEBNfNvUKe1sHuv_4L21RI8E=.743b485c-de8a-457b-93d1-92fc68f1f85b@github.com>
 <kLHQxbKbN9_eU_ajjqPhoAm_cWh5uLG_WSzJTa3BduE=.e7d35261-a60d-4207-a80a-603a47fab587@github.com>
Message-ID: <DqtnZWYJWU8GV-8jGF6-2MpiCLmF4BmbgWsLlt2mqns=.46f4c866-c883-472b-99f3-fd5a13c25c11@github.com>

On Tue, 16 Dec 2025 07:40:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> I added the last sentence but I'm a little bit uncertain about the grammar. Feel free to nit-pick if it sounds weird.
>
> In C++20 we can have the message be part of the attribute. `[[nodiscard("The caller is responsible to throw an exception on failure")]]`

But the way it says `// The caller is responsible to thow an exception on failure` now. There is an typo.

Maybe `It is the caller's responsibility to throw an exception on failure` or `The caller  is responsible for throwing an exception on failure`

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1792#discussion_r2622157678

From stefank at openjdk.org  Tue Dec 16 07:51:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 07:51:54 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v4]
In-Reply-To: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
Message-ID: <AXrLksr6fhCwVTWOPTYO9wopsWMV403CcrfEJiP-yzo=.05eefe3d-4013-4659-a656-cc05b0725075@github.com>

> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
> 
> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Typo in access.hpp

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1792/files
  - new: https://git.openjdk.org/valhalla/pull/1792/files/536c5836..31aafe73

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

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

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

From aboldtch at openjdk.org  Tue Dec 16 07:51:55 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:51:55 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v4]
In-Reply-To: <AXrLksr6fhCwVTWOPTYO9wopsWMV403CcrfEJiP-yzo=.05eefe3d-4013-4659-a656-cc05b0725075@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <AXrLksr6fhCwVTWOPTYO9wopsWMV403CcrfEJiP-yzo=.05eefe3d-4013-4659-a656-cc05b0725075@github.com>
Message-ID: <w_7yg3vLlAb1k8LVwhg60T-GX5Kcpk1vE3z390JeZV0=.12efa892-9c06-4dbf-8d40-bb544194614a@github.com>

On Tue, 16 Dec 2025 07:48:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo in access.hpp

Marked as reviewed by aboldtch (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1792#pullrequestreview-3581764524

From stefank at openjdk.org  Tue Dec 16 07:51:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 07:51:57 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v3]
In-Reply-To: <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
Message-ID: <hC2ymU944FSweBXdENX6xT2LM2pmW7LFB5hgM3hi7gE=.0e97ede1-5e57-4e33-8560-24ba5220ac1a@github.com>

On Mon, 15 Dec 2025 21:36:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment at nodiscard

Axel spotted a typo.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1792#issuecomment-3659238010

From duke at openjdk.org  Tue Dec 16 07:51:58 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 07:51:58 GMT
Subject: [lworld] RFR: 8373567: [lworld] Move array copy exception throwing
 out of GC barriers [v3]
In-Reply-To: <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
 <OYfJn30pDP7Mf17ffrNXRZHB8vI06kmEfjzO0Dqov98=.975a184e-c3de-4df1-97e0-fd7da6141b1d@github.com>
Message-ID: <zGqYEHxw064W2AywcCsMxWP2HeIr9qS0DZ4WJYREuug=.e8515493-3e0d-4579-b852-49ff1ab4e220@github.com>

On Mon, 15 Dec 2025 21:36:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
>> 
>> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment at nodiscard

@stefank 
Your change (at version 31aafe73b43a38c144fa124a352d686221f41328) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1792#issuecomment-3659241343

From dsimms at openjdk.org  Tue Dec 16 07:54:23 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 07:54:23 GMT
Subject: RFR: 8373620: [lworld] [lw5] Substitute params with type
 j.l.r.RuntimeType by j.l.Class in j.l.runtime.ArrayCreation
In-Reply-To: <kvKfTuNPvfNrMWjKO-UHcR3M8ePAY7-WaiMkNYEvIJs=.6c68b4ee-84a6-4136-a80f-f3330320c427@github.com>
References: <vCSX1YiBcch3UPZJ0qDBepI6koAowmwblJhxcUkZ9ns=.cf6dcaaf-8cbf-4f4a-92fb-a25d0ce785a5@github.com>
 <kvKfTuNPvfNrMWjKO-UHcR3M8ePAY7-WaiMkNYEvIJs=.6c68b4ee-84a6-4136-a80f-f3330320c427@github.com>
Message-ID: <YwWy7zGTOBUJneb8JY_0YHTFWViwoZcPV_-fmKWM4sc=.b385a468-ad57-4d4f-8b13-889fc6a83ba8@github.com>

On Mon, 15 Dec 2025 15:31:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> update methods in java.lang.runtime.ArrayCreation, change the arguments with type RuntimeType to java.lang.Class
>
> \touch

@vicente-romero-oracle did the "Commit message must refer to an issue" failure clear after reviewing or when ?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1796#issuecomment-3659251686

From dsimms at openjdk.org  Tue Dec 16 07:54:29 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 07:54:29 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <T8YENgtogoeoeiHYBmGyYy0ySFGgtxoN0P37Z_elDxk=.705a44b9-aa6a-4c7e-84a0-4f3ceb06c579@github.com>

Merge tag 'jdk-26+27' into lworld_merge_jdk_26_27

Added tag jdk-26+27 for changeset 45dcc0e7

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

Commit messages:
 - Merge jdk
 - 8371914: PNG defines in CFLAGS can cause compilation errors with external libpng
 - 8370939: C2: SIGSEGV in SafePointNode::verify_input when processing MH call from Compile::process_late_inline_calls_no_inline()
 - 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public
 - 8360702: runtime/Thread/AsyncExceptionTest.java timed out
 - 8370715: JFR: Races are possible when dumping recordings
 - 8373062: JFR build failure with CDS disabled
 - 8373063: Test sun/security/provider/acvp/ML_DSA_Intrinsic_Test.java fails on Aarch64 after JDK-8372816
 - 8337791: VectorAPI jtreg ABSMaskedByteMaxVectorTests crashes with UseAVX=0 -XX:MaxVectorSize=8
 - 8321139: jlink's compression plugin doesn't handle -c option correctly
 - ... and 139 more: https://git.openjdk.org/valhalla/compare/c03121d9...bf24b748

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

Changes: https://git.openjdk.org/valhalla/pull/1802/files
  Stats: 24410 lines in 614 files changed: 14218 ins; 7577 del; 2615 mod
  Patch: https://git.openjdk.org/valhalla/pull/1802.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1802/head:pull/1802

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

From stefank at openjdk.org  Tue Dec 16 07:57:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 07:57:20 GMT
Subject: [lworld] Integrated: 8373567: [lworld] Move array copy exception
 throwing out of GC barriers
In-Reply-To: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
References: <rAZsz5ajoDAXTH7Kt2I0R-A2O6Dy6SeWoi_ap_D_pHk=.dec79b10-aa76-4c6e-a548-89ef1c459293@github.com>
Message-ID: <MNqNd_BL3jOXHp3UaqmcnzEuFMoKIHmOVhl-OGwXE5o=.27ab6e94-2ccc-43d9-a2d1-623f7b910ce3@github.com>

On Fri, 12 Dec 2025 09:16:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The lworld branch has support for null-restricted arrays, and to support this code has been adjacent to the code that perform array copy check casts. The code that performs the check casts used to be located inside the GC access barriers, but the code that finally threw exceptions were located in the runtime code. In the lworld branch the code that throws the check cast exception and the new null pointer exception has been moved into the GC access barriers.
> 
> I propose that we revert back to the old style where the exception throwing was somewhat decoupled from the GC access barriers.

This pull request has now been integrated.

Changeset: c661c30f
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c661c30fff54fa4a83f5c10cda24bf4a9b031632
Stats:     312 lines in 14 files changed: 88 ins; 62 del; 162 mod

8373567: [lworld] Move array copy exception throwing out of GC barriers

Reviewed-by: aboldtch, tschatzl, fparain, heidinga

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

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

From aboldtch at openjdk.org  Tue Dec 16 07:57:26 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 16 Dec 2025 07:57:26 GMT
Subject: [lworld] Integrated: 8373507: [lworld] Add override keyword to *Klass
 classes
In-Reply-To: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
References: <W3-fjUSav4J2GZ1u56bAMnvYZl2-j1TjWRwcjgWP7Cs=.2c4d9166-13e8-44d3-a838-29e9d8a980fd@github.com>
Message-ID: <btlW-ohecgMwxV5MPnW0XQtmVPDjCzLoWn-KZZetYpQ=.ade245ec-f9b3-4bfe-8039-8671cdad3534@github.com>

On Thu, 11 Dec 2025 11:51:00 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This is a enhancement which should also go into mainline, however since lworld is changing a lot of the Klass type hierarchy it seems more important to just get this into this repo. 
> 
> Using override provides better visibility and compiler support for suspicious virtual methods. It makes it clears when reading a class header file if a new virtual interface is introduced or if it simply overridden. 
> 
> It catches when the virtual hierarchy is different for different build configurations (like `is_flatArray_klass_slow` which is on the `Klass` in debug and on `FlatArrayKlass` in release. This is obviously a bug and `is_flatArray_klass_slow` should not be available in a release build) or suspicious virtual functions (like `InstanceKlass::restore_unshareable_info(ClassLoaderData*,Handle,PackageEntry*, JavaThread*)` which is only overridden by `InlineKlass` and only delegates to `InstanceKlass`, so it could just not have overridden this function).
> 
> We should aim to migrate all our C++ classes to use `override` or `final` rather than virtual to catch more bugs and have more expressive header files. But it seems extra prudent here as lworld is moving around a lot of things in this area.

This pull request has now been integrated.

Changeset: a07dfe93
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a07dfe9398b986ca0812c63acf7beac08f148364
Stats:     143 lines in 10 files changed: 0 ins; 5 del; 138 mod

8373507: [lworld] Add override keyword to *Klass classes

Reviewed-by: mchevalier, fparain

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

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

From dsimms at openjdk.org  Tue Dec 16 08:22:22 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 08:22:22 GMT
Subject: [lworld] RFR: 8373706: [lworld] Layout names should be
 self-explanatory
In-Reply-To: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
References: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
Message-ID: <Hhr_vrJYIHYM3-VcgZksFQHC4qgcU6FsDoGzVYODUMU=.82cee9b9-a12e-4664-87fa-d7944bbf623e@github.com>

On Mon, 15 Dec 2025 19:39:44 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Renaming of layout kinds to make them self-explanatory.
> Also, provides layout kind -> string methods to normalize names of layouts in all logging messages and tests.
> 
> Initially tested with tier 1-3 (re-validating after merge/minor changes).
> 
> Thank you.
> 
> Fred

Marked as reviewed by dsimms (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1801#pullrequestreview-3581872273

From dsimms at openjdk.org  Tue Dec 16 08:24:21 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 08:24:21 GMT
Subject: [lworld] RFR: 8373606: [lworld] PrintFlatArrayLayout should print
 LayoutKind and ArrayProperties
In-Reply-To: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
References: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
Message-ID: <L6RSoA-yDDvCPdpn02oq3Tzh21v3FgIgGDhS0GK_cZ4=.dc5010c4-7713-430f-b658-ce66a470406d@github.com>

On Fri, 12 Dec 2025 16:32:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Extend the information printed by PrintFlatArrayLayout to include LayoutKind and ArrayProperties.
> 
> Tested with Mach5 tier1

Marked as reviewed by dsimms (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1795#pullrequestreview-3581880477

From thartmann at openjdk.org  Tue Dec 16 08:53:34 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 16 Dec 2025 08:53:34 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v6]
In-Reply-To: <n02-oRScNw0uNs0Ho1HZPMs6k0wxi0WE8-Me6Kc_v9w=.9886f0ba-c76a-4272-8383-2ab4fcfbe75f@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>
 <w8u-QzWAoRxsXZCIT5ygiLz8hUeDxBs2LeaUuqci5hE=.a3509567-1d9c-41bf-9e01-ea8e3044def4@github.com>
 <_AUnQub310kMTCCjkX20tRzLPFqRNTdPoWGdbvSl_pM=.c230c99c-3272-4594-85b2-0d73fc8eb083@github.com>
 <n02-oRScNw0uNs0Ho1HZPMs6k0wxi0WE8-Me6Kc_v9w=.9886f0ba-c76a-4272-8383-2ab4fcfbe75f@github.com>
Message-ID: <Yl71swdMeLV0bKX7NX0_YDt1tqTD4EMvk4CSoIWL70E=.427b0701-bdc5-4db7-8d2a-090e0ca4abe6@github.com>

On Mon, 15 Dec 2025 11:46:46 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Should we cast it to `InlineTypeNode` in `LibraryCallKit::inline_newArray` instead?
>
> I'm not sure, either. There is this TODO at `LibraryCallKit::inline_newArray`
> 
>     // TODO 8350865 Should we add a check of the init_val type (maybe in debug only + halt)?
> 
> Do you think I should insert a `checkcast` here or leave it as it is for now?

I think a checkcast would be nice if it avoids the check in macro.cpp. We can then add a runtime check with JDK-8350865.

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

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

From thartmann at openjdk.org  Tue Dec 16 08:55:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 16 Dec 2025 08:55:21 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v2]
In-Reply-To: <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@github.com>
Message-ID: <V-RLIdzRgcoW18tNaLuV1ILJWv_NHqHvQuiwZjqgbM4=.3456d01c-29f3-4397-a160-e976a906050e@github.com>

On Mon, 15 Dec 2025 09:36:55 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # 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 ha...
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8369045: remove strength reduction flag

src/hotspot/share/opto/graphKit.cpp line 2051:

> 2049:         _gvn.set_type(ret, ret->Value(&_gvn));
> 2050: 
> 2051:         // Don't add store to buffer call if we are strength reducing

Why do we need to add the above runtime check of the result again when doing strength reduction?

src/hotspot/share/opto/graphKit.cpp line 2226:

> 2224:            ((_gvn.is_IterGVN() && !C->inlining_incrementally()) && InlineTypeReturnedAsFields && !call->as_CallJava()->method()->return_type()->is_loaded()),
> 2225:            "unexpected number of results");
> 2226:     // If we are doing strength reduction and the return types is not loaded we

Suggestion:

    // If we are doing strength reduction and the return type is not loaded we

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2622361763
PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2622358572

From phubner at openjdk.org  Tue Dec 16 09:00:38 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:00:38 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
 <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
Message-ID: <PWetlZDkTqXjOFUcwjzI3f2Wpj_gAuHe_b1aPtd1cuc=.1121a8b5-dfbf-47e9-9d26-e549b7949139@github.com>

On Mon, 15 Dec 2025 22:45:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
>> 
>>  - Use the new function for the Parallel changes.
>>  - Merge branch 'lworld' into JDK-8371357
>>  - Remove wrong comment.
>>  - Fix imports.
>>  - Reviewer comments.
>>  - Copyright.
>>  - Revert "Don't synchronize on Double."
>>    
>>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>>  - Accidentally changed too many enable_preview.
>>  - Make heap dump test require debug VM.
>>  - Change to arguments.
>>  - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a
>
> src/hotspot/share/oops/markWord.hpp line 134:
> 
>> 132:   // instance state
>> 133:   static const int age_bits                       = 4;
>> 134:   // prototype header bits (fast path instead of klass layout_helper)
> 
> Why drop the word `static` in the comment here?

Static prototypes were part of an older model that no longer exists.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2622383158

From phubner at openjdk.org  Tue Dec 16 09:10:27 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:10:27 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <l8_vzNzt41oe_F9aajZDpypBYEdWWPTHLcNvYQEq-og=.b9e1561c-f2cf-4552-a134-6c96ca24aa22@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
 <l8_vzNzt41oe_F9aajZDpypBYEdWWPTHLcNvYQEq-og=.b9e1561c-f2cf-4552-a134-6c96ca24aa22@github.com>
Message-ID: <jc6-G3r6cUtjgGQ88GOsuXgN9vEvmb58EwBr6FZrdpg=.bc33df76-7cdc-41f6-b7a1-739fd8c2c9ce@github.com>

On Mon, 15 Dec 2025 20:05:58 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> test/jdk/ProblemList-Xcomp.txt line 35:
>> 
>>> 33: valhalla/valuetypes/ObjectNewInstance.java                      8369045 macosx-all
>>> 34: valhalla/valuetypes/ProxyTest.java                              8369045 macosx-all
>>> 35: valhalla/valuetypes/WeakReferenceTest.java                      8369045 macosx-all
>> 
>> Do these tests only fail with `-Xcomp` when `--enable-preview` is used?
>> Or do these tests only fail with `-Xcomp` in `lworld` regardless of the `--enable-preview` value?
>> 
>> If it's the latter case, then `ProblemList-Xcomp.txt` is the right place.
>> 
>> Reading through [JDK-8369045](https://bugs.openjdk.org/browse/JDK-8369045), it sounds like
>> `--enable-preview` is necessary so I don't think `ProblemList-Xcomp.txt` is the right place.
>
> valhalla/valutypes/ tests add `--enable-preview` so they are going to fail if executed with `-Xcomp` only.

As Leonid said: `-Xcomp`'s PL is the right place since all of these tests are designed with `@enablePreview`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2622408199

From phubner at openjdk.org  Tue Dec 16 09:10:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:10:31 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
Message-ID: <fj88Y0XdTEmB44gdEAfm8St4W0bNCzVFEUVMaJ5smXo=.bca187d5-c6cd-4e84-88c1-7de3bfb7e522@github.com>

On Mon, 15 Dec 2025 19:47:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into JDK-8373575
>>  - Move some tests to Xcomp list.
>>  - Add failing test to problemlist.
>>  - Add one of the AOT tests.
>>  - Problemlist and fix.
>
> test/langtools/TEST.ROOT line 53:
> 
>> 51:     vm.continuations \
>> 52:     vm.debug \
>> 53:     java.enablePreview
> 
> This just requires the `java.enablePreview` property to be set to `true` or `false`.
> It does not require `java.enablePreview` == `true`, correct?

This is required for us to be able to evaluate `java.enablePreview` in a JTREG `@requires` annotation. All properties are included on an allowlist basis, this is said allowlist.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2622410518

From phubner at openjdk.org  Tue Dec 16 09:10:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:10:32 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <NkKsqusNK9MhDOQ_pPRQsdkQ1leEkUxJZ_bQJDQ9i0s=.d084484e-842f-4922-ba81-155dbbeb3fd2@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
 <NkKsqusNK9MhDOQ_pPRQsdkQ1leEkUxJZ_bQJDQ9i0s=.d084484e-842f-4922-ba81-155dbbeb3fd2@github.com>
Message-ID: <Jtm3pUJGDlfg6u1AOkTzX3Hl_2D0kpXIkQ4I_npXxqk=.e684edb8-2d91-40e0-b2d9-112d48a4d368@github.com>

On Mon, 15 Dec 2025 21:11:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/langtools/tools/javac/AnonymousClass/AnonymousClassFlags.java line 29:
>> 
>>> 27:  * @summary Verify that anonymous class binaries have the correct flags set
>>> 28:  * @modules java.base/jdk.internal.misc
>>> 29:  * @requires !java.enablePreview
>> 
>> Why is `@requires !java.enablePreview` needed here? The test's id value is NoPreview so that might
>> indicate that the test doesn't support --enable-preview bits, but I had to expand the review's context
>> to see that id value.
>
> Another thought occurred to me. Perhaps add a comment line above the `@requires`:
> 
> @comment Test does not like Valhalla value classes.
> 
> or something like that. I think it would be good if we added a comment
> when we use `@requires !java.enablePreview` to indicate which preview
> feature is problematic.

This test is run twice, once without preview and once with preview. We need to guard the test without preview, such that if someone manually specifies `JTREG=JAVA_OPTIONS=--enable-preview`, the test doesn't fail. I'll add a comment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2622416792

From phubner at openjdk.org  Tue Dec 16 09:15:40 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:15:40 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <l0I5K5P3fyg6j5SOwyNGb6ZtJJ9v-91uJTT4AyR_ZkI=.10dc115d-b2c0-40f7-9124-0b77281593b3@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <l0I5K5P3fyg6j5SOwyNGb6ZtJJ9v-91uJTT4AyR_ZkI=.10dc115d-b2c0-40f7-9124-0b77281593b3@github.com>
Message-ID: <C4Tvch_17GA03I9K2rrXrj_8-i9VaGvDAKiY1QEIvBE=.1ebfc379-bf8d-4cd9-9108-2f44525362f4@github.com>

On Mon, 15 Dec 2025 21:07:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'lworld' into JDK-8373575
>>  - Move some tests to Xcomp list.
>>  - Add failing test to problemlist.
>>  - Add one of the AOT tests.
>>  - Problemlist and fix.
>
> test/hotspot/jtreg/compiler/escapeAnalysis/Test8329757.java line 46:
> 
>> 44:     void q() {
>> 45:         int e;
>> 46:         synchronized (new Object()) {
> 
> What motivated this change?

We cannot synchronize on value classes (primitive boxes are migrated to value classes with preview mode enabled) and we throw an `IdentityException` if we attempt to do so. I've talked with the author of the test and compiler folks and it doesn't change the semantics if we change the mutex.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2622436048

From phubner at openjdk.org  Tue Dec 16 09:19:42 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:19:42 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <NkKsqusNK9MhDOQ_pPRQsdkQ1leEkUxJZ_bQJDQ9i0s=.d084484e-842f-4922-ba81-155dbbeb3fd2@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <jp-i_JX-icaqV2j6bU_5WAMoo9z4rlr4128jw6fpISI=.da7558b9-1bf2-459e-a56c-e27ece8df276@github.com>
 <NkKsqusNK9MhDOQ_pPRQsdkQ1leEkUxJZ_bQJDQ9i0s=.d084484e-842f-4922-ba81-155dbbeb3fd2@github.com>
Message-ID: <Yk5wXd0wM9c25gFHCFoj8RMZB4EK1WZFm0ngnR2B7qI=.164a206c-3504-43d0-a11f-533d8a101815@github.com>

On Mon, 15 Dec 2025 21:11:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/langtools/tools/javap/T4975569.java line 30:
>> 
>>> 28:  * @modules jdk.jdeps/com.sun.tools.javap
>>> 29:  * @modules java.base/jdk.internal.misc
>>> 30:  * @requires !java.enablePreview
>> 
>> Why is  `@requires !java.enablePreview` needed here? The test's `id` value is `NoPreview` so that might
>> indicate that the test doesn't support `--enable-preview` bits, but I had to expand the review's context
>> to see that `id` value.
>
> Another thought occurred to me. Perhaps add a comment line above the `@requires`:
> 
> @comment Test does not like Valhalla value classes.
> 
> or something like that. I think it would be good if we added a comment
> when we use `@requires !java.enablePreview` to indicate which preview
> feature is problematic.

Added a comment.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2622449562

From jsikstro at openjdk.org  Tue Dec 16 09:28:36 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 16 Dec 2025 09:28:36 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
Message-ID: <mmgyTnGcLGoqtS3vFwLZu9XJ_bIcibClrb_J2owNwK0=.d7cb8c40-50c3-4719-8d2e-af407e870d4b@github.com>

On Mon, 15 Dec 2025 19:46:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Use the new function for the Parallel changes.
>  - Merge branch 'lworld' into JDK-8371357
>  - Remove wrong comment.
>  - Fix imports.
>  - Reviewer comments.
>  - Copyright.
>  - Revert "Don't synchronize on Double."
>    
>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>  - Accidentally changed too many enable_preview.
>  - Make heap dump test require debug VM.
>  - Change to arguments.
>  - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a

Now that we're not using EnableValhalla, which was in runtime/globals.hpp, there are several includes of runtime/globals.hpp which have been added over the years in the lworld branch that don't need to be added anymore.

I don't see an issue with including runtime/globals.hpp unnecessarily, just pointing it out.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3659588591

From duke at openjdk.org  Tue Dec 16 09:42:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 09:42:12 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v3]
In-Reply-To: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
Message-ID: <MKPSv_siLY6cxJujHnAJT7Mhjszbb0zGY2DL5J5EFdQ=.1b36137d-164e-41b3-a442-ba98cc7377fd@github.com>

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

 - remove automatic formatting
 - comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1761/files
  - new: https://git.openjdk.org/valhalla/pull/1761/files/e8b28af5..bf9ddb9e

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

  Stats: 87 lines in 2 files changed: 18 ins; 8 del; 61 mod
  Patch: https://git.openjdk.org/valhalla/pull/1761.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1761/head:pull/1761

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

From phubner at openjdk.org  Tue Dec 16 09:53:37 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:53:37 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v6]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <jycuetS1zgMB1H4k2HV75pATdWSflggsSa_NElnNrSE=.262fa88c-0e41-441f-ae6b-f1077cbbaf73@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

Paul H?bner has updated the pull request incrementally with two additional commits since the last revision:

 - Reviewer feedback.
 - Update problem list.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/7336f262..c948bff2

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

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

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

From phubner at openjdk.org  Tue Dec 16 09:53:41 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 09:53:41 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
Message-ID: <JlRlkqHoAuGQXFrtIK-BUarlclltad-hT2sP_lIhm2E=.1cb39765-6b97-40fc-915b-eb687c9d0ac8@github.com>

On Mon, 15 Dec 2025 19:22:29 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'lworld' into JDK-8373575
>  - Move some tests to Xcomp list.
>  - Add failing test to problemlist.
>  - Add one of the AOT tests.
>  - Problemlist and fix.

Addressed the comments, let's ship this if that's okay with the reviewers.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1793#issuecomment-3659689318

From phubner at openjdk.org  Tue Dec 16 10:03:48 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 10:03:48 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
 <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
Message-ID: <OKLAIcqiQbj0KM7gCG2KQId7J757S3KVwouCwl1cQpY=.243d0391-d07c-4547-a17b-b6ec81222caf@github.com>

On Mon, 15 Dec 2025 22:11:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
>> 
>>  - Use the new function for the Parallel changes.
>>  - Merge branch 'lworld' into JDK-8371357
>>  - Remove wrong comment.
>>  - Fix imports.
>>  - Reviewer comments.
>>  - Copyright.
>>  - Revert "Don't synchronize on Double."
>>    
>>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>>  - Accidentally changed too many enable_preview.
>>  - Make heap dump test require debug VM.
>>  - Change to arguments.
>>  - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a
>
> src/hotspot/share/cds/cdsConfig.hpp line 213:
> 
>> 211:     return Arguments::enable_preview() && EnableValhalla;
>> 212:   }
>> 213: 
> 
> Does this file still need to include `arguments.hpp`? I'm not seeing anymore calls into `Arguments::foo`.

Nope, I'll get rid of it.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2622602501

From phubner at openjdk.org  Tue Dec 16 10:19:23 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 10:19:23 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v4]
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <dAxaWCTvZ-ShIGiBLE_j8CoboLU7u__wqFiSxpUb9nE=.5c29920a-7226-4340-8616-fa38149bf2a4@github.com>

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

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

  Reviewer comments.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1759/files
  - new: https://git.openjdk.org/valhalla/pull/1759/files/58fb031a..e6c091fb

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

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

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

From phubner at openjdk.org  Tue Dec 16 10:19:25 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 10:19:25 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <mmgyTnGcLGoqtS3vFwLZu9XJ_bIcibClrb_J2owNwK0=.d7cb8c40-50c3-4719-8d2e-af407e870d4b@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
 <mmgyTnGcLGoqtS3vFwLZu9XJ_bIcibClrb_J2owNwK0=.d7cb8c40-50c3-4719-8d2e-af407e870d4b@github.com>
Message-ID: <Mgg7AHO70cPcrZYDs8skOAUQEuZ1DoqLo8bkz5DKLeE=.2178c654-308f-439e-a693-26cc0a3f4c25@github.com>

On Tue, 16 Dec 2025 09:25:37 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Now that we're not using EnableValhalla, which was in runtime/globals.hpp, there are several includes of runtime/globals.hpp which have been added over the years in the lworld branch that don't need to be added anymore.
> 
> I don't see an issue with including runtime/globals.hpp unnecessarily, just pointing it out.

Good idea. I've added it to the follow up RFE where we are doing cleanups already.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3659785104

From phubner at openjdk.org  Tue Dec 16 10:19:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 10:19:30 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
 <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
Message-ID: <qHGfCFHbtAjVc9Q4BI-yxlRw3qoeRpkjvIg8aL4rY9Q=.d64b9b5b-0d71-4edd-a642-e362650c39e8@github.com>

On Mon, 15 Dec 2025 22:30:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
>> 
>>  - Use the new function for the Parallel changes.
>>  - Merge branch 'lworld' into JDK-8371357
>>  - Remove wrong comment.
>>  - Fix imports.
>>  - Reviewer comments.
>>  - Copyright.
>>  - Revert "Don't synchronize on Double."
>>    
>>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>>  - Accidentally changed too many enable_preview.
>>  - Make heap dump test require debug VM.
>>  - Change to arguments.
>>  - ... and 13 more: https://git.openjdk.org/valhalla/compare/8c0c190b...58fb031a
>
> src/hotspot/share/oops/arrayOop.hpp line 59:
> 
>> 57:   // Given a type, return true if elements of that type must be aligned to 64-bit.
>> 58:   static bool element_type_should_be_aligned(BasicType type) {
>> 59:     if (type == T_FLAT_ELEMENT) {
> 
> You don't need `EnableValhalla` or `Arguments::is_valhalla_enabled()` as long as all callers
> of `element_type_should_be_aligned()` only pass known valid BasicType values. If any caller
> passes a non-valid BasicType value as part of a "probing call", then a call with a value that
> happens to match `T_FLAT_ELEMENT` by a VM with `Arguments::is_valhalla_enabled() == false`
> will return `true` unexpectedly.

I think this should be fine because `T_FLAT_ELEMENT` is hardcoded to `15` regardless of if Valhalla/preview is enabled.

> src/hotspot/share/runtime/arguments.cpp line 4006:
> 
>> 4004:     FLAG_SET_DEFAULT(BytecodeVerificationRemote, true);
>> 4005:   }
>> 4006:   if (is_valhalla_enabled() || (is_interpreter_only() && !CDSConfig::is_dumping_archive() && !UseSharedSpaces)) {
> 
> Hmmm... The original logic is `!EnableValhalla` so shouldn't this be: `!is_valhalla_enabled()`?

You're right. Good spot!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2622631986
PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2622645808

From phubner at openjdk.org  Tue Dec 16 10:19:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 10:19:31 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <qHGfCFHbtAjVc9Q4BI-yxlRw3qoeRpkjvIg8aL4rY9Q=.d64b9b5b-0d71-4edd-a642-e362650c39e8@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
 <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
 <qHGfCFHbtAjVc9Q4BI-yxlRw3qoeRpkjvIg8aL4rY9Q=.d64b9b5b-0d71-4edd-a642-e362650c39e8@github.com>
Message-ID: <PiD12hVjFVnqH-Fz1zrkyHgpEa3n0GyDpvm-ZLoQS58=.53355955-c752-4959-be32-f9fd73df900b@github.com>

On Tue, 16 Dec 2025 10:08:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> src/hotspot/share/oops/arrayOop.hpp line 59:
>> 
>>> 57:   // Given a type, return true if elements of that type must be aligned to 64-bit.
>>> 58:   static bool element_type_should_be_aligned(BasicType type) {
>>> 59:     if (type == T_FLAT_ELEMENT) {
>> 
>> You don't need `EnableValhalla` or `Arguments::is_valhalla_enabled()` as long as all callers
>> of `element_type_should_be_aligned()` only pass known valid BasicType values. If any caller
>> passes a non-valid BasicType value as part of a "probing call", then a call with a value that
>> happens to match `T_FLAT_ELEMENT` by a VM with `Arguments::is_valhalla_enabled() == false`
>> will return `true` unexpectedly.
>
> I think this should be fine because `T_FLAT_ELEMENT` is hardcoded to `15` regardless of if Valhalla/preview is enabled.

Testing until tier 4 also shows no issue, so I think I'm confident enough to leave it as is. Unless someone from compiler has any insights?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2622637514

From dsimms at openjdk.org  Tue Dec 16 10:31:06 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 10:31:06 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <T8YENgtogoeoeiHYBmGyYy0ySFGgtxoN0P37Z_elDxk=.705a44b9-aa6a-4c7e-84a0-4f3ceb06c579@github.com>
References: <T8YENgtogoeoeiHYBmGyYy0ySFGgtxoN0P37Z_elDxk=.705a44b9-aa6a-4c7e-84a0-4f3ceb06c579@github.com>
Message-ID: <XJYFDwyF_blCyXkxNMpiCewy3quqBuHbjc7CCiY9sAQ=.62e2597a-657e-4b8f-b95c-f6ffe4cfddbc@github.com>

On Tue, 16 Dec 2025 07:45:08 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-26+27' into lworld_merge_jdk_26_27
> 
> Added tag jdk-26+27 for changeset 45dcc0e7

This pull request has now been integrated.

Changeset: f4bad65a
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f4bad65a02e1d0d23ab61f7f2cc79be8a3ef7a4c
Stats:     24410 lines in 614 files changed: 14218 ins; 7577 del; 2615 mod

Merge

Merge jdk-26+27

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

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

From dsimms at openjdk.org  Tue Dec 16 10:36:49 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 10:36:49 GMT
Subject: RFR: 8373670: [lworld] Relax jcheck checks
Message-ID: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>

Disable reviewer and issue checks

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

Commit messages:
 - Issue title "[lw5]", but not enforced
 - 8373670: [lw5] Relax jcheck checks

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

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

From dsimms at openjdk.org  Tue Dec 16 10:36:50 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 10:36:50 GMT
Subject: RFR: 8373670: [lworld] Relax jcheck checks
In-Reply-To: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
References: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
Message-ID: <C8IHdqnSCC4Ripb_x1Ih3iNROks-S3BK05PNMJlzDqk=.e819e1c2-dfdf-433b-abd6-4cd15de8d2ce@github.com>

On Mon, 15 Dec 2025 10:03:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Disable reviewer and issue checks

One forgot `jcheck `is run twice, once for the current config in repo and then for the new, and the issue regex for "[lworld]" ([SKARA-2640](https://bugs.openjdk.org/browse/SKARA-2640) was still enforced

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

PR Comment: https://git.openjdk.org/valhalla/pull/1798#issuecomment-3659856728

From liach at openjdk.org  Tue Dec 16 10:36:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 10:36:51 GMT
Subject: RFR: 8373670: [lworld] Relax jcheck checks
In-Reply-To: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
References: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
Message-ID: <YF2J0dqZSaTMsTJ78qlN7_YdKhSXNPg8MQStf5XIGmM=.c6ec1fcb-814b-4515-9178-8eebb7e9199b@github.com>

On Mon, 15 Dec 2025 10:03:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Disable reviewer and issue checks

.jcheck/conf line 11:

> 9: warning=issuestitle,binary
> 10: 
> 11: [repository]

I think you can update the `branches=.*` field below, maybe make it `branches=lworld` for an exact match only?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1798#discussion_r2619959882

From dsimms at openjdk.org  Tue Dec 16 10:36:52 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 10:36:52 GMT
Subject: RFR: 8373670: [lworld] Relax jcheck checks
In-Reply-To: <YF2J0dqZSaTMsTJ78qlN7_YdKhSXNPg8MQStf5XIGmM=.c6ec1fcb-814b-4515-9178-8eebb7e9199b@github.com>
References: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
 <YF2J0dqZSaTMsTJ78qlN7_YdKhSXNPg8MQStf5XIGmM=.c6ec1fcb-814b-4515-9178-8eebb7e9199b@github.com>
Message-ID: <DagH7WKD4wkNkHu-_VSyZgd-3xXlLRBy_7YgiAfNoz4=.ea9447c1-8905-4688-a841-cc7d685f39d5@github.com>

On Mon, 15 Dec 2025 15:49:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Disable reviewer and issue checks
>
> .jcheck/conf line 11:
> 
>> 9: warning=issuestitle,binary
>> 10: 
>> 11: [repository]
> 
> I think you can update the `branches=.*` field below, maybe make it `branches=lworld` for an exact match only?

No, we allow arbitrary branch names in the Valhalla repository, this pr target is for `lw5` . Not sure I follow.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1798#discussion_r2622177866

From stefank at openjdk.org  Tue Dec 16 10:40:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 10:40:55 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
Message-ID: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>

The InlineKlassFixedBlock class has the following fields:

class InlineKlassFixedBlock {
  Array<SigEntry>** _extended_sig;
  Array<VMRegPair>** _return_regs;
  address* _pack_handler;
  address* _pack_handler_jobject;
  address* _unpack_handler;
  int* _null_reset_value_offset;


with associated functions that all look something like this:

  address adr_extended_sig() const {
    assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
    return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
  }


Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.

This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.

I propose that we restructure the code to reduce the casting and fix the type confusion.

As part of this cleanup I've also:

1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.

I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.

2) Simplified (IMHO) the address calculation of the location of the fixed block.

3) Moved the fixed block access functions together

Alternative:

One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:

fixed_block()._field = value;


I'm leaving this open for reviewers nudge what they think is cleanest. 

Question:

Has the name "fixed block" some meaning that conveys a concept of value classes?

Testing:

tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

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

Commit messages:
 - 8373779: [lworld] Type confusion with InlineKlassFixedBlock fields

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

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

From phubner at openjdk.org  Tue Dec 16 11:28:24 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 11:28:24 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v7]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <Lag_apfR89dnaZl-uVrsI1fXAWIBPye4kwlMNyLq96Y=.fc59b553-5abb-4d09-8674-bba14f350238@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'lworld' into JDK-8373575
 - Reviewer feedback.
 - Update problem list.
 - Merge branch 'lworld' into JDK-8373575
 - Move some tests to Xcomp list.
 - Add failing test to problemlist.
 - Add one of the AOT tests.
 - Problemlist and fix.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/c948bff2..bea53b9b

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

  Stats: 24912 lines in 643 files changed: 14349 ins; 7644 del; 2919 mod
  Patch: https://git.openjdk.org/valhalla/pull/1793.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1793/head:pull/1793

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

From phubner at openjdk.org  Tue Dec 16 11:30:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 11:30:08 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v5]
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <DKD8s1CiABzpK5FHTEVjt-hu7VbNii1qANdZevgj1dQ=.0a3fdbf5-c28c-446e-b4ea-9d63587365e1@github.com>

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'lworld' into JDK-8371357
 - Reviewer comments.
 - Use the new function for the Parallel changes.
 - Merge branch 'lworld' into JDK-8371357
 - Remove wrong comment.
 - Fix imports.
 - Reviewer comments.
 - Copyright.
 - Revert "Don't synchronize on Double."
   
   This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
 - Accidentally changed too many enable_preview.
 - ... and 15 more: https://git.openjdk.org/valhalla/compare/f4bad65a...b5612ea0

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

Changes: https://git.openjdk.org/valhalla/pull/1759/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1759&range=04
  Stats: 159 lines in 56 files changed: 59 ins; 13 del; 87 mod
  Patch: https://git.openjdk.org/valhalla/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1759/head:pull/1759

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

From stefank at openjdk.org  Tue Dec 16 11:40:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 11:40:20 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v3]
In-Reply-To: <PiD12hVjFVnqH-Fz1zrkyHgpEa3n0GyDpvm-ZLoQS58=.53355955-c752-4959-be32-f9fd73df900b@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <p_EtUlSpLVg-Xbd5UDMDqU5XXlX4scyuvd-ayL7e6mo=.682ab334-9928-4a65-9e88-3dc84a1a1488@github.com>
 <WjopKjYxJNV31OFbRinXpHo6RylREvRpjgVUOB54BQo=.3477f076-a336-409d-a276-e80646acf6b8@github.com>
 <qHGfCFHbtAjVc9Q4BI-yxlRw3qoeRpkjvIg8aL4rY9Q=.d64b9b5b-0d71-4edd-a642-e362650c39e8@github.com>
 <PiD12hVjFVnqH-Fz1zrkyHgpEa3n0GyDpvm-ZLoQS58=.53355955-c752-4959-be32-f9fd73df900b@github.com>
Message-ID: <EdBJHTI7U8Jt5Rgcahp5UOZv-zMrmLXwPwZ1T2OjqCQ=.57565fd3-1b8d-4481-9b39-639f0b62d717@github.com>

On Tue, 16 Dec 2025 10:10:20 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> I think this should be fine because `T_FLAT_ELEMENT` is hardcoded to `15` regardless of if Valhalla/preview is enabled.
>
> Testing until tier 4 also shows no issue, so I think I'm confident enough to leave it as is. Unless someone from compiler has any insights?

FWIW, a follow-up could add an assert in this branch that we are indeed running with value classes.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1759#discussion_r2622919594

From thartmann at openjdk.org  Tue Dec 16 11:52:26 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 16 Dec 2025 11:52:26 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <pDP0sYc1hixKIzaa5pWmgDZO9BGDaJHtNjj2HNz77LU=.fba67efd-8255-4c8b-89e6-c2301f2c09fe@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

This is a nice cleanup, thanks Stefan!

> Has the name "fixed block" some meaning that conveys a concept of value classes?

No, I don't think so.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1803#pullrequestreview-3582694272

From duke at openjdk.org  Tue Dec 16 11:59:51 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 11:59:51 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v3]
In-Reply-To: <MKPSv_siLY6cxJujHnAJT7Mhjszbb0zGY2DL5J5EFdQ=.1b36137d-164e-41b3-a442-ba98cc7377fd@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <MKPSv_siLY6cxJujHnAJT7Mhjszbb0zGY2DL5J5EFdQ=.1b36137d-164e-41b3-a442-ba98cc7377fd@github.com>
Message-ID: <pi2J-0vULSiW9_nQlC3C4XiV5SZnV2KeK49Bqvh2unc=.f330785d-e585-45a1-a283-f7ec343a3318@github.com>

On Tue, 16 Dec 2025 09:42:12 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 two additional commits since the last revision:
> 
>  - remove automatic formatting
>  - comments

Latest changes current in CI testing.

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

PR Review: https://git.openjdk.org/valhalla/pull/1761#pullrequestreview-3582212851

From duke at openjdk.org  Tue Dec 16 11:59:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 11:59:54 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v4]
In-Reply-To: <3CLg-4Umco2-hXsTgxgB41tDbjMfD15FbpITJjB9xCA=.8f88691b-589b-41a1-bcb4-5b4262fe7952@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <PamE2OIDMXDCW20GQU3Xr5jiIdxMNDyMQFRI9XtU2nM=.9a89a569-3622-491d-8a24-0afb572c8317@github.com>
 <3CLg-4Umco2-hXsTgxgB41tDbjMfD15FbpITJjB9xCA=.8f88691b-589b-41a1-bcb4-5b4262fe7952@github.com>
Message-ID: <oasrNb8BQiRmOkd4Ta7PbOuBmnotpjXrQHSp_dq3BhM=.168e9ed3-139a-4d73-adee-064d695e4256@github.com>

On Wed, 10 Dec 2025 10:39:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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.)

I'll try to sum this up with a comment somewhere.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622556074

From duke at openjdk.org  Tue Dec 16 11:59:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 11:59:57 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <bS2kpDJvTwRkMZxQ6rzZnh7_p9Pp0E28a-YLGamk7Zs=.104ad12b-94d6-48e1-a96d-1c55196e535d@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <bS2kpDJvTwRkMZxQ6rzZnh7_p9Pp0E28a-YLGamk7Zs=.104ad12b-94d6-48e1-a96d-1c55196e535d@github.com>
Message-ID: <a9fSqEUjTFERo_gC0nJ3R9Xv_fZa1CVYE8EXRxB__SE=.9a265bc8-6480-487a-b9df-1d24c4475dfb@github.com>

On Wed, 26 Nov 2025 19:48:07 GMT, Roger Riggs <rriggs 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 59:
> 
>> 57:  */
>> 58: public class JRTIndex implements Closeable {
>> 59:     public static JRTIndex getInstance(boolean previewMode) {
> 
> Generally, we (core-libs) have been dropping the "get" prefix on accessors; so there's no need to change the name of the method back to an older pattern.

Done.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622574653

From duke at openjdk.org  Tue Dec 16 12:00:00 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:00 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v4]
In-Reply-To: <PIhXnJn4PhSYwJGpUIKq8unOb5NEGz0nedoghTn_5lo=.15bb732d-026e-4dcf-a789-a5db1105f840@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>
 <PIhXnJn4PhSYwJGpUIKq8unOb5NEGz0nedoghTn_5lo=.15bb732d-026e-4dcf-a789-a5db1105f840@github.com>
Message-ID: <3AoWHZRnWnvGSB8c2L_aN5xqIQvD47lNa2tRV4Hk1oY=.465fd9e4-7607-4036-b842-760e0afbf6b1@github.com>

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

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 76:
>> 
>>> 74:     }
>>> 75: 
>>> 76:     private static class FileSystemResources {
>> 
>> Just moving all the outer class code into here. The actual changes are pretty small.
>> Mostly just the static management of the preview/non-preview versions and introduction of close semantics.
>
> This kind of refactoring is better done separately, making the intended change harder to review.

Doing so would slow this review down by at least a day. Are you okay with that given the time constraints. This change *isn't* just a "neatening up" of the code, there's key functionality here (since the relationship of JRTIndex instances to the underlying resources is moving from "one-to-one" to "many-to-one". I'll see about splitting this and all the closeable related changes up, but they need to go in before the rest of the plumbing.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622569854

From duke at openjdk.org  Tue Dec 16 12:00:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:02 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <QxeGDxOY3Aj-doX42krGcwQ9JNlHGMUGiZSAIAuV71g=.0a028384-5fd5-4d71-bdd5-bcacdccb0db3@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <QxeGDxOY3Aj-doX42krGcwQ9JNlHGMUGiZSAIAuV71g=.0a028384-5fd5-4d71-bdd5-bcacdccb0db3@github.com>
Message-ID: <P9R27WAXhObp1CcGY-vlYTyO06B4q5h5ImUqEQQEGs8=.9739e7ea-9fcb-4908-9d17-179e9d0cecdf@github.com>

On Wed, 10 Dec 2025 11:09:17 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/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.

There's only really one other place, but (see my other comment about asserts) I don't think the other case should be an assertion, since callers can just try to use the instance after it's closed. Here, it's a bug *in this source file* if close() were called twice (hence okay as an assert).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622824109

From duke at openjdk.org  Tue Dec 16 12:00:05 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:05 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v4]
In-Reply-To: <4z2sS2JZrAcPXtp5S4waExd-4nn1f_w1zieD6PSbuWI=.63f38ea6-2697-4b30-b991-a32b1afcfe8d@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <3HjsRShWk4GgyWcUBMgIHn2JPTNRkboWiWrFO94UD0o=.6453c17b-e8d1-49aa-88dd-55e64b4240ea@github.com>
 <4z2sS2JZrAcPXtp5S4waExd-4nn1f_w1zieD6PSbuWI=.63f38ea6-2697-4b30-b991-a32b1afcfe8d@github.com>
Message-ID: <ttk6DNVlu5-os_2rkPzwuWHCJ0BUdywsRE9f3SHns90=.db8c771c-5116-4b17-8a39-42cb5c0c8f50@github.com>

On Wed, 10 Dec 2025 11:10:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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.

Done (ISE).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622671431

From duke at openjdk.org  Tue Dec 16 12:00:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:07 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <KdTWiMpQkIvdtBAGWS1obYVvEYZKbxqwE7cCvQtA7is=.2c2ac018-908e-49dd-bd0d-53f53693fa7f@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <bS2kpDJvTwRkMZxQ6rzZnh7_p9Pp0E28a-YLGamk7Zs=.104ad12b-94d6-48e1-a96d-1c55196e535d@github.com>
 <KdTWiMpQkIvdtBAGWS1obYVvEYZKbxqwE7cCvQtA7is=.2c2ac018-908e-49dd-bd0d-53f53693fa7f@github.com>
Message-ID: <o6rqerUdGYfMiUwoVEZU5UUueGh7-fNmtWe2YmXjy2w=.519d7e75-d0a0-46b3-9157-78a9fc497376@github.com>

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

>> src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java line 305:
>> 
>>> 303:     }
>>> 304: 
>>> 305:     private final FileSystemResources sharedResources;
>> 
>> The fields of JRTIndex should be at the top of the class.
>> Fields, constructors, static methods, the rest.  
>> There's some debate about where nested classes go (I say at the end).
>
> It is worth saying something about the values that are kept here. 
> It looks like a singleton but is per JRTIndex and preview.

I'll move the field constructor and close method, but leave the rest to avoid churn.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622682829

From duke at openjdk.org  Tue Dec 16 12:00:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:10 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v4]
In-Reply-To: <vYyWFJsHzgmMHrg-80S0IfhKfrzdP2FIRHpJwtk3J9E=.8b10b2f1-c8f0-4c36-b6ed-510b532ccf89@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>
 <vYyWFJsHzgmMHrg-80S0IfhKfrzdP2FIRHpJwtk3J9E=.8b10b2f1-c8f0-4c36-b6ed-510b532ccf89@github.com>
Message-ID: <AgkV0PnqOdzcZuFYudf9_EQhZL1KejEivQJpG59TlUU=.d3bdb1fb-1d51-4e42-bc4b-5e69d9ffdb0f@github.com>

On Wed, 10 Dec 2025 13:45:31 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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.

I added comments. Thanks for explaining, I am much more confident this is correct now.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622797735

From duke at openjdk.org  Tue Dec 16 12:00:09 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:09 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v4]
In-Reply-To: <Mq9UPiqWZAab9x9-xDC_mQhaGOES15IwOXjBrcYXNo0=.debeef0a-0a84-4d75-890b-94addcdead5d@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>
 <Mq9UPiqWZAab9x9-xDC_mQhaGOES15IwOXjBrcYXNo0=.debeef0a-0a84-4d75-890b-94addcdead5d@github.com>
Message-ID: <PSq5Brx74Ebk3xcXaWXi4ywGRWFuGDLTiYwm0rgZBJ4=.accbff32-1467-475a-b1f8-65a9de4f2402@github.com>

On Wed, 10 Dec 2025 10:41:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> 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");

I don't see this as an assertion because I could easily write a test which causes it to happen.
To me, assertions are for code invariants that "should never happen" due to the immediate surrounding code and logic. This can be triggered by a badly behaved caller, which (due to the public nature of this class) could be anyone.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622742076

From duke at openjdk.org  Tue Dec 16 12:00:11 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:11 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <DIyRJz0ol38V2CDx20rokQPqEqEpW7J--tzWUr7uanw=.de6339a7-0e16-4c96-8884-4f72f013823b@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <BFxPYa4_ecuG4IvX0eEcUN4agELrJk8oc5hGT0-826w=.c2ca422e-4912-4867-8e1a-a3840d706d9e@github.com>
 <Hb-VfVMvt5pRQ_pK0kM7DmTqnrEAYXpX7MlhZ5fcQPo=.c4727c91-f3bc-4b2e-bf8a-8d4e216c7f33@github.com>
 <DIyRJz0ol38V2CDx20rokQPqEqEpW7J--tzWUr7uanw=.de6339a7-0e16-4c96-8884-4f72f013823b@github.com>
Message-ID: <tkA07HujsML0_la1sLFWStAbreQl_8q4q4FeXI_z-As=.9c12294b-93fc-48e5-affe-5e03aa3d9eba@github.com>

On Mon, 15 Dec 2025 16:32:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I think in the compiler you can't assume single threaded-ness, and unless this adds a deadlock risk (which I am pretty sure it doesn't) it's definitely my preference to have correctness and avoid weird bugs/failures.
>
> One instance of javac (i.e. one result of `ToolProvider.getSystemJavaCompiler().getTask(...)` is single-threaded, and cannot even be passed to a different thread without an external synchronization. There's no need for synchronization inside single instance of javac.
> 
> The case of file managers is a bit different: some backend data structures (like `JRTIndex` as such) are shared across various instances of file managers, and those definitely need to be synchronized. To what degree synchronization is needed here is unclear to me. The javadoc says that multi-threaded access to file managers is not required, and I don't think that concurrent use of the `JavacFileManager` from multiple instances of javac  is quite realistic (settings like multi-release or preview setting are kept in fields in the file manager, and the different instances of javac would talk past each other).
> 
> I.e. I don't think the synchronization here is really necessary. OTOH, the `JavacFileManager.getJRTIndex()` is currently synchronized, and it would seem more consistent for the `getJRTIndex()` and `closeables` to share the same synchronization approach. I would agree with Maurizio that I would mildly prefer to drop the synchronization, but I can live with the synchronization.

I prefer, for the sake of future maintainers, to make synchronization consistent. If one bit of code thinks locking is needed, then locking should be applied correctly everywhere to that instance. Not doing that means that, in a codebase which can be "light on comments", the confusion caused by seeing some bits of code caring about locking, and some not, could cost hours or even days of a maintainer's time as they try to untangle the inferred logic around synchronization. Worse it could lead to extremely rare and hard to debug problems.

Remember that what's assumed to be single threaded today might not be so in future and future maintainers may be much less familiar with the code than you are.

I the absence of a concrete clad argument that synchronisation is absolutely unnecessary (and in which case I want to remove it *everywhere* for this data structure and add comments explaining why that's safe) I strongly prefer to make the code more self-describing by making locking behaviour consistent.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622542560

From duke at openjdk.org  Tue Dec 16 12:00:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:14 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <PiUyFc_cztnUEZvJJ7EjYfNkGLd87AYgkYdrBDJI0t0=.a09e2702-6a03-4375-aa58-d7908db2d7f7@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <LMvkolnX7wWGCFFy6WXI3Sdg0j3kAg5Q-mi_qT-UxXA=.59d20110-d82e-46e3-8afc-632e54038a50@github.com>
 <PiUyFc_cztnUEZvJJ7EjYfNkGLd87AYgkYdrBDJI0t0=.a09e2702-6a03-4375-aa58-d7908db2d7f7@github.com>
Message-ID: <IkltLRNz3ClfYCeZd50O2TvSJ12QRwgKGlEOYA5Ez-s=.91b1f989-d84d-4970-b75f-cb29b36d471b@github.com>

On Wed, 10 Dec 2025 10:28:59 GMT, Jan Lahoda <jlahoda 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/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.

I think I get it. I'll try to sum it up in a comment since this is so subtle.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622550524

From duke at openjdk.org  Tue Dec 16 12:00:16 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 12:00:16 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v2]
In-Reply-To: <uVgKp0J6ksemp-GBGo_B9Tw72o7iGNP5xq6lN1ci0Y8=.8cca3608-f154-463c-972f-6c9231b3e3e5@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>
 <uVgKp0J6ksemp-GBGo_B9Tw72o7iGNP5xq6lN1ci0Y8=.8cca3608-f154-463c-972f-6c9231b3e3e5@github.com>
Message-ID: <tsTdsxYfq95ACHTzJZMdCf78HCyBm5FNE0YMC-VkQvU=.18a089af-4e80-4cf5-ae5b-6cae2c4a8358@github.com>

On Wed, 10 Dec 2025 10:15:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> 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.

If either of you think an additional comment would help future maintainers here, let me know what it should be.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1761#discussion_r2622813360

From duke at openjdk.org  Tue Dec 16 11:59:47 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 11:59:47 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v4]
In-Reply-To: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
Message-ID: <7prMzojKd4Xke3KoakT_44MaQBaCiGOO0_wXO3R-EWs=.6d87cd29-b1da-4ec2-8e82-36be412b2f35@github.com>

> 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:

  review feedback

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1761/files
  - new: https://git.openjdk.org/valhalla/pull/1761/files/bf9ddb9e..11e4c83e

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

  Stats: 114 lines in 7 files changed: 74 ins; 19 del; 21 mod
  Patch: https://git.openjdk.org/valhalla/pull/1761.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1761/head:pull/1761

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

From stefank at openjdk.org  Tue Dec 16 12:33:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 12:33:06 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes and
 words
Message-ID: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>

The following function in `InstanceKlass` is supposed to return size in words:

  static int size(int vtable_length, int itable_length,
                  int nonstatic_oop_map_size,
                  bool is_interface,
                  bool is_inline_type) {
    return align_metadata_size(header_size() +
           vtable_length +
           itable_length +
           nonstatic_oop_map_size +
           (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
           (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
  }

but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.

This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:

Before:

0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer

After:

0x000001800024d260 97 fully_initialized WS java.lang.Integer


That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 

I've so far only done some local smoke testing with TEST=hotspot_valhalla

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

Commit messages:
 - 8373787: [lworld] InstanceKlass::size mixes bytes and words

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

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

From phubner at openjdk.org  Tue Dec 16 12:55:19 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 12:55:19 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
Message-ID: <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>

On Tue, 16 Dec 2025 12:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The following function in `InstanceKlass` is supposed to return size in words:
> 
>   static int size(int vtable_length, int itable_length,
>                   int nonstatic_oop_map_size,
>                   bool is_interface,
>                   bool is_inline_type) {
>     return align_metadata_size(header_size() +
>            vtable_length +
>            itable_length +
>            nonstatic_oop_map_size +
>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>   }
> 
> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
> 
> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
> 
> Before:
> 
> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
> 
> After:
> 
> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
> 
> 
> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
> 
> I've so far only done some local smoke testing with TEST=hotspot_valhalla

This is a good catch! I think it would be good to stress test these changes with (App)CDS/AOT and COH on/off, possibly in conjunction. Judging by the fact that the RefArrayKlass assertion was kind of weak this whole time, I wouldn't be surprised if this unearths more CDS issues.

src/hotspot/share/oops/flatArrayKlass.hpp line 95:

> 93: 
> 94:   // sizing
> 95:   static int header_size()  { return sizeof(FlatArrayKlass) / wordSize; }

Curiously enough we actually got this right for `RefArrayKlass::header_size()` and I'm guessing the following assertion didn't actually do anything meaningful:

assert(RefArrayKlass::header_size() <= InstanceKlass::header_size(),
         "array klasses must be same size as InstanceKlass");

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

> 1048:            nonstatic_oop_map_size +
> 1049:            (is_interface ? (int)sizeof(Klass*) / wordSize : 0) +
> 1050:            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) / wordSize : 0));

Do we have an `x / wordSize` helper function anywhere? Too much inline arithmetic makes it hard to maintain, imo.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1804#pullrequestreview-3582934819
PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623156322
PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623158498

From phubner at openjdk.org  Tue Dec 16 12:55:21 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 12:55:21 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
 <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
Message-ID: <DQqPvKRwI4WCpHEJYS7aBXdxwLLHlX8vC-IVGtpLY40=.62e21ac4-8828-4107-9869-f3a4b764bcc2@github.com>

On Tue, 16 Dec 2025 12:49:20 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> The following function in `InstanceKlass` is supposed to return size in words:
>> 
>>   static int size(int vtable_length, int itable_length,
>>                   int nonstatic_oop_map_size,
>>                   bool is_interface,
>>                   bool is_inline_type) {
>>     return align_metadata_size(header_size() +
>>            vtable_length +
>>            itable_length +
>>            nonstatic_oop_map_size +
>>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>>   }
>> 
>> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
>> 
>> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
>> 
>> Before:
>> 
>> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
>> 
>> After:
>> 
>> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
>> 
>> 
>> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
>> 
>> I've so far only done some local smoke testing with TEST=hotspot_valhalla
>
> src/hotspot/share/oops/flatArrayKlass.hpp line 95:
> 
>> 93: 
>> 94:   // sizing
>> 95:   static int header_size()  { return sizeof(FlatArrayKlass) / wordSize; }
> 
> Curiously enough we actually got this right for `RefArrayKlass::header_size()` and I'm guessing the following assertion didn't actually do anything meaningful:
> 
> assert(RefArrayKlass::header_size() <= InstanceKlass::header_size(),
>          "array klasses must be same size as InstanceKlass");

Maybe it could even make sense to tighten the `<=` into a `=`, going by the error message. Thoughts?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623165585

From coleenp at openjdk.org  Tue Dec 16 13:11:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 13:11:35 GMT
Subject: [lworld] RFR: 8369043: [lworld] -XX:AOTMode=create crashes with
 UseCompactObjectHeaders on aarch64
Message-ID: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>

Some index_dependent_slop code found its way into the aarch64 code in the valhalla repo that isn't in mainline, and seems to have no reason to belong to the valhalla code.  Removing it and unproblem listing the tests.  The tests might soon fail for other reasons, but no longer fail for this one.
Tested with tier8 without this failure.  It's hard to reproduce in isolation.

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

Commit messages:
 - 8369043: [lworld] -XX:AOTMode=create crashes with UseCompactObjectHeaders on aarch64

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

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

From coleenp at openjdk.org  Tue Dec 16 13:15:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 13:15:22 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <_YNDa60g88Kuj7VJHns9KRY987PHy4EtGnY94cAsw2Q=.a2f0c768-de16-4a8c-a68d-dc5df37d3183@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

This is a nice cleanup.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1803#pullrequestreview-3583027946

From vromero at openjdk.org  Tue Dec 16 13:37:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Dec 2025 13:37:56 GMT
Subject: RFR: 8373670: [lworld] Relax jcheck checks
In-Reply-To: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
References: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
Message-ID: <8Tp7tcwBBL2Q5UHVmeO9NvoqIuqBLBxvCAoiBnCH-yc=.447aa199-1057-4da5-8695-24e1576767c1@github.com>

On Mon, 15 Dec 2025 10:03:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Disable reviewer and issue checks

lgtm, thanks!

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1798#pullrequestreview-3583121916

From fparain at openjdk.org  Tue Dec 16 13:52:27 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 13:52:27 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <wlYTQt22tiIognJ466yN-nu47OgG9TrAbBjR-6Kkbsw=.05a0f3e7-d8d9-4675-969e-feb7e86e22f7@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

The name InlineKlassFixedBlock has no particular meaning. It was just the name given to the struct when we stopped adding/removing individual inline klass fields to the variable section, and put all of them in a single block easier to manage. It could be renamed to something more meaningful like InlineKlassExtraFields. Which name would you prefer?

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

PR Comment: https://git.openjdk.org/valhalla/pull/1803#issuecomment-3660610505

From dsimms at openjdk.org  Tue Dec 16 13:52:32 2025
From: dsimms at openjdk.org (David Simms)
Date: Tue, 16 Dec 2025 13:52:32 GMT
Subject: Integrated: 8373670: [lworld] Relax jcheck checks
In-Reply-To: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
References: <PNO0_egSRr63IcuGmJzR8VWkAiJrRuHUs3FtqRK86os=.f24e0144-1118-4fac-8d8a-a904b408495a@github.com>
Message-ID: <-vgxw_nAGJ3GrxxfR3k0YxOHONXxTbCn3X7ImSfa-hk=.f9043587-5783-4790-b31c-93e98007a00e@github.com>

On Mon, 15 Dec 2025 10:03:34 GMT, David Simms <dsimms at openjdk.org> wrote:

> Disable reviewer and issue checks

This pull request has now been integrated.

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

8373670: [lworld] Relax jcheck checks

Reviewed-by: vromero

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

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

From fparain at openjdk.org  Tue Dec 16 13:59:20 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 13:59:20 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <do2RuYNa91Ask_vxL423D1DIiQinvdeHEEyqVlIT78s=.69039360-8b5a-4b9d-a89c-e44065f31a74@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

Thank you for this nice cleanup.
The InlineKlassFixedBlock should be declared in inlineKlass.hpp, but for some reasons I forgot, it was not possible when initially added, this is why it ended in instanceKlass.hpp unfortunately. Fixing this oddity in a different CR is fine.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1803#pullrequestreview-3583217768

From duke at openjdk.org  Tue Dec 16 14:22:48 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 14:22:48 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v5]
In-Reply-To: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
Message-ID: <tUkFM5RBKUlShbM9veAyfyrD_GApYGuwx4CIKrA4Elc=.1a5cb3a1-5e8e-46dc-924f-a33308b3722e@github.com>

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

 - Merge branch 'lworld' into plumbing
 - correct assertion
 - review feedback
 - remove automatic formatting
 - comments
 - Remove note about StableValue (not possible)
 - Use byte array not stream for simplicity
 - properties fix
 - Arguments fix, tweak close method
 - with extra patches
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/2839e49d...5dba9c85

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1761/files
  - new: https://git.openjdk.org/valhalla/pull/1761/files/11e4c83e..5dba9c85

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

  Stats: 270102 lines in 2548 files changed: 179878 ins; 50975 del; 39249 mod
  Patch: https://git.openjdk.org/valhalla/pull/1761.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1761/head:pull/1761

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

From stefank at openjdk.org  Tue Dec 16 14:29:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 14:29:37 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <DQqPvKRwI4WCpHEJYS7aBXdxwLLHlX8vC-IVGtpLY40=.62e21ac4-8828-4107-9869-f3a4b764bcc2@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
 <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
 <DQqPvKRwI4WCpHEJYS7aBXdxwLLHlX8vC-IVGtpLY40=.62e21ac4-8828-4107-9869-f3a4b764bcc2@github.com>
Message-ID: <oejC_-ZvzsWslX9JjMcyUHVcjkXi23EEaBXdwwKsDVM=.7a960ce9-56ba-4a53-be45-5785a89db588@github.com>

On Tue, 16 Dec 2025 12:52:18 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> src/hotspot/share/oops/flatArrayKlass.hpp line 95:
>> 
>>> 93: 
>>> 94:   // sizing
>>> 95:   static int header_size()  { return sizeof(FlatArrayKlass) / wordSize; }
>> 
>> Curiously enough we actually got this right for `RefArrayKlass::header_size()` and I'm guessing the following assertion didn't actually do anything meaningful:
>> 
>> assert(RefArrayKlass::header_size() <= InstanceKlass::header_size(),
>>          "array klasses must be same size as InstanceKlass");
>
> Maybe it could even make sense to tighten the `<=` into a `=`, going by the error message. Thoughts?

I think the reason why the check is there is so that vtables start at the same offset in all Klasses. So, it really just wants to make sure that the array klasses are not so big that they start putting fields where the vtable is supposed to start. I think the comment can be tweaked a little bit here.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623510191

From stefank at openjdk.org  Tue Dec 16 14:29:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 14:29:39 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
 <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
Message-ID: <NAtZCnSVX8TvqXYMNqncLShqDQZCqmkPRHlb19u2s38=.22788ade-01d8-48b0-b485-d62cb3182da4@github.com>

On Tue, 16 Dec 2025 12:50:01 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> The following function in `InstanceKlass` is supposed to return size in words:
>> 
>>   static int size(int vtable_length, int itable_length,
>>                   int nonstatic_oop_map_size,
>>                   bool is_interface,
>>                   bool is_inline_type) {
>>     return align_metadata_size(header_size() +
>>            vtable_length +
>>            itable_length +
>>            nonstatic_oop_map_size +
>>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>>   }
>> 
>> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
>> 
>> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
>> 
>> Before:
>> 
>> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
>> 
>> After:
>> 
>> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
>> 
>> 
>> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
>> 
>> I've so far only done some local smoke testing with TEST=hotspot_valhalla
>
> src/hotspot/share/oops/instanceKlass.hpp line 1050:
> 
>> 1048:            nonstatic_oop_map_size +
>> 1049:            (is_interface ? (int)sizeof(Klass*) / wordSize : 0) +
>> 1050:            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) / wordSize : 0));
> 
> Do we have an `x / wordSize` helper function anywhere? Too much inline arithmetic makes it hard to maintain, imo.

I couldn't find. And there's a very large number of these in the code base. I think this would be a cleanup that one would do outside of the Valhalla project.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623513456

From stefank at openjdk.org  Tue Dec 16 14:34:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 14:34:26 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <wlYTQt22tiIognJ466yN-nu47OgG9TrAbBjR-6Kkbsw=.05a0f3e7-d8d9-4675-969e-feb7e86e22f7@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
 <wlYTQt22tiIognJ466yN-nu47OgG9TrAbBjR-6Kkbsw=.05a0f3e7-d8d9-4675-969e-feb7e86e22f7@github.com>
Message-ID: <Cg2eqCvQhwWCu1f4KksIeZDiUMF0xOLUaEWC2R1WNBQ=.b4752b3a-7fff-47db-afa0-b440310fa182@github.com>

On Tue, 16 Dec 2025 13:47:57 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> The name InlineKlassFixedBlock has no particular meaning. It was just the name given to the struct when we stopped adding/removing individual inline klass fields to the variable section, and put all of them in a single block easier to manage. It could be renamed to something more meaningful like InlineKlassExtraFields. Which name would you prefer?

Thanks. Then I might get around to figuring out another name for it.

> Thank you for this nice cleanup. The InlineKlassFixedBlock should be declared in inlineKlass.hpp, but for some reasons I forgot, it was not possible when initially added, this is why it ended in instanceKlass.hpp unfortunately. Fixing this oddity in a different CR is fine.

The main reason I could find is that the size calculation in instanceKlass.cpp uses `sizeof(InlineKlassFixedBlock)`. That can be fixed by making a slight alteration to the allocation code + adding `size()` overload in `InlineKlass`.

I'll create a PR for that and then people can see if they like it or not.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1803#issuecomment-3660842597
PR Comment: https://git.openjdk.org/valhalla/pull/1803#issuecomment-3660852280

From fparain at openjdk.org  Tue Dec 16 14:36:37 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 14:36:37 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
Message-ID: <sHr5uk3TgTE65_4tMUIlkm-me0vAttK7-_GNlHY1X7w=.260e23ee-6ce1-438a-81ce-aa9af5e3c6a6@github.com>

On Tue, 16 Dec 2025 12:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The following function in `InstanceKlass` is supposed to return size in words:
> 
>   static int size(int vtable_length, int itable_length,
>                   int nonstatic_oop_map_size,
>                   bool is_interface,
>                   bool is_inline_type) {
>     return align_metadata_size(header_size() +
>            vtable_length +
>            itable_length +
>            nonstatic_oop_map_size +
>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>   }
> 
> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
> 
> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
> 
> Before:
> 
> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
> 
> After:
> 
> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
> 
> 
> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
> 
> I've so far only done some local smoke testing with TEST=hotspot_valhalla

Good catch!
Looks good to me.
Additional cleanup in arrays code could be addressed in a different CR.

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1804#pullrequestreview-3583422011

From fparain at openjdk.org  Tue Dec 16 14:36:38 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 14:36:38 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <oejC_-ZvzsWslX9JjMcyUHVcjkXi23EEaBXdwwKsDVM=.7a960ce9-56ba-4a53-be45-5785a89db588@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
 <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
 <DQqPvKRwI4WCpHEJYS7aBXdxwLLHlX8vC-IVGtpLY40=.62e21ac4-8828-4107-9869-f3a4b764bcc2@github.com>
 <oejC_-ZvzsWslX9JjMcyUHVcjkXi23EEaBXdwwKsDVM=.7a960ce9-56ba-4a53-be45-5785a89db588@github.com>
Message-ID: <R4hVEVVU9GKel4b_8qHMU6gpeYvtWva2XilQh_f8Tg8=.04156a9e-c733-49dc-97b5-bfa78d9bd05a@github.com>

On Tue, 16 Dec 2025 14:26:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Maybe it could even make sense to tighten the `<=` into a `=`, going by the error message. Thoughts?
>
> I think the reason why the check is there is so that vtables start at the same offset in all Klasses. So, it really just wants to make sure that the array klasses are not so big that they start putting fields where the vtable is supposed to start. I think the comment can be tweaked a little bit here.

It is even weirder when you consider that the RefArrayKlass/FlatArrayKlass::header_size() value is only used for assertion. All paths I've found using this method end up calling `ArrayKlass::static_size()`, where the header size value is asserted, then immediately erased:


int ArrayKlass::static_size(int header_size) {
  // size of an array klass object
  assert(header_size <= InstanceKlass::header_size(), "bad header size");
  // If this assert fails, see comments in base_create_array_klass.
  header_size = InstanceKlass::header_size();
  int vtable_len = Universe::base_vtable_size();
  int size = header_size + vtable_len;
  return align_metadata_size(size);
}


Could we have a more static way to check this header size constraint?

This could be the topic of another CR.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623531226

From stefank at openjdk.org  Tue Dec 16 14:38:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 14:38:44 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <t01_rIQ0PDwXMu4zPHXsZC8YduLhLKkcMWKjS4LbxUg=.ce421d0b-e590-4dc5-8908-73d96bc7e381@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

Thanks for reviewing this! I'm running this through tier1 before issuing the integrate command.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1803#issuecomment-3660878245

From fparain at openjdk.org  Tue Dec 16 14:46:52 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 14:46:52 GMT
Subject: [lworld] RFR: 8373606: [lworld] PrintFlatArrayLayout should print
 LayoutKind and ArrayProperties
In-Reply-To: <EIfD-Jbm7x5sQGBYJloxxZYNYKUAlaRBl1hd0pcEOWE=.9450b323-39a3-41db-a24a-be9d623d9b48@github.com>
References: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
 <EIfD-Jbm7x5sQGBYJloxxZYNYKUAlaRBl1hd0pcEOWE=.9450b323-39a3-41db-a24a-be9d623d9b48@github.com>
Message-ID: <-3a4ifjs6dkjUdrrQve8ZzxixJIOkMqej-jYfpZj-_k=.c0fe299a-f381-4ab8-a00d-ccb587011cfa@github.com>

On Mon, 15 Dec 2025 23:02:43 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Extend the information printed by PrintFlatArrayLayout to include LayoutKind and ArrayProperties.
>> 
>> Tested with Mach5 tier1
>
> looks reasonable

Thanks @DanHeidinga @MrSimms for your reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1795#issuecomment-3660900666

From fparain at openjdk.org  Tue Dec 16 14:46:55 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 14:46:55 GMT
Subject: [lworld] Integrated: 8373606: [lworld] PrintFlatArrayLayout should
 print LayoutKind and ArrayProperties
In-Reply-To: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
References: <1UiyoarC5D5FAsCH9i3-sHfAQynrkojox-bzO9OjWOQ=.efd43849-31c8-4ce6-b25e-3dfb3848d813@github.com>
Message-ID: <6piYsKzuAa7V0EtZ__X5rUI7ky5_honaarywK43j4pc=.fbb8cf74-f2cc-4a65-b23b-71625d5b7c34@github.com>

On Fri, 12 Dec 2025 16:32:59 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Extend the information printed by PrintFlatArrayLayout to include LayoutKind and ArrayProperties.
> 
> Tested with Mach5 tier1

This pull request has now been integrated.

Changeset: 991a47dc
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/991a47dcb41e308cb3c315f52c6f41411cb7b94d
Stats:     84 lines in 6 files changed: 66 ins; 17 del; 1 mod

8373606: [lworld] PrintFlatArrayLayout should print LayoutKind and ArrayProperties

Reviewed-by: heidinga, dsimms

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

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

From phubner at openjdk.org  Tue Dec 16 14:48:52 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 14:48:52 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <NAtZCnSVX8TvqXYMNqncLShqDQZCqmkPRHlb19u2s38=.22788ade-01d8-48b0-b485-d62cb3182da4@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
 <IwrJ-btyjfPPyALU1PcJYeZ-FxZy-m0YXdh9AW6i1EA=.0b8a53e3-97b6-48ec-bed2-c06f778282bc@github.com>
 <NAtZCnSVX8TvqXYMNqncLShqDQZCqmkPRHlb19u2s38=.22788ade-01d8-48b0-b485-d62cb3182da4@github.com>
Message-ID: <mshzVrJ80MqFF9XRN19IGIaiDntQrDhLUTOKoM8xbj0=.92e10a83-54b0-4a0c-af5b-990a9fc696ed@github.com>

On Tue, 16 Dec 2025 14:26:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.hpp line 1050:
>> 
>>> 1048:            nonstatic_oop_map_size +
>>> 1049:            (is_interface ? (int)sizeof(Klass*) / wordSize : 0) +
>>> 1050:            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) / wordSize : 0));
>> 
>> Do we have an `x / wordSize` helper function anywhere? Too much inline arithmetic makes it hard to maintain, imo.
>
> I couldn't find. And there's a very large number of these in the code base. I think this would be a cleanup that one would do outside of the Valhalla project.

Agree, doesn't make sense to do it for this change let alone Valhalla.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1804#discussion_r2623582535

From fparain at openjdk.org  Tue Dec 16 14:52:55 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 14:52:55 GMT
Subject: [lworld] RFR: 8373706: [lworld] Layout names should be
 self-explanatory [v2]
In-Reply-To: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
References: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
Message-ID: <_8l5t4vC_o1aTpls70oFVgc-0kS08lh2GoU9poOq9aE=.1c78c9da-831e-4438-88f4-17a649e159ed@github.com>

> Renaming of layout kinds to make them self-explanatory.
> Also, provides layout kind -> string methods to normalize names of layouts in all logging messages and tests.
> 
> Initially tested with tier 1-3 (re-validating after merge/minor changes).
> 
> Thank you.
> 
> Fred

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

  Fix ending blank line

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1801/files
  - new: https://git.openjdk.org/valhalla/pull/1801/files/13808f44..2cfafbdf

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

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

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

From phubner at openjdk.org  Tue Dec 16 14:53:21 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 14:53:21 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v8]
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <O_GUsE54xIcvtYnGPFXKArJ4UhMDP0OrQkrisSGnzUo=.a84c78e3-07d5-49ef-8571-e31ee21e7441@github.com>

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

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

  Add new test to problem list.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1793/files
  - new: https://git.openjdk.org/valhalla/pull/1793/files/bea53b9b..89d1da67

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

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

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

From fparain at openjdk.org  Tue Dec 16 14:52:57 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 14:52:57 GMT
Subject: [lworld] RFR: 8373706: [lworld] Layout names should be
 self-explanatory [v2]
In-Reply-To: <BNQxe8FNLgsMUADaut2QAXlR41Qwau7KqZhyK-JnJrU=.0f1dbda8-f829-4d36-b9eb-df9dd6dd690f@github.com>
References: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
 <BNQxe8FNLgsMUADaut2QAXlR41Qwau7KqZhyK-JnJrU=.0f1dbda8-f829-4d36-b9eb-df9dd6dd690f@github.com>
Message-ID: <XES6Bbqvh6ofaW9m4S8iGhrpIDqA0nzlHstwjFks1ok=.3e78372d-94c5-44bb-b6ab-35b438300692@github.com>

On Mon, 15 Dec 2025 22:32:09 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix ending blank line
>
> looks reasonable to me

Thanks @DanHeidinga @MrSimms for your reviews.

> src/hotspot/share/oops/layoutKind.cpp line 45:
> 
>> 43:       ShouldNotReachHere();
>> 44:   }
>> 45: }
> 
> Do we need a blank line at the end of the file?

Fixed

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

PR Comment: https://git.openjdk.org/valhalla/pull/1801#issuecomment-3660934478
PR Review Comment: https://git.openjdk.org/valhalla/pull/1801#discussion_r2623590406

From rriggs at openjdk.org  Tue Dec 16 14:55:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Dec 2025 14:55:16 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v5]
In-Reply-To: <tUkFM5RBKUlShbM9veAyfyrD_GApYGuwx4CIKrA4Elc=.1a5cb3a1-5e8e-46dc-924f-a33308b3722e@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <tUkFM5RBKUlShbM9veAyfyrD_GApYGuwx4CIKrA4Elc=.1a5cb3a1-5e8e-46dc-924f-a33308b3722e@github.com>
Message-ID: <E_dLJEWhNnOsIqmmShzcZtcYaKGAYgtmoue7eXGNKQc=.ddb7c0b1-1143-4c9d-89fd-5ab4f6c43fa6@github.com>

On Tue, 16 Dec 2025 14:22:48 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 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 11 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into plumbing
>  - correct assertion
>  - review feedback
>  - remove automatic formatting
>  - comments
>  - Remove note about StableValue (not possible)
>  - Use byte array not stream for simplicity
>  - properties fix
>  - Arguments fix, tweak close method
>  - with extra patches
>  - ... and 1 more: https://git.openjdk.org/valhalla/compare/272ace68...5dba9c85

Looks good enough to become the default and additional cleanup can be done later.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1761#pullrequestreview-3583510922

From duke at openjdk.org  Tue Dec 16 15:03:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 15:03:47 GMT
Subject: [lworld] RFR: 8372515: [lworld] Plumb in javac flags for compiling
 with preview mode [v5]
In-Reply-To: <tUkFM5RBKUlShbM9veAyfyrD_GApYGuwx4CIKrA4Elc=.1a5cb3a1-5e8e-46dc-924f-a33308b3722e@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
 <tUkFM5RBKUlShbM9veAyfyrD_GApYGuwx4CIKrA4Elc=.1a5cb3a1-5e8e-46dc-924f-a33308b3722e@github.com>
Message-ID: <nUp7Coyfxxq2LpM8UJHpvhSM1hpUhWO1c2X6mm7iniQ=.d82faac5-db40-449d-8243-0f5ceea1b04f@github.com>

On Tue, 16 Dec 2025 14:22:48 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 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 11 additional commits since the last revision:
> 
>  - Merge branch 'lworld' into plumbing
>  - correct assertion
>  - review feedback
>  - remove automatic formatting
>  - comments
>  - Remove note about StableValue (not possible)
>  - Use byte array not stream for simplicity
>  - properties fix
>  - Arguments fix, tweak close method
>  - with extra patches
>  - ... and 1 more: https://git.openjdk.org/valhalla/compare/4e04540c...5dba9c85

@david-beaumont 
Your change (at version 5dba9c8595d2644ed070b6a0b6d85753204265ca) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1761#issuecomment-3660995773

From liach at openjdk.org  Tue Dec 16 15:19:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 15:19:30 GMT
Subject: [lworld] RFR: 8373701: [lworld] Revert Use Objects.equals in
 HashMap and ConcurrentHashmap
In-Reply-To: <uuNuLk_g0Zcvttq41nsdz4I6EQmTFteyuXGNBl5B5Fw=.e8ad5cc7-f39f-421a-ac81-f26920a5140d@github.com>
References: <uuNuLk_g0Zcvttq41nsdz4I6EQmTFteyuXGNBl5B5Fw=.e8ad5cc7-f39f-421a-ac81-f26920a5140d@github.com>
Message-ID: <pKmfyekXeyW9P8xt5oBhSG7LvwZAsvRmFQW5mLfcgBo=.7a6a6ca5-837e-441a-8658-8df686214fa8@github.com>

On Mon, 15 Dec 2025 19:14:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revert the use of Objects.equals to the previous explicit `==` check for identity and conditional call to .equals. The use of Objects.equals (without identity) caused classes with poorly written .equals methods to work incorrectly with HashMap and ConcurrentHashMap.
> 
> This reverts commit c8d4a247861052aa6ed43125bcbe49995326938f.

As discussed with John Rose and others. I guess the goal is to represent == as some sort of C2 macro node, so if an `equals` invocation` tests `==` it can be coalesced with the caller ==.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1800#pullrequestreview-3583422475

From rriggs at openjdk.org  Tue Dec 16 15:19:29 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Dec 2025 15:19:29 GMT
Subject: [lworld] RFR: 8373701: [lworld] Revert Use Objects.equals in HashMap
 and ConcurrentHashmap
Message-ID: <uuNuLk_g0Zcvttq41nsdz4I6EQmTFteyuXGNBl5B5Fw=.e8ad5cc7-f39f-421a-ac81-f26920a5140d@github.com>

Revert the use of Objects.equals to the previous explicit `==` check for identity and conditional call to .equals. The use of Objects.equals (without identity) caused classes with poorly written .equals methods to work incorrectly with HashMap and ConcurrentHashMap.

This reverts commit c8d4a247861052aa6ed43125bcbe49995326938f.

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

Commit messages:
 - Revert "8366214: [lworld] Use Objects.equals in HashMap and ConcurrentHashmap"

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

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

From dcubed at openjdk.org  Tue Dec 16 15:20:12 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 16 Dec 2025 15:20:12 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v8]
In-Reply-To: <O_GUsE54xIcvtYnGPFXKArJ4UhMDP0OrQkrisSGnzUo=.a84c78e3-07d5-49ef-8571-e31ee21e7441@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <O_GUsE54xIcvtYnGPFXKArJ4UhMDP0OrQkrisSGnzUo=.a84c78e3-07d5-49ef-8571-e31ee21e7441@github.com>
Message-ID: <dK9iItTmDoU-hbRIxe5vejCILTRfRXMVdKMBoEyqVCM=.7818cda0-3a5a-426f-bdcf-2508377946ed@github.com>

On Tue, 16 Dec 2025 14:53:21 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new test to problem list.

Thumbs up. Thanks for making additional tweaks.

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

Marked as reviewed by dcubed (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1793#pullrequestreview-3583640153

From duke at openjdk.org  Tue Dec 16 15:32:03 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 15:32:03 GMT
Subject: RFR: 8373806: [lworld] Disable preview patching by default
Message-ID: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>

Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.

This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.

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

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

Commit messages:
 - flip default property value

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

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

From rriggs at openjdk.org  Tue Dec 16 15:52:48 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Dec 2025 15:52:48 GMT
Subject: RFR: 8373806: [lworld] Disable preview patching by default
In-Reply-To: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
References: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
Message-ID: <ba-nb-F7jqzznZaNU-X9mNXuTq_hDjvBpb5_ZmZH9SI=.0752e9ab-6672-4ead-9dab-340b1cf819d3@github.com>

On Tue, 16 Dec 2025 15:25:30 GMT, David Beaumont <duke at openjdk.org> wrote:

> Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.
> 
> This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
> A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1806#pullrequestreview-3583795146

From fparain at openjdk.org  Tue Dec 16 15:55:17 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:55:17 GMT
Subject: [lworld] RFR: 8373706: [lworld] Layout names should be
 self-explanatory [v3]
In-Reply-To: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
References: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
Message-ID: <ZdBJW8DsfTOsveYGcLpkl8z27MjTXYc3CARgyGyZT_w=.ab69afd1-51d2-476c-a166-ed52a5959710@github.com>

> Renaming of layout kinds to make them self-explanatory.
> Also, provides layout kind -> string methods to normalize names of layouts in all logging messages and tests.
> 
> Initially tested with tier 1-3 (re-validating after merge/minor changes).
> 
> Thank you.
> 
> Fred

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

 - Merge remote-tracking branch 'upstream/lworld' into print_layout_cleanup
 - Fix ending blank line
 - Make layout names should be self-explanatory

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

Changes: https://git.openjdk.org/valhalla/pull/1801/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1801&range=02
  Stats: 106 lines in 15 files changed: 13 ins; 1 del; 92 mod
  Patch: https://git.openjdk.org/valhalla/pull/1801.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1801/head:pull/1801

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

From fparain at openjdk.org  Tue Dec 16 15:57:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 16 Dec 2025 15:57:32 GMT
Subject: [lworld] Integrated: 8373706: [lworld] Layout names should be
 self-explanatory
In-Reply-To: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
References: <9sL5ERNPk7Vxk1iBPJdgvEPVdkmTU2B4vdtrH8gumyI=.13567096-af6b-4b5b-a370-fe25c7d930d7@github.com>
Message-ID: <kw8WJ_mdC00lTgaef8sXnpjqoVeCb6-sHrIrdqWvB24=.75164706-c49e-454c-b94b-f97f577da522@github.com>

On Mon, 15 Dec 2025 19:39:44 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Renaming of layout kinds to make them self-explanatory.
> Also, provides layout kind -> string methods to normalize names of layouts in all logging messages and tests.
> 
> Initially tested with tier 1-3 (re-validating after merge/minor changes).
> 
> Thank you.
> 
> Fred

This pull request has now been integrated.

Changeset: b0ac1629
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b0ac16290fe4126a5597430e655ecd5a745d288c
Stats:     106 lines in 15 files changed: 13 ins; 1 del; 92 mod

8373706: [lworld] Layout names should be self-explanatory

Reviewed-by: heidinga, dsimms

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

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

From phubner at openjdk.org  Tue Dec 16 16:07:46 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 16:07:46 GMT
Subject: [lworld] Integrated: 8373575: [lworld] Fix and problem list failing
 JDK, langtools and HotSpot tier 1 tests under --enable-preview
In-Reply-To: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
Message-ID: <PKlL8zKMcw9LqU7VZvUKcMaQj5c_QAhEWg3QfDLh6JM=.be2cca7d-0114-4bc3-a1e6-6b12b5a51c6c@github.com>

On Fri, 12 Dec 2025 13:20:30 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
> 
> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
> 
> Testing: tier1, with and without `--enable-preview`.

This pull request has now been integrated.

Changeset: ef301b76
Author:    Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ef301b763d03e612be7ad34b49b84f39fd7ce287
Stats:     48 lines in 10 files changed: 45 ins; 0 del; 3 mod

8373575: [lworld] Fix and problem list failing JDK, langtools and HotSpot tier 1 tests under --enable-preview

Reviewed-by: coleenp, lmesnik, dcubed

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

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

From phubner at openjdk.org  Tue Dec 16 16:07:44 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 16:07:44 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v8]
In-Reply-To: <O_GUsE54xIcvtYnGPFXKArJ4UhMDP0OrQkrisSGnzUo=.a84c78e3-07d5-49ef-8571-e31ee21e7441@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <O_GUsE54xIcvtYnGPFXKArJ4UhMDP0OrQkrisSGnzUo=.a84c78e3-07d5-49ef-8571-e31ee21e7441@github.com>
Message-ID: <z-Fa7wqK7gjto9fcZCXzckpKMz6VCc7mHwWqQ4FJ_E8=.7dcc774f-0ea6-48de-9d6c-5788344e5bf8@github.com>

On Tue, 16 Dec 2025 14:53:21 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> Many tier 1 tests fail when running with `JTREG="JAVA_OPTIONS=--enable-preview"`. This PR does trivial fixes to test configurations and problemlists the rest of the failing tests.
>> 
>> This PR is necessary to complete [JDK-8371357](https://bugs.openjdk.org/browse/JDK-8371357).
>> 
>> Testing: tier1, with and without `--enable-preview`.
>
> Paul H?bner has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add new test to problem list.

Thanks for the reviews everyone.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1793#issuecomment-3661282256

From thartmann at openjdk.org  Tue Dec 16 16:11:51 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 16 Dec 2025 16:11:51 GMT
Subject: [lworld] RFR: 8369043: [lworld] -XX:AOTMode=create crashes with
 UseCompactObjectHeaders on aarch64
In-Reply-To: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>
References: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>
Message-ID: <gGElUbqVFwFN7l6_81BRx2jQ3A07IIChjbFyEojkGj8=.42df9bfb-3675-4715-ace8-8ef1c3f8d06e@github.com>

On Tue, 16 Dec 2025 13:05:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Some index_dependent_slop code found its way into the aarch64 code in the valhalla repo that isn't in mainline, and seems to have no reason to belong to the valhalla code.  Removing it and unproblem listing the tests.  The tests might soon fail for other reasons, but no longer fail for this one.
> Tested with tier8 without this failure.  It's hard to reproduce in isolation.

Looks good to me.

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

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1805#pullrequestreview-3583879640

From phubner at openjdk.org  Tue Dec 16 16:23:12 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 16:23:12 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v6]
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'lworld' into JDK-8371357
 - Merge branch 'lworld' into JDK-8371357
 - Reviewer comments.
 - Use the new function for the Parallel changes.
 - Merge branch 'lworld' into JDK-8371357
 - Remove wrong comment.
 - Fix imports.
 - Reviewer comments.
 - Copyright.
 - Revert "Don't synchronize on Double."
   
   This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
 - ... and 16 more: https://git.openjdk.org/valhalla/compare/ef301b76...6eae2446

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

Changes: https://git.openjdk.org/valhalla/pull/1759/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1759&range=05
  Stats: 159 lines in 56 files changed: 59 ins; 13 del; 87 mod
  Patch: https://git.openjdk.org/valhalla/pull/1759.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1759/head:pull/1759

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

From duke at openjdk.org  Tue Dec 16 16:28:12 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 16:28:12 GMT
Subject: [lworld] Integrated: 8372515: [lworld] Plumb in javac flags for
 compiling with preview mode
In-Reply-To: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
References: <_LrOki5ZGHeh5-OezPeJIUMW3opfRUTYKnuvU3X0t-c=.1ddf512e-9522-41c4-8c20-4b46fb40780f@github.com>
Message-ID: <ZEWdHRh6QwcavburxQPlsxAa3QEiuaidgkS61pknYm4=.5817395f-cc7f-4c0c-adee-f36cff555632@github.com>

On Tue, 25 Nov 2025 14:52:23 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.

This pull request has now been integrated.

Changeset: 7bcb2999
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/7bcb29996955edd5473c2e5e8ecf30c5c03d882e
Stats:     667 lines in 17 files changed: 518 ins; 86 del; 63 mod

8372515: [lworld] Plumb in javac flags for compiling with preview mode

Reviewed-by: mcimadamore, rriggs

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

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

From stefank at openjdk.org  Tue Dec 16 16:31:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 16:31:26 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v6]
In-Reply-To: <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>
Message-ID: <wiyMxnIx1ebrM1ktyeacd9vztCHAIA7q6SC58o9S85s=.563d3aa3-eb6f-4527-b2cf-9cb5f42a5344@github.com>

On Tue, 16 Dec 2025 16:23:12 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'lworld' into JDK-8371357
>  - Merge branch 'lworld' into JDK-8371357
>  - Reviewer comments.
>  - Use the new function for the Parallel changes.
>  - Merge branch 'lworld' into JDK-8371357
>  - Remove wrong comment.
>  - Fix imports.
>  - Reviewer comments.
>  - Copyright.
>  - Revert "Don't synchronize on Double."
>    
>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>  - ... and 16 more: https://git.openjdk.org/valhalla/compare/ef301b76...6eae2446

Marked as reviewed by stefank (Author).

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

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3583961936

From duke at openjdk.org  Tue Dec 16 16:37:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 16:37:54 GMT
Subject: [lworld] RFR: 8373806: [lworld] Disable preview patching by
 default [v2]
In-Reply-To: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
References: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
Message-ID: <jbfb_oBm_hSgJ-OgW0rKP1INoNEpUFW4dlaOVfHXAZU=.3850cfbc-4eb2-4fb8-b2d9-daf30e447d53@github.com>

> Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.
> 
> This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
> A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.

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

 - flip default property value
 - Merge branch 'lworld' into plumbing
 - correct assertion
 - review feedback
 - remove automatic formatting
 - comments
 - Remove note about StableValue (not possible)
 - Use byte array not stream for simplicity
 - properties fix
 - Arguments fix, tweak close method
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/b98b941e...c8cfd92b

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1806/files
  - new: https://git.openjdk.org/valhalla/pull/1806/files/c8cfd92b..c8cfd92b

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

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

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

From liach at openjdk.org  Tue Dec 16 16:50:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 16:50:53 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview
Message-ID: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>

Fixes the inconsistency observed by @Arraying for this test.

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

Commit messages:
 - Remove PL entry
 - 8372740

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

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

From phubner at openjdk.org  Tue Dec 16 16:50:53 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 16:50:53 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview
In-Reply-To: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
Message-ID: <BHDJDOnQ9EhCmOTCPLxkF8hEL_pbzBjkX0xCPYgu-2c=.6c62d74a-66ec-4f53-b457-f817b6b5ccd0@github.com>

On Tue, 16 Dec 2025 16:41:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes the inconsistency observed by @Arraying for this test.

So if I understand this properly, this is VM-independent and the outcome should solely be judged based on if `javac` compiles a preview class?

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

PR Review: https://git.openjdk.org/valhalla/pull/1807#pullrequestreview-3584048606

From lmesnik at openjdk.org  Tue Dec 16 16:54:45 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Dec 2025 16:54:45 GMT
Subject: [lworld] RFR: 8373575: [lworld] Fix and problem list failing JDK, 
 langtools and HotSpot tier 1 tests under --enable-preview [v5]
In-Reply-To: <C4Tvch_17GA03I9K2rrXrj_8-i9VaGvDAKiY1QEIvBE=.1ebfc379-bf8d-4cd9-9108-2f44525362f4@github.com>
References: <8nhtiJdjDSaZIW8Oe3QDOVSLIA1g2gbf-ITqzs8xoh0=.5fbe501b-df5d-4bfb-bfdc-84307a096f4e@github.com>
 <S2lE8SM5N8Ak54TFZE9j5m-BQ_nsacpLx7qvq9ztRD0=.b3f39161-bf78-4e69-be75-99e524a8b9ef@github.com>
 <l0I5K5P3fyg6j5SOwyNGb6ZtJJ9v-91uJTT4AyR_ZkI=.10dc115d-b2c0-40f7-9124-0b77281593b3@github.com>
 <C4Tvch_17GA03I9K2rrXrj_8-i9VaGvDAKiY1QEIvBE=.1ebfc379-bf8d-4cd9-9108-2f44525362f4@github.com>
Message-ID: <QJh1vVoFGSG2GPNQRjMXRrjxvPjiYxaRCOYPya84d1k=.cd11410c-efa5-410b-b6b6-44821ac18197@github.com>

On Tue, 16 Dec 2025 09:13:12 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/escapeAnalysis/Test8329757.java line 46:
>> 
>>> 44:     void q() {
>>> 45:         int e;
>>> 46:         synchronized (new Object()) {
>> 
>> What motivated this change?
>
> We cannot synchronize on value classes (primitive boxes are migrated to value classes with preview mode enabled) and we throw an `IdentityException` if we attempt to do so. I've talked with the author of the test and compiler folks and it doesn't change the semantics if we change the mutex.

I think it makes sense to push this and similar changes into jdk/jdk to minimize diff for valhalla.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1793#discussion_r2624032539

From phubner at openjdk.org  Tue Dec 16 16:56:52 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 16:56:52 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview
In-Reply-To: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
Message-ID: <CNm40NFp5GVH8qlBeeVUOQFIOQ3o_thq_balgzCPmEM=.dca59d67-7d73-42df-b35f-76ae3ebf2023@github.com>

On Tue, 16 Dec 2025 16:41:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes the inconsistency observed by @Arraying for this test.

We have some test setups with and without preview that use an alternative structure without `-Dpreview` by making use of `@enablePreview`, as follows:

/*
 * @test id=NoPreview
 * @bug 8161013
 * @summary Verify that anonymous class binaries have the correct flags set
 * @modules java.base/jdk.internal.misc
 * @comment Ensure that that this test is skipped if the test is run on a preview enabled
            VM as the compiled test class has not been forced into preview mode.
            Valhalla affects the outcome.
 * @requires !java.enablePreview
 * @run main AnonymousClassFlags
 */

/*
 * @test id=Preview
 * @bug 8161013
 * @summary Verify that anonymous class binaries have the correct flags set
 * @modules java.base/jdk.internal.misc
 * @enablePreview
 * @compile -XDforcePreview AnonymousClassFlags.java
 * @run main AnonymousClassFlags
 */

Personally I think the above style is a bit cleaner, and we definitely run this PR's test without `--enable-preview` in tier1, so both tests would get executed in tier1. What do you think? I'm not super fussed about it.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1807#issuecomment-3661499257

From liach at openjdk.org  Tue Dec 16 16:56:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 16:56:52 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview
In-Reply-To: <CNm40NFp5GVH8qlBeeVUOQFIOQ3o_thq_balgzCPmEM=.dca59d67-7d73-42df-b35f-76ae3ebf2023@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
 <CNm40NFp5GVH8qlBeeVUOQFIOQ3o_thq_balgzCPmEM=.dca59d67-7d73-42df-b35f-76ae3ebf2023@github.com>
Message-ID: <ja0E3dfO6qf_kFtviBuzZvbPdun4i3RqF8latDQ7IjY=.881fbdce-78f0-45a1-a305-967b42dd3e9a@github.com>

On Tue, 16 Dec 2025 16:54:20 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Fixes the inconsistency observed by @Arraying for this test.
>
> We have some test setups with and without preview that use an alternative structure without `-Dpreview` by making use of `@enablePreview`, as follows:
> 
> /*
>  * @test id=NoPreview
>  * @bug 8161013
>  * @summary Verify that anonymous class binaries have the correct flags set
>  * @modules java.base/jdk.internal.misc
>  * @comment Ensure that that this test is skipped if the test is run on a preview enabled
>             VM as the compiled test class has not been forced into preview mode.
>             Valhalla affects the outcome.
>  * @requires !java.enablePreview
>  * @run main AnonymousClassFlags
>  */
> 
> /*
>  * @test id=Preview
>  * @bug 8161013
>  * @summary Verify that anonymous class binaries have the correct flags set
>  * @modules java.base/jdk.internal.misc
>  * @enablePreview
>  * @compile -XDforcePreview AnonymousClassFlags.java
>  * @run main AnonymousClassFlags
>  */
> 
> Personally I think the above style is a bit cleaner, and we definitely run this PR's test without `--enable-preview` in tier1, so both tests would get executed in tier1. What do you think? I'm not super fussed about it.

@Arraying Yes. javac and javap should not exhibit consistent behavior when their underlying runtime enables preview or not.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1807#issuecomment-3661499823

From liach at openjdk.org  Tue Dec 16 17:06:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 17:06:53 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview [v2]
In-Reply-To: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
Message-ID: <HUjhOMf13yZloQqX5Bx9uzUNme-MwoudLtUZMpoe6nk=.0c45e3c1-9477-4e39-a3ae-f7f61ff6ffcc@github.com>

> Fixes the inconsistency observed by @Arraying for this test.

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

  Informative names

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1807/files
  - new: https://git.openjdk.org/valhalla/pull/1807/files/17029f4b..952db91c

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

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

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

From duke at openjdk.org  Tue Dec 16 17:08:15 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 17:08:15 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
Message-ID: <tiNUC1UAtWfcljPc1DP8YsFibCYM0TOBcmtwmP7d5iU=.e1f3c9f1-9c7c-4163-933b-afa9184a7c2a@github.com>

On Tue, 16 Dec 2025 12:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The following function in `InstanceKlass` is supposed to return size in words:
> 
>   static int size(int vtable_length, int itable_length,
>                   int nonstatic_oop_map_size,
>                   bool is_interface,
>                   bool is_inline_type) {
>     return align_metadata_size(header_size() +
>            vtable_length +
>            itable_length +
>            nonstatic_oop_map_size +
>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>   }
> 
> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
> 
> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
> 
> Before:
> 
> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
> 
> After:
> 
> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
> 
> 
> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
> 
> I've so far only done some local smoke testing with TEST=hotspot_valhalla

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1804#issuecomment-3661544221

From duke at openjdk.org  Tue Dec 16 17:08:31 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 17:08:31 GMT
Subject: [lworld] RFR: 8373806: [lworld] Disable preview patching by
 default [v3]
In-Reply-To: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
References: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
Message-ID: <WoABTVIGF4cCaUMGhIdLbMH0gk84dtWI0Qs7K4l9WZ0=.7eadbca3-bbbf-4530-96c9-56f8d69d5154@github.com>

> Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.
> 
> This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
> A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.

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

 - Merge branch 'plumbing' into flip_default
 - Merge branch 'lworld' into plumbing
 - flip default property value
 - Merge branch 'lworld' into plumbing
 - correct assertion
 - review feedback
 - remove automatic formatting
 - comments
 - Remove note about StableValue (not possible)
 - Use byte array not stream for simplicity
 - ... and 4 more: https://git.openjdk.org/valhalla/compare/7bcb2999...e7924de7

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

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

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

From stefank at openjdk.org  Tue Dec 16 17:08:15 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 17:08:15 GMT
Subject: [lworld] RFR: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
Message-ID: <dctG6ii1zsJkWbI2uibEcQc5anm-mnNZsBI-Q9NzxjE=.e702913a-30fa-46ee-9381-b5b9b99148a1@github.com>

On Tue, 16 Dec 2025 12:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The following function in `InstanceKlass` is supposed to return size in words:
> 
>   static int size(int vtable_length, int itable_length,
>                   int nonstatic_oop_map_size,
>                   bool is_interface,
>                   bool is_inline_type) {
>     return align_metadata_size(header_size() +
>            vtable_length +
>            itable_length +
>            nonstatic_oop_map_size +
>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>   }
> 
> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
> 
> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
> 
> Before:
> 
> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
> 
> After:
> 
> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
> 
> 
> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
> 
> I've so far only done some local smoke testing with TEST=hotspot_valhalla

Thanks for all the reviews! This passes tier1-3 and TEST=hotspot_valhalla and TEST=jdk_valhalla locally. I'm marking this for integration.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1804#issuecomment-3661537255

From phubner at openjdk.org  Tue Dec 16 17:09:19 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 17:09:19 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview [v2]
In-Reply-To: <HUjhOMf13yZloQqX5Bx9uzUNme-MwoudLtUZMpoe6nk=.0c45e3c1-9477-4e39-a3ae-f7f61ff6ffcc@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
 <HUjhOMf13yZloQqX5Bx9uzUNme-MwoudLtUZMpoe6nk=.0c45e3c1-9477-4e39-a3ae-f7f61ff6ffcc@github.com>
Message-ID: <WcpEgaORn-r8_9Qz7jqcT86yi2cOq-60ij6od4-6WlA=.0ecd3450-f6c1-4015-9e2d-ebd796752588@github.com>

On Tue, 16 Dec 2025 17:06:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Fixes the inconsistency observed by @Arraying for this test.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Informative names

We discussed it offline, I think this approach is probably best. Thanks!

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1807#pullrequestreview-3584118988

From stefank at openjdk.org  Tue Dec 16 17:13:14 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 17:13:14 GMT
Subject: [lworld] Integrated: 8373787: [lworld] InstanceKlass::size mixes bytes
 and words
In-Reply-To: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
References: <5i2bw6bKtjD9u55Dl37xDtODfPH66DtH2GLbn4HSSpY=.9c739bcf-e99a-44ad-982b-fdb185fad36d@github.com>
Message-ID: <zg84Il_LG0NzahBThxObLJa3cf_KLEIf_-wj-b3lwWU=.27067271-a708-4456-87bf-6620def297c5@github.com>

On Tue, 16 Dec 2025 12:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The following function in `InstanceKlass` is supposed to return size in words:
> 
>   static int size(int vtable_length, int itable_length,
>                   int nonstatic_oop_map_size,
>                   bool is_interface,
>                   bool is_inline_type) {
>     return align_metadata_size(header_size() +
>            vtable_length +
>            itable_length +
>            nonstatic_oop_map_size +
>            (is_interface ? (int)sizeof(Klass*)/wordSize : 0) +
>            (is_inline_type ? (int)sizeof(InlineKlassFixedBlock) : 0));
>   }
> 
> but `sizeof(InlineKlassFixedBlock)` returns a size in bytes. This adds 640 bytes instead of 80 bytes to all InlineKlasses.
> 
> This can be seen by running `jcmd <pid> VM.classes` to check the size of the InlineKlass of Integer before and after the fix for this:
> 
> Before:
> 
> 0x00000ffc0024d260 167 fully_initialized WS java.lang.Integer
> 
> After:
> 
> 0x000001800024d260 97 fully_initialized WS java.lang.Integer
> 
> 
> That is in words. So this bug added an extra `(167 - 97) * 8 == 560` bytes. 
> 
> I've so far only done some local smoke testing with TEST=hotspot_valhalla

This pull request has now been integrated.

Changeset: e82573ea
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e82573ea7cc59d92aa57f17674e4e52ffd619751
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8373787: [lworld] InstanceKlass::size mixes bytes and words

Reviewed-by: phubner, fparain

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

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

From liach at openjdk.org  Tue Dec 16 17:15:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 17:15:36 GMT
Subject: git: openjdk/valhalla: lworld: 8372740: [lworld]
 tools/javap/4870651/T4870651.java fails with --enable-preview
Message-ID: <774b2bab-322b-4ee7-97cc-9dcc438ade92@openjdk.org>

Changeset: df1aa757
Branch: lworld
Author:    Chen Liang <liach at openjdk.org>
Date:      2025-12-16 17:14:24 +0000
URL:       https://git.openjdk.org/valhalla/commit/df1aa7576920dba5b3fbe70906f819f0e0b32a80

8372740: [lworld] tools/javap/4870651/T4870651.java fails with --enable-preview

Reviewed-by: phubner

! test/langtools/ProblemList-enable-preview.txt
! test/langtools/tools/javap/4870651/T4870651.java
! test/langtools/tools/javap/4870651/Test.java


From liach at openjdk.org  Tue Dec 16 17:17:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 17:17:06 GMT
Subject: [lworld] RFR: 8372740: [lworld] tools/javap/4870651/T4870651.java
 fails with --enable-preview [v2]
In-Reply-To: <HUjhOMf13yZloQqX5Bx9uzUNme-MwoudLtUZMpoe6nk=.0c45e3c1-9477-4e39-a3ae-f7f61ff6ffcc@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
 <HUjhOMf13yZloQqX5Bx9uzUNme-MwoudLtUZMpoe6nk=.0c45e3c1-9477-4e39-a3ae-f7f61ff6ffcc@github.com>
Message-ID: <wP5U2erRI2cLLPUT8loEbplm6sPTRp1gO3ReFfgVQDA=.b00edcc3-6bcd-4f57-aadc-5948229d4c67@github.com>

On Tue, 16 Dec 2025 17:06:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Fixes the inconsistency observed by @Arraying for this test.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Informative names

Thanks for the review! Tested both with preview on and off.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1807#issuecomment-3661572433

From liach at openjdk.org  Tue Dec 16 17:17:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 17:17:08 GMT
Subject: [lworld] Integrated: 8372740: [lworld]
 tools/javap/4870651/T4870651.java fails with --enable-preview
In-Reply-To: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
References: <9j_W3ExVfMoKcvFQV3b3ywdb2bxJsrY-W9FCyxjzUKA=.1465a753-0da3-40d7-b56d-910b71570df0@github.com>
Message-ID: <6I0DC9JZDDDUYCMd4PidVX0d6-btH22RzUnn1rMnS-8=.676732ec-03d6-4888-8953-4499dbd7dad5@github.com>

On Tue, 16 Dec 2025 16:41:50 GMT, Chen Liang <liach at openjdk.org> wrote:

> Fixes the inconsistency observed by @Arraying for this test.

This pull request has now been integrated.

Changeset: df1aa757
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/df1aa7576920dba5b3fbe70906f819f0e0b32a80
Stats:     22 lines in 3 files changed: 13 ins; 2 del; 7 mod

8372740: [lworld] tools/javap/4870651/T4870651.java fails with --enable-preview

Reviewed-by: phubner

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

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

From coleenp at openjdk.org  Tue Dec 16 17:21:16 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 17:21:16 GMT
Subject: [lworld] RFR: 8369043: [lworld] -XX:AOTMode=create crashes with
 UseCompactObjectHeaders on aarch64
In-Reply-To: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>
References: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>
Message-ID: <HxnjoV6YJEis8jRCl5uErKAt8Oza9g6RsLv4rOXp3AU=.44bf75dc-689d-416f-97c3-1706c7252212@github.com>

On Tue, 16 Dec 2025 13:05:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Some index_dependent_slop code found its way into the aarch64 code in the valhalla repo that isn't in mainline, and seems to have no reason to belong to the valhalla code.  Removing it and unproblem listing the tests.  The tests might soon fail for other reasons, but no longer fail for this one.
> Tested with tier8 without this failure.  It's hard to reproduce in isolation.

Thanks Tobias for reviewing.

I should have added that I'll integrate now to clear out these various test errors to different tests.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1805#issuecomment-3661591767
PR Comment: https://git.openjdk.org/valhalla/pull/1805#issuecomment-3661594448

From coleenp at openjdk.org  Tue Dec 16 17:21:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 17:21:17 GMT
Subject: [lworld] Integrated: 8369043: [lworld] -XX:AOTMode=create crashes with
 UseCompactObjectHeaders on aarch64
In-Reply-To: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>
References: <QTzJDB82hh4tvv6Fvxaq4k4AWsojsui9ZB8gBYJj7y8=.48a3e03d-96a6-4ef7-adbe-5fcc7de69b89@github.com>
Message-ID: <8cB4-Of0ZXEMhcktAcqkh8NFvsvX817Hasa9buLzf08=.07cd1857-7bc1-4612-8041-c530b07af79a@github.com>

On Tue, 16 Dec 2025 13:05:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Some index_dependent_slop code found its way into the aarch64 code in the valhalla repo that isn't in mainline, and seems to have no reason to belong to the valhalla code.  Removing it and unproblem listing the tests.  The tests might soon fail for other reasons, but no longer fail for this one.
> Tested with tier8 without this failure.  It's hard to reproduce in isolation.

This pull request has now been integrated.

Changeset: 26b76409
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/26b764096f099704f69b60721e17a7a73bca49a4
Stats:     10 lines in 2 files changed: 0 ins; 8 del; 2 mod

8369043: [lworld] -XX:AOTMode=create crashes with UseCompactObjectHeaders on aarch64

Reviewed-by: thartmann

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

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

From coleenp at openjdk.org  Tue Dec 16 17:38:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 17:38:42 GMT
Subject: [lworld] RFR: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
Message-ID: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>

This change fixes the test to try to load a different class with a CFLH.  With --enable-preview, the java/util/Locale class may be loaded when loading the migrated classes at VM startup, so will be shared in this configuration.  So I picked java/util/Calendar instead.
Tested with the test on windows-x64.

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

Commit messages:
 - 8372686: [lworld] runtime/cds/serviceability/ReplaceCriticalClasses.java fails with --enable-preview
 - 8372686: [lworld] runtime/cds/serviceability/ReplaceCriticalClasses.java fails with --enable-preview

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

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

From phubner at openjdk.org  Tue Dec 16 17:38:43 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 16 Dec 2025 17:38:43 GMT
Subject: [lworld] RFR: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
In-Reply-To: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>
References: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>
Message-ID: <we8AVN4wwFBn5imveib_avYlL9a6-7ZzrD6aa5KZYoU=.691f9fb3-66de-45fe-abf3-7a733ceacd01@github.com>

On Tue, 16 Dec 2025 17:27:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change fixes the test to try to load a different class with a CFLH.  With --enable-preview, the java/util/Locale class may be loaded when loading the migrated classes at VM startup, so will be shared in this configuration.  So I picked java/util/Calendar instead.
> Tested with the test on windows-x64.

Wow, good catch. Do you know who/what causes `Locale` to be loaded?

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1808#pullrequestreview-3584225521

From rriggs at openjdk.org  Tue Dec 16 18:13:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Dec 2025 18:13:52 GMT
Subject: [lworld] RFR: 8373806: [lworld] Disable preview patching by
 default [v3]
In-Reply-To: <WoABTVIGF4cCaUMGhIdLbMH0gk84dtWI0Qs7K4l9WZ0=.7eadbca3-bbbf-4530-96c9-56f8d69d5154@github.com>
References: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
 <WoABTVIGF4cCaUMGhIdLbMH0gk84dtWI0Qs7K4l9WZ0=.7eadbca3-bbbf-4530-96c9-56f8d69d5154@github.com>
Message-ID: <Q66r5lsXyHxBStivklCH8pNcwWFq4V13LY3ESawAPjA=.8b3cd373-06bc-42b4-87c6-e2d789e741e8@github.com>

On Tue, 16 Dec 2025 17:08:31 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.
>> 
>> This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
>> A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'plumbing' into flip_default
>  - Merge branch 'lworld' into plumbing
>  - flip default property value
>  - Merge branch 'lworld' into plumbing
>  - correct assertion
>  - review feedback
>  - remove automatic formatting
>  - comments
>  - Remove note about StableValue (not possible)
>  - Use byte array not stream for simplicity
>  - ... and 4 more: https://git.openjdk.org/valhalla/compare/7bcb2999...e7924de7

It doesn't seem necessary to merge in the "plumb"ing PR. that should have come from lworld when the plumbing was integrated and the dependency updated by skara.
There should only be the 1 commit with the "true" enables.
But at least it only shows the correct three files with the changes.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1806#issuecomment-3661799260

From dcubed at openjdk.org  Tue Dec 16 18:50:47 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 16 Dec 2025 18:50:47 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v6]
In-Reply-To: <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>
Message-ID: <dCWg4AXbgfiEhR9lXZDYezti0JSfqu6mJGB-vrsk-Jk=.9388c4a3-8c22-4ae6-bab8-d6d60b4efdf3@github.com>

On Tue, 16 Dec 2025 16:23:12 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'lworld' into JDK-8371357
>  - Merge branch 'lworld' into JDK-8371357
>  - Reviewer comments.
>  - Use the new function for the Parallel changes.
>  - Merge branch 'lworld' into JDK-8371357
>  - Remove wrong comment.
>  - Fix imports.
>  - Reviewer comments.
>  - Copyright.
>  - Revert "Don't synchronize on Double."
>    
>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>  - ... and 16 more: https://git.openjdk.org/valhalla/compare/ef301b76...6eae2446

Thumbs up.

I re-reviewed the changes from v02 -> v05 and they look good.

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

Marked as reviewed by dcubed (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1759#pullrequestreview-3584513602
PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3661922238

From matsaave at openjdk.org  Tue Dec 16 19:15:10 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 16 Dec 2025 19:15:10 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping [v2]
In-Reply-To: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
Message-ID: <RQL5EUE9FemhzC0uL3QrxwynLJ7irU8W6l4B37OcHvk=.484fce0a-d38d-4417-bc1b-88e854a9cd61@github.com>

> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
> 
> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.

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

 - Merge branch 'lworld' into enable_cds_heap
 - Reverted preview patching flag
 - Fred comment
 - Removed test from group
 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - Properly rewrite fast_vputfield and fast_vgetfield
 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - Enable CDS heap dumping

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

Changes: https://git.openjdk.org/valhalla/pull/1757/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1757&range=01
  Stats: 69 lines in 8 files changed: 37 ins; 28 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1757.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1757/head:pull/1757

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

From coleenp at openjdk.org  Tue Dec 16 19:44:53 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 19:44:53 GMT
Subject: [lworld] RFR: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
In-Reply-To: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>
References: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>
Message-ID: <j8YCOFw05pvbaQOB3RFyOagZErgh5WlLWy5dyNSmTHY=.ced5dd18-f49c-43dc-aea8-b953f4df92bd@github.com>

On Tue, 16 Dec 2025 17:27:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change fixes the test to try to load a different class with a CFLH.  With --enable-preview, the java/util/Locale class may be loaded when loading the migrated classes at VM startup, so will be shared in this configuration.  So I picked java/util/Calendar instead.
> Tested with the test on windows-x64.

This doesn't actually work or else our test system isn't working.  Closing for now.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1808#issuecomment-3662104087

From coleenp at openjdk.org  Tue Dec 16 19:44:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 16 Dec 2025 19:44:54 GMT
Subject: [lworld] Withdrawn: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
In-Reply-To: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>
References: <NTNrvD82f6-Le1arHFt3vlExk40g-Uabsk_dP_u-LIs=.44616bc8-d7eb-4695-b33b-07ffb8eebf8c@github.com>
Message-ID: <06UAxqFA3FCmhhnBGs46ddG4zpWlEwiMadFH5OCiWsw=.675f32dc-ee3a-4454-8852-30e1eecbcd8d@github.com>

On Tue, 16 Dec 2025 17:27:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change fixes the test to try to load a different class with a CFLH.  With --enable-preview, the java/util/Locale class may be loaded when loading the migrated classes at VM startup, so will be shared in this configuration.  So I picked java/util/Calendar instead.
> Tested with the test on windows-x64.

This pull request has been closed without being integrated.

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

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

From stefank at openjdk.org  Tue Dec 16 19:52:45 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 19:52:45 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <-wUvXuHl5qX8sQrpYBMEmtLphNPG0JNGsDUOk1Z4sUc=.8a362686-72b0-40ca-9ee6-bd420559cd9b@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

Tier1 passed. Marking this for integration.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1803#issuecomment-3662127671

From duke at openjdk.org  Tue Dec 16 19:52:45 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 19:52:45 GMT
Subject: [lworld] RFR: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <B-C3joD9b5KVL7fiXW0ufYeLMXIGanhoUcEyXFn7NH8=.8c679ab4-c9f9-474e-943d-9d89abbb3c22@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1803#issuecomment-3662129575

From vromero at openjdk.org  Tue Dec 16 20:11:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 16 Dec 2025 20:11:55 GMT
Subject: [lworld] RFR: 8373261: [lworld] VerifyError: Strict fields not a
 subset of initial strict instance fields
Message-ID: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>

The verifier is failing due to an incorrect

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

Commit messages:
 - 8373261: [lworld] VerifyError: Strict fields not a subset of initial strict instance fields

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

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

From rriggs at openjdk.org  Tue Dec 16 20:24:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Dec 2025 20:24:23 GMT
Subject: [lworld] Integrated: 8373701: [lworld] Revert Use Objects.equals in
 HashMap and ConcurrentHashmap
In-Reply-To: <uuNuLk_g0Zcvttq41nsdz4I6EQmTFteyuXGNBl5B5Fw=.e8ad5cc7-f39f-421a-ac81-f26920a5140d@github.com>
References: <uuNuLk_g0Zcvttq41nsdz4I6EQmTFteyuXGNBl5B5Fw=.e8ad5cc7-f39f-421a-ac81-f26920a5140d@github.com>
Message-ID: <gYiQD57YNMdWrEQGSmmjmByZLheGQWnOTxIg9Zh5PbE=.e1a93a38-80cf-4df9-baaa-a8f72aff2c24@github.com>

On Mon, 15 Dec 2025 19:14:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Revert the use of Objects.equals to the previous explicit `==` check for identity and conditional call to .equals. The use of Objects.equals (without identity) caused classes with poorly written .equals methods to work incorrectly with HashMap and ConcurrentHashMap.
> 
> This reverts commit c8d4a247861052aa6ed43125bcbe49995326938f.

This pull request has now been integrated.

Changeset: 5f0a81e4
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/5f0a81e459e4eaac17a3299f431f2c968d0a5412
Stats:     45 lines in 2 files changed: 7 ins; 1 del; 37 mod

8373701: [lworld] Revert Use Objects.equals in HashMap and ConcurrentHashmap

Reviewed-by: liach

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

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

From duke at openjdk.org  Tue Dec 16 20:28:16 2025
From: duke at openjdk.org (duke)
Date: Tue, 16 Dec 2025 20:28:16 GMT
Subject: [lworld] RFR: 8373806: [lworld] Disable preview patching by
 default [v3]
In-Reply-To: <WoABTVIGF4cCaUMGhIdLbMH0gk84dtWI0Qs7K4l9WZ0=.7eadbca3-bbbf-4530-96c9-56f8d69d5154@github.com>
References: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
 <WoABTVIGF4cCaUMGhIdLbMH0gk84dtWI0Qs7K4l9WZ0=.7eadbca3-bbbf-4530-96c9-56f8d69d5154@github.com>
Message-ID: <EfitufytknLV7lPmsDyP6FWy8L8zx0fECEsfgQUBuEE=.00ba2b2d-30cc-4ec1-bd1a-8ec316905ff6@github.com>

On Tue, 16 Dec 2025 17:08:31 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.
>> 
>> This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
>> A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.
>
> David Beaumont has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'plumbing' into flip_default
>  - Merge branch 'lworld' into plumbing
>  - flip default property value
>  - Merge branch 'lworld' into plumbing
>  - correct assertion
>  - review feedback
>  - remove automatic formatting
>  - comments
>  - Remove note about StableValue (not possible)
>  - Use byte array not stream for simplicity
>  - ... and 4 more: https://git.openjdk.org/valhalla/compare/7bcb2999...e7924de7

@david-beaumont 
Your change (at version e7924de7d0cd6d17f432040e1789f1a6036aecd9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1806#issuecomment-3662252414

From stefank at openjdk.org  Tue Dec 16 20:44:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 Dec 2025 20:44:57 GMT
Subject: [lworld] Integrated: 8373779: [lworld] Type confusion with
 InlineKlassFixedBlock fields
In-Reply-To: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
References: <zfCkAqkf4e-ogs8meqR6PvJExNRLLKbG_XE9RRTx2ns=.d73e354e-2d5d-4654-9bc3-e4ffcbc48c1d@github.com>
Message-ID: <Npz8TaKab4PUH805RU2EdlGCeINdmoLGFJXqPFs3Vng=.7f6f08e8-42b4-4e97-a6a1-2a206346a302@github.com>

On Tue, 16 Dec 2025 10:35:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The InlineKlassFixedBlock class has the following fields:
> 
> class InlineKlassFixedBlock {
>   Array<SigEntry>** _extended_sig;
>   Array<VMRegPair>** _return_regs;
>   address* _pack_handler;
>   address* _pack_handler_jobject;
>   address* _unpack_handler;
>   int* _null_reset_value_offset;
> 
> 
> with associated functions that all look something like this:
> 
>   address adr_extended_sig() const {
>     assert(_adr_inlineklass_fixed_block != nullptr, "Should have been initialized");
>     return ((address)_adr_inlineklass_fixed_block) + in_bytes(byte_offset_of(InlineKlassFixedBlock, _extended_sig));
>   }
> 
> 
> Given the name of the function you would expect that it returned the address of the `_extended_sig` field, and the implementation seems to support this observation. So, the type above should be `Array<SigEntry>***`. However, callers of this function expects the type to be `Array<SigEntry>**` and casts it as such.
> 
> This all seems to work because we erase the type by casting to `address` and then it doesn't matter what types the `InlineKlassFixedBlock` fields have, as long as they are pointer fields.
> 
> I propose that we restructure the code to reduce the casting and fix the type confusion.
> 
> As part of this cleanup I've also:
> 
> 1) Moved the initialization of the InlineKlassFixedBlock to the InlineKlass constructor.
> 
> I think we can pull this even further and move the InlineKlassFixedBlock over to inlineKlass.hpp instead of having it in instanceKlass.hpp. And adding a proper constructor for this class instead of the explicit set of the fields. I've refrained from doing that change in this PR.
> 
> 2) Simplified (IMHO) the address calculation of the location of the fixed block.
> 
> 3) Moved the fixed block access functions together
> 
> Alternative:
> 
> One alternatives that we could consider is to skip adding the setters because they are all used from InlineKlass, which has direct access to the fields of the fixed block. Then the code would simply look like this:
> 
> fixed_block()._field = value;
> 
> 
> I'm leaving this open for reviewers nudge what they think is cleanest. 
> 
> Question:
> 
> Has the name "fixed block" some meaning that conveys a concept of value classes?
> 
> Testing:
> 
> tier1-3 on an earlier version, but I've made some tweaks after that and will rerun testing.

This pull request has now been integrated.

Changeset: d408d01f
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d408d01f0a415f9f779c5b7e01ea2499052ff26e
Stats:     215 lines in 6 files changed: 45 ins; 96 del; 74 mod

8373779: [lworld] Type confusion with InlineKlassFixedBlock fields

Reviewed-by: thartmann, coleenp, fparain

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

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

From duke at openjdk.org  Tue Dec 16 21:13:56 2025
From: duke at openjdk.org (David Beaumont)
Date: Tue, 16 Dec 2025 21:13:56 GMT
Subject: [lworld] Integrated: 8373806: [lworld] Disable preview patching by
 default
In-Reply-To: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
References: <8pmRLsyBEr2uJv6K33LSL5jPNVGagyi9qU9NOYX1kTU=.da468240-5a87-4cbb-92c7-6fc40777e4ba@github.com>
Message-ID: <3YUZvv6Q6qFlVN4CE5XBSOkSfD9UJbTVUsVGnf8bJkA=.01db039e-668f-4914-b12e-625cfaf23bb1@github.com>

On Tue, 16 Dec 2025 15:25:30 GMT, David Beaumont <duke at openjdk.org> wrote:

> Flip the 3 places where the PREVIEW_PATCHING_DEFAULT property default is defined.
> 
> This will enable the JRT file-system preview mode code for *almost* all tests and code by default.
> A few tests still set the property explicitly to false, but everything else should now no longer be using preview patching.

This pull request has now been integrated.

Changeset: 1077e4f9
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1077e4f9f06336af30d95fc28cbab4d31c9f2a44
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8373806: [lworld] Disable preview patching by default

Reviewed-by: rriggs

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

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

From thartmann at openjdk.org  Wed Dec 17 06:45:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 17 Dec 2025 06:45:18 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v2]
In-Reply-To: <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@github.com>
Message-ID: <oips92rUjhpODGCYXFOqSTxsmqUAleLqUYS-vbZgIv4=.4354513f-5ac8-4eb7-951e-462907c51d69@github.com>

On Mon, 15 Dec 2025 09:36:55 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # 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 ha...
>
> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8369045: remove strength reduction flag

You also need to remove the tests from the problem list again (see https://github.com/openjdk/valhalla/pull/1793).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1768#issuecomment-3663889426

From dfenacci at openjdk.org  Wed Dec 17 09:16:14 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 09:16:14 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v3]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <yKM_dJCAY3EReFKBm4LKdyF96tJ8C3EAHU40prYavQo=.55c79ef5-e840-40a8-9172-e330ab4b41c3@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 ca...

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/opto/graphKit.cpp
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1768/files
  - new: https://git.openjdk.org/valhalla/pull/1768/files/ccf58125..60aef931

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 duke at openjdk.org  Wed Dec 17 09:29:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 09:29:29 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always closes
 its delegate leading to ClosedFileSystemException in TestOriginatingElements
Message-ID: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>

Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.

This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.

This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.

This fix could also probable go straight into mainline as a clone since it won't break anything there.

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

Commit messages:
 - Allow callers to decide if delgate file manager should be closed

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

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

From jsikstro at openjdk.org  Wed Dec 17 09:44:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 17 Dec 2025 09:44:47 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays with
 no oops in ZGC
Message-ID: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>

Hello,

ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.

The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.

Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 

Testing:
* hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`

* Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.

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

Commit messages:
 - 8373858: [lworld] Segmented clearing for flatArrays with no oops in ZGC

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

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

From aboldtch at openjdk.org  Wed Dec 17 09:49:21 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 17 Dec 2025 09:49:21 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC
In-Reply-To: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
Message-ID: <qHAo7uAtGdiDEfP2HDZF1k0uo4GfiIF_HgvmqCkx5MU=.53785c62-6db8-43bf-aa7b-a2837b2dddca@github.com>

On Wed, 17 Dec 2025 09:40:00 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
> 
> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
> 
> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
> 
> Testing:
> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
> 
> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.

lgtm. Thanks for fixing.

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

Marked as reviewed by aboldtch (no project role).

PR Review: https://git.openjdk.org/valhalla/pull/1811#pullrequestreview-3586875976

From duke at openjdk.org  Wed Dec 17 09:50:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 09:50:04 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v2]
In-Reply-To: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
Message-ID: <zJ0cZWt_Yxr60rA71bWouC6f1sNmBlQJg4WYwuYYDks=.9169c2da-a8cd-41a4-af67-5ac35e66313b@github.com>

> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
> 
> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
> 
> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
> 
> This fix could also probable go straight into mainline as a clone since it won't break anything there.

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

  tidy and restore eagerly removed not-actually-dead code

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1810/files
  - new: https://git.openjdk.org/valhalla/pull/1810/files/5b780501..d49af5d7

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

  Stats: 39 lines in 3 files changed: 27 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/valhalla/pull/1810.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1810/head:pull/1810

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

From duke at openjdk.org  Wed Dec 17 09:52:45 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 09:52:45 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v3]
In-Reply-To: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
Message-ID: <fSI08xXlhZNn9W1NQSkA650AjW3j_we61t49LHabG9U=.1ce6a242-4113-4883-907b-fe0820314e88@github.com>

> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
> 
> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
> 
> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
> 
> This fix could also probable go straight into mainline as a clone since it won't break anything there.

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

  undo reformatting

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1810/files
  - new: https://git.openjdk.org/valhalla/pull/1810/files/d49af5d7..d41fac6b

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

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

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

From jsikstro at openjdk.org  Wed Dec 17 10:02:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 17 Dec 2025 10:02:52 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v2]
In-Reply-To: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
Message-ID: <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>

> Hello,
> 
> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
> 
> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
> 
> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
> 
> Testing:
> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
> 
> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Offline review feedback

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1811/files
  - new: https://git.openjdk.org/valhalla/pull/1811/files/d25f1542..bf305dcc

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

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

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

From stefank at openjdk.org  Wed Dec 17 10:02:53 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 10:02:53 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v2]
In-Reply-To: <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
Message-ID: <e-v39qxZ31vveemPVmy5X2lV4DQexwXZf0oQqOnAoAc=.267a3fa7-d4c7-4202-90ed-523ba1b44948@github.com>

On Wed, 17 Dec 2025 10:00:06 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline review feedback

Marked as reviewed by stefank (Author).

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

PR Review: https://git.openjdk.org/valhalla/pull/1811#pullrequestreview-3586932044

From duke at openjdk.org  Wed Dec 17 10:16:02 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 10:16:02 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v2]
In-Reply-To: <zJ0cZWt_Yxr60rA71bWouC6f1sNmBlQJg4WYwuYYDks=.9169c2da-a8cd-41a4-af67-5ac35e66313b@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
 <zJ0cZWt_Yxr60rA71bWouC6f1sNmBlQJg4WYwuYYDks=.9169c2da-a8cd-41a4-af67-5ac35e66313b@github.com>
Message-ID: <Dh7lB34SlRkZRIiwtblwntZoiPKWXr7-i0DMR96IUNA=.f6bd9c5e-7131-4084-afac-33045a82fa3e@github.com>

On Wed, 17 Dec 2025 09:50:04 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
>> 
>> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
>> 
>> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
>> 
>> This fix could also probable go straight into mainline as a clone since it won't break anything there.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tidy and restore eagerly removed not-actually-dead code

test/langtools/tools/javac/classfiles/InnerClasses/T8068517.java line 110:

> 108:         try (JavaFileManager fm = ToolProvider.getSystemJavaCompiler().getStandardFileManager(null, null, null)) {
> 109:             ToolBox tb = new ToolBox();
> 110:             try (var memoryFM1 = new ToolBox.MemoryFileManager(fm, false);

I could leave this alone, but it seemed nicer to actually acknowledge that the file managers are closeable.

test/langtools/tools/lib/toolbox/ToolBox.java line 858:

> 856:          * and delegates to a default file manager for input files.
> 857:          */
> 858:         public MemoryFileManager() {

This is the vast majority of users, they don't care about the delegated instance and want it closed.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1810#discussion_r2626408506
PR Review Comment: https://git.openjdk.org/valhalla/pull/1810#discussion_r2626419184

From duke at openjdk.org  Wed Dec 17 10:16:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 10:16:04 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v3]
In-Reply-To: <fSI08xXlhZNn9W1NQSkA650AjW3j_we61t49LHabG9U=.1ce6a242-4113-4883-907b-fe0820314e88@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
 <fSI08xXlhZNn9W1NQSkA650AjW3j_we61t49LHabG9U=.1ce6a242-4113-4883-907b-fe0820314e88@github.com>
Message-ID: <bd22-T3tkb6DaS8qxIrrVJpAk6srxt9KOCTocDMX6iE=.e77eeab0-93e6-4a88-818e-7a19de591f2f@github.com>

On Wed, 17 Dec 2025 09:52:45 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
>> 
>> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
>> 
>> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
>> 
>> This fix could also probable go straight into mainline as a clone since it won't break anything there.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo reformatting

test/langtools/tools/lib/toolbox/ToolBox.java line 868:

> 866:          * @param fileManager the file manager to be used for input files
> 867:          */
> 868:         public MemoryFileManager(JavaFileManager fileManager) {

Only called in 2 places, so migrating callers with an extra parameter is easy.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1810#discussion_r2626415770

From stefank at openjdk.org  Wed Dec 17 10:27:41 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 10:27:41 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock
Message-ID: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>

Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.

To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.

I propose a few changes:

1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.

2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.

3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.

WDYT?

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

Commit messages:
 - 8373864: [lworld] Hide and rename InstanceKlassFixedBlock

Changes: https://git.openjdk.org/valhalla/pull/1812/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1812&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373864
  Stats: 205 lines in 15 files changed: 81 ins; 53 del; 71 mod
  Patch: https://git.openjdk.org/valhalla/pull/1812.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1812/head:pull/1812

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

From phubner at openjdk.org  Wed Dec 17 10:52:57 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 10:52:57 GMT
Subject: [lworld] RFR: 8371357: [lworld] Remove EnableValhalla [v6]
In-Reply-To: <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
 <50ywT05i7URBoSnFRcYhZ6Mz57FbYbeb70r2qVFmv50=.f7c52550-605a-4e6f-8825-53e14ef3ff8f@github.com>
Message-ID: <3MhlurvVg8QTEfKlta6oqAmp_rcP61TLlRQMw2gZXjI=.248a4604-6917-4d06-b9f5-2cb546a65c36@github.com>

On Tue, 16 Dec 2025 16:23:12 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
>> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
>> * Some checks were redundant and could be removed entirely.
>> * I've made the `EnableValhalla` flag obsolete.
>> * Some tests had to be updated.
>> 
>> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
>> 
>> Testing: tiers 1-4.
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Merge branch 'lworld' into JDK-8371357
>  - Merge branch 'lworld' into JDK-8371357
>  - Reviewer comments.
>  - Use the new function for the Parallel changes.
>  - Merge branch 'lworld' into JDK-8371357
>  - Remove wrong comment.
>  - Fix imports.
>  - Reviewer comments.
>  - Copyright.
>  - Revert "Don't synchronize on Double."
>    
>    This reverts commit cbf849c2ce6059af2b43b3dd8cb42445eab4df2b.
>  - ... and 16 more: https://git.openjdk.org/valhalla/compare/ef301b76...6eae2446

Thanks all for the diligent feedback and reviews.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1759#issuecomment-3664779812

From phubner at openjdk.org  Wed Dec 17 10:52:58 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 10:52:58 GMT
Subject: [lworld] Integrated: 8371357: [lworld] Remove EnableValhalla
In-Reply-To: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
References: <hogghMkYAup-qyu5s07D-YGAczZ0nf7Zr5RD5-Xm7aM=.fbbd233f-02af-428d-9c0c-ae8c83cd8171@github.com>
Message-ID: <6syyrjKeSmeJ3Yim5yIZFt7oTr0iTPM56Bj5qACTw9A=.01e57d95-f831-4d2e-a6aa-97674b7eb670@github.com>

On Tue, 25 Nov 2025 13:37:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This removes the `EnableValhalla` in favour of the `--enable-preview` flag. Concretely:
> * I've replaced most of the `EnableValhalla` checks with `Arguments::is_valhalla_enabled()`. 
> * Some checks were redundant and could be removed entirely.
> * I've made the `EnableValhalla` flag obsolete.
> * Some tests had to be updated.
> 
> This greatly changes the semantics of tests. I've refined some test groups to make it easier.
> 
> Testing: tiers 1-4.

This pull request has now been integrated.

Changeset: 59a270d7
Author:    Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/59a270d73a2cc067bdc8c3380eafc615e1284481
Stats:     159 lines in 56 files changed: 59 ins; 13 del; 87 mod

8371357: [lworld] Remove EnableValhalla

Reviewed-by: coleenp, stefank, dcubed

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

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

From duke at openjdk.org  Wed Dec 17 11:05:35 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 11:05:35 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v4]
In-Reply-To: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
Message-ID: <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>

> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
> 
> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
> 
> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
> 
> This fix could also probable go straight into mainline as a clone since it won't break anything there.

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

  add @since for new method

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1810/files
  - new: https://git.openjdk.org/valhalla/pull/1810/files/d41fac6b..1b29ac47

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

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

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

From phubner at openjdk.org  Wed Dec 17 11:07:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 11:07:08 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v2]
In-Reply-To: <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
Message-ID: <mjDIlRcxKMIMbFQLtglweMLktaJtXLVYwTQJ2o109go=.406cd135-3734-4c75-8106-79e19f303876@github.com>

On Wed, 17 Dec 2025 10:02:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline review feedback

src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 64:

> 62:   }
> 63: 
> 64:   if (is_oop_containing_flat_array(_klass)) {

> A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.

Is this something we can guard against in the code as well? What happens if somebody creates a null-restricted non-atomic primitive-only flat array via the `ValueClass` API? Tearing from the user's POV is absolutely okay in such a case, but will any ZGC assumptions be violated?

src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 87:

> 85:     oopDesc::release_set_mark(mem, _klass->prototype_header().set_marked());
> 86:   } else {
> 87:     if (EnableValhalla) {

FYI this will cause a merge conflict.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1811#discussion_r2626615251
PR Review Comment: https://git.openjdk.org/valhalla/pull/1811#discussion_r2626602012

From phubner at openjdk.org  Wed Dec 17 11:25:02 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 11:25:02 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock
In-Reply-To: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
Message-ID: <NdkKTwa70OfPH6zAtw7y_4cOrq93zdGN9W78F17H6Hk=.d955bfe1-05d7-47c1-8cef-30d0987552a0@github.com>

On Wed, 17 Dec 2025 10:21:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
> 
> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
> 
> I propose a few changes:
> 
> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
> 
> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
> 
> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
> 
> WDYT?

Looks good overall, just minor comments.

src/hotspot/share/ci/ciMethod.hpp line 44:

> 42: class BCEscapeAnalyzer;
> 43: class InlineTree;
> 44: class SigEntry;

Why do we need this declaration? AFAICT `ciMethod`'s method should be unaffected by this change?

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

> 88: 
> 89:   Members& members() {
> 90:     assert(_adr_inline_klass_members != 0, "Should have been initialized");

Nitpick: `nullptr` for clarity as that's what we initialize it as?

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1812#pullrequestreview-3587240158
PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2626646022
PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2626660311

From sjohanss at openjdk.org  Wed Dec 17 11:25:38 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 17 Dec 2025 11:25:38 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <Um2d9SGjpXEY2FuJi0EG28zZ3whtt9kH8uaCjjeWq_I=.647aff89-0c68-4393-9cd9-bfb8860cb3ba@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
 <Um2d9SGjpXEY2FuJi0EG28zZ3whtt9kH8uaCjjeWq_I=.647aff89-0c68-4393-9cd9-bfb8860cb3ba@github.com>
Message-ID: <0UK5n4C2Ev8VbJkChhikWiEIRCHKaiPwnFNBGn17bWE=.14d2146a-c0b0-4e4f-becd-62e376c6010a@github.com>

On Mon, 15 Dec 2025 08:38:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
>> 
>> **Summary**
>> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
>> 
>> **Testing**
>> * mach5 tier1-3 (ongoing)
>
> Looks good.

Thanks for the review @stefank

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

PR Comment: https://git.openjdk.org/valhalla/pull/1794#issuecomment-3664901498

From phubner at openjdk.org  Wed Dec 17 11:39:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 11:39:31 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
Message-ID: <UpiATjn0Tib7kPzjGrh3S-_4z_fMQ1q-s3tE2jFq36E=.80ff26e1-4dca-4721-b416-7eb151b52a72@github.com>

On Fri, 12 Dec 2025 15:28:27 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
> 
> **Summary**
> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
> 
> **Testing**
> * mach5 tier1-3 (ongoing)

LGTM, thanks.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1794#pullrequestreview-3587312976

From sjohanss at openjdk.org  Wed Dec 17 11:39:31 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 17 Dec 2025 11:39:31 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <UpiATjn0Tib7kPzjGrh3S-_4z_fMQ1q-s3tE2jFq36E=.80ff26e1-4dca-4721-b416-7eb151b52a72@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
 <UpiATjn0Tib7kPzjGrh3S-_4z_fMQ1q-s3tE2jFq36E=.80ff26e1-4dca-4721-b416-7eb151b52a72@github.com>
Message-ID: <LuIFuWOdeezhS-Jty6Gm1DrHqqFEIo83o73Q9qNbIzw=.33967384-c305-471e-83f0-86072e190c41@github.com>

On Wed, 17 Dec 2025 11:33:57 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
>> 
>> **Summary**
>> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
>> 
>> **Testing**
>> * mach5 tier1-3 (ongoing)
>
> LGTM, thanks.

Thanks @Arraying

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

PR Comment: https://git.openjdk.org/valhalla/pull/1794#issuecomment-3664943710

From duke at openjdk.org  Wed Dec 17 11:39:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 17 Dec 2025 11:39:32 GMT
Subject: [lworld] RFR: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
Message-ID: <FJRfvKh7uAWv9ph19TkNIskqvURNaVwzNyy_6EVpXeY=.baf19fbd-71cf-44dc-8791-717b241579dd@github.com>

On Fri, 12 Dec 2025 15:28:27 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
> 
> **Summary**
> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
> 
> **Testing**
> * mach5 tier1-3 (ongoing)

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1794#issuecomment-3664948193

From sjohanss at openjdk.org  Wed Dec 17 11:44:45 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 17 Dec 2025 11:44:45 GMT
Subject: [lworld] Integrated: 8373608: [lworld] Remove ObjBufferAllocator
In-Reply-To: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
References: <budZbzDVwoj7ClGTUrPcQ_KPnkhVksusZ-LaiRdgzBk=.d314849e-edaa-4058-9c89-1c16aa1dd1d4@github.com>
Message-ID: <-LHhDFFzMb4PFrFU7tYsUus-QVfVI1br2Y_iLT9Xe-g=.85cdb85f-cc6f-4873-bd14-bac9672bc93b@github.com>

On Fri, 12 Dec 2025 15:28:27 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove `ObjBufferAllocator` since the impementation now is identical to `ObjAllocator`. 
> 
> **Summary**
> This was not the case when ObjBufferAllocator was first introduced. Back then it skipped clearing the memory and just called oopDesc::set_klass_gap(mem, 0). This is no longer the case after [JDK-8350630](https://bugs.openjdk.org/browse/JDK-8350630) in which `ObjBufferAllocator` was changed to also clear the memory. The previous optimization is likely not needed and we should streamline the code to always use `ObjAllocator`.
> 
> **Testing**
> * mach5 tier1-3 (ongoing)

This pull request has now been integrated.

Changeset: 619ef43b
Author:    Stefan Johansson <sjohanss at openjdk.org>
Committer: Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/619ef43b00b1e13452a2dd8f4d8320f45e27f8e0
Stats:     34 lines in 7 files changed: 0 ins; 32 del; 2 mod

8373608: [lworld] Remove ObjBufferAllocator

Reviewed-by: stefank, phubner

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

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

From stefank at openjdk.org  Wed Dec 17 12:55:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 12:55:00 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock
In-Reply-To: <NdkKTwa70OfPH6zAtw7y_4cOrq93zdGN9W78F17H6Hk=.d955bfe1-05d7-47c1-8cef-30d0987552a0@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <NdkKTwa70OfPH6zAtw7y_4cOrq93zdGN9W78F17H6Hk=.d955bfe1-05d7-47c1-8cef-30d0987552a0@github.com>
Message-ID: <ufsEsTFbK5oBJtatbC-Q2H2j_xbWFQKFYkuWfWd93J4=.6e1d480d-bb28-4afa-a1e1-48833e963aaf@github.com>

On Wed, 17 Dec 2025 11:18:51 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
>> 
>> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
>> 
>> I propose a few changes:
>> 
>> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
>> 
>> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
>> 
>> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
>> 
>> WDYT?
>
> src/hotspot/share/oops/inlineKlass.hpp line 90:
> 
>> 88: 
>> 89:   Members& members() {
>> 90:     assert(_adr_inline_klass_members != 0, "Should have been initialized");
> 
> Nitpick: `nullptr` for clarity as that's what we initialize it as?

Of course! Thanks. This is left-overs from an earlier prototype, where I only saved the offset to the Members. That removes the need for CDS to patch this address, but it adds extra instructions to the compiler, so I skipped that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2626951939

From stefank at openjdk.org  Wed Dec 17 13:01:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 13:01:03 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock
In-Reply-To: <NdkKTwa70OfPH6zAtw7y_4cOrq93zdGN9W78F17H6Hk=.d955bfe1-05d7-47c1-8cef-30d0987552a0@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <NdkKTwa70OfPH6zAtw7y_4cOrq93zdGN9W78F17H6Hk=.d955bfe1-05d7-47c1-8cef-30d0987552a0@github.com>
Message-ID: <6-RPPYtonax2pYqAgCL5nu3RQGyjKU7RMVpRceT7ZUc=.30b18d5d-8d93-40e3-b87e-4a08a2a8ca37@github.com>

On Wed, 17 Dec 2025 11:13:48 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
>> 
>> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
>> 
>> I propose a few changes:
>> 
>> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
>> 
>> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
>> 
>> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
>> 
>> WDYT?
>
> src/hotspot/share/ci/ciMethod.hpp line 44:
> 
>> 42: class BCEscapeAnalyzer;
>> 43: class InlineTree;
>> 44: class SigEntry;
> 
> Why do we need this declaration? AFAICT `ciMethod`'s method should be unaffected by this change?

This file uses it here:

  const GrowableArray<SigEntry>* get_sig_cc() const;


and I removed the forward declaration from instanceKlass.hpp, which caused this file to lose its last forward declaration of this class, leading to compilation errors.

This is a pre-existing "issue" that we can upstream together with various other nit fixes if we want to.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2626973828

From stefank at openjdk.org  Wed Dec 17 13:07:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 13:07:44 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v2]
In-Reply-To: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
Message-ID: <cwqUF-hB1bnUPzqfklyI2Nvm15MbnZ5_iMbeWri7SJk=.7957f9b3-8be2-426e-994f-4e96663e9887@github.com>

> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
> 
> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
> 
> I propose a few changes:
> 
> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
> 
> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
> 
> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
> 
> WDYT?

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

 - Fix null check
 - Merge remote-tracking branch 'valhalla/lworld' into lworld_8373864_inline_klass_members
 - 8373864: [lworld] Hide and rename InstanceKlassFixedBlock

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1812/files
  - new: https://git.openjdk.org/valhalla/pull/1812/files/817757d4..8cc3c015

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

  Stats: 160 lines in 57 files changed: 59 ins; 13 del; 88 mod
  Patch: https://git.openjdk.org/valhalla/pull/1812.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1812/head:pull/1812

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

From fparain at openjdk.org  Wed Dec 17 13:32:29 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 17 Dec 2025 13:32:29 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v2]
In-Reply-To: <cwqUF-hB1bnUPzqfklyI2Nvm15MbnZ5_iMbeWri7SJk=.7957f9b3-8be2-426e-994f-4e96663e9887@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <cwqUF-hB1bnUPzqfklyI2Nvm15MbnZ5_iMbeWri7SJk=.7957f9b3-8be2-426e-994f-4e96663e9887@github.com>
Message-ID: <LaCiwm6c8tz8CNWDiNsJpCAkl6FH_5avqPaKEVwbi2Q=.56965ee9-ebdc-443f-adba-1b3f9db222cc@github.com>

On Wed, 17 Dec 2025 13:07:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
>> 
>> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
>> 
>> I propose a few changes:
>> 
>> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
>> 
>> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
>> 
>> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
>> 
>> WDYT?
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Fix null check
>  - Merge remote-tracking branch 'valhalla/lworld' into lworld_8373864_inline_klass_members
>  - 8373864: [lworld] Hide and rename InstanceKlassFixedBlock

Marked as reviewed by fparain (Committer).

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

> 51:   // features (see InstanceKlass::size). Therefore, we can't put C++ fields
> 52:   // directly into the InlineKlass class, but instead we stamp out a block of
> 53:   // these members after the part of the object that comes from the InstanceKlass.

Suggestion: clarify in the comment that the goal was to have the same offset for the vtable in both InstanceKlass and InlineKlass, so the vtable could be accessed without having to differentiate between the two kinds of Klass.

Otherwise, nice rework!

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

PR Review: https://git.openjdk.org/valhalla/pull/1812#pullrequestreview-3587762946
PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2627080706

From dfenacci at openjdk.org  Wed Dec 17 13:38:21 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 13:38:21 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v4]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <HOydNqGvYXTvmi4ggzoezZYIIibVyhOOORJZN-4GuUU=.df104236-e593-4864-b69e-4c4bc12672d6@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 ca...

Damon Fenacci has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'JDK-8369045' of https://github.com/dafedafe/valhalla into JDK-8369045
 - JDK-8369045: don't re-add condition if stress-reducing
 - Revert "JDK-8369045: remove strength reduction flag"
   
   This reverts commit ccf58125b13655bb6c15af747345efbd6791f93d.

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1768/files
  - new: https://git.openjdk.org/valhalla/pull/1768/files/60aef931..e1fe634f

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

  Stats: 32 lines in 3 files changed: 6 ins; 1 del; 25 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 dfenacci at openjdk.org  Wed Dec 17 13:45:10 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 13:45:10 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v4]
In-Reply-To: <mLnduR9HuYndRggjcu307B1hYTYMkrLueuJFFLe0s_4=.b503065b-3b7a-4314-b2c7-355f5f528490@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <MBJo4oPmQ2YFyMFTf1AL5dN5ug_HJDsgMP4ofFKGp44=.ab760ae3-2762-4840-8f73-08045df746c5@github.com>
 <G-1DT1_1mdrTLQr9O71dlC8Sirvl41Cv8LuCqJnzGJ8=.0e733e62-d02c-4b20-8314-2fe28cf9fc24@github.com>
 <mLnduR9HuYndRggjcu307B1hYTYMkrLueuJFFLe0s_4=.b503065b-3b7a-4314-b2c7-355f5f528490@github.com>
Message-ID: <kX0RKJha5kHjNtiu-jMMIdo9qJdczizjyIoFONEyiTY=.d4a34b1b-8d34-4c6c-985a-3eb02cba7fa8@github.com>

On Mon, 15 Dec 2025 09:42:15 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> That's a possibility. I've also considered checking for `!C->inlining_incrementally() && C->late_inline_count() > 0` but I'm a bit torn between being 100% sure we are doing strength reduction but using a compile "flags" (a bit ?) and checking for other, already available, conditions (like the one you suggest), which make me a bit unsure and could potentially change in the future...
>> But I guess introducing a new field to `Compile` just for this should be avoided. So, let's go for `_gvn.is_IterGVN() && !C->inlining_incrementally()` ?
>
> Fixed.

I spoke too soon: `_gvn` is actually set when the `GraphKit` is created (when generating the call) and is not using the context of the call being strength-reduced. So, unfortunately it seems that the least-invasive way to figure out if we are strength-reducing is to have a compile flag. I reverted the change.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2627124461

From jlahoda at openjdk.org  Wed Dec 17 13:43:05 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Dec 2025 13:43:05 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v4]
In-Reply-To: <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
 <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>
Message-ID: <4zaPfEhjtwmO20ghkGpOcVZ-xwPDPDXZ8VmDGwBL8ec=.eee64a51-f637-4be3-9a75-dd0f40adffcf@github.com>

On Wed, 17 Dec 2025 11:05:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
>> 
>> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
>> 
>> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
>> 
>> This fix could also probable go straight into mainline as a clone since it won't break anything there.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @since for new method

I think the standard way to change behavior for `Forwarning...` classes is to simply override the method in the subclass, and implement whatever logic needed - delegating or not. In this case, subclasses can override the `close` method to do nothing. While I agree the `close` is a little bit special, I am not convinced it is special enough to warrant a field and a new constructor.

For `MemoryFileManager`, a new constructor parameter is fine I think - that's a specialized class and not an API.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1810#issuecomment-3665408186

From mcimadamore at openjdk.org  Wed Dec 17 13:59:26 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 Dec 2025 13:59:26 GMT
Subject: [lworld] RFR: 8373261: [lworld] VerifyError: Strict fields not a
 subset of initial strict instance fields
In-Reply-To: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
References: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
Message-ID: <lwJXkyHCVvb6U0XxhlwJ6FwwCUkSr6f6uQ42XGnnLT4=.ded65af4-f657-418d-8812-a9f8e2716088@github.com>

On Tue, 16 Dec 2025 20:06:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The verifier is failing due to an incorrect EarlyLarvalFrame generated by javac. The issue can be reproduced by compiling this test case:
> 
> 
> public class Test {
>     static value class Val1 {
>         int i1;
>         int i2;
>         int i3;
>         int i4;
> 
>         public Val1() {
>             this.i1 = 0;
>             this.i2 = 0;
>             this.i3 = 0;
>             this.i4 = 0;
>         }
>     }
> 
>     static value class Val2 {
>         int i1;
>         Val1 val1;
> 
>         public Val2(boolean b) {
>             this.i1 = 0;
>             this.val1 = b ? null : new Val1(); // this statement will trigger the generation of an EarlyLarvalFrame
>         }
>     }
> 
>     public static void main(String[] args) {
>         Val2 val = new Val2(true);
>     }
> }
> 
> so from the example above, for `Val2`'s constructor, javac is generating an `EarlyLarvalFrame` that included `Val1`'s `i4` field as an uninitialized strict field. The reason is that method `findUninitStrictFields` in `Flow` was not stopping at the max valid local variable for the current method. There are some data structures that are reused during flow analysis without being cleared from method to method to save time. So basically this method was reading "logically erased" info left during the analysis of the previous constructor.
> 
> TIA for the review

Marked as reviewed by mcimadamore (Committer).

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2122:

> 2120:             for (int i = firstadr; i < nextadr; i++) {
> 2121:                 JCVariableDecl variableDecl = vardecls[i];
> 2122:                 if (uninits.isMember(variableDecl.sym.adr) && variableDecl.sym.isStrict()) {

This could also be replaced with `uninints.isMember(i)` right?

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

PR Review: https://git.openjdk.org/valhalla/pull/1809#pullrequestreview-3587882053
PR Review Comment: https://git.openjdk.org/valhalla/pull/1809#discussion_r2627175201

From jlahoda at openjdk.org  Wed Dec 17 14:04:14 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Dec 2025 14:04:14 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails since
 jimage change
Message-ID: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>

Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.

Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)

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

Commit messages:
 - Fixing test when running with -DDISABLE_PREVIEW_PATCHING=true (and forcing a run with this option).

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

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

From dfenacci at openjdk.org  Wed Dec 17 14:05:37 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 14:05:37 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v5]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <zSycgyu1-PBnC5qpyP7AjNunuhY9HxKgd2QkuC-JAMM=.aaab1555-dafa-4978-b347-bcc5fcf40284@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 ca...

Damon Fenacci 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 13 additional commits since the last revision:

 - JDK-8369045 remove tests from problemlist
 - Merge branch 'lworld' into JDK-8369045
 - Merge branch 'JDK-8369045' of https://github.com/dafedafe/valhalla into JDK-8369045
 - Update src/hotspot/share/opto/graphKit.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - JDK-8369045: don't re-add condition if stress-reducing
 - Revert "JDK-8369045: remove strength reduction flag"
   
   This reverts commit ccf58125b13655bb6c15af747345efbd6791f93d.
 - JDK-8369045: remove strength reduction flag
 - JDK-8369045: remove new line
 - Revert "JDK-8369045: add bool for rt_loaded"
   
   This reverts commit 696695f03afdeb5f2538eb2279658b31661536d0.
 - JDK-8369045: add comment
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/dac77499...32fae207

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1768/files
  - new: https://git.openjdk.org/valhalla/pull/1768/files/e1fe634f..32fae207

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

  Stats: 270328 lines in 2598 files changed: 179899 ins; 50912 del; 39517 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 stefank at openjdk.org  Wed Dec 17 14:09:12 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 14:09:12 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v3]
In-Reply-To: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
Message-ID: <6Dc2QkfM2I-pE7vWiKT8sAucEXn47FJIpNfGMli3DVk=.abbc1c5b-84bb-4863-875e-d39e12113895@github.com>

> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
> 
> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
> 
> I propose a few changes:
> 
> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
> 
> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
> 
> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
> 
> WDYT?

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Further clarification of Members

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1812/files
  - new: https://git.openjdk.org/valhalla/pull/1812/files/8cc3c015..5d4ee20f

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

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

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

From stefank at openjdk.org  Wed Dec 17 14:09:16 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 14:09:16 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v2]
In-Reply-To: <LaCiwm6c8tz8CNWDiNsJpCAkl6FH_5avqPaKEVwbi2Q=.56965ee9-ebdc-443f-adba-1b3f9db222cc@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <cwqUF-hB1bnUPzqfklyI2Nvm15MbnZ5_iMbeWri7SJk=.7957f9b3-8be2-426e-994f-4e96663e9887@github.com>
 <LaCiwm6c8tz8CNWDiNsJpCAkl6FH_5avqPaKEVwbi2Q=.56965ee9-ebdc-443f-adba-1b3f9db222cc@github.com>
Message-ID: <Ysbz_gBCJiGpvI1DuCAj86oBpo2dChnYIyMw-SpwNZY=.6bf5ea6c-4215-4672-bd20-c2013b44391b@github.com>

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

>> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Fix null check
>>  - Merge remote-tracking branch 'valhalla/lworld' into lworld_8373864_inline_klass_members
>>  - 8373864: [lworld] Hide and rename InstanceKlassFixedBlock
>
> src/hotspot/share/oops/inlineKlass.hpp line 53:
> 
>> 51:   // features (see InstanceKlass::size). Therefore, we can't put C++ fields
>> 52:   // directly into the InlineKlass class, but instead we stamp out a block of
>> 53:   // these members after the part of the object that comes from the InstanceKlass.
> 
> Suggestion: clarify in the comment that the goal was to have the same offset for the vtable in both InstanceKlass and InlineKlass, so the vtable could be accessed without having to differentiate between the two kinds of Klass.
> 
> Otherwise, nice rework!

Thanks! I've updated the comment to go into more details. Please, take a look and see if this is better.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2627201378

From vromero at openjdk.org  Wed Dec 17 14:16:26 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Dec 2025 14:16:26 GMT
Subject: Integrated: Merge lworld
Message-ID: <I-Rqa8WHdbuCs6iJOZaRfW48oeIH_nkzPJrkWLOJ0Jw=.df7a80fe-f176-47c2-b03c-854ee217b170@github.com>

Merge branch 'lworld' into lw5_merge_lworld
# Conflicts:
#	src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java

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

Commit messages:
 - Merge branch 'lworld' into lw5_merge_lworld
 - 8373670: [lworld] Relax jcheck checks
 - Merge
 - Merge
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - 8347754: [lw5] fix the order of nullness markers in signatures
 - Merge lworld
 - Merge lworld
 - ... and 62 more: https://git.openjdk.org/valhalla/compare/619ef43b...cb9ca633

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/valhalla/pull/1814/files
  Stats: 6804 lines in 102 files changed: 6680 ins; 2 del; 122 mod
  Patch: https://git.openjdk.org/valhalla/pull/1814.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1814/head:pull/1814

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

From vromero at openjdk.org  Wed Dec 17 14:16:29 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Dec 2025 14:16:29 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <I-Rqa8WHdbuCs6iJOZaRfW48oeIH_nkzPJrkWLOJ0Jw=.df7a80fe-f176-47c2-b03c-854ee217b170@github.com>
References: <I-Rqa8WHdbuCs6iJOZaRfW48oeIH_nkzPJrkWLOJ0Jw=.df7a80fe-f176-47c2-b03c-854ee217b170@github.com>
Message-ID: <oGxCMVymHNy0FqbQ2VV9Y5uONW8FWYXBuoVT4siUWuE=.6b4b7b46-6204-4a3e-ace2-734f93bc6dab@github.com>

On Wed, 17 Dec 2025 14:07:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Merge branch 'lworld' into lw5_merge_lworld
> # Conflicts:
> #	src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java

This pull request has now been integrated.

Changeset: 19ceeca7
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/19ceeca7efc64d42f4186da394eebcea78304986
Stats:     74166 lines in 1391 files changed: 48290 ins; 17802 del; 8074 mod

Merge lworld

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

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

From duke at openjdk.org  Wed Dec 17 14:19:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 14:19:41 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v4]
In-Reply-To: <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
 <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>
Message-ID: <_2UG_QDYWAAgNSe-ALiQ45CvrBk9klxa9eR9Zv9PTxk=.cfc8448b-01d1-4108-bf1a-226ed0e5d53b@github.com>

On Wed, 17 Dec 2025 11:05:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
>> 
>> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
>> 
>> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
>> 
>> This fix could also probable go straight into mainline as a clone since it won't break anything there.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @since for new method

Fair enough, that was my other thought, but since it's analogous to various I/O file/stream forwarding APIs which *do* explicitly call out whether the delegate should be closed, I thought I'd push on that route first.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1810#issuecomment-3665564966

From phubner at openjdk.org  Wed Dec 17 14:24:23 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 14:24:23 GMT
Subject: [lworld] RFR: 8373880
Message-ID: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>

Trivial PR to problem list noisy failing tests.

As far as I have observed (so far): the tools tests fail with and without --enable-preview. The rest only with --enable-preview.

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

Commit messages:
 - Add the actual tests.
 - Update duplicate JBS entry.

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

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

From rriggs at openjdk.org  Wed Dec 17 14:29:37 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Dec 2025 14:29:37 GMT
Subject: [lworld] RFR: 8373880: [lworld] Problemlist several tests that are
 failing after JDK-8371357
In-Reply-To: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>
References: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>
Message-ID: <cZJXhVWHrdinkkhBBS5MCi_3dmzTJywz9Ybn_A5CPtw=.95b831ea-868d-49fb-a3c6-05cd766610f0@github.com>

On Wed, 17 Dec 2025 14:16:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Trivial PR to problem list noisy failing tests.
> 
> As far as I have observed (so far): the tools tests fail with and without --enable-preview. The rest only with --enable-preview.

Quiet please.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1815#pullrequestreview-3588008542

From phubner at openjdk.org  Wed Dec 17 14:33:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 14:33:50 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v3]
In-Reply-To: <6Dc2QkfM2I-pE7vWiKT8sAucEXn47FJIpNfGMli3DVk=.abbc1c5b-84bb-4863-875e-d39e12113895@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <6Dc2QkfM2I-pE7vWiKT8sAucEXn47FJIpNfGMli3DVk=.abbc1c5b-84bb-4863-875e-d39e12113895@github.com>
Message-ID: <AnyvdQuEsSy-73vgZ6tNcvp0soAdhctsVQWU7Xd5s1s=.b6c00e85-0284-4663-900c-99fd944c2401@github.com>

On Wed, 17 Dec 2025 14:09:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
>> 
>> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
>> 
>> I propose a few changes:
>> 
>> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
>> 
>> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
>> 
>> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
>> 
>> WDYT?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further clarification of Members

Love the ASCII-diagram. Thanks for doing this.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1812#pullrequestreview-3588018176

From fparain at openjdk.org  Wed Dec 17 14:33:52 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 17 Dec 2025 14:33:52 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v2]
In-Reply-To: <Ysbz_gBCJiGpvI1DuCAj86oBpo2dChnYIyMw-SpwNZY=.6bf5ea6c-4215-4672-bd20-c2013b44391b@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <cwqUF-hB1bnUPzqfklyI2Nvm15MbnZ5_iMbeWri7SJk=.7957f9b3-8be2-426e-994f-4e96663e9887@github.com>
 <LaCiwm6c8tz8CNWDiNsJpCAkl6FH_5avqPaKEVwbi2Q=.56965ee9-ebdc-443f-adba-1b3f9db222cc@github.com>
 <Ysbz_gBCJiGpvI1DuCAj86oBpo2dChnYIyMw-SpwNZY=.6bf5ea6c-4215-4672-bd20-c2013b44391b@github.com>
Message-ID: <-Sw_SsJD3uCUryhVsf32USn9mwxbxX8HKmaDOPAqQyM=.63559d1e-809e-4266-bc48-ed4794b922ab@github.com>

On Wed, 17 Dec 2025 14:04:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/oops/inlineKlass.hpp line 53:
>> 
>>> 51:   // features (see InstanceKlass::size). Therefore, we can't put C++ fields
>>> 52:   // directly into the InlineKlass class, but instead we stamp out a block of
>>> 53:   // these members after the part of the object that comes from the InstanceKlass.
>> 
>> Suggestion: clarify in the comment that the goal was to have the same offset for the vtable in both InstanceKlass and InlineKlass, so the vtable could be accessed without having to differentiate between the two kinds of Klass.
>> 
>> Otherwise, nice rework!
>
> Thanks! I've updated the comment to go into more details. Please, take a look and see if this is better.

Thank you for the comment update. The rational behind the InlineKlass::Member is made very clear.
Ship it!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1812#discussion_r2627300207

From phubner at openjdk.org  Wed Dec 17 14:36:49 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 14:36:49 GMT
Subject: [lworld] RFR: 8373880: [lworld] Problemlist several tests that are
 failing after JDK-8371357
In-Reply-To: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>
References: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>
Message-ID: <1Yc8yeRbNfKwiNaNRqe2cmtL9i6b_E4Ju5pTrrys2Qs=.ba545e3c-b7a9-4ec1-b6bf-db0c795fa11d@github.com>

On Wed, 17 Dec 2025 14:16:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Trivial PR to problem list noisy failing tests.
> 
> As far as I have observed (so far): the tools tests fail with and without --enable-preview. The rest only with --enable-preview.

Thanks!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1815#issuecomment-3665626172

From phubner at openjdk.org  Wed Dec 17 14:36:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 14:36:50 GMT
Subject: [lworld] Integrated: 8373880: [lworld] Problemlist several tests that
 are failing after JDK-8371357
In-Reply-To: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>
References: <uc1tVjqHxjgmrcfoirOvpgZ7fQRQn8-lGUf_8m9k_s4=.d33769fb-fa7b-487f-9edb-45399e781647@github.com>
Message-ID: <2iHEGGqoGyzd2D3LVtI6Y9n7qk5dW53yDfJAPytcJtY=.82058eda-3ef6-48d9-b5e5-1dcce30d2f23@github.com>

On Wed, 17 Dec 2025 14:16:41 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Trivial PR to problem list noisy failing tests.
> 
> As far as I have observed (so far): the tools tests fail with and without --enable-preview. The rest only with --enable-preview.

This pull request has now been integrated.

Changeset: 718779d9
Author:    Paul H?bner <phubner at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/718779d9bd61277f691529f0ea3a8173379c162b
Stats:     10 lines in 4 files changed: 9 ins; 0 del; 1 mod

8373880: [lworld] Problemlist several tests that are failing after JDK-8371357

Reviewed-by: rriggs

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

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

From rriggs at openjdk.org  Wed Dec 17 14:39:07 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Dec 2025 14:39:07 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change
In-Reply-To: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
Message-ID: <TAxb1tCMOIivb5yRmNw7i3j32hfiQxrYbLqRS_it1dg=.7065fa24-0120-4610-89f0-c79ad8b067b0@github.com>

On Wed, 17 Dec 2025 13:33:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
> 
> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)

looks good.

Please undo the problem listing in [ttps://git.openjdk.org/valhalla/pull/1815](https://git.openjdk.org/valhalla/pull/1815)

fyi, we've switched the default to use JImage full time. The conditional will become dead code and be removed.

fyi, I see a Problem listing of both tests has been done in [ttps://git.openjdk.org/valhalla/pull/1815](https://git.openjdk.org/valhalla/pull/1815).
Please merge and remove the problem listing.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1813#pullrequestreview-3588049506
Changes requested by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1813#pullrequestreview-3588056253
PR Comment: https://git.openjdk.org/valhalla/pull/1813#issuecomment-3665637956
PR Comment: https://git.openjdk.org/valhalla/pull/1813#issuecomment-3665645745

From phubner at openjdk.org  Wed Dec 17 14:39:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 14:39:08 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change
In-Reply-To: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
Message-ID: <Y3tQWDqA3x3ul6LQPSbkU0NjpUk7UKHIb90wCoS7Df0=.3d2e2f6a-4fca-411d-bccc-1b4e77780b33@github.com>

On Wed, 17 Dec 2025 13:33:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
> 
> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)

FYI, these tests were problemlisted, among many others, in #1815 to address noise issues.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1813#issuecomment-3665638510

From stefank at openjdk.org  Wed Dec 17 14:48:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 14:48:34 GMT
Subject: [lworld] RFR: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock [v3]
In-Reply-To: <6Dc2QkfM2I-pE7vWiKT8sAucEXn47FJIpNfGMli3DVk=.abbc1c5b-84bb-4863-875e-d39e12113895@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
 <6Dc2QkfM2I-pE7vWiKT8sAucEXn47FJIpNfGMli3DVk=.abbc1c5b-84bb-4863-875e-d39e12113895@github.com>
Message-ID: <oaL5TwEXg3T7wZJs3yFbGMq43d1kvD29bkcmrXu93Cw=.75dcdda9-2433-43c9-a7d8-f10bfe36dc94@github.com>

On Wed, 17 Dec 2025 14:09:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
>> 
>> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
>> 
>> I propose a few changes:
>> 
>> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
>> 
>> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
>> 
>> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
>> 
>> WDYT?
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further clarification of Members

Thanks for reviewing! No new failures with Tier1-3 on Linux & Win.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1812#issuecomment-3665686542

From stefank at openjdk.org  Wed Dec 17 14:52:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 14:52:56 GMT
Subject: [lworld] Integrated: 8373864: [lworld] Hide and rename
 InstanceKlassFixedBlock
In-Reply-To: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
References: <y9nfPRc9-DRDm1WFVyf6scfMjvAaIvIZCd_UkkSjDcM=.5a86cb29-288d-4fc1-bc53-4eb0a0ede858@github.com>
Message-ID: <ErAfykFwF-Iv-gX6qTbcen7pvE3TyK3Luo24GwR_Xmw=.8e20c54e-5414-4c15-b1ae-ccced9f5339d@github.com>

On Wed, 17 Dec 2025 10:21:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Sub-classes of `InstanceKlass` can't have C++ fields because they would end up overlayed on top of the vtable and other dynamically sized sections of the `InstanceKlass` object.
> 
> To handle that the `InlineKlass` has a companion class named `InlineKlassFixedBlock`, which lists all the member fields that belongs to the InlineKlass, and an instance of that gets stamped into the `InlineKlass` object after the parts that are provided by the `InstanceKlass`.
> 
> I propose a few changes:
> 
> 1) Move `InlineKlassFixedBlock` away from instanceKlass.hpp and place it inside inlineKlass.hpp instead.
> 
> 2) Nest `InlineKlassFixedBlock` it inside `InlineKlass`. It's only `InlineKlass `(and the compilers) that touch these fields, so it doesn't have to be a public, top-level class.
> 
> 3) Rename it from `InlineKlassFixedBlock` to `InlineKlass::Members`. I think that "fixed block" term is unclear and doesn't help the reader understand its role in the `InlineKlass`. Hopefully, the name `Members` is a clearer.
> 
> WDYT?

This pull request has now been integrated.

Changeset: d586e57d
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d586e57d7488461e808e7cb566586d7112b72dc6
Stats:     222 lines in 15 files changed: 98 ins; 53 del; 71 mod

8373864: [lworld] Hide and rename InstanceKlassFixedBlock

Reviewed-by: phubner, fparain

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

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

From dfenacci at openjdk.org  Wed Dec 17 15:01:26 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 15:01:26 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v6]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <vhKIT5kXVdPK1TjDVufgHFl7kL0tvUFdB-BLYf3A0p0=.26192b24-7ea8-451d-ada4-bafd26557457@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 ca...

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8369045 remove another test from problemlist

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1768/files
  - new: https://git.openjdk.org/valhalla/pull/1768/files/32fae207..7790bef4

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

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 duke at openjdk.org  Wed Dec 17 15:03:07 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 15:03:07 GMT
Subject: [lworld] RFR: 8373825: [lworld] ForwardingFileManager always
 closes its delegate leading to ClosedFileSystemException in
 TestOriginatingElements [v4]
In-Reply-To: <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>
References: <aljLNbEJt1gRoIpksqdHbrH83yyJgi1syGsBfdLAYZY=.5b3abc11-eb79-44d7-9350-59bbbfc1ba87@github.com>
 <6p8PzZlggpmUn2LKqlm9xU6zbpk2PyyEbOJRtrtjkZM=.64473c40-89d1-4406-b450-8bdc00dabd16@github.com>
Message-ID: <u3S7L8n5_lavcynNZQuH-2epqjZ9xdYY62Acw1tBgMA=.a826db77-b63f-4c1a-8b5f-cd88f773b868@github.com>

On Wed, 17 Dec 2025 11:05:35 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Allow users of ForwardingFileManager to specify if the delegate file manager should also be closed.
>> 
>> This fixes a use-after-close bug in TestOriginatingElements, where the system file manager and wrapping memory file manager have different, nested, lifetimes resulting in an early call to close the system file manager when the wrapper is closed, causing subsequent legitimate use of the system file manager to fail.
>> 
>> This wasn't noticed before now since the system file manager was using the singleton JRT file-system in which "close" does nothing. Now it's using a properly scoped instance of the JRT file-system which can be closed.
>> 
>> This fix could also probable go straight into mainline as a clone since it won't break anything there.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add @since for new method

Actually the more I think about it, the more I'm convinced it's a better API if the forwarding class knows whether to close or not. The reasoning is this:

* There is only one correct answer to "should be delegate be closed or not", *there is no safe default*.
* The existing code assumes a behaviour which could lead to hard-to-debug bugs.
* By adding a new constructor, the question of lifetime ownership becomes visible to people using the class.

While it's not a forcing function (the other constructor with original behaviour must still exist), there's more chance users encountering the class for the first time will think about the issue, compared to having to just remember that lifetime ownership is a thing and what the forwarding class does.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1810#issuecomment-3665745443

From dfenacci at openjdk.org  Wed Dec 17 15:05:10 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 15:05:10 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v2]
In-Reply-To: <V-RLIdzRgcoW18tNaLuV1ILJWv_NHqHvQuiwZjqgbM4=.3456d01c-29f3-4397-a160-e976a906050e@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@github.com>
 <V-RLIdzRgcoW18tNaLuV1ILJWv_NHqHvQuiwZjqgbM4=.3456d01c-29f3-4397-a160-e976a906050e@github.com>
Message-ID: <peSw8AlgxoyagfRgO1F7waVVti_8YuKfYKiP1q3wJnU=.a224bf3e-3c6e-4b0a-af5e-a1d11f9cf1d4@github.com>

On Tue, 16 Dec 2025 08:51:59 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8369045: remove strength reduction flag
>
> src/hotspot/share/opto/graphKit.cpp line 2051:
> 
>> 2049:         _gvn.set_type(ret, ret->Value(&_gvn));
>> 2050: 
>> 2051:         // Don't add store to buffer call if we are strength reducing
> 
> Why do we need to add the above runtime check of the result again when doing strength reduction?

We actually don't ?
I moved it inside the not-strength-reducing block.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1768#discussion_r2627420774

From dfenacci at openjdk.org  Wed Dec 17 15:12:47 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 15:12:47 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v7]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <J01FPSv46csJvEoB_Cg_gzdaf3Nd_LjdCFtff3ktBOw=.2bf5a5bc-fdd1-43c2-8349-b1145917a7ce@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 ca...

Damon Fenacci has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'lworld' into JDK-8369045
 - JDK-8369045 remove another test from problemlist
 - JDK-8369045 remove tests from problemlist
 - Merge branch 'lworld' into JDK-8369045
 - Merge branch 'JDK-8369045' of https://github.com/dafedafe/valhalla into JDK-8369045
 - Update src/hotspot/share/opto/graphKit.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - JDK-8369045: don't re-add condition if stress-reducing
 - Revert "JDK-8369045: remove strength reduction flag"
   
   This reverts commit ccf58125b13655bb6c15af747345efbd6791f93d.
 - JDK-8369045: remove strength reduction flag
 - JDK-8369045: remove new line
 - ... and 5 more: https://git.openjdk.org/valhalla/compare/d586e57d...b2c399f4

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

Changes: https://git.openjdk.org/valhalla/pull/1768/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1768&range=06
  Stats: 70 lines in 5 files changed: 27 ins; 8 del; 35 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 dfenacci at openjdk.org  Wed Dec 17 15:12:48 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Wed, 17 Dec 2025 15:12:48 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v2]
In-Reply-To: <oips92rUjhpODGCYXFOqSTxsmqUAleLqUYS-vbZgIv4=.4354513f-5ac8-4eb7-951e-462907c51d69@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <Rb-kCdylBStJ_mkndF9wRqpzlGQGo4EK91_PVqR8RzE=.b89a9e75-2c60-4545-8955-6a9d5820aa83@github.com>
 <oips92rUjhpODGCYXFOqSTxsmqUAleLqUYS-vbZgIv4=.4354513f-5ac8-4eb7-951e-462907c51d69@github.com>
Message-ID: <su0qKAgDSalyTxW8YID8v_gWE_v0FM6zad_06q78IDA=.0a01f062-c2f2-48bf-ac54-b0bf1fe8e6a1@github.com>

On Wed, 17 Dec 2025 06:42:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> You also need to remove the tests from the problem list again (see https://github.com/openjdk/valhalla/pull/1793).

Removed.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1768#issuecomment-3665782143

From qamai at openjdk.org  Wed Dec 17 15:18:04 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 17 Dec 2025 15:18:04 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v10]
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: <dBT9mc86O0dLwnWr7lB73gNNjL6y2x08aKGZ2I8nTJs=.04ffaebc-64c3-4175-b151-aee858b2cde6@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 14 commits:

 - ArrayProperties needs to agree with LayoutKind
 - Merge branch 'lworld' into AryKlassPtrfactory
 - Merge branch 'lworld' into AryKlassPtrfactory
 - reviews
 - reviews
 - Should not clone MergeMem
 - fix NarrowMemProj
 - Merge branch 'lworld' into AryKlassPtrfactory
 - Fix Parse::array_store and PhaseMacroNode::value_from_mem
 - whitespace
 - ... and 4 more: https://git.openjdk.org/valhalla/compare/1077e4f9...bdd91920

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

Changes: https://git.openjdk.org/valhalla/pull/1755/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1755&range=09
  Stats: 598 lines in 23 files changed: 261 ins; 156 del; 181 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 mchevalier at openjdk.org  Wed Dec 17 15:34:48 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Wed, 17 Dec 2025 15:34:48 GMT
Subject: [lworld] RFR: 8373844: [lworld] Un-problem list
 ScalarReplacementWithGCBarrierTests.java
Message-ID: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>

It was previously fixed in JDK-8372697.

But I've rested after the fateful removal of EnableValhalla, and it seems to pass. Let's just un-problem list.

Thanks,
Marc

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

Commit messages:
 - Un-problemlist

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

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

From chagedorn at openjdk.org  Wed Dec 17 15:48:17 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 17 Dec 2025 15:48:17 GMT
Subject: [lworld] RFR: 8373844: [lworld] Un-problem list
 ScalarReplacementWithGCBarrierTests.java
In-Reply-To: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
References: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
Message-ID: <fAUO-S9vZbKUhqNgXZ5JSomvBS2fFxPqZl9YrHN4JYg=.952c12ac-1dd8-4263-861e-9ceeedbb32e3@github.com>

On Wed, 17 Dec 2025 15:26:57 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It was previously fixed in JDK-8372697.
> 
> But I've rested after the fateful removal of EnableValhalla, and it seems to pass. Let's just un-problem list.
> 
> Thanks,
> Marc

Looks good and trivial.

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1816#pullrequestreview-3588376059

From phubner at openjdk.org  Wed Dec 17 15:56:59 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 15:56:59 GMT
Subject: [lworld] RFR: 8373844: [lworld] Un-problem list
 ScalarReplacementWithGCBarrierTests.java
In-Reply-To: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
References: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
Message-ID: <S8FOxhnByy_ntigwbix6_CcBtiS_2hf_tjB90ACOKQs=.2fdd6cc5-601d-4d36-a07a-c9350ac93be1@github.com>

On Wed, 17 Dec 2025 15:26:57 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It was previously fixed in JDK-8372697.
> 
> But I've rested after the fateful removal of EnableValhalla, and it seems to pass. Let's just un-problem list.
> 
> Thanks,
> Marc

Thanks for doing this. Ship it!

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1816#pullrequestreview-3588413199

From matsaave at openjdk.org  Wed Dec 17 16:00:27 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Dec 2025 16:00:27 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping [v3]
In-Reply-To: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
Message-ID: <ipD11QLHx7mISJatXaNDDp37s43Urf7JkBEWARwAv60=.33c6b8a2-66fc-490c-8918-f8de7a1ea60a@github.com>

> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
> 
> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.

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

 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - Reverted preview patching flag
 - Fred comment
 - Removed test from group
 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - Properly rewrite fast_vputfield and fast_vgetfield
 - Merge branch 'lworld' into enable_cds_heap
 - Merge branch 'lworld' into enable_cds_heap
 - ... and 1 more: https://git.openjdk.org/valhalla/compare/d586e57d...12219718

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

Changes: https://git.openjdk.org/valhalla/pull/1757/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1757&range=02
  Stats: 69 lines in 8 files changed: 37 ins; 28 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1757.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1757/head:pull/1757

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

From thartmann at openjdk.org  Wed Dec 17 16:07:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 17 Dec 2025 16:07:25 GMT
Subject: [lworld] RFR: 8372917: [lworld] C2 compilation bailout asserts due to
 label in inconsistent state
Message-ID: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>

When an expected compilation bailout (like 'CodeCache is full') happens during matching, not all nodes might be visited and therefore the Valhalla specific `verified_entry` label might be in inconsistent state (used but not bound). We should simply reset it when we bail out. For more details, see JBS.

Thanks,
Tobias

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

Commit messages:
 - 8372917: [lworld] C2 compilation bailout asserts due to label in inconsistent state

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

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

From jsikstro at openjdk.org  Wed Dec 17 16:22:05 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 17 Dec 2025 16:22:05 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v3]
In-Reply-To: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
Message-ID: <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>

> Hello,
> 
> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
> 
> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
> 
> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
> 
> Testing:
> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
> 
> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.

Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:

 - Add test for large primitive only flat arrays
 - Assert fixes

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1811/files
  - new: https://git.openjdk.org/valhalla/pull/1811/files/bf305dcc..c35878c0

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

  Stats: 85 lines in 2 files changed: 77 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/1811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1811/head:pull/1811

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

From jsikstro at openjdk.org  Wed Dec 17 16:22:09 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 17 Dec 2025 16:22:09 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v2]
In-Reply-To: <mjDIlRcxKMIMbFQLtglweMLktaJtXLVYwTQJ2o109go=.406cd135-3734-4c75-8106-79e19f303876@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
 <mjDIlRcxKMIMbFQLtglweMLktaJtXLVYwTQJ2o109go=.406cd135-3734-4c75-8106-79e19f303876@github.com>
Message-ID: <_qMx5mednNw18dB3t2k9ZsbgQ6bnsKxAmj61JMJkA8s=.c74260f6-86b2-4844-8b23-ac5f23295bfe@github.com>

On Wed, 17 Dec 2025 11:03:49 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Offline review feedback
>
> src/hotspot/share/gc/z/zObjArrayAllocator.cpp line 64:
> 
>> 62:   }
>> 63: 
>> 64:   if (is_oop_containing_flat_array(_klass)) {
> 
>> A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
> 
> Is this something we can guard against in the code as well? What happens if somebody creates a null-restricted non-atomic primitive-only flat array via the `ValueClass` API? Tearing from the user's POV is absolutely okay in such a case, but will any ZGC assumptions be violated?

In my initial sanity tests I just checked what classes were getting past the new `is_oop_containing_flat_array`, without checking if the passed the size check. It turns out that there are no tests in jdk_valhalla or hotspot_valhalla where ZGC allocates a large enough primitive-only array to get into the segment clearing code.

We can't add any asserts here as we have tests which uses null-restricted and/or loosely-consistent properties.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1811#discussion_r2627706607

From jsikstro at openjdk.org  Wed Dec 17 16:23:40 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 17 Dec 2025 16:23:40 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v2]
In-Reply-To: <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <lia4zgcbDlct7e0eA15M-bdHH4efpVZ2Pi-C7Nn1X5Y=.49484d90-e687-4995-9e93-b1eab5c8e575@github.com>
Message-ID: <kEfuy1Nb3KNqw0KWic9__E2Uq4Qqf7Trz_CYMoLoH4s=.1e23f6f1-454f-4126-b322-94b90ccce3e0@github.com>

On Wed, 17 Dec 2025 10:02:52 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline review feedback

I pushed a new commit which fixes some asserts that were hit in the clearing code. And I've added a new smoke-screen test `test/hotspot/jtreg/runtime/valhalla/inlinetypes/FlatArrayLargeIndicesTest.java` which allocates primitive-only flat arrays large enough to get into the segmented clearing code.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1811#issuecomment-3666126484

From vromero at openjdk.org  Wed Dec 17 16:37:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Dec 2025 16:37:34 GMT
Subject: [lworld] RFR: 8373261: [lworld] VerifyError: Strict fields not a
 subset of initial strict instance fields [v2]
In-Reply-To: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
References: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
Message-ID: <2OeaVvObpx6tcXsseTOD2RSTSBb0V-Ht71beSurbsA4=.7ad6694e-31c8-48b1-844b-e09ac0f90efb@github.com>

> The verifier is failing due to an incorrect EarlyLarvalFrame generated by javac. The issue can be reproduced by compiling this test case:
> 
> 
> public class Test {
>     static value class Val1 {
>         int i1;
>         int i2;
>         int i3;
>         int i4;
> 
>         public Val1() {
>             this.i1 = 0;
>             this.i2 = 0;
>             this.i3 = 0;
>             this.i4 = 0;
>         }
>     }
> 
>     static value class Val2 {
>         int i1;
>         Val1 val1;
> 
>         public Val2(boolean b) {
>             this.i1 = 0;
>             this.val1 = b ? null : new Val1(); // this statement will trigger the generation of an EarlyLarvalFrame
>         }
>     }
> 
>     public static void main(String[] args) {
>         Val2 val = new Val2(true);
>     }
> }
> 
> so from the example above, for `Val2`'s constructor, javac is generating an `EarlyLarvalFrame` that included `Val1`'s `i4` field as an uninitialized strict field. The reason is that method `findUninitStrictFields` in `Flow` was not stopping at the max valid local variable for the current method. There are some data structures that are reused during flow analysis without being cleared from method to method to save time. So basically this method was reading "logically erased" info left during the analysis of the previous constructor.
> 
> TIA for the review

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1809/files
  - new: https://git.openjdk.org/valhalla/pull/1809/files/a317c78a..75e460af

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

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

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

From vromero at openjdk.org  Wed Dec 17 16:37:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Dec 2025 16:37:38 GMT
Subject: [lworld] RFR: 8373261: [lworld] VerifyError: Strict fields not a
 subset of initial strict instance fields [v2]
In-Reply-To: <lwJXkyHCVvb6U0XxhlwJ6FwwCUkSr6f6uQ42XGnnLT4=.ded65af4-f657-418d-8812-a9f8e2716088@github.com>
References: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
 <lwJXkyHCVvb6U0XxhlwJ6FwwCUkSr6f6uQ42XGnnLT4=.ded65af4-f657-418d-8812-a9f8e2716088@github.com>
Message-ID: <BPyDkFrP84ACPsQt8SaHq3jL-Zq_seI85GDKMzRix38=.c20c7c50-4e81-4914-b8b2-20a86ed8b206@github.com>

On Wed, 17 Dec 2025 13:56:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   addressing review comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2122:
> 
>> 2120:             for (int i = firstadr; i < nextadr; i++) {
>> 2121:                 JCVariableDecl variableDecl = vardecls[i];
>> 2122:                 if (uninits.isMember(variableDecl.sym.adr) && variableDecl.sym.isStrict()) {
> 
> This could also be replaced with `uninints.isMember(i)` right?

sure, done

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1809#discussion_r2627758602

From vromero at openjdk.org  Wed Dec 17 16:37:40 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 17 Dec 2025 16:37:40 GMT
Subject: [lworld] Integrated: 8373261: [lworld] VerifyError: Strict fields not
 a subset of initial strict instance fields
In-Reply-To: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
References: <Hw6gsHnG_JX4RHIpMDxIokXMvnJEuuVvTYtCwv0Bz4k=.084c34ff-26dc-4439-9eaf-41ee0c3497a5@github.com>
Message-ID: <fr7niAQVGq3GsmVdEkh3sqJim0UHgeM_L3FK_CgmYM4=.a9709650-0021-40e9-ade3-f731b1ae314b@github.com>

On Tue, 16 Dec 2025 20:06:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> The verifier is failing due to an incorrect EarlyLarvalFrame generated by javac. The issue can be reproduced by compiling this test case:
> 
> 
> public class Test {
>     static value class Val1 {
>         int i1;
>         int i2;
>         int i3;
>         int i4;
> 
>         public Val1() {
>             this.i1 = 0;
>             this.i2 = 0;
>             this.i3 = 0;
>             this.i4 = 0;
>         }
>     }
> 
>     static value class Val2 {
>         int i1;
>         Val1 val1;
> 
>         public Val2(boolean b) {
>             this.i1 = 0;
>             this.val1 = b ? null : new Val1(); // this statement will trigger the generation of an EarlyLarvalFrame
>         }
>     }
> 
>     public static void main(String[] args) {
>         Val2 val = new Val2(true);
>     }
> }
> 
> so from the example above, for `Val2`'s constructor, javac is generating an `EarlyLarvalFrame` that included `Val1`'s `i4` field as an uninitialized strict field. The reason is that method `findUninitStrictFields` in `Flow` was not stopping at the max valid local variable for the current method. There are some data structures that are reused during flow analysis without being cleared from method to method to save time. So basically this method was reading "logically erased" info left during the analysis of the previous constructor.
> 
> TIA for the review

This pull request has now been integrated.

Changeset: 9bc2649c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9bc2649cc4c3a620e8cc04f869c8cd41e2055b09
Stats:     63 lines in 2 files changed: 59 ins; 1 del; 3 mod

8373261: [lworld] VerifyError: Strict fields not a subset of initial strict instance fields

Reviewed-by: mcimadamore

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

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

From stefank at openjdk.org  Wed Dec 17 16:39:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 16:39:27 GMT
Subject: [lworld] RFR: 8373912: [lworld] Small cleanups to InlineKlass
Message-ID: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>

A few cleanups found while scanning over the InlineKlass files:

* Fix include list and forward declarations
* Move non-trivial implementation out of .hpp
* Remove copy-n-past functions from InstanceKlass
* Remove redundant CDS function overrides
* Deduplicate null marker address calculation
* Deduplicate allocate_instance
* Fix raw casts from oop 
* Tweak comments

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

Commit messages:
 - 8373912: [lworld] Small cleanups to InlineKlass

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

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

From stefank at openjdk.org  Wed Dec 17 16:44:23 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 16:44:23 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v3]
In-Reply-To: <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
Message-ID: <K9tWfVbOEzn7iT1_ddTWicZZyK32Yob4-lC5kG7gkq0=.9fa68546-29ec-45f7-b23b-3684deeb47e6@github.com>

On Wed, 17 Dec 2025 16:22:05 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for large primitive only flat arrays
>  - Assert fixes

Looks good to me.

I wonder if it would make sense to check that the value really was cleared with 0 and that our clearing code didn't try to write colored nulls.

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

Marked as reviewed by stefank (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1811#pullrequestreview-3588617104

From duke at openjdk.org  Wed Dec 17 17:00:38 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 17:00:38 GMT
Subject: [lworld] RFR: 8373896: [lworld] Remove now-dead preview patching code
Message-ID: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>

Removing code guarded by now obsolete preview patching property.
This should be a no-op functionally.
Some minor tidying around arguments.cpp since now there's no reason to init the jimage file in the module patching code.

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

Commit messages:
 - Removing the obviously dead code

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

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

From matsaave at openjdk.org  Wed Dec 17 17:19:09 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Dec 2025 17:19:09 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping [v4]
In-Reply-To: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
Message-ID: <ynpRCH_knjaQLRO_8spIX0dA09iIKDo37-e4JEOJoV8=.5e8598fa-8e0c-4733-87d8-b54a158da4aa@github.com>

> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
> 
> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Un-problem listed test

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1757/files
  - new: https://git.openjdk.org/valhalla/pull/1757/files/12219718..806761aa

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

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

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

From stefank at openjdk.org  Wed Dec 17 17:21:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 17:21:21 GMT
Subject: [lworld] RFR: 8373912: [lworld] Small cleanups to InlineKlass [v2]
In-Reply-To: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
References: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
Message-ID: <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>

> A few cleanups found while scanning over the InlineKlass files:
> 
> * Fix include list and forward declarations
> * Move non-trivial implementation out of .hpp
> * Remove copy-n-past functions from InstanceKlass
> * Remove redundant CDS function overrides
> * Deduplicate null marker address calculation
> * Deduplicate allocate_instance
> * Fix raw casts from oop 
> * Tweak comments

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove lingering references to InlineKlassFixedBlock

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1818/files
  - new: https://git.openjdk.org/valhalla/pull/1818/files/8cae412a..9b8c2816

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

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

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

From thartmann at openjdk.org  Wed Dec 17 17:32:09 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 17 Dec 2025 17:32:09 GMT
Subject: [lworld] RFR: 8372917: [lworld] C2 compilation bailout asserts due
 to label in inconsistent state [v2]
In-Reply-To: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>
References: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>
Message-ID: <gKkAO9dmnBFcL2FeXZ8A0nsbXUbgDZwkO-KI_BcVXos=.6ddc94f3-1a05-4f1f-9a58-4d5e34c24609@github.com>

> When an expected compilation bailout (like 'CodeCache is full') happens during matching, not all nodes might be visited and therefore the Valhalla specific `verified_entry` label might be in inconsistent state (used but not bound). We should simply reset it when we bail out. For more details, see JBS.
> 
> Thanks,
> Tobias

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

 - Un-problem listing
 - Merge branch 'lworld' into JDK-8372918
 - 8372917: [lworld] C2 compilation bailout asserts due to label in inconsistent state

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1817/files
  - new: https://git.openjdk.org/valhalla/pull/1817/files/9a67e6dd..3ffcb3f4

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

  Stats: 294 lines in 21 files changed: 165 ins; 54 del; 75 mod
  Patch: https://git.openjdk.org/valhalla/pull/1817.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1817/head:pull/1817

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

From qamai at openjdk.org  Wed Dec 17 17:37:56 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 17 Dec 2025 17:37:56 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v11]
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: <kPp9OPZJkdfwKufeVPUt_Ej3uiWuwXTUTX8fxpvVjx0=.8b97a016-3cc1-4cb2-b4b7-4da11bd7aa9a@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 because properties passed into with_properties is not the same as properties() of the result

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1755/files
  - new: https://git.openjdk.org/valhalla/pull/1755/files/bdd91920..1983febc

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

  Stats: 32 lines in 6 files changed: 13 ins; 10 del; 9 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  Wed Dec 17 17:39:39 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 17 Dec 2025 17:39:39 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v10]
In-Reply-To: <dBT9mc86O0dLwnWr7lB73gNNjL6y2x08aKGZ2I8nTJs=.04ffaebc-64c3-4175-b151-aee858b2cde6@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <dBT9mc86O0dLwnWr7lB73gNNjL6y2x08aKGZ2I8nTJs=.04ffaebc-64c3-4175-b151-aee858b2cde6@github.com>
Message-ID: <3TcGK3TKK3_bAAFtOhNAKGIlDvgncAf7EaQwqRz_sTw=.aadcc45a-df68-4265-9602-25d5593f3093@github.com>

On Wed, 17 Dec 2025 15:18:04 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 14 commits:
> 
>  - ArrayProperties needs to agree with LayoutKind
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - reviews
>  - reviews
>  - Should not clone MergeMem
>  - fix NarrowMemProj
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix Parse::array_store and PhaseMacroNode::value_from_mem
>  - whitespace
>  - ... and 4 more: https://git.openjdk.org/valhalla/compare/1077e4f9...bdd91920

I have resolved the merge conflict and the failure. The issue was that the properties of an `ArrayKlass` do not agree with its layout kind. What I did was to normalize the properties after layout selection.

@fparain What do you think? Thanks a lot.

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

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

From jbhateja at openjdk.org  Wed Dec 17 17:41:01 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 Dec 2025 17:41:01 GMT
Subject: [lworld+vector] Integrated: Merge lworld
Message-ID: <z7QO1c_tWhPdHtfoiFaPb7FQF1VWSXzhTTGSjxjixfw=.847a13e8-5662-452d-887f-b52d5cbce6b2@github.com>

Merge from lworld in lworld+vector branch.

Apart from the usual merge conflict resolution, the patch also contains bug fixes for some special handling around multifields.
To segregate the code changes and maintain the history[1][2][3][4][5], these bug fixes were initially checked into a temporary private merge branch and are now part of the merge. 


[1] Special copy constructor used for initializing base and synthetic multifields 
    https://github.com/jatin-bhateja/valhalla/commit/0fe3153e79251fe661ea1bd368472f2f75cb360d
[2] Fix ciField population for multifields 
    https://github.com/jatin-bhateja/valhalla/commit/4a26aff14801e010ea238e8d5a52a52465c6f849
[3] Multifield handling during type domain buildup
     https://github.com/jatin-bhateja/valhalla/commit/74ca0245c5d9f5eb186baa962e11d3f5c8f4ed35
[4] prevent store forwarding across CPU memory barrier
     https://github.com/jatin-bhateja/valhalla/commit/cfc71acd89b2e3233d788565f1cf1061651a70f9
[5] Fix to accommodate additional padding during offset computation of multifields
     https://github.com/jatin-bhateja/valhalla/commit/75ec6296531839ab375efa58b909827269994449

After latest merge, all the VectorAPI and Valhalla JTREG tests are passing with -XX:-UseNonAtomicValueFlattening at
variaous AVX levels. With -XX:+UseNonAtomicValueFlattening there are some failures which will be addressed post
merge commit.

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

Commit messages:
 - FIXME for MULTIFILE handling in acmp map
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_lworld2
 - Merge branch 'lworld' of http://github.com/openjdk/valhalla into merge_lworld2
 - Merge branch 'lworld' of https://github.com/openjdk/valhalla into merge_lworld2
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - JDK 8327435: [lworld+vector] Align existing Vector API support with JEP 401
 - ... and 18 more: https://git.openjdk.org/valhalla/compare/a07dfe93...802d8f79

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/valhalla/pull/1688/files
  Stats: 12464 lines in 288 files changed: 5054 ins; 2474 del; 4936 mod
  Patch: https://git.openjdk.org/valhalla/pull/1688.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1688/head:pull/1688

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

From jbhateja at openjdk.org  Wed Dec 17 17:41:03 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 Dec 2025 17:41:03 GMT
Subject: [lworld+vector] Integrated: Merge lworld
In-Reply-To: <z7QO1c_tWhPdHtfoiFaPb7FQF1VWSXzhTTGSjxjixfw=.847a13e8-5662-452d-887f-b52d5cbce6b2@github.com>
References: <z7QO1c_tWhPdHtfoiFaPb7FQF1VWSXzhTTGSjxjixfw=.847a13e8-5662-452d-887f-b52d5cbce6b2@github.com>
Message-ID: <6jNLlLMBUWl-W_pv5JU48ar4CNMz6z0TP_Ggb852Iak=.4db24fea-f443-4c5b-bca8-93b7f7236a07@github.com>

On Tue, 21 Oct 2025 01:27:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector branch.
> 
> Apart from the usual merge conflict resolution, the patch also contains bug fixes for some special handling around multifields.
> To segregate the code changes and maintain the history[1][2][3][4][5], these bug fixes were initially checked into a temporary private merge branch and are now part of the merge. 
> 
> 
> [1] Special copy constructor used for initializing base and synthetic multifields 
>     https://github.com/jatin-bhateja/valhalla/commit/0fe3153e79251fe661ea1bd368472f2f75cb360d
> [2] Fix ciField population for multifields 
>     https://github.com/jatin-bhateja/valhalla/commit/4a26aff14801e010ea238e8d5a52a52465c6f849
> [3] Multifield handling during type domain buildup
>      https://github.com/jatin-bhateja/valhalla/commit/74ca0245c5d9f5eb186baa962e11d3f5c8f4ed35
> [4] prevent store forwarding across CPU memory barrier
>      https://github.com/jatin-bhateja/valhalla/commit/cfc71acd89b2e3233d788565f1cf1061651a70f9
> [5] Fix to accommodate additional padding during offset computation of multifields
>      https://github.com/jatin-bhateja/valhalla/commit/75ec6296531839ab375efa58b909827269994449
> 
> After latest merge, all the VectorAPI and Valhalla JTREG tests are passing with -XX:-UseNonAtomicValueFlattening at
> variaous AVX levels. With -XX:+UseNonAtomicValueFlattening there are some failures which will be addressed post
> merge commit.

For the record copy pasting the comments from closed PR https://github.com/openjdk/valhalla/pull/1593

Hi @liach, For now, vectorAPI fallback does make heavy use of unsafe APIs for explicit larval transitions.
There is a whole lot of discussion that went into the usage of the @multifield annotation for contiguous backing storage allocation. Sharing some links for your reference.

https://cr.openjdk.org/~jrose/values/multi-field.html
https://cr.openjdk.org/~jbhateja/Valhalla/Valhalla-VectorAPI-OracleF2F-3-Apr_2024.pptx
 
----------

Hi @liach , 

Currently, Unsafe.put* APIs expect to operate on a mutable value, without Unsafe.makePrivateBuffer, there is no way to transition a value object to larval state.

<img width="800" height="400" alt="image" src="https://github.com/user-attachments/assets/af826cda-55e1-4b0c-a2ea-62592f7623d6" />


Here is a typical update kernel for the nary operation fallback implementation. 

<img width="500" height="200" alt="image" src="https://github.com/user-attachments/assets/4a31baa7-52b8-4e0b-8c42-924407bb5665" />



**Here are some relevant FAQs on the need for multifield annotation.**

Q. Why do we need @multifield annotated field in VectorPayloads and not just retain the array-backed backing storage?
A.  Even currently, Vector instances are immutable, with each modification or application of an operation, a new vector is generated. 
      Each new vector has a distinct backing storage in the form of an array; thus, no two vector ever share their backing storage, which makes vectors an immutable quantity. 
      
     Vector<Float>  newVector  =  Vec1.lanewise(VectorOperators.ADD, Vec2);
     
Since arrays are always allocated over the heap, they carry an identity, which is the distinctive heap address for each new backing storage array.

This contradicts the philosophy of value type instances, which are identity-free; the compiler treats two values with the same contents as equivalent entities and is free to substitute one with another. 

By replacing existing array-backed storage with a @multifield annotated storage, we ensure that payload adheres to true value semantics, a @multifiled is seen as a bundle of fields, encapsulating payload is a value class, unlike an array, a multifield is never allocated an explicit heap storage. 

Here is an example code

 
<img width="400" height="500" alt="image" src="https://github.com/user-attachments/assets/14cb3fbc-15cf-461e-846e-b200f744f793" />


Even though Payload is a value class, its two instances with the same backing storage are not equal, because arrays have identity.
By treating vectors as value objects, we expect that two vectors with the same contents should be equal.

Q.  Is there any alternative to @multifield?
A.  All we need to ensure is that the backing storage has no identity.  Thus, we could have multiple primitive type fields in the payload, one for each lane of the vector. 

 
<img width="450" height="310" alt="image" src="https://github.com/user-attachments/assets/af977c64-6373-4533-aceb-6d283cecd094" />

Consider the above modified payload class ?TrueValuePayload?, here we create a separate primitive type field for each lane of the vector, thus two vector values with the same contents are treated as equivalent entities. 

With @multifield we intend to create identity-free backing storage. 


Q.  What are the complications with explicit fields for each lane in the container payload?
A.  First, at load time, build_layout randomizes the fields' layout,  but that is not a major concern since fields can always be updated using their effective offsets, for a multifield update **, existing reflective name-based APIs don't suffice, we need an UNSAFE api which accepts the offsets, since a multifield has hidden / synthetic fields which can only be accessed by adding offsets w.r.t to base field** 

A bigger concern is that the C2 compiler will see scalar fields as different inputs to InlineTypeNode. The compiler creates an InlineTypeNode for each instance of a value class and scalarizes the fields, with different scalar field we may observe multiple inputs to IR, one for each lane. Each scalar field will be of primitive Type, while the type of InlineTypeNode will be PayloadType, since an inline type node corresponds to a value object. We expect to deal in vector-type field, i.e., the one that carry an ideal type TypeVect. 

Vector IR  is forwarded to its user every time we perform a vector_unbox operation over VectorPayload, this way, vector IR inputs are directly forwarded to the vector operation nodes.

Keeping multiple scalar fields, one for each lane type in the VectorPayload class, while creating a vector IR for a bundle of lanes, will result in adding kludges in the code.  Consider the following case

     var  v1 = FloatVector.fromArray(SP, arr1, index)
     var  v2 = FloatVector.fromArray(SP, arr2, index)
     res =  v1.lanewise(VectorOperators.ADD, v2)

    v1 and v2 are concrete vector class instances, where the vector class is a valuetype, with stock Valhalla, IR corresponding to fromArray API will look like the following

                                           
<img width="374" height="224" alt="image" src="https://github.com/user-attachments/assets/5f923efe-5b42-4e47-b04f-13abd4cfeee8" />


While the expected IR pallet should look like the following 

 
<img width="354" height="313" alt="image" src="https://github.com/user-attachments/assets/26d1ce93-f4d4-48fd-afaf-1b32a0904d2d" />


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

Hi @liach ,

Here is a quick sync-up on the merge status.

I started the merge yesterday, but it may take a few more days as there have been lots of changes in the code over the last 4 months. I am studying the code changes and documenting the new code model, in crystalline form. Following is our new model for larval objects.

Core concept (New model):-
  - A value object can be updated when it's in the larval state, either explicitly through makePrivateBuffer or implicitly during new object creation.
  - A value in a larval state must be in a non-scalarized form, i.e., it should exist as an oop.
  - Updates to a larval value field are done by emitting an explicit store operation/IR, This mandates an OOP form of larval object; this is a major change from the earlier model, where puffield could directly update the incoming edge of scalarized InlineTypeNode IR. Given that a value object is an immutable quantity, any update is only possible by way of creating a new value, thereby going through a temporary larval state.
  - Value object is transitioned to a non-larval state after the constructor call or after finishPrivateBuffer.
  - For vector API, backing storage is in the form of a @Multifield payload, since only the base field can be exposed in Java code, and the rest of the synthetic fields are internally generated based on the annotation processing during class file parsing; hence, we definitely need an Unsafe API to update all the synthetic fields.
  - New flexible constructor does allow updates to fields before the super call, but we still cannot pass uninitializedThis to an external initialization routine (like an unsafe API) from a constructor. As a result of this, currently the VectorPayalod*MF constructors only initialize the base multifield through a putfield bytecode. [JDK-8368810](https://bugs.openjdk.org/browse/JDK-8368810) tracks this issue.

In the current context, we have the following options to perform vector updates in the fallback implementation:-

Premise: Value objects are immutable, and two vector values with the same lane contents must be treated as equals.


  **a/ Current update loop:-**
      

                          res = Unsafe.makePrivateBuffer(arg1);
                          for (int i = 0; i < laneCount; i++) {
                                 larg1 =  Unsafe.getFloat(arg1, offset[i]);
                                 larg2 =  Unsafe.getFloat(arg2, offset[i]);
	                         Unsafe.putFloat(res, larg1 + larg2);                // res is in oop form since its in a mutable state.         
                          }
                          res = Unsafe.finishPrivateBuffer(res);                   // re-create scalarized representation from larval state. 

         
The lifetime of a larval is very restricted today, and by Java application compilation, we don't emit any bytecode b/w the new and its subsequent initializing constructor. However, using handcrafted bytecode, we can have a gap b/w a new ininitialized allocation and its initializing constructor, but the JVM runtime rules for bytecode verification catch any undefined behavior. Unsafe operations are outside the purview of JVM bytecode verification.

Problem arises when we make the lifetime of the larval object being acted upon by an unsafe API span across a block or even loop of bytecode; in such cases, we may need to handle larval and non-larval merges OR emit an undefined behavior error.

  Q. How performant is the unsafe get / put operation?
  A. There are intrinsic and native implementations of get/put APIs, given that it's an unsafe operation compiler does not care about emitting any out-of-bound checks, as it's the responsibility of the user. In such a case, an unsafe get simply computes an effective address (base + offset) and emits load / store instructions. Does the loop involving unsafe operation auto-vectorized ? Yes, since the auto-vectorizer looks for contiguity in the address across iterations.

Consider the impact of long-lived larval res in the above update loop on intrinsicfication


               <statistics type='intrinsic'>
                      Compiler intrinsic usage:
                         2 (50.0%) _getFloat (worked)
                         1 (25.0%) _putFloat (worked)
                         1 (25.0%) _makePrivateBuffer (worked)
                         0 ( 0.0%) _finishPrivateBuffer (failed)
                         4 (100.0%) total (worked,failed)
                    </statistics> 



res, was made a larval quantity using makePrivateBuffer, but scalarization triggered at gen_checkcast, which observed a value type oop, which by the way is in larval state. As a result, finishPrivateBuffer receives an InlineTypeNode while it always expects to receive a larval value oop, and hence intrinsification fails, it has a side effect on auto-vectorization, which does not observe an IR expression for store and its associated address computation since we take the native implementation route. Hence, the performance of fall fallback implementation degrades.

Q. What are the possible solutions here? 
A. Compiler should never try to scalarize the larval oop at checkcast bytecode; this handling exists because type profiling sharpens the oop's type to a value type, thus facilitating scalarization.  Another solution is to make finishPrivateBuffer intrinsic more robust; it should simply return the InlineTypeNode by setting the Allocation->_larval to false. This is attempted by an unmerged patch[1]
All in all, there are loopholes if we increase the life span of the larval object; in this case, it spans across the loop.

  **b/ Other larval lifetime limiting options:-**

In the fallback implementation, we intend to operate at the lane level; it may turn out that the generated IR is auto-vectorizable, but it's purely a performance optimization by the Compiler, and was not the intent of the user in the first place. So we read the input lanes using Unsafe API, we need an Unsafe get here, since synthetic multifields are not part of user visible Java code and have no symbol or type information in the constant pool. Thus, with multi-field, we ought to use unsafe APIs. Unsafe. get does not mandate larval transitions of the input value vector. What needs to change, well, to limit the larval life time, we need to allocate a temporary buffer before the loop for storing the result of the computation loop.

We need a new Unsafe API that accepts the temporary buffer and the result value object. This API will internally buffer the scalarized value, update its field from the temporary result storage, and then re-materialize the scalarized representation from the updated buffer. 

  Q. Will this API again have both native and intrinsic implementation?
  A.  Yes, it will definitely have native implementation, and the intrinsic implementation should make use of vector IR if the target supports the required vector size, OR it will need to emit scalar load / store IR, We can be intelligent in the intrinsic implementation to optimize this copy operation using a narrower vector. 

  Q. Will this be performant over the existing solution? 
  A. Additional allocation of a temporary buffer is costly; we can bank on escape analysis and loop unrolling to eliminate this allocation, but given that the temporary storage is passed to a native routine, it escapes the scope. With a Vector IR-based intrinsic implementation, we do need a contiguous memory view of temporary storage; otherwise, we may need to emit multiple scalar inserts into a vector, which is very costly. Overall, we don't expect the new implementation to be performant, mainly due to the additional allocation penalty. BTW, even today, vectors are immutable and vector factory routines are used in the fallback implementation to allocate memory for backing storage, thus we not only allocate a new concrete vector but also its backing storage, with current Valhalla and flat payloads we only need one allocation for vector and its backing storage, with new approach we may have to give away that benefit for reduced larval lifetime. It may turn out that the new approach is
  inferior in terms of performance with respect to the existing VectorAPI-Valhalla solution, but eventually may be at par with mainline support.

So it's tempting to try out the new solution to limit the complexity due to long-lifespan larval objects.

   **c/ Alternative approach : Create a new immutable value with each iteration of the update loop  this is near to new code model .**


                          res = __default_value__
                          for (int i = 0; i < laneCount; i++) {
                                 larg1 =  Unsafe.getFloat(arg1, offset[i]);
                                 larg2 =  Unsafe.getFloat(arg2, offset[i]);
	                         res =     Unsafe.updateLane(res, larg1 + larg2);     // res is in oop form since its in a mutable state.         
                          }


This also limits the lifetime of the larval value object, but on the hind side performs a buffering and scalarization with each iteration. When we buffer, we not only allocate a new temporary storage, but also emit field-level stores to dump the contents into temporary storage; this is very expensive if done for each lane update, given that we are only updating one lane of vector but are still paying the penalty to save and restore all unmodified lanes per iteration.

While this does limit the larval life span, it has a huge performance penalty in comparison to both the existing approaches of larval life time across loop and single update with temporary storage allocation. 

In the vector API, the fallback implementation is wrapped within the intrinsic entry point. As long as intrinsification is successful, we are not hit by a fallback; a poor fallback may delay the warmup stage, but for long-running SIMD kernels, warmups are never an issue as long as intrinsifications are successful.

I have created a prototype application [2] mimicking the vector API use case for you. Please give it a try with the existing lworld+vector branch after integrating the patch[1]

**While I am merging and understanding the implications of the new code mode, it will help if you can share your plan/test sample for the latest API to limit the scope of larval transition, keeping in view the above context.**

**Some notes on the implications of patch[1]**
Currently, the compiler does not handle vector calling convention emitting out of scalarization; this is a concern with the generic handling of multifield, where the return value was a container of a multifield and the multifield value was held by a vector register, in such a case, the caller will expect to receive the value in a vector register, with the vector API we deal in abstract vectors across method boundaries, which are never scalarized, anyway, extending the calling convention is on our list of items for Valhalla.

To circumvent this issue seen with the test case, we can disable scalarization of return values using -XX:-InlineTypeReturnedAsFields

[1] https://github.com/jatin-bhateja/external_staging/blob/main/Backup/lworld_vector_performance_uplift_patch_30_9_2025.diff

[2] https://github.com/jatin-bhateja/external_staging/blob/main/Code/java/valhalla/valhalla_401/valhalla_vector_api_mf_proto.java

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

Hi @liach ,

I am working on refreshing lworld+vector branch and also thinking through some post-merge improvements.
For record sake, adding my notes in the comments.

post merge improvements:-
    - Replace VectorBox and VectorBoxAllocate nodes with InlineTypeNode.
    - New Ideal Transforms to sweep intermediate logic after inline expansion.
  
  Code snippet:-


Source:-
       vec1 = fromArray(SRC1)              - [1]
       vec2 = fromArray(SRC2)              - [2]
       res = vec1.lanewise(MUL,vec2)       - [3]
       res.intoArray(RES)                  - [4]


  Intermediate Representation for [1][2]
       
       LoadVector 
          |
          v
       InlineTypeNode (VectorPayload)
          |
          v
       InlineTypeNode (Double256Vector)
          |
          v
       CastPP (NotNull) 
          |
          v
       CheckCastPP (Double256Vector)
        |
        v     
       [x] -> AddP -> LoadVector
        |                  |
        |                  v
        |             InlineTypeNode (VectorPayload)      [[[[ make_from_oop ]]]           
        |                  |
        | oop              v
        |-----------> InlineTypeNode (Double256Vector)
                           |
                           v
                          [y]


  Intermediate Representation for [3]

           [y]         [y]
            |           |
            v           v
      VectorUnbox   VectorUnbox
            |         /
            |        /
            |       /
            |      /
            |     /                                                                                            
            |    /
            |   /
            [Mul]
              |
              v
        InlineTypeNode (VectorPayloadMF)
              |
              v
        InlineTypeNode (Double256Vector)
              |
              v
            CastPP
              |
              v
          CheckCastPP
              |
              v    
             [x] -> AddP -> LoadVector
              |                  |
              |                  v
              |             InlineTypeNode (VectorPayload)      [[[[ make_from_oop ]]]           
              |                  |
              | oop              v
              |-----------> InlineTypeNode (Double256Vector)
                                 |
                                 v
                                [y]
 
 Intermediate Representation for [4]

         [y]
          |
          v
    VectorUnboxNode
          |
          v
     StoreVector

New Transforms for boxing + unboxing optimizations :-
-------------------------------------------------------------

- Unboxing will simply be reduced to the action of fetching the correct VectorIR from its preceding input graph snippet.
- In the context where boxing is needed, we will bank process_inline_types node for buffering 

   Q. Do we have sufficient infrastructure for lazy buffering during process_inline_types in the downstream flow?
   A. No, buffering is done upfront as it needs precise memory and control edges. Currently, the compiler performs eager buffering 
        in scenarios that mandate non-scalarized forms of value objects. i.e. non-flat field assignment or passing 
        value type arguments when InlineTypePassFieldsAsArgs is not set.
       
     Q. What if we do upfront buffering of InlineTypeNode corresponding to vector boxes ?
     A. A buffer and its associated InlineTypeNode must be in sync all the time. Any field update of a value object creates a new value. This can only be achieved through a new value instance allocation i.e., it must go through an intermediate larval state. All the fields of a value instance are final; thus, we cannot use putfield to update their contents, getfield does return the initializing value of the value instance field.
         
        MyValue (value type)
            - float f1;
            - float f2;
            - float f3;
            - float f4;

        val1 = new MyValue(0.0f, 1.0f, 2.0f, 3.0f);
            -->  new MyValue (oop)
                  |
                  --> make_from_oop(oop) post construction

        val2 = new MyValue(val1.f1, 2.0f, val1.f3, val1.f4)  // getfield val1.f1 will pass 0.0f
                  |                                          // getfield val1.f3 will pass 2.0f
                  |                                          // getfield val1.f4 will pass 3.0f
                  |                                          
                  --> make_from_oop(oop) post construction
                        
        return val2.f1 + val2.f2; will return 0.0f + 2.0f, thus there will be no consumer of InlineTypeNodes, and they will be swept 
        out along with their allocations. 

      Q. In the new code model, is an InlineTypeNode always backed by an allocation?
      A. An inline type node is created from initializing this pointer passed as Parma0 of the constructor, unless it's created through make_from_multi, i.e., from scalarize arguments parameters. 


(gdb) l
889         if (cg->method()->is_object_constructor() && receiver != nullptr && gvn().type(receiver)->is_inlinetypeptr()) {
890           InlineTypeNode* non_larval = InlineTypeNode::make_from_oop(this, receiver, gvn().type(receiver)->inline_klass());
891           // Relinquish the oop input, we will delay the allocation to the point it is needed, see the
892           // comments in InlineTypeNode::Ideal for more details
893           non_larval = non_larval->clone_if_required(&gvn(), nullptr);
894           non_larval->set_oop(gvn(), null());
895           non_larval->set_is_buffered(gvn(), false);
896           non_larval = gvn().transform(non_larval)->as_InlineType();
897           map()->replace_edge(receiver, non_larval);
898         }


     
  [Action Item] 
        -Try to always link the backing oop to the newly scalarized InlineTypeNode, since the new code model always creates
          a new larval value on every field modification, hence, oop and scalarized nodes are always in sync.

  [Results] 
         Working on standalone tests, need to regress through the performance and validation suite.
            - Functional validation is almost fine.
            - Also, most of the InlineTypeNode are swept out unless there is any specific context that needs a materialized
              value.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1688#issuecomment-3640741548

From jbhateja at openjdk.org  Wed Dec 17 17:41:09 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 17 Dec 2025 17:41:09 GMT
Subject: [lworld+vector] Integrated: Merge lworld
In-Reply-To: <z7QO1c_tWhPdHtfoiFaPb7FQF1VWSXzhTTGSjxjixfw=.847a13e8-5662-452d-887f-b52d5cbce6b2@github.com>
References: <z7QO1c_tWhPdHtfoiFaPb7FQF1VWSXzhTTGSjxjixfw=.847a13e8-5662-452d-887f-b52d5cbce6b2@github.com>
Message-ID: <wciK4xhX_pd3HRtGCnA0B0xrjPj91Ee_2fhAPRxMNEg=.df72d26d-0077-4212-899b-5a3469acc27d@github.com>

On Tue, 21 Oct 2025 01:27:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Merge from lworld in lworld+vector branch.
> 
> Apart from the usual merge conflict resolution, the patch also contains bug fixes for some special handling around multifields.
> To segregate the code changes and maintain the history[1][2][3][4][5], these bug fixes were initially checked into a temporary private merge branch and are now part of the merge. 
> 
> 
> [1] Special copy constructor used for initializing base and synthetic multifields 
>     https://github.com/jatin-bhateja/valhalla/commit/0fe3153e79251fe661ea1bd368472f2f75cb360d
> [2] Fix ciField population for multifields 
>     https://github.com/jatin-bhateja/valhalla/commit/4a26aff14801e010ea238e8d5a52a52465c6f849
> [3] Multifield handling during type domain buildup
>      https://github.com/jatin-bhateja/valhalla/commit/74ca0245c5d9f5eb186baa962e11d3f5c8f4ed35
> [4] prevent store forwarding across CPU memory barrier
>      https://github.com/jatin-bhateja/valhalla/commit/cfc71acd89b2e3233d788565f1cf1061651a70f9
> [5] Fix to accommodate additional padding during offset computation of multifields
>      https://github.com/jatin-bhateja/valhalla/commit/75ec6296531839ab375efa58b909827269994449
> 
> After latest merge, all the VectorAPI and Valhalla JTREG tests are passing with -XX:-UseNonAtomicValueFlattening at
> variaous AVX levels. With -XX:+UseNonAtomicValueFlattening there are some failures which will be addressed post
> merge commit.

This pull request has now been integrated.

Changeset: 428bd1cc
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/428bd1cc0ea8b4abd63eaf42fb9021eb7146f481
Stats:     1324648 lines in 14000 files changed: 740418 ins; 464506 del; 119724 mod

Merge

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

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

From rriggs at openjdk.org  Wed Dec 17 17:42:26 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Dec 2025 17:42:26 GMT
Subject: [lworld] RFR: 8373896: [lworld] Remove now-dead preview patching
 code
In-Reply-To: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
References: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
Message-ID: <m29KyIAtAtIrcpFOi0JnA-czHQYSEoOEOvYejT_Cu1Y=.a45354af-a3aa-492e-bc5c-e81befed856c@github.com>

On Wed, 17 Dec 2025 16:55:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing code guarded by now obsolete preview patching property.
> This should be a no-op functionally.
> Some minor tidying around arguments.cpp since now there's no reason to init the jimage file in the module patching code.

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1819#pullrequestreview-3588855224

From duke at openjdk.org  Wed Dec 17 17:51:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 17:51:14 GMT
Subject: [lworld] RFR: 8373896: [lworld] Remove now-dead preview patching
 code
In-Reply-To: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
References: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
Message-ID: <jqttsqJ17tfDb1Pvw96EKOHviFMl0QqCM8oZGe8U6JY=.4828072c-d21f-4fd1-8583-73c746c6d850@github.com>

On Wed, 17 Dec 2025 16:55:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing code guarded by now obsolete preview patching property.
> This should be a no-op functionally.
> Some minor tidying around arguments.cpp since now there's no reason to init the jimage file in the module patching code.

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

> 56:  * @build tests.* jdk.test.lib.process.OutputAnalyzer
> 57:  *        jdk.test.lib.process.ProcessTools
> 58:  * @run main/othervm/timeout=1200 -ea -esa -DDISABLE_PREVIEW_PATCHING=false -Xmx1g PackagedModulesVsRuntimeImageLinkTest

Not 100% sure why this was explicitly leaving patching on, but it passes locally.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1819#discussion_r2627919939

From duke at openjdk.org  Wed Dec 17 17:54:05 2025
From: duke at openjdk.org (duke)
Date: Wed, 17 Dec 2025 17:54:05 GMT
Subject: [lworld] RFR: 8373896: [lworld] Remove now-dead preview patching
 code
In-Reply-To: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
References: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
Message-ID: <E-y77bQrcXdtvqfBNcw5Ba8_nP2NG6Lmhf71QYO54gE=.ecd61876-9f2b-4828-8f85-992b98fe63a4@github.com>

On Wed, 17 Dec 2025 16:55:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing code guarded by now obsolete preview patching property.
> This should be a no-op functionally.
> Some minor tidying around arguments.cpp since now there's no reason to init the jimage file in the module patching code.

@david-beaumont 
Your change (at version 25bafcda15292671afc54c75dd508dd35117b780) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1819#issuecomment-3666499566

From stefank at openjdk.org  Wed Dec 17 18:43:41 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 17 Dec 2025 18:43:41 GMT
Subject: [lworld] RFR: 8373510: [lworld] Remove dead code in
 ConstantPool::klass_at_impl()
In-Reply-To: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
References: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
Message-ID: <ljxgQNp2TZ4W1kAtIVaANpo8QeYtnoPxA6FktZgwPrI=.2c1e9b81-a374-452d-8013-04a02679b790@github.com>

On Thu, 11 Dec 2025 16:45:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of dead code in `ConstantPool::klass_at_impl`. The first is about the local `inline_type_signature` that is never written to after initialization, and the default value just disables some code, the other is an `else if` condition that is subsumed by the previous `if`.
> 
> Testing: local compilation,:hotspot_valhalla does not show additional failures
> 
> Thanks,
>   Thomas

Looks good to me.

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

Marked as reviewed by stefank (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1788#pullrequestreview-3589138084

From coleenp at openjdk.org  Wed Dec 17 18:45:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 17 Dec 2025 18:45:44 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping [v4]
In-Reply-To: <ynpRCH_knjaQLRO_8spIX0dA09iIKDo37-e4JEOJoV8=.5e8598fa-8e0c-4733-87d8-b54a158da4aa@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
 <ynpRCH_knjaQLRO_8spIX0dA09iIKDo37-e4JEOJoV8=.5e8598fa-8e0c-4733-87d8-b54a158da4aa@github.com>
Message-ID: <wmJwhTHL8W4rTQnYKNHXZeenacC5Yl5FbM3T9rXRMM4=.8a248b14-b2d0-4010-840f-b945d1e36646@github.com>

On Wed, 17 Dec 2025 17:19:09 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
>> 
>> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Un-problem listed test

Looks good! I've been testing with this so have also verified this change.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1757#pullrequestreview-3589148825

From phubner at openjdk.org  Wed Dec 17 18:49:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 17 Dec 2025 18:49:50 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v3]
In-Reply-To: <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
Message-ID: <NTSBw3z4JdOk4Wwnq0Cn4X1VK6tj6WTxcjPi86AhF6I=.908b7570-51df-40e5-908f-c8a7e6e7b5eb@github.com>

On Wed, 17 Dec 2025 16:22:05 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for large primitive only flat arrays
>  - Assert fixes

Looks good, thanks for adding the test.

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

Marked as reviewed by phubner (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1811#pullrequestreview-3589163013

From fparain at openjdk.org  Wed Dec 17 19:14:28 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 17 Dec 2025 19:14:28 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping [v4]
In-Reply-To: <ynpRCH_knjaQLRO_8spIX0dA09iIKDo37-e4JEOJoV8=.5e8598fa-8e0c-4733-87d8-b54a158da4aa@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
 <ynpRCH_knjaQLRO_8spIX0dA09iIKDo37-e4JEOJoV8=.5e8598fa-8e0c-4733-87d8-b54a158da4aa@github.com>
Message-ID: <Bx88X0DygB9w6yQxpwrpq0_yJCEY7WP_WtE9EfH-LQA=.dc2743e8-8320-4294-962d-6e5590c4d814@github.com>

On Wed, 17 Dec 2025 17:19:09 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
>> 
>> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Un-problem listed test

LGTM

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1757#pullrequestreview-3589267519

From jlahoda at openjdk.org  Wed Dec 17 19:20:09 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Dec 2025 19:20:09 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change [v2]
In-Reply-To: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
Message-ID: <bnPmqZ2acmK9ZaUQxYlMLFbP8FHrZXqyUs6_ImHIKdI=.25a72188-e7da-4d00-b244-dfe0df643bb0@github.com>

> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
> 
> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)

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

 - Removing flags that are no longer necessary.
 - Removing tests from problem list.
 - Merge remote-tracking branch 'upstream-ssh/lworld' into JDK-8373828
 - Fixing test when running with -DDISABLE_PREVIEW_PATCHING=true (and forcing a run with this option).

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1813/files
  - new: https://git.openjdk.org/valhalla/pull/1813/files/eb89a424..e37fa48b

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

  Stats: 486 lines in 80 files changed: 221 ins; 99 del; 166 mod
  Patch: https://git.openjdk.org/valhalla/pull/1813.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1813/head:pull/1813

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

From jlahoda at openjdk.org  Wed Dec 17 19:20:11 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 17 Dec 2025 19:20:11 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change
In-Reply-To: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
Message-ID: <6FasbV0w3jm5D_cPcmJ8ukfHDlsoG29p9EN80VaHXnM=.4deadf01-1a59-41cc-873c-11aee0a12483@github.com>

On Wed, 17 Dec 2025 13:33:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
> 
> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)

Thanks - I've update the patch:
- removed the tests from the problem lists
- removed the no-longer necessary flags

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

PR Comment: https://git.openjdk.org/valhalla/pull/1813#issuecomment-3666797128

From matsaave at openjdk.org  Wed Dec 17 19:22:41 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Dec 2025 19:22:41 GMT
Subject: [lworld] RFR: 8370904: [lworld] Enable CDS heap dumping [v4]
In-Reply-To: <wmJwhTHL8W4rTQnYKNHXZeenacC5Yl5FbM3T9rXRMM4=.8a248b14-b2d0-4010-840f-b945d1e36646@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
 <ynpRCH_knjaQLRO_8spIX0dA09iIKDo37-e4JEOJoV8=.5e8598fa-8e0c-4733-87d8-b54a158da4aa@github.com>
 <wmJwhTHL8W4rTQnYKNHXZeenacC5Yl5FbM3T9rXRMM4=.8a248b14-b2d0-4010-840f-b945d1e36646@github.com>
Message-ID: <9tY46Pjeg4osFiBVb3FJF93xMHFCWiyg42Q84KQEDyY=.7fe29abb-a8a3-4c0b-b804-ac9b1641d28b@github.com>

On Wed, 17 Dec 2025 18:43:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Un-problem listed test
>
> Looks good! I've been testing with this so have also verified this change.

Thanks for the reviews @coleenp and @fparain!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1757#issuecomment-3666808873

From matsaave at openjdk.org  Wed Dec 17 19:22:43 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 17 Dec 2025 19:22:43 GMT
Subject: [lworld] Integrated: 8370904: [lworld] Enable CDS heap dumping
In-Reply-To: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
References: <dmmVieQX_IHsaKVl5F6l9KfHn4_6bZ6wVcKmuq3Fk7g=.b470e18c-4cf5-4fb0-9c00-ab4b103b8c30@github.com>
Message-ID: <RBHTI87G_kgHG3F_9Wd-4IRkfRXcS3V8ELwsTHE_wtY=.a169b767-5b9e-4c17-b5b5-958141b4b70f@github.com>

On Fri, 21 Nov 2025 18:49:25 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> CDS heap dumping was manually disabled in lworld due to the method in which the migrated value classes were added to the JDK. Migrated value classes were added through module patching which is incompatible with CDS heap dumping, but now since they are added through jimage, we can re-enable CDS heap dumping and related features that rely on it.
> 
> AOT adds some complexity to this as it loads and links classes in VM startup, so alternate code paths need to be considered. Signature calling conventions are stored in adapters which are archived in the AOT code cache, but they aren't usable at runtime, so they need to be regenerated even if we don't regenerate the adapters.

This pull request has now been integrated.

Changeset: 9eead93b
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/9eead93b026ccf011cc9cdda8abe5b02dab86ed0
Stats:     70 lines in 9 files changed: 37 ins; 29 del; 4 mod

8370904: [lworld] Enable CDS heap dumping

Reviewed-by: coleenp, fparain

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

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

From duke at openjdk.org  Wed Dec 17 19:50:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 17 Dec 2025 19:50:08 GMT
Subject: [lworld] Integrated: 8373896: [lworld] Remove now-dead preview
 patching code
In-Reply-To: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
References: <wO4qBwBwiONMhIwkaDlvVOhEZTM-vuzK-Qfcb2-Rz8o=.03c822f2-ca29-4182-bd48-278d19b15620@github.com>
Message-ID: <2pKK6YYuygCmCTFX3OFAfbwz4GSw9yoX1asUFAOdxek=.5aa03cbd-10ca-4209-962f-a8e98c822027@github.com>

On Wed, 17 Dec 2025 16:55:15 GMT, David Beaumont <duke at openjdk.org> wrote:

> Removing code guarded by now obsolete preview patching property.
> This should be a no-op functionally.
> Some minor tidying around arguments.cpp since now there's no reason to init the jimage file in the module patching code.

This pull request has now been integrated.

Changeset: db91a9fb
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/db91a9fbcce4444a5d96b15a483f5af379f08f5f
Stats:     124 lines in 9 files changed: 2 ins; 112 del; 10 mod

8373896: [lworld] Remove now-dead preview patching code

Reviewed-by: rriggs

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

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

From rriggs at openjdk.org  Wed Dec 17 20:14:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 Dec 2025 20:14:51 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change [v2]
In-Reply-To: <bnPmqZ2acmK9ZaUQxYlMLFbP8FHrZXqyUs6_ImHIKdI=.25a72188-e7da-4d00-b244-dfe0df643bb0@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
 <bnPmqZ2acmK9ZaUQxYlMLFbP8FHrZXqyUs6_ImHIKdI=.25a72188-e7da-4d00-b244-dfe0df643bb0@github.com>
Message-ID: <Ibatvz0lIC9xMId6ONc8cWoxgfulajDTiN_lCztjj88=.fafcc549-ea76-46ba-9110-c29426dd0179@github.com>

On Wed, 17 Dec 2025 19:20:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
>> 
>> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Removing flags that are no longer necessary.
>  - Removing tests from problem list.
>  - Merge remote-tracking branch 'upstream-ssh/lworld' into JDK-8373828
>  - Fixing test when running with -DDISABLE_PREVIEW_PATCHING=true (and forcing a run with this option).

Looks good.  Thanks

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1813#pullrequestreview-3589466460

From coleenp at openjdk.org  Thu Dec 18 01:29:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 01:29:48 GMT
Subject: [lworld] RFR: 8373912: [lworld] Small cleanups to InlineKlass [v2]
In-Reply-To: <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>
References: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
 <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>
Message-ID: <Pm72pOhmtfIxwj5neBqPg-3Uvd3rS12eiLM8veCCl9c=.c4840ce6-650e-4e11-a1eb-0cc1de3182cf@github.com>

On Wed, 17 Dec 2025 17:21:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> A few cleanups found while scanning over the InlineKlass files:
>> 
>> * Fix include list and forward declarations
>> * Move non-trivial implementation out of .hpp
>> * Remove copy-n-past functions from InstanceKlass
>> * Remove redundant CDS function overrides
>> * Deduplicate null marker address calculation
>> * Deduplicate allocate_instance
>> * Fix raw casts from oop 
>> * Tweak comments
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove lingering references to InlineKlassFixedBlock

This looks good.  Thank you for the cleanups.

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1818#pullrequestreview-3590298541

From dsimms at openjdk.org  Thu Dec 18 03:38:17 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Dec 2025 03:38:17 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <JkDbLg9aoBVbSpVBADr-fhH9n7Pa1oVaeLTG3lhw7yQ=.1b1b7c23-1001-4ede-a55d-7ddebe88a62d@github.com>

Merge jdk-27+1

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

Commit messages:
 - Merge branch 'lworld' into lworld_merge_jdk_27_1
 - Version flick
 - Merge jdk
 - 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods
 - 8370890: Start of release updates for JDK 27

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

Changes: https://git.openjdk.org/valhalla/pull/1821/files
  Stats: 1562 lines in 92 files changed: 1201 ins; 90 del; 271 mod
  Patch: https://git.openjdk.org/valhalla/pull/1821.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1821/head:pull/1821

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

From vromero at openjdk.org  Thu Dec 18 05:33:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 05:33:03 GMT
Subject: Integrated: 8373953: [bworld] Undo inference changes lub and glb
In-Reply-To: <Lc1eAVXp1Rwwss-Cvt7cVhYADmO3lN7ZIVeqNPi6hec=.7c3537d5-c840-42e2-b6e6-f1b623601a5a@github.com>
References: <Lc1eAVXp1Rwwss-Cvt7cVhYADmO3lN7ZIVeqNPi6hec=.7c3537d5-c840-42e2-b6e6-f1b623601a5a@github.com>
Message-ID: <T6bAkJmxUc0V5AHNPbgVfN5CUedM7cicIKrfz3JcMpE=.60868bc6-3846-4cf6-ac4e-1407e007c6cf@github.com>

On Thu, 18 Dec 2025 05:24:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> remove special support for non-nullable types in lub and gbl

This pull request has now been integrated.

Changeset: 4a3cf282
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4a3cf2827a1058c504323abe7c3096a84d8406e6
Stats:     15 lines in 1 file changed: 0 ins; 9 del; 6 mod

8373953: [bworld] Undo inference changes lub and glb

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

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

From vromero at openjdk.org  Thu Dec 18 05:33:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 05:33:03 GMT
Subject: Integrated: 8373953: [bworld] Undo inference changes lub and glb
Message-ID: <Lc1eAVXp1Rwwss-Cvt7cVhYADmO3lN7ZIVeqNPi6hec=.7c3537d5-c840-42e2-b6e6-f1b623601a5a@github.com>

remove special support for non-nullable types in lub and gbl

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

Commit messages:
 - 8373953: [bworld] Undo inference changes lub and glb

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

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

From thartmann at openjdk.org  Thu Dec 18 06:21:27 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 06:21:27 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v11]
In-Reply-To: <kPp9OPZJkdfwKufeVPUt_Ej3uiWuwXTUTX8fxpvVjx0=.8b97a016-3cc1-4cb2-b4b7-4da11bd7aa9a@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <kPp9OPZJkdfwKufeVPUt_Ej3uiWuwXTUTX8fxpvVjx0=.8b97a016-3cc1-4cb2-b4b7-4da11bd7aa9a@github.com>
Message-ID: <tuGSJlBaXwjwRnmWOSxvNCcSnE8H3u0eo0u2mYc3Ex4=.592bed5c-a54d-4411-abd7-c336b8c40f96@github.com>

On Wed, 17 Dec 2025 17:37:56 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:
> 
>   Fix because properties passed into with_properties is not the same as properties() of the result

Testing is all clean now. I let @fparain comment on the runtime changes (he's very busy but promised to have a look).

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

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

From dsimms at openjdk.org  Thu Dec 18 06:42:37 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Dec 2025 06:42:37 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <JkDbLg9aoBVbSpVBADr-fhH9n7Pa1oVaeLTG3lhw7yQ=.1b1b7c23-1001-4ede-a55d-7ddebe88a62d@github.com>
References: <JkDbLg9aoBVbSpVBADr-fhH9n7Pa1oVaeLTG3lhw7yQ=.1b1b7c23-1001-4ede-a55d-7ddebe88a62d@github.com>
Message-ID: <xmYyvvektSkLUQiSIEx-VGwHkv6smee0WyucMd38PSU=.367adbda-a7b5-4601-a0b7-85e5e9153290@github.com>

On Thu, 18 Dec 2025 03:30:59 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-27+1

This pull request has now been integrated.

Changeset: 8be821d7
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8be821d7654fc341370f7677fe7dcf67bdbf8ca8
Stats:     1562 lines in 92 files changed: 1201 ins; 90 del; 271 mod

Merge

Merge jdk-27+1

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

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

From mchevalier at openjdk.org  Thu Dec 18 07:37:25 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 18 Dec 2025 07:37:25 GMT
Subject: [lworld] RFR: 8373844: [lworld] Un-problem list
 ScalarReplacementWithGCBarrierTests.java
In-Reply-To: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
References: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
Message-ID: <a1Vacrh1ls8srhYBhSpWSoC9ROMKPVG10hagh6uwOdg=.448f5a8c-7163-4dd2-897a-cb602f0fa1bd@github.com>

On Wed, 17 Dec 2025 15:26:57 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It was previously fixed in JDK-8372697.
> 
> But I've rested after the fateful removal of EnableValhalla, and it seems to pass. Let's just un-problem list.
> 
> Thanks,
> Marc

Shipped it! Thanks for review @Arraying & @chhagedorn!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1816#issuecomment-3668795962

From mchevalier at openjdk.org  Thu Dec 18 07:37:25 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 18 Dec 2025 07:37:25 GMT
Subject: [lworld] Integrated: 8373844: [lworld] Un-problem list
 ScalarReplacementWithGCBarrierTests.java
In-Reply-To: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
References: <XASn2YsBxGSQZWqIl42UM9n1oE8Ta-l4NUohG9eo6K0=.43131b06-baca-4146-ad84-069d0b8d75aa@github.com>
Message-ID: <H1nzkjobBCOIsmoACZpOzSea0bgAH6FXFDZqWy-PMWg=.3a5e857d-ebbb-43f5-930e-39fb785842eb@github.com>

On Wed, 17 Dec 2025 15:26:57 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> It was previously fixed in JDK-8372697.
> 
> But I've rested after the fateful removal of EnableValhalla, and it seems to pass. Let's just un-problem list.
> 
> Thanks,
> Marc

This pull request has now been integrated.

Changeset: d23b654e
Author:    Marc Chevalier <mchevalier at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d23b654e2e6b446060cfb6151ad83c1db5329cdf
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8373844: [lworld] Un-problem list ScalarReplacementWithGCBarrierTests.java

Reviewed-by: chagedorn, phubner

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

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

From duke at openjdk.org  Thu Dec 18 07:43:17 2025
From: duke at openjdk.org (duke)
Date: Thu, 18 Dec 2025 07:43:17 GMT
Subject: [lworld] RFR: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change [v2]
In-Reply-To: <bnPmqZ2acmK9ZaUQxYlMLFbP8FHrZXqyUs6_ImHIKdI=.25a72188-e7da-4d00-b244-dfe0df643bb0@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
 <bnPmqZ2acmK9ZaUQxYlMLFbP8FHrZXqyUs6_ImHIKdI=.25a72188-e7da-4d00-b244-dfe0df643bb0@github.com>
Message-ID: <2cjYeVJieysCFtfPEguaSbDqJOXkKY3m4IkfjX6qioo=.351ba341-690f-460d-bea8-cc56a5e176ae@github.com>

On Wed, 17 Dec 2025 19:20:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
>> 
>> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Removing flags that are no longer necessary.
>  - Removing tests from problem list.
>  - Merge remote-tracking branch 'upstream-ssh/lworld' into JDK-8373828
>  - Fixing test when running with -DDISABLE_PREVIEW_PATCHING=true (and forcing a run with this option).

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1813#issuecomment-3668819957

From chagedorn at openjdk.org  Thu Dec 18 07:55:18 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 18 Dec 2025 07:55:18 GMT
Subject: [lworld] RFR: 8372917: [lworld] C2 compilation bailout asserts due
 to label in inconsistent state [v2]
In-Reply-To: <gKkAO9dmnBFcL2FeXZ8A0nsbXUbgDZwkO-KI_BcVXos=.6ddc94f3-1a05-4f1f-9a58-4d5e34c24609@github.com>
References: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>
 <gKkAO9dmnBFcL2FeXZ8A0nsbXUbgDZwkO-KI_BcVXos=.6ddc94f3-1a05-4f1f-9a58-4d5e34c24609@github.com>
Message-ID: <En8Mi9d-zhwYLq6A92NfxpwU06coSStAECmufzCiuU4=.30923f55-6ce8-46aa-9dbf-e777150ef142@github.com>

On Wed, 17 Dec 2025 17:32:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When an expected compilation bailout (like 'CodeCache is full') happens during matching, not all nodes might be visited and therefore the Valhalla specific `verified_entry` label might be in inconsistent state (used but not bound). We should simply reset it when we bail out. For more details, see JBS.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Un-problem listing
>  - Merge branch 'lworld' into JDK-8372918
>  - 8372917: [lworld] C2 compilation bailout asserts due to label in inconsistent state

Looks good!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1817#pullrequestreview-3591262334

From thartmann at openjdk.org  Thu Dec 18 08:00:35 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 08:00:35 GMT
Subject: [lworld] RFR: 8372917: [lworld] C2 compilation bailout asserts due
 to label in inconsistent state [v2]
In-Reply-To: <gKkAO9dmnBFcL2FeXZ8A0nsbXUbgDZwkO-KI_BcVXos=.6ddc94f3-1a05-4f1f-9a58-4d5e34c24609@github.com>
References: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>
 <gKkAO9dmnBFcL2FeXZ8A0nsbXUbgDZwkO-KI_BcVXos=.6ddc94f3-1a05-4f1f-9a58-4d5e34c24609@github.com>
Message-ID: <qfKKVCiTIyXd6sRQwnIgKIdfz8MW9nvCJazD-L96HPI=.89e1eac8-4730-499d-8001-5974fe67ac80@github.com>

On Wed, 17 Dec 2025 17:32:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> When an expected compilation bailout (like 'CodeCache is full') happens during matching, not all nodes might be visited and therefore the Valhalla specific `verified_entry` label might be in inconsistent state (used but not bound). We should simply reset it when we bail out. For more details, see JBS.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Un-problem listing
>  - Merge branch 'lworld' into JDK-8372918
>  - 8372917: [lworld] C2 compilation bailout asserts due to label in inconsistent state

Thanks Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1817#issuecomment-3668878359

From thartmann at openjdk.org  Thu Dec 18 08:00:37 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 08:00:37 GMT
Subject: [lworld] Integrated: 8372917: [lworld] C2 compilation bailout asserts
 due to label in inconsistent state
In-Reply-To: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>
References: <Xa41RNDM3zrRem_ZUsKvM1gLfbh4Evl318W2_EzJxPo=.fdc8784f-ff0e-4ecf-bc9c-57e52a895aaa@github.com>
Message-ID: <0kZHaoOAZCXOvpypBQGKQXS4rswa1RsHZFJ7mTQuFyo=.6ca450b3-0f64-415a-a590-f29c7c35914f@github.com>

On Wed, 17 Dec 2025 16:01:22 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When an expected compilation bailout (like 'CodeCache is full') happens during matching, not all nodes might be visited and therefore the Valhalla specific `verified_entry` label might be in inconsistent state (used but not bound). We should simply reset it when we bail out. For more details, see JBS.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 49bff14f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/49bff14fef20d3edb0e8ae5d3d2c40449d248926
Stats:     6 lines in 2 files changed: 5 ins; 1 del; 0 mod

8372917: [lworld] C2 compilation bailout asserts due to label in inconsistent state

Reviewed-by: chagedorn

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

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

From mchevalier at openjdk.org  Thu Dec 18 08:35:22 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 18 Dec 2025 08:35:22 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996
Message-ID: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>

Let's proceed piece by piece.

# `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp`

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220

`push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are.

But let's dig a bit, that will be useful later!


   push_call_clobbered_registers()
=> push_call_clobbered_registers_except(exclude = empty set)
=> push(call_clobbered_gp_registers() - exclude, sp)  // with exclude = empty set

So, we save at least `call_clobbered_gp_registers` which is defined as:

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620

So, we save r0-r7 and r10-r17

# `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp`

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124

Digging the history looks like it still makes sense, it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.

# `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_x86.cpp`

Same as before. But it's not even guarantee that `InlineTypePassFieldsAsArgs` is true. We can have such a backtrace:

CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
do_oop_store (templateTable_x86.cpp:148)
(called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))

where the last give `r8` for `tmp3`. It is not quite clear to me why we don't have a problem in mainline, because it looks like corrupting address base register is a bad idea given that we use it after.

# `MacroAssembler::unpack_inline_helper` in `macroAssembler_aarch64.cpp`

## First part
https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7163-L7166

Yes, these registers are saved, as we saw above! I've added some asserts to make sure that they are still in the `call_clobbered_gp_registers()` set. But it seems a bit redundant: that's what clobber are, registers that we cannot trust to be kept. If we use a register not in this set, the native callee shouldn't touch it. Better safe than sorry?

## Second Part

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7269-L7271

This is fine.

Indeed, we might reset the stream just before, but then we exhaust it in the loop.
https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7251-L7262

This is already what we do before:
https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7182-L7183
(and this loop has no break).

So entering the if and running the second reset will just leave the stream in the same state.

About this piece, I also took the liberty of changing a tiny bit the ctor of `ScalarizedInlineArgsStream` as this class was not correct if `step` is not 1 or -1. We could also have fixed it by changing the line 79 in
https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/share/runtime/signature_cc.hpp#L75-L81
with `_depth = abs(_step)`, but that looks like a recipe for a less explicit constructor, and more obscure code for a feature that is not desirable (skipping elements).

# `gen_c2i_adapter` in `sharedRuntime_aarch64.cpp`

## First part

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L623-L633

After some digging, the comment about r13 doesn't seem correct to me. I've changed it.

The second part is again about trusting `push_call_clobbered_registers` to push enough things. I've added some asserts again.

## Second part

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#L645-L647

Yes, but we save too much. `save_live_registers` calls `push_CPU_state(_save_vectors, ...)` defined there:
https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3649-L3673

It will always save registers r0-r29, but also the floating point registers. The difference is that with `save_vectors`, we save the whole vectors, while without `save_vectors`, we save only 1 word (8 bytes) per float register (4 words for 4 registers). So, the question is whether we use more that the lower word of each register for arguments, and... I'm not sure. We can keep saving them as it consumes only a bit of stack space, but it runs the same amount of instructions as not saving them.

But I said we save too much, that's because we will save v0-v31 (or pieces of) anyway, while `c_farg*` and `j_farg*` are only the registers v0-v7. If I understand well, in this context (we are generating an adapter), around a call (for instance to allocate a buffer) we need to save only the registers that are relevant for the calling convention, like the ones that can hold arguments. If the register v25 (for instance) contained something useful for the caller, it should have been saved by the caller before doing the call, and so before entering the adapter. Since v25 is not used by the adapter or the calling convention, we don't need to save it. Is it worth refining `save_live_registers`?

# `gen_c2i_adapter` in `sharedRuntime_x86_64.cpp`

The x86 version of the last thing:
https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L918-L921

`/*save_vectors*/` is actually `save_wide_vectors`. `save_live_registers` calls `push_FPU_state` anyway which does `fxsave`, which saves XMM0-XMM15. If `save_wide_vectors`, then `save_live_registers` makes sure to save all of ZMM (the rest of ZMM0-ZMM15, as well as the others ZMM). `c_farg*` and `j_farg*` are defined as xmm0-xmm7. XMM registers are already 128 bits (that's 16 bytes), so if we are not using the rest of zmm registers for arguments, it should be fine. Unlike on Aarch64, saving setting `save_wide_vectors` to `true` would create a lot more instructions: only one `fxsave` is enough for the xmm0-15, but the rest must be saved a lot more manually, once piece at a time.

While we probably are good with "only" 16 bytes saved, we need to save only what is used in the calling convention and in the adapter, so my guess would be that we actually only need to save xmm0-xmm7. I'm not sure it's worth improving `save_live_registers` since saving xmm0-xmm15 is done in a single instruction, we would trade a little of stack space for quite a lot more instructions. Maybe it's just fine to over-save.

# `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_x86`

https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp#L238-L255

This branch was introduced in 4c3231c "Merge tag 'jdk-20+8' into lworld" on 2022-08-31.

The non-Valhalla side:
- was introduced in 9583e36 (8284161: Implementation of Virtual Threads (Preview)) on 2022-05-07
- to replace what a `push_set` from eb4849e (8283327: Add methods to save/restore registers when calling into the VM from C1/interpreter barrier code) on 2022-03-21
- that was itself replacing a few `push` from 2a0986b8 (8199417: Modularize interpreter GC barriers) on 2018-04-11 (which introduced the whole code)

The Valhalla side:
- saving the `j_farg*` was added in 2455c8ed (8251398: [lworld] TestCallingConvention::test36 spuriously fails due to incorrect field value) on 2020-08-11
- the `pusha` comes from d9f3aaa9 (8242210: [lworld] TestCallingConvention::test36 spuriously fails) on 2020-04-09
- which placed the code from 2a0986b8 (8199417: Modularize interpreter GC barriers) mentioned before.

So it seems the merge jdk was done in a very conservative way, keeping both sides that evolved separately. Yet, the Valhalla side is probably overkill.


   push_call_clobbered_registers(save_fpu = true)
=> push_call_clobbered_registers(exlude = empty set, save_fpu = true)
=> push_set(call_clobbered_xmm_registers(), gp_area_size) if save_fpu


`call_clobbered_xmm_registers()` is all the xmm on all os, except on windows where it's xmm0-xmm5 + xmm16-xmm_max. That covers the `c_farg*` (since on windows it only goes from 0 to 3), but it doesn't cover the `j_farg*` (that are from 0 to 7, even on windows). But on Windows, only xmm0-xmm5 are considered volatile (clobbers). Since we are calling a native function, it should be fine (that is `call_clobbered_xmm_registers()` and its comment are correct).

Thanks,
Marc

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

Commit messages:
 - Merge remote-tracking branch 'origin/lworld' into JDK-8366717.investigate
 - oop_store_at
 - assert in oop_store_at
 - Cleanup
 - Experimenting g1_write_barrier_pre
 - gen_c2i_adapter
 - unpack_inline_helper
 - Actually no
 - Try the thing in oop_store_at
 - Asserting
 - ... and 2 more: https://git.openjdk.org/valhalla/compare/619ef43b...3f013c81

Changes: https://git.openjdk.org/valhalla/pull/1824/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1824&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366717
  Stats: 72 lines in 9 files changed: 17 ins; 39 del; 16 mod
  Patch: https://git.openjdk.org/valhalla/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1824/head:pull/1824

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

From tschatzl at openjdk.org  Thu Dec 18 08:55:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 18 Dec 2025 08:55:49 GMT
Subject: [lworld] RFR: 8373510: [lworld] Remove dead code in
 ConstantPool::klass_at_impl()
In-Reply-To: <Teg_zg7SQy3PyPbt7VdtUFB4xEbGelWrwHuQbWNXS6o=.309f198c-daae-4ba1-bae2-5b70aef0cc62@github.com>
References: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
 <Teg_zg7SQy3PyPbt7VdtUFB4xEbGelWrwHuQbWNXS6o=.309f198c-daae-4ba1-bae2-5b70aef0cc62@github.com>
Message-ID: <FjSOXJhCdy7vf0YALvflHzvQwrnLgRSPyVm5ItHHUXw=.dc47733d-345f-4ed3-842e-071f441a742c@github.com>

On Fri, 12 Dec 2025 16:45:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this removal of dead code in `ConstantPool::klass_at_impl`. The first is about the local `inline_type_signature` that is never written to after initialization, and the default value just disables some code, the other is an `else if` condition that is subsumed by the previous `if`.
>> 
>> Testing: local compilation,:hotspot_valhalla does not show additional failures
>> 
>> Thanks,
>>   Thomas
>
> Looks good to me.
> Thank you.

Thanks @fparain @stefank for your reviews

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

PR Comment: https://git.openjdk.org/valhalla/pull/1788#issuecomment-3669163698

From duke at openjdk.org  Thu Dec 18 08:58:49 2025
From: duke at openjdk.org (duke)
Date: Thu, 18 Dec 2025 08:58:49 GMT
Subject: [lworld] RFR: 8373510: [lworld] Remove dead code in
 ConstantPool::klass_at_impl()
In-Reply-To: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
References: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
Message-ID: <hvRgHNkkG1SMDjwQjpNQtve39XfLby4NDhgbzkXD1-U=.84aab7f5-412b-4132-8b4e-664e5f582155@github.com>

On Thu, 11 Dec 2025 16:45:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of dead code in `ConstantPool::klass_at_impl`. The first is about the local `inline_type_signature` that is never written to after initialization, and the default value just disables some code, the other is an `else if` condition that is subsumed by the previous `if`.
> 
> Testing: local compilation,:hotspot_valhalla does not show additional failures
> 
> Thanks,
>   Thomas

@tschatzl 
Your change (at version 894645d99264c39c87212c199001a154482235fd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1788#issuecomment-3669173516

From stefank at openjdk.org  Thu Dec 18 11:02:19 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Dec 2025 11:02:19 GMT
Subject: [lworld] RFR: 8373912: [lworld] Small cleanups to InlineKlass [v2]
In-Reply-To: <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>
References: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
 <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>
Message-ID: <ZTC5wHE5KACVii19kitns24tTrjJBundOp_rJLfSzqk=.5a07fc34-174e-49af-9303-71e66d5906fc@github.com>

On Wed, 17 Dec 2025 17:21:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> A few cleanups found while scanning over the InlineKlass files:
>> 
>> * Fix include list and forward declarations
>> * Move non-trivial implementation out of .hpp
>> * Remove copy-n-past functions from InstanceKlass
>> * Remove redundant CDS function overrides
>> * Deduplicate null marker address calculation
>> * Deduplicate allocate_instance
>> * Fix raw casts from oop 
>> * Tweak comments
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove lingering references to InlineKlassFixedBlock

Thanks for the review, Coleen! Tier1 passes.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1818#issuecomment-3669698318

From duke at openjdk.org  Thu Dec 18 11:02:20 2025
From: duke at openjdk.org (duke)
Date: Thu, 18 Dec 2025 11:02:20 GMT
Subject: [lworld] RFR: 8373912: [lworld] Small cleanups to InlineKlass [v2]
In-Reply-To: <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>
References: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
 <tBDf9XdB1m1FRTkvLZzzNu3aGnZo2aw33DAXZDv751s=.c9569b1c-d715-406b-bde7-43b3ee092be4@github.com>
Message-ID: <aGOuHlc_Ok51BBoQlbKMMNtpIkJeJIxQnnSblQbc_x8=.014d92e8-2f91-42a5-b9b5-d2f6c24a74f2@github.com>

On Wed, 17 Dec 2025 17:21:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> A few cleanups found while scanning over the InlineKlass files:
>> 
>> * Fix include list and forward declarations
>> * Move non-trivial implementation out of .hpp
>> * Remove copy-n-past functions from InstanceKlass
>> * Remove redundant CDS function overrides
>> * Deduplicate null marker address calculation
>> * Deduplicate allocate_instance
>> * Fix raw casts from oop 
>> * Tweak comments
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove lingering references to InlineKlassFixedBlock

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1818#issuecomment-3669707150

From thartmann at openjdk.org  Thu Dec 18 11:46:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 11:46:56 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability check in
 C2
Message-ID: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>

C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.

This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.

When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.

Testing: tier1-tier6 + valhalla-comp-stress

Thanks,
Tobias

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

Commit messages:
 - More refactoring, better comments
 - More comments, removing workaround
 - Merge
 - v5
 - Refactoring v4
 - Refactoring v3
 - Refactoring, more checks, new test
 - Merge branch 'lworld' into JDK-8228362
 - All tests pass
 - Diagnostic printing
 - ... and 10 more: https://git.openjdk.org/valhalla/compare/9eead93b...4d711c87

Changes: https://git.openjdk.org/valhalla/pull/1823/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1823&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8228361
  Stats: 1503 lines in 30 files changed: 1266 ins; 106 del; 131 mod
  Patch: https://git.openjdk.org/valhalla/pull/1823.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1823/head:pull/1823

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

From dsimms at openjdk.org  Thu Dec 18 12:02:24 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Dec 2025 12:02:24 GMT
Subject: [lworld] Integrated: Merge jdk
Message-ID: <5VkWC5IFYL19FB5n4-gwLYBllRWCPdCs0WteEFhaY_Y=.63870f2a-c0ab-48a5-9951-ee1fee03d0ae@github.com>

Merge jdk-27+2

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

Commit messages:
 - Adjust testing
 - Still need Klass::is_identity_class(), now virtual call
 - StrongDependency -> DependencyType::NonFloatingNarrowing
 - Merge tag 'jdk-27+2' into lworld_merge_jdk_27_2
 - 8371718: (sc) Channels.new{Input,Output}Stream can allocate unbounded memory for a socket channel
 - 8334549: [Sound] Test timed out: javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
 - 8369736: Add management interface for AOT cache creation
 - 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated
 - 8373362: Http3TestServer should not log an exception stack trace when it is stopping normally
 - 8373335: Serial: Clean up SerialHeap members by access specifies
 - ... and 65 more: https://git.openjdk.org/valhalla/compare/8be821d7...c9279ddf

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

Changes: https://git.openjdk.org/valhalla/pull/1825/files
  Stats: 26081 lines in 256 files changed: 17423 ins; 7502 del; 1156 mod
  Patch: https://git.openjdk.org/valhalla/pull/1825.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1825/head:pull/1825

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

From dsimms at openjdk.org  Thu Dec 18 12:02:24 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Dec 2025 12:02:24 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <5VkWC5IFYL19FB5n4-gwLYBllRWCPdCs0WteEFhaY_Y=.63870f2a-c0ab-48a5-9951-ee1fee03d0ae@github.com>
References: <5VkWC5IFYL19FB5n4-gwLYBllRWCPdCs0WteEFhaY_Y=.63870f2a-c0ab-48a5-9951-ee1fee03d0ae@github.com>
Message-ID: <GU-qTpCLgGgDwutujiabtJuLsvp9HkWAojhDq4DrKHg=.61e4059e-88b7-4681-ba22-72f572188b79@github.com>

On Thu, 18 Dec 2025 11:53:54 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-27+2

This pull request has now been integrated.

Changeset: b9de628e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b9de628e0c1e0536c056145454db480bfb8a4bd4
Stats:     26081 lines in 256 files changed: 17423 ins; 7502 del; 1156 mod

Merge

Merge jdk-27+2

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

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

From tschatzl at openjdk.org  Thu Dec 18 12:09:10 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 18 Dec 2025 12:09:10 GMT
Subject: [lworld] Integrated: 8373510: [lworld] Remove dead code in
 ConstantPool::klass_at_impl()
In-Reply-To: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
References: <9OAeLp7iU0DfxQ1hhSEd6fNOEvpWqDFk5XwjBO7ZYVM=.8659924f-7626-4e0a-a0c8-7a2a882a32ee@github.com>
Message-ID: <jkrwuoC6fhaZtJjRKf1Ib7J_AVOXTRDp2g6B9l9Q7QU=.0df24272-f0e9-4f7c-aba4-c9cef3061322@github.com>

On Thu, 11 Dec 2025 16:45:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this removal of dead code in `ConstantPool::klass_at_impl`. The first is about the local `inline_type_signature` that is never written to after initialization, and the default value just disables some code, the other is an `else if` condition that is subsumed by the previous `if`.
> 
> Testing: local compilation,:hotspot_valhalla does not show additional failures
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: cd7c36e7
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/cd7c36e72da82c55050d0087b053a4b131f5bd00
Stats:     25 lines in 1 file changed: 1 ins; 19 del; 5 mod

8373510: [lworld] Remove dead code in ConstantPool::klass_at_impl()

Reviewed-by: fparain, stefank

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

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

From stefank at openjdk.org  Thu Dec 18 12:11:25 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Dec 2025 12:11:25 GMT
Subject: [lworld] Integrated: 8373912: [lworld] Small cleanups to InlineKlass
In-Reply-To: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
References: <J2Jnh10TossLDRkB8k_kbuCEDLAAiER33895_6L3Zns=.22e87e5d-d019-41e7-964e-92925fef0cff@github.com>
Message-ID: <SUf3cR9qP1DoHT4z_Opwp9d2I64ZQns5QGLDTOp5ByA=.114fe8e7-b18b-4073-971d-092d0e080153@github.com>

On Wed, 17 Dec 2025 16:34:06 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> A few cleanups found while scanning over the InlineKlass files:
> 
> * Fix include list and forward declarations
> * Move non-trivial implementation out of .hpp
> * Remove copy-n-past functions from InstanceKlass
> * Remove redundant CDS function overrides
> * Deduplicate null marker address calculation
> * Deduplicate allocate_instance
> * Fix raw casts from oop 
> * Tweak comments

This pull request has now been integrated.

Changeset: 8692887d
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8692887d7cb99ba9fdd5ac7388abb68f72ab4a31
Stats:     78 lines in 5 files changed: 25 ins; 38 del; 15 mod

8373912: [lworld] Small cleanups to InlineKlass

Reviewed-by: coleenp

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

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

From jlahoda at openjdk.org  Thu Dec 18 12:12:31 2025
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 Dec 2025 12:12:31 GMT
Subject: [lworld] Integrated: 8373826: [lworld] Test PreviewAutoSuppress fails
 since jimage change
In-Reply-To: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
References: <W44QuW82XZ4IUses8CIQnVFHeW7RzPUDNlS_pIeELfM=.03b4100b-dc58-4804-9e50-9daaf5e93dd3@github.com>
Message-ID: <R_fujjxFOjiUAV35T5HYUfjeIOzwSD3aQYpcN32aW2E=.ce486915-0c30-470a-a519-f22d5ae6035f@github.com>

On Wed, 17 Dec 2025 13:33:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Fixing `test/langtools/tools/javac/diags/CheckExamples.java` (`test/langtools/tools/javac/diags/examples/PrimitivePatternMatching.java`) and `test/langtools/tools/javac/preview/PreviewAutoSuppress.java` tests.
> 
> Unfortunately, it is quite hard to make the tests work both with and without `-DDISABLE_PREVIEW_PATCHING=true` (could be done for `PreviewAutoSuppress.java`, but it is very hard to do sensible for `CheckExamples.java`), so given the future is `-DDISABLE_PREVIEW_PATCHING=true`, this change forces this option. (The practical impact of testing only this variant for these two tests is basically zero, I think. We have a different test that verifies all the combinations.)

This pull request has now been integrated.

Changeset: 3c41c2aa
Author:    Jan Lahoda <jlahoda at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3c41c2aa442076827cb4480373a1d481e481cdf1
Stats:     10 lines in 5 files changed: 3 ins; 5 del; 2 mod

8373826: [lworld] Test PreviewAutoSuppress fails since jimage change
8373828: [lworld] Test CheckExamples fails since jimage change

Reviewed-by: rriggs

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

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

From dsimms at openjdk.org  Thu Dec 18 12:12:47 2025
From: dsimms at openjdk.org (David Simms)
Date: Thu, 18 Dec 2025 12:12:47 GMT
Subject: git: openjdk/valhalla: lworld: 8373912: [lworld] Small cleanups to
 InlineKlass
Message-ID: <80111335-2ca9-4860-9b54-bd287c555a8e@openjdk.org>

Changeset: 8692887d
Branch: lworld
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: David Simms <dsimms at openjdk.org>
Date:      2025-12-18 12:08:50 +0000
URL:       https://git.openjdk.org/valhalla/commit/8692887d7cb99ba9fdd5ac7388abb68f72ab4a31

8373912: [lworld] Small cleanups to InlineKlass

Reviewed-by: coleenp

! src/hotspot/share/oops/flatArrayOop.inline.hpp
! src/hotspot/share/oops/inlineKlass.cpp
! src/hotspot/share/oops/inlineKlass.hpp
! src/hotspot/share/oops/inlineKlass.inline.hpp
! src/hotspot/share/oops/instanceKlass.hpp


From mchevalier at openjdk.org  Thu Dec 18 12:14:58 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Thu, 18 Dec 2025 12:14:58 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail with
 --enable-preview
Message-ID: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>

Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.

There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.

The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have

value class MyValue {
    int x;
}
class C {
    MyValue v;  // assumed flat.
}

the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.

I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.

The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::initialize_from(fieldDescriptor* fd)`:
https://github.com/openjdk/valhalla/blob/26b764096f099704f69b60721e17a7a73bca49a4/src/hotspot/share/ci/ciField.cpp#L341


Thanks,
Marc

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

Commit messages:
 - Solving conflict with myself: Merge remote-tracking branch 'lworld' into JDK-8372700
 - Un-problemlist
 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - Cleanup
 - Cleanup
 - Fix header size
 - damn is_null_or_zero assumes is_valid
 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - Segfault?
 - segfault
 - ... and 4 more: https://git.openjdk.org/valhalla/compare/b9de628e...9269cf54

Changes: https://git.openjdk.org/valhalla/pull/1826/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372700
  Stats: 292 lines in 20 files changed: 274 ins; 4 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1826.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826

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

From thartmann at openjdk.org  Thu Dec 18 12:16:48 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 12:16:48 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
Message-ID: <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>

> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
> 
> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
> 
> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
> 
> Testing: tier1-tier6 + valhalla-comp-stress
> 
> Thanks,
> Tobias

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

 - Merge branch 'lworld' into JDK-8228361
 - More refactoring, better comments
 - More comments, removing workaround
 - Merge
 - v5
 - Refactoring v4
 - Refactoring v3
 - Refactoring, more checks, new test
 - Merge branch 'lworld' into JDK-8228362
 - All tests pass
 - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7

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

Changes: https://git.openjdk.org/valhalla/pull/1823/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1823&range=01
  Stats: 1503 lines in 30 files changed: 1266 ins; 106 del; 131 mod
  Patch: https://git.openjdk.org/valhalla/pull/1823.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1823/head:pull/1823

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

From chagedorn at openjdk.org  Thu Dec 18 12:41:04 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 18 Dec 2025 12:41:04 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
Message-ID: <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>

On Thu, 18 Dec 2025 12:16:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'lworld' into JDK-8228361
>  - More refactoring, better comments
>  - More comments, removing workaround
>  - Merge
>  - v5
>  - Refactoring v4
>  - Refactoring v3
>  - Refactoring, more checks, new test
>  - Merge branch 'lworld' into JDK-8228362
>  - All tests pass
>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7

Nice work! Some small comments, otherwise, it looks good to me.

src/hotspot/share/opto/callnode.cpp line 1189:

> 1187:     Node* left = in(TypeFunc::Parms);
> 1188:     Node* right = in(TypeFunc::Parms + 1);
> 1189:     if (!left->is_top() && !right->is_top() && (left->is_InlineType() || right->is_InlineType())) {

I think you can remove the `is_top()` checks since the `is_InlineType()` checks already cover that.

Suggestion:

    if (left->is_InlineType() || right->is_InlineType()) {

src/hotspot/share/opto/inlinetypenode.cpp line 673:

> 671: 
> 672: // Check if a substitutability check between 'this' and 'other' can be implemented in IR
> 673: bool InlineTypeNode::can_emit_substitutability_check(Node* other) {

Can be made `const`. Same for `check_substitutability()`.

src/hotspot/share/opto/inlinetypenode.cpp line 712:

> 710: 
> 711:     Node* field_base = base;
> 712:     Node* field_ptr = ptr;

To better follow the logic below, I suggest the following names:
- `val` -> `this_field`
- `ptr`/`field_ptr` -> `other`/`field_other`. 

And further down use this/other instead of left/right.

src/hotspot/share/opto/inlinetypenode.cpp line 722:

> 720:       assert(base != nullptr, "lost base");
> 721:       field_ptr = igvn->register_new_node_with_optimizer(new AddPNode(base, ptr, igvn->MakeConX(field_off)));
> 722:       if (!field_is_flat(i)) {

How about adding a `InlineTypeNode::field()` method and then directly calling `is_flat()`, `is_null_free()` on the field instead of reloading it each time over the index?

src/hotspot/share/opto/library_call.cpp line 4424:

> 4422: }
> 4423: 
> 4424: //---------------------------load_mirror_from_klass----------------------------

Suggestion:

src/hotspot/share/opto/subnode.cpp line 932:

> 930:   //   CmpL(OrL(CastP2X(..), CastP2X(..)), 0L)
> 931:   // that are used by acmp to implement a "both operands are null" check.
> 932:   // See also the corresponding code in CmpPNode::Ideal.

I suggest to move it above as a method comment.

src/hotspot/share/opto/subnode.cpp line 1219:

> 1217:     // If one operand is an inline type, convert this to a "both operands are null" check:
> 1218:     //   CmpL(OrL(CastP2X(..), CastP2X(..)), 0L)
> 1219:     // CmpLNode::Ideal might optimize this further to avoid keeping buffer allocations alive.

Why is this possible?

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1823#pullrequestreview-3591965308
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630422825
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630435789
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630806019
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630474288
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630818564
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630845361
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630855979

From chagedorn at openjdk.org  Thu Dec 18 12:59:40 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 18 Dec 2025 12:59:40 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
 <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
Message-ID: <RiqV9kwrCk3aY0_eOtPZranPMDklN4vRaeUg5dU_Odg=.b837bfc4-6d46-42f3-be90-2a608f946cdf@github.com>

On Thu, 18 Dec 2025 10:17:02 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'lworld' into JDK-8228361
>>  - More refactoring, better comments
>>  - More comments, removing workaround
>>  - Merge
>>  - v5
>>  - Refactoring v4
>>  - Refactoring v3
>>  - Refactoring, more checks, new test
>>  - Merge branch 'lworld' into JDK-8228362
>>  - All tests pass
>>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7
>
> src/hotspot/share/opto/callnode.cpp line 1189:
> 
>> 1187:     Node* left = in(TypeFunc::Parms);
>> 1188:     Node* right = in(TypeFunc::Parms + 1);
>> 1189:     if (!left->is_top() && !right->is_top() && (left->is_InlineType() || right->is_InlineType())) {
> 
> I think you can remove the `is_top()` checks since the `is_InlineType()` checks already cover that.
> 
> Suggestion:
> 
>     if (left->is_InlineType() || right->is_InlineType()) {

Scratch that, my suggestion is incorrect.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2630975062

From coleenp at openjdk.org  Thu Dec 18 13:16:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 13:16:56 GMT
Subject: [lworld] RFR: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
Message-ID: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>

This replaces Locale with Calendar and removes BaseLocale to test loading with ClassFileLoadHook, like my previous pull request.  Also removes the test from the ProblemList-enable-valhalla.txt file.

BaseLocale is also loaded and I thought it was the migrated classes that caused early loading for Locale, but it was really the module patching that we used to do for --enable-preview.  See call stack in bug report.

Tested with the test on windows, where it failed.

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

Commit messages:
 - 8372686: [lworld] runtime/cds/serviceability/ReplaceCriticalClasses.java fails with --enable-preview

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

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

From thartmann at openjdk.org  Thu Dec 18 13:30:15 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 13:30:15 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
 <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
Message-ID: <kbE-pB3X2Ra_GcqIffNkyUVL_9V7LwrLpwErrJ81fM8=.9e4b06cf-5094-4ee9-b2ef-5a48bbbc0c4e@github.com>

On Thu, 18 Dec 2025 12:09:58 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'lworld' into JDK-8228361
>>  - More refactoring, better comments
>>  - More comments, removing workaround
>>  - Merge
>>  - v5
>>  - Refactoring v4
>>  - Refactoring v3
>>  - Refactoring, more checks, new test
>>  - Merge branch 'lworld' into JDK-8228362
>>  - All tests pass
>>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7
>
> src/hotspot/share/opto/inlinetypenode.cpp line 712:
> 
>> 710: 
>> 711:     Node* field_base = base;
>> 712:     Node* field_ptr = ptr;
> 
> To better follow the logic below, I suggest the following names:
> - `val` -> `this_field`
> - `ptr`/`field_ptr` -> `other`/`field_other`. 
> 
> And further down use this/other instead of left/right.

Makes sense, will update code and comments accordingly.

> src/hotspot/share/opto/library_call.cpp line 4424:
> 
>> 4422: }
>> 4423: 
>> 4424: //---------------------------load_mirror_from_klass----------------------------
> 
> Suggestion:

I moved this code back to where it is in mainline and would therefore rather leave it unchanged.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631106461
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631105692

From thartmann at openjdk.org  Thu Dec 18 13:33:27 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 13:33:27 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
 <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
Message-ID: <W1IQ_p0xYccJc6T_Z7L1Ju8T_w_vQxGIU6C4MwOHgec=.04b5fcf3-63cb-43fd-8f26-de0a9c287026@github.com>

On Thu, 18 Dec 2025 10:21:09 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'lworld' into JDK-8228361
>>  - More refactoring, better comments
>>  - More comments, removing workaround
>>  - Merge
>>  - v5
>>  - Refactoring v4
>>  - Refactoring v3
>>  - Refactoring, more checks, new test
>>  - Merge branch 'lworld' into JDK-8228362
>>  - All tests pass
>>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7
>
> src/hotspot/share/opto/inlinetypenode.cpp line 673:
> 
>> 671: 
>> 672: // Check if a substitutability check between 'this' and 'other' can be implemented in IR
>> 673: bool InlineTypeNode::can_emit_substitutability_check(Node* other) {
> 
> Can be made `const`. Same for `check_substitutability()`.

Good catch, I'll update accordingly.

> src/hotspot/share/opto/inlinetypenode.cpp line 722:
> 
>> 720:       assert(base != nullptr, "lost base");
>> 721:       field_ptr = igvn->register_new_node_with_optimizer(new AddPNode(base, ptr, igvn->MakeConX(field_off)));
>> 722:       if (!field_is_flat(i)) {
> 
> How about adding a `InlineTypeNode::field()` method and then directly calling `is_flat()`, `is_null_free()` on the field instead of reloading it each time over the index?

I think that's a good idea but out of scope of this PR because these methods are used all over the place. I filed [JDK-8374006](https://bugs.openjdk.org/browse/JDK-8374006) for this.

> src/hotspot/share/opto/subnode.cpp line 932:
> 
>> 930:   //   CmpL(OrL(CastP2X(..), CastP2X(..)), 0L)
>> 931:   // that are used by acmp to implement a "both operands are null" check.
>> 932:   // See also the corresponding code in CmpPNode::Ideal.
> 
> I suggest to move it above as a method comment.

But there's other code in that method that does different optimizations, right?

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631116850
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631115930
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631119989

From thartmann at openjdk.org  Thu Dec 18 13:42:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 13:42:19 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
Message-ID: <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>

> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
> 
> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
> 
> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
> 
> Testing: tier1-tier6 + valhalla-comp-stress
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Adjustments according to review comments

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

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1823/files
  - new: https://git.openjdk.org/valhalla/pull/1823/files/4f8556c7..35757d7f

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

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

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

From thartmann at openjdk.org  Thu Dec 18 13:42:22 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 13:42:22 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
Message-ID: <vdyQ6OjoMMweKwSjIdtF-Q6iuPh4QLU8EZyPytuZtDc=.ef72449f-c6ee-449a-ae67-0a54282e3623@github.com>

On Thu, 18 Dec 2025 12:16:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'lworld' into JDK-8228361
>  - More refactoring, better comments
>  - More comments, removing workaround
>  - Merge
>  - v5
>  - Refactoring v4
>  - Refactoring v3
>  - Refactoring, more checks, new test
>  - Merge branch 'lworld' into JDK-8228362
>  - All tests pass
>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7

Thanks a lot for the review, Christian! I replied to all of your comments and adjusted the code accordingly.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1823#issuecomment-3670341995

From thartmann at openjdk.org  Thu Dec 18 13:42:24 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 13:42:24 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
 <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
Message-ID: <BhYvaQdKnimnlnh0Nxy89Rw0pjb43kXExHtyDp0lwbw=.63966e53-acf4-4801-85e3-705cb467aa31@github.com>

On Thu, 18 Dec 2025 12:24:35 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjustments according to review comments
>
> src/hotspot/share/opto/subnode.cpp line 1219:
> 
>> 1217:     // If one operand is an inline type, convert this to a "both operands are null" check:
>> 1218:     //   CmpL(OrL(CastP2X(..), CastP2X(..)), 0L)
>> 1219:     // CmpLNode::Ideal might optimize this further to avoid keeping buffer allocations alive.
> 
> Why is this possible?

As we discussed off-thread, this relies on CmpP being a buffer oop pointer comparison and since there are no guarantees that such pointers are equivalent, we can convert the check. I improved the comment and hopefully it's easier to follow now.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631145191

From duke at openjdk.org  Thu Dec 18 13:42:57 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 18 Dec 2025 13:42:57 GMT
Subject: [lworld] RFR: 8362252: [lworld] Possible synchronization issue in
 jdk/internal/jimage/ImageReader.java
Message-ID: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com>

Tidying up syncrhonization around shared image.

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

Commit messages:
 - Tidying up syncrhonization around shared image

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

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

From chagedorn at openjdk.org  Thu Dec 18 13:49:36 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 18 Dec 2025 13:49:36 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
Message-ID: <fESwHPDv6hK8xU5bmumDHFYw5HON4mC89lk7RqkDU9w=.b18abb5f-2bc1-486c-8738-315d637ef1dd@github.com>

On Thu, 18 Dec 2025 13:42:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments according to review comments

Thanks for the update, it looks good to me!

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

Marked as reviewed by chagedorn (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1823#pullrequestreview-3593084997

From chagedorn at openjdk.org  Thu Dec 18 13:49:39 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Thu, 18 Dec 2025 13:49:39 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <W1IQ_p0xYccJc6T_Z7L1Ju8T_w_vQxGIU6C4MwOHgec=.04b5fcf3-63cb-43fd-8f26-de0a9c287026@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
 <2K9_jEZQdBMDuqp5F6VPT8b_kJod3BhvwDHX1YzH3ic=.2118b7c1-9beb-488e-b5b1-ca27e2930279@github.com>
 <W1IQ_p0xYccJc6T_Z7L1Ju8T_w_vQxGIU6C4MwOHgec=.04b5fcf3-63cb-43fd-8f26-de0a9c287026@github.com>
Message-ID: <oZo5YVMyUn6IKz3XCRYxYITo9y6gIcMQso9gNEk3Jeo=.bd25b126-f870-464c-9019-95c426273276@github.com>

On Thu, 18 Dec 2025 13:30:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 722:
>> 
>>> 720:       assert(base != nullptr, "lost base");
>>> 721:       field_ptr = igvn->register_new_node_with_optimizer(new AddPNode(base, ptr, igvn->MakeConX(field_off)));
>>> 722:       if (!field_is_flat(i)) {
>> 
>> How about adding a `InlineTypeNode::field()` method and then directly calling `is_flat()`, `is_null_free()` on the field instead of reloading it each time over the index?
>
> I think that's a good idea but out of scope of this PR because these methods are used all over the place. I filed [JDK-8374006](https://bugs.openjdk.org/browse/JDK-8374006) for this.

Sounds good, thanks!

>> src/hotspot/share/opto/subnode.cpp line 932:
>> 
>>> 930:   //   CmpL(OrL(CastP2X(..), CastP2X(..)), 0L)
>>> 931:   // that are used by acmp to implement a "both operands are null" check.
>>> 932:   // See also the corresponding code in CmpPNode::Ideal.
>> 
>> I suggest to move it above as a method comment.
>
> But there's other code in that method that does different optimizations, right?

Yes, right, keep it like that.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631169712
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631171655

From stefank at openjdk.org  Thu Dec 18 13:52:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Dec 2025 13:52:40 GMT
Subject: [lworld] RFR: 8374007: [lworld] Remove dead code in Symbol
Message-ID: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>

There's dead code in Symbol that I propose that we remove.

FWIW, I stared at Symol::is_same_fundamental_type a bit and think that there's a bug in that function and that the second `ends_with` should have been `s->ends_with`.

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

Commit messages:
 - 8374007: [lworld] Remove dead code in Symbol

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

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

From fparain at openjdk.org  Thu Dec 18 13:52:41 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Dec 2025 13:52:41 GMT
Subject: [lworld] RFR: 8374007: [lworld] Remove dead code in Symbol
In-Reply-To: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
References: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
Message-ID: <K7z0vVyHVsnCKJu2a6dVZq_ckEtosC_w1LtVQtBAanM=.c07e03fb-e3c8-4ed8-b2b5-5bf72bf36db2@github.com>

On Thu, 18 Dec 2025 13:45:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's dead code in Symbol that I propose that we remove.
> 
> FWIW, I stared at Symol::is_same_fundamental_type a bit and think that there's a bug in that function and that the second `ends_with` should have been `s->ends_with`.

LGTM

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

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1829#pullrequestreview-3593090411

From duke at openjdk.org  Thu Dec 18 13:57:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Thu, 18 Dec 2025 13:57:08 GMT
Subject: [lworld] RFR: 8362252: [lworld] Possible synchronization issue in
 jdk/internal/jimage/ImageReader.java
In-Reply-To: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com>
References: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com>
Message-ID: <xqINq4laVgfDgeQl-jWo5T2JyoCZQvxy7glWbjklEsE=.e03f1861-c53b-4988-aae7-136e4a20eab5@github.com>

On Thu, 18 Dec 2025 13:36:12 GMT, David Beaumont <duke at openjdk.org> wrote:

> Tidying up syncrhonization around shared image.

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

> 406:             synchronized (OPEN_FILES) {
> 407:                 ReaderKey key = new ReaderKey(imagePath, previewMode);
> 408:                 SharedImageReader reader = OPEN_FILES.get(key);

I changed the name of this for clarity. It's a bit confusing to have two "image reader" instances in scope with one called "image" and one called just "reader".

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

> 442:                     nodes.clear();
> 443:                 }
> 444:                 super.close();

I will double check if moving this outside the synchronization of OPEN_FILES is an issue.
The underlying BasicImageReader using a file channel, which is close (with locking) in this close() method.
The vague worry I have is that now the outter OPEN_FILES lock isn't held, we can get a race where the same file has a file channel being closed as a new one is being opened, and I'm not 100% sure I know if that's safe.
Moving this back into the OPEN_FILES lock is possible, but leaves this code doing more work with the locks held, which I'm inclined to avoid if possible.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1828#discussion_r2631177032
PR Review Comment: https://git.openjdk.org/valhalla/pull/1828#discussion_r2631195409

From thartmann at openjdk.org  Thu Dec 18 13:57:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 13:57:13 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v11]
In-Reply-To: <kPp9OPZJkdfwKufeVPUt_Ej3uiWuwXTUTX8fxpvVjx0=.8b97a016-3cc1-4cb2-b4b7-4da11bd7aa9a@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <kPp9OPZJkdfwKufeVPUt_Ej3uiWuwXTUTX8fxpvVjx0=.8b97a016-3cc1-4cb2-b4b7-4da11bd7aa9a@github.com>
Message-ID: <_lM03MIdVDOs7_8hVusAscZFyo-uxphnydT_LR9ms7M=.a7d50caa-e082-4026-ab50-564454fe3a9f@github.com>

On Wed, 17 Dec 2025 17:37:56 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:
> 
>   Fix because properties passed into with_properties is not the same as properties() of the result

I had a quick off-thread discussion with Frederic who voiced some concerns: ArrayProperties are user requirements and shouldn?t be changed by the JVM, even if the chosen layout provides stronger guarantees. However, since your normalization only affects atomicity, and non-atomicity is not part of JEP 401, it?s OK to proceed for now. Please file a follow-up bug to track these concerns though.

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

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

From thartmann at openjdk.org  Thu Dec 18 14:00:14 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 14:00:14 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
Message-ID: <2lm2HiJ4CkGNK19wA3be9YhHzgU6H_d0GmvqRSkp4Pw=.48a4fc00-b0fa-4b3d-b8b7-d121184d9fe2@github.com>

On Thu, 18 Dec 2025 13:42:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments according to review comments

Thanks again Christian!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1823#issuecomment-3670411758

From coleenp at openjdk.org  Thu Dec 18 14:05:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 14:05:28 GMT
Subject: [lworld] RFR: 8374007: [lworld] Remove dead code in Symbol
In-Reply-To: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
References: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
Message-ID: <OyApVoV-U6NIErGn-oiStgpYyTEon_CSQtyy4bommhg=.f55354be-ec9b-4836-abca-4cad764e250b@github.com>

On Thu, 18 Dec 2025 13:45:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's dead code in Symbol that I propose that we remove.
> 
> FWIW, I stared at Symol::is_same_fundamental_type a bit and think that there's a bug in that function and that the second `ends_with` should have been `s->ends_with`.

Nice removal. Thank you!

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

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1829#pullrequestreview-3593153101

From vromero at openjdk.org  Thu Dec 18 14:08:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 14:08:54 GMT
Subject: [lworld] RFR: 8367931: [lworld] Handling of @Strict by javac needs
 some fixes
Message-ID: <dG63kgy-mkf-JeaZnbu9omLHZdrfYW-ZM2qLZ2yzBnU=.6e3ec067-f8ae-4fca-911f-7d2c41fab732@github.com>

javac is setting the @Strict annotation in the RuntimeInvisibleAnnotations attribute of the annotated field. This is due to a bug in how the annotation type is being entered in the symbol table. This PR is fixing this issue,

TIA

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

Commit messages:
 - 8367931: Handling of @Strict by javac needs some fixes

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

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

From liach at openjdk.org  Thu Dec 18 14:26:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 14:26:18 GMT
Subject: [lworld] RFR: 8367931: [lworld] Handling of @Strict by javac needs
 some fixes
In-Reply-To: <dG63kgy-mkf-JeaZnbu9omLHZdrfYW-ZM2qLZ2yzBnU=.6e3ec067-f8ae-4fca-911f-7d2c41fab732@github.com>
References: <dG63kgy-mkf-JeaZnbu9omLHZdrfYW-ZM2qLZ2yzBnU=.6e3ec067-f8ae-4fca-911f-7d2c41fab732@github.com>
Message-ID: <W2Nc7A6jtFkcyTMWOlyLKh9WsyDIDH6znZ2sQgsjve4=.898131ef-23e2-4259-88d3-5fddcb591e4f@github.com>

On Thu, 18 Dec 2025 01:39:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is setting the @Strict annotation in the RuntimeInvisibleAnnotations attribute of the annotated field. This is due to a bug in how the annotation type is being entered in the symbol table. This PR is fixing this issue,
> 
> TIA

Looks right that we are handling this equivalent to `@Override`.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1820#pullrequestreview-3593259530

From mhaessig at openjdk.org  Thu Dec 18 14:45:45 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 18 Dec 2025 14:45:45 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
Message-ID: <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>

On Thu, 18 Dec 2025 13:42:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments according to review comments

Thank you for this improvement, @TobiHartmann! The logic looks good to me. I mainly have some readability and factoring suggestions of the take it or leave it kind and a misunderstanding about a comment.

src/hotspot/share/opto/callnode.cpp line 1184:

> 1182:   }
> 1183: 
> 1184:   // Try to replace the runtime call to the substitutability test emitted by acmp if (at least) one operand is a known type

If this would be in its own helper method, `Ideal` would stay smaller and feel less about substitutability, and you could reduce the nesting with short circuit returns. Not sure if this is worth the plumbing though.

src/hotspot/share/opto/inlinetypenode.cpp line 675:

> 673: bool InlineTypeNode::can_emit_substitutability_check(Node* other) const {
> 674:   if (other != nullptr && other->is_InlineType() && bottom_type() != other->bottom_type()) {
> 675:     // Different types, this is dead code because there's a check above that guarantees this.

Shouldn't this be an assert, then? Or at least call it a sanity check instead, just so no one gets an idea and removes it when they have not realized yet that the bottom type check is essential for the rest of the method.

src/hotspot/share/opto/inlinetypenode.cpp line 694:

> 692: 
> 693: // Emit IR to check substitutability between 'this' (left operand) and the value object referred to by 'other' (right operand).
> 694: // Parse-time checks guarantee that both operands have the same type. If 'other' is not an InlineTypeNode, we need to emit loads for the field values.

If both `this` and `other` have the same type and `this` is an `InlineTypeNode`, how can `other` not be an `InlineTypeNode`?

src/hotspot/share/opto/inlinetypenode.cpp line 781:

> 779:     } else {
> 780:       assert(ft->is_primitive_type() || !ft->as_klass()->can_be_inline_klass(), "Needs substitutability test");
> 781:       acmp_val_guard(igvn, region, phi, ctrl, bt, BoolTest::ne, this_field, other_field);

Moving the primitive case to the top of this if chain and only having the assert case in the else branch would help readability a bit.

test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAcmpEdgeCases.java line 201:

> 199:                 Float.intBitsToFloat(0xFFC00000), // negative quiet
> 200:                 Float.intBitsToFloat(0xFF800001), // negative signaling
> 201:                 Float.intBitsToFloat(0xFFFFFFFF),  // negative max payload

This looks like something that could be reused for many tests if it were in the testlibrary.

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

PR Review: https://git.openjdk.org/valhalla/pull/1823#pullrequestreview-3593105796
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631359613
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631201116
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631230805
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631263459
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631323210

From mhaessig at openjdk.org  Thu Dec 18 14:45:49 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 18 Dec 2025 14:45:49 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
Message-ID: <wIUNjutzyJ3_JHWonmyh_Xfw7lyTaLXXK99cASsWI1A=.a4349fa5-bb20-4d76-82b8-9e59f7aaec9f@github.com>

On Thu, 18 Dec 2025 12:16:48 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'lworld' into JDK-8228361
>  - More refactoring, better comments
>  - More comments, removing workaround
>  - Merge
>  - v5
>  - Refactoring v4
>  - Refactoring v3
>  - Refactoring, more checks, new test
>  - Merge branch 'lworld' into JDK-8228362
>  - All tests pass
>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7

src/hotspot/share/opto/inlinetypenode.cpp line 659:

> 657:     assert(is_reference_type(bt), "must be");
> 658:     cmp = igvn->register_new_node_with_optimizer(new CmpPNode(val1, val2));
> 659:   }

The following might be a bit cleaner and self-explanatory.
Suggestion:

  if (is_single_word_type(bt)) {
    if (bt == T_FLOAT) {
      val1 = igvn->register_new_node_with_optimizer(new MoveF2INode(val1));
      val2 = igvn->register_new_node_with_optimizer(new MoveF2INode(val2));
    }
    cmp = igvn->register_new_node_with_optimizer(new CmpINode(val1, val2));
  } else if (is_double_word_type(bt)) {
    if (bt == T_DOUBLE) {
      val1 = igvn->register_new_node_with_optimizer(new MoveD2LNode(val1));
      val2 = igvn->register_new_node_with_optimizer(new MoveD2LNode(val2));
    }
    cmp = igvn->register_new_node_with_optimizer(new CmpLNode(val1, val2));
  } else {
    assert(is_reference_type(bt), "must be");
    cmp = igvn->register_new_node_with_optimizer(new CmpPNode(val1, val2));
  }

 Note, this still needs an appropriate implementation for `is_single_word_type()` in `gobal_definitions.hpp`:
```c++
inline bool is_integral_type(BasicType t) {
  return is_subword_type(t) || t == T_INT || t == T_FLOAT;
}

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631186288

From qamai at openjdk.org  Thu Dec 18 15:07:13 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 15:07:13 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v12]
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: <N6vVkwlfI0PPRnIwIkvrqSEJXcE2PDNhtS-ZbsWP4qM=.8e6a7700-1537-4d05-82f5-89190c197555@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 16 commits:

 - Merge branch 'lworld' into AryKlassPtrfactory
 - Fix because properties passed into with_properties is not the same as properties() of the result
 - ArrayProperties needs to agree with LayoutKind
 - Merge branch 'lworld' into AryKlassPtrfactory
 - Merge branch 'lworld' into AryKlassPtrfactory
 - reviews
 - reviews
 - Should not clone MergeMem
 - fix NarrowMemProj
 - Merge branch 'lworld' into AryKlassPtrfactory
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...0b78ccaf

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

Changes: https://git.openjdk.org/valhalla/pull/1755/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1755&range=11
  Stats: 612 lines in 23 files changed: 264 ins; 156 del; 192 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 18 15:11:20 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 15:11:20 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v12]
In-Reply-To: <N6vVkwlfI0PPRnIwIkvrqSEJXcE2PDNhtS-ZbsWP4qM=.8e6a7700-1537-4d05-82f5-89190c197555@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <N6vVkwlfI0PPRnIwIkvrqSEJXcE2PDNhtS-ZbsWP4qM=.8e6a7700-1537-4d05-82f5-89190c197555@github.com>
Message-ID: <UKyq2pPVrJLiPREGRlmJS6Q_mg1YqUW_V4Zi3GwWZ8M=.80004800-bd31-46e2-a5d0-baadbb8080aa@github.com>

On Thu, 18 Dec 2025 15:07:13 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 16 commits:
> 
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix because properties passed into with_properties is not the same as properties() of the result
>  - ArrayProperties needs to agree with LayoutKind
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - reviews
>  - reviews
>  - Should not clone MergeMem
>  - fix NarrowMemProj
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - ... and 6 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...0b78ccaf

Thanks, then I will integrate this PR then. I have created https://bugs.openjdk.org/browse/JDK-8374022.

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

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

From mhaessig at openjdk.org  Thu Dec 18 15:17:46 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 18 Dec 2025 15:17:46 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
Message-ID: <cCHCnbuBxnBnPf0zoWH5Rm0hS9FioTb9VewzuFaRZQk=.ac2c9dec-28a4-446b-8dbf-a0842f0b98da@github.com>

On Thu, 18 Dec 2025 13:42:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments according to review comments

Marked as reviewed by mhaessig (no project role).

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

PR Review: https://git.openjdk.org/valhalla/pull/1823#pullrequestreview-3593530456

From thartmann at openjdk.org  Thu Dec 18 15:25:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:25:18 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v2]
In-Reply-To: <wIUNjutzyJ3_JHWonmyh_Xfw7lyTaLXXK99cASsWI1A=.a4349fa5-bb20-4d76-82b8-9e59f7aaec9f@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Q6jRt42m1xwo7V_rW5BwJjxlZM-CvBRuCLk6Qz6nAok=.b02f8876-7133-4eb6-a7e4-35e000725310@github.com>
 <wIUNjutzyJ3_JHWonmyh_Xfw7lyTaLXXK99cASsWI1A=.a4349fa5-bb20-4d76-82b8-9e59f7aaec9f@github.com>
Message-ID: <YlV7xXO7I8BdaNV4iVCbQUpRHiV3ulhIBB7_2IRRipI=.60ee3c77-1fd8-4520-9b39-464c6e5a624d@github.com>

On Thu, 18 Dec 2025 13:51:35 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'lworld' into JDK-8228361
>>  - More refactoring, better comments
>>  - More comments, removing workaround
>>  - Merge
>>  - v5
>>  - Refactoring v4
>>  - Refactoring v3
>>  - Refactoring, more checks, new test
>>  - Merge branch 'lworld' into JDK-8228362
>>  - All tests pass
>>  - ... and 11 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...4f8556c7
>
> src/hotspot/share/opto/inlinetypenode.cpp line 659:
> 
>> 657:     assert(is_reference_type(bt), "must be");
>> 658:     cmp = igvn->register_new_node_with_optimizer(new CmpPNode(val1, val2));
>> 659:   }
> 
> The following might be a bit cleaner and self-explanatory.
> Suggestion:
> 
>   if (is_single_word_type(bt)) {
>     if (bt == T_FLOAT) {
>       val1 = igvn->register_new_node_with_optimizer(new MoveF2INode(val1));
>       val2 = igvn->register_new_node_with_optimizer(new MoveF2INode(val2));
>     }
>     cmp = igvn->register_new_node_with_optimizer(new CmpINode(val1, val2));
>   } else if (is_double_word_type(bt)) {
>     if (bt == T_DOUBLE) {
>       val1 = igvn->register_new_node_with_optimizer(new MoveD2LNode(val1));
>       val2 = igvn->register_new_node_with_optimizer(new MoveD2LNode(val2));
>     }
>     cmp = igvn->register_new_node_with_optimizer(new CmpLNode(val1, val2));
>   } else {
>     assert(is_reference_type(bt), "must be");
>     cmp = igvn->register_new_node_with_optimizer(new CmpPNode(val1, val2));
>   }
> 
>  Note, this still needs an appropriate implementation for `is_single_word_type()` in `gobal_definitions.hpp`:
> ```c++
> inline bool is_integral_type(BasicType t) {
>   return is_subword_type(t) || t == T_INT || t == T_FLOAT;
> }

That's a good suggestion. I'll update the code accordingly!

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631521349

From thartmann at openjdk.org  Thu Dec 18 15:25:14 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:25:14 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
Message-ID: <A54YLsJpXXTWlc3wQI2-OxTgU7thBYMUMJIvuRhNTSI=.56b4ff2a-ff82-4beb-962b-2704a5422f05@github.com>

On Thu, 18 Dec 2025 13:42:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
>> 
>> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
>> 
>> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
>> 
>> Testing: tier1-tier6 + valhalla-comp-stress
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjustments according to review comments

Thanks for your review Manuel! To avoid having to re-run all testing, because I'm paranoid just before vacation starts, I'll postpone your suggestions to a follow-up RFE (I filed [JDK-8374024](https://bugs.openjdk.org/browse/JDK-8374024)) and will integrate this shorty.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1823#issuecomment-3670823387

From thartmann at openjdk.org  Thu Dec 18 15:25:20 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:25:20 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
 <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>
Message-ID: <zI1on2eCpAwU8VXz4_PWrNf7wlx9HeVYPtlVEkij-H8=.c5470885-d740-40ea-8308-c7c7f23bbcf5@github.com>

On Thu, 18 Dec 2025 13:56:11 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjustments according to review comments
>
> src/hotspot/share/opto/inlinetypenode.cpp line 675:
> 
>> 673: bool InlineTypeNode::can_emit_substitutability_check(Node* other) const {
>> 674:   if (other != nullptr && other->is_InlineType() && bottom_type() != other->bottom_type()) {
>> 675:     // Different types, this is dead code because there's a check above that guarantees this.
> 
> Shouldn't this be an assert, then? Or at least call it a sanity check instead, just so no one gets an idea and removes it when they have not realized yet that the bottom type check is essential for the rest of the method.

Maybe I'm misunderstanding your comment but with "dead code" I meant that the IR will be folded but didn't fold yet. We still need the checks in the C++ code to avoid optimizing dead code during IGVN (we would need all kinds of is_top checks further below).

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631525123

From vromero at openjdk.org  Thu Dec 18 15:35:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 15:35:53 GMT
Subject: [lworld] RFR: 8367931: [lworld] Handling of @Strict by javac needs
 some fixes
In-Reply-To: <W2Nc7A6jtFkcyTMWOlyLKh9WsyDIDH6znZ2sQgsjve4=.898131ef-23e2-4259-88d3-5fddcb591e4f@github.com>
References: <dG63kgy-mkf-JeaZnbu9omLHZdrfYW-ZM2qLZ2yzBnU=.6e3ec067-f8ae-4fca-911f-7d2c41fab732@github.com>
 <W2Nc7A6jtFkcyTMWOlyLKh9WsyDIDH6znZ2sQgsjve4=.898131ef-23e2-4259-88d3-5fddcb591e4f@github.com>
Message-ID: <7-uC8tAQ4xIp3DuPArfmGMRAOVveH4Udt-qkvpy5pUc=.e4c511e2-e012-4b3f-9893-5fb3c09effa1@github.com>

On Thu, 18 Dec 2025 14:23:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> Looks right that we are handling this equivalent to `@Override`.

yep, thanks for the review

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

PR Comment: https://git.openjdk.org/valhalla/pull/1820#issuecomment-3670871191

From vromero at openjdk.org  Thu Dec 18 15:35:54 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 15:35:54 GMT
Subject: [lworld] Integrated: 8367931: [lworld] Handling of @Strict by javac
 needs some fixes
In-Reply-To: <dG63kgy-mkf-JeaZnbu9omLHZdrfYW-ZM2qLZ2yzBnU=.6e3ec067-f8ae-4fca-911f-7d2c41fab732@github.com>
References: <dG63kgy-mkf-JeaZnbu9omLHZdrfYW-ZM2qLZ2yzBnU=.6e3ec067-f8ae-4fca-911f-7d2c41fab732@github.com>
Message-ID: <LNu8T3kqne6ZfAdETlem7QBdFqXDBETsk5mpnghrL3E=.44b73d0a-2e10-4687-b139-4ffe5a648fa5@github.com>

On Thu, 18 Dec 2025 01:39:09 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> javac is setting the @Strict annotation in the RuntimeInvisibleAnnotations attribute of the annotated field. This is due to a bug in how the annotation type is being entered in the symbol table. This PR is fixing this issue,
> 
> TIA

This pull request has now been integrated.

Changeset: 20f2dbfa
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/20f2dbfa86a5b3d3433b666f50bb761519ff9af2
Stats:     6 lines in 2 files changed: 5 ins; 0 del; 1 mod

8367931: [lworld] Handling of @Strict by javac needs some fixes

Reviewed-by: liach

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

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

From thartmann at openjdk.org  Thu Dec 18 15:37:01 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:37:01 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
 <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>
Message-ID: <qRPRpPbeImfGkWuPLUjsugmrMFqxHFhUz4ozypOMUJg=.2a0231bd-51a6-479d-8af1-a35892fa4109@github.com>

On Thu, 18 Dec 2025 14:40:14 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjustments according to review comments
>
> src/hotspot/share/opto/callnode.cpp line 1184:
> 
>> 1182:   }
>> 1183: 
>> 1184:   // Try to replace the runtime call to the substitutability test emitted by acmp if (at least) one operand is a known type
> 
> If this would be in its own helper method, `Ideal` would stay smaller and feel less about substitutability, and you could reduce the nesting with short circuit returns. Not sure if this is worth the plumbing though.

Good point, I'll factor it out.

> src/hotspot/share/opto/inlinetypenode.cpp line 694:
> 
>> 692: 
>> 693: // Emit IR to check substitutability between 'this' (left operand) and the value object referred to by 'other' (right operand).
>> 694: // Parse-time checks guarantee that both operands have the same type. If 'other' is not an InlineTypeNode, we need to emit loads for the field values.
> 
> If both `this` and `other` have the same type and `this` is an `InlineTypeNode`, how can `other` not be an `InlineTypeNode`?

The type of the node (in C2's type system) is not coupled to the node type (i.e. the C++ type): `this` can be a `InlineTypeNode` with type `TypeInstPtr` of `ciValueKlass` but `other` can, and often will be, for example, a `LoadPNode` of the same type `TypeInstPtr` of `ciValueKlass`. For example, when `other` is loaded from an `Object` field that could contain any object. Only the parse-time checks emitted by acmp then guarantee that once we reach the substitutability check, both operands will have the same type. And during parsing we often don't even know the type of `this`, so we can't cast and scalarize `other` accordingly.

> src/hotspot/share/opto/inlinetypenode.cpp line 781:
> 
>> 779:     } else {
>> 780:       assert(ft->is_primitive_type() || !ft->as_klass()->can_be_inline_klass(), "Needs substitutability test");
>> 781:       acmp_val_guard(igvn, region, phi, ctrl, bt, BoolTest::ne, this_field, other_field);
> 
> Moving the primitive case to the top of this if chain and only having the assert case in the else branch would help readability a bit.

Not sure if I'm following, do you mean by inverting the condition of `if (this_field->is_InlineType()) {`?

> test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAcmpEdgeCases.java line 201:
> 
>> 199:                 Float.intBitsToFloat(0xFFC00000), // negative quiet
>> 200:                 Float.intBitsToFloat(0xFF800001), // negative signaling
>> 201:                 Float.intBitsToFloat(0xFFFFFFFF),  // negative max payload
> 
> This looks like something that could be reused for many tests if it were in the testlibrary.

Yes, good point. I'll think about where to put this.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631569385
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631542513
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631560286
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631567758

From thartmann at openjdk.org  Thu Dec 18 15:40:26 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:40:26 GMT
Subject: [lworld] RFR: 8372113: [lworld] Fix various issues with TypeAryPtr
 and TypeAryKlassPtr [v12]
In-Reply-To: <N6vVkwlfI0PPRnIwIkvrqSEJXcE2PDNhtS-ZbsWP4qM=.8e6a7700-1537-4d05-82f5-89190c197555@github.com>
References: <-geYrEDp7JsltcC-Wlu13sU7nJ2PXn2_k1vY0s7LWS4=.dea68d64-a022-4dda-911e-3c351e4378d8@github.com>
 <N6vVkwlfI0PPRnIwIkvrqSEJXcE2PDNhtS-ZbsWP4qM=.8e6a7700-1537-4d05-82f5-89190c197555@github.com>
Message-ID: <46G6Gzw72JjtC0SXjwBPJY0Be8WQKtHjtzvrPp1nyqo=.46d4b999-1cef-4564-98b1-48ce6f7c4e67@github.com>

On Thu, 18 Dec 2025 15:07:13 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 16 commits:
> 
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Fix because properties passed into with_properties is not the same as properties() of the result
>  - ArrayProperties needs to agree with LayoutKind
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - reviews
>  - reviews
>  - Should not clone MergeMem
>  - fix NarrowMemProj
>  - Merge branch 'lworld' into AryKlassPtrfactory
>  - ... and 6 more: https://git.openjdk.org/valhalla/compare/3c41c2aa...0b78ccaf

Sounds good, thank you!

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

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

From thartmann at openjdk.org  Thu Dec 18 15:42:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:42:21 GMT
Subject: [lworld] Integrated: 8228361: [lworld] Optimize the substitutability
 check in C2
In-Reply-To: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
Message-ID: <ETKOKTtKAX0KhsrLYvMdyyRDJ2Y5Rl55ckNwbZgT618=.80d22011-f528-457b-b042-a46b4330864d@github.com>

On Thu, 18 Dec 2025 07:31:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> C2 will now remove the slow call to `ValueObjectMethods::isSubstitutable(Alt)` whenever it's able to determine the layout of one of the operands. It will then emit code to directly compare the fields.
> 
> This patch also contains an intrinsic for `_getFieldMap` that will be used by the new core-libs implementation of the substitutability check ([JDK-8370450](https://bugs.openjdk.org/browse/JDK-8370450)) that's used by the interpreter / C1 and as a slow path in C2.
> 
> When browsing code, I marked a few rough edges in unrelated code for follow-up cleanups with the corresponding bug numbers.
> 
> Testing: tier1-tier6 + valhalla-comp-stress
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: b63e3bef
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/b63e3bef28559b26360b8bce2a90322a1fddcc85
Stats:     1506 lines in 30 files changed: 1269 ins; 106 del; 131 mod

8228361: [lworld] Optimize the substitutability check in C2

Reviewed-by: chagedorn, mhaessig

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

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

From thartmann at openjdk.org  Thu Dec 18 15:44:21 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 15:44:21 GMT
Subject: git: openjdk/valhalla: lworld: 8228361: [lworld] Optimize the
 substitutability check in C2
Message-ID: <28f5763f-566e-4fd0-a6a3-55682dfc967e@openjdk.org>

Changeset: b63e3bef
Branch: lworld
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2025-12-18 15:39:34 +0000
URL:       https://git.openjdk.org/valhalla/commit/b63e3bef28559b26360b8bce2a90322a1fddcc85

8228361: [lworld] Optimize the substitutability check in C2

Reviewed-by: chagedorn, mhaessig

! src/hotspot/share/ci/ciInlineKlass.cpp
! src/hotspot/share/ci/ciInlineKlass.hpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/inlinetypenode.cpp
! src/hotspot/share/opto/inlinetypenode.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/mulnode.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/subnode.cpp
! src/hotspot/share/opto/subnode.hpp
! src/java.base/share/classes/java/lang/runtime/ValueObjectMethods.java
! src/java.base/share/classes/jdk/internal/misc/Unsafe.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeIRNode.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeRegexes.java
+ test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAcmpEdgeCases.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestAcmpStressUnstableIf.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestIntrinsics.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorld.java
! test/hotspot/jtreg/compiler/valhalla/inlinetypes/TestLWorldProfiling.java


From qamai at openjdk.org  Thu Dec 18 15:47:34 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 18 Dec 2025 15:47:34 GMT
Subject: [lworld] Integrated: 8372113: [lworld] Fix various issues with
 TypeAryPtr and TypeAryKlassPtr
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: <jrvRIAfhb_yZUCpHvqgyNULCATP_PcXragtEp8HniAs=.affd7f42-30aa-4587-bbf8-5b99fd1c7747@github.com>

On Fri, 21 Nov 2025 10:18:12 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.

This pull request has now been integrated.

Changeset: 10c0db67
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/10c0db676e2526e42e30d01949ec5035ee1ce607
Stats:     612 lines in 23 files changed: 264 ins; 156 del; 192 mod

8372113: [lworld] Fix various issues with TypeAryPtr and TypeAryKlassPtr

Reviewed-by: thartmann

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

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

From jsikstro at openjdk.org  Thu Dec 18 15:53:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 18 Dec 2025 15:53:47 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v3]
In-Reply-To: <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
Message-ID: <KPQpuzUr2xDmjWOmvSwSH2cNkQDQPWMABaLeC0S7g5g=.e4bc5b9b-4ce9-41cc-84f2-0b5f5d6d0e00@github.com>

On Wed, 17 Dec 2025 16:22:05 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for large primitive only flat arrays
>  - Assert fixes

I tried filling flatArrays with colored nulls and added asserts to the test but I couldn't hit them at all. Not sure, but looks like there's something else going on.

assertEquals(array[0], null);
assertEquals(looseArray[0], new LooseIntegers());


I'd like to get this in before EOD tomorrow, so I'm integrating now. I'd be happy to follow up the test if we want to make it more complete.

Thank you for the reviews @xmas92 @stefank @Arraying. I reran hotspot_valhalla and jdk_valhalla on the tip of lworld, which looks good. I also double-checked that the test fails without some of the changes in this patch.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1811#issuecomment-3670938301

From duke at openjdk.org  Thu Dec 18 15:53:48 2025
From: duke at openjdk.org (duke)
Date: Thu, 18 Dec 2025 15:53:48 GMT
Subject: [lworld] RFR: 8373858: [lworld] Segmented clearing for flatArrays
 with no oops in ZGC [v3]
In-Reply-To: <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
 <jcyN1L2bRjkYotIF1bi-Y3O47baWdmHvbGA3pY1fbME=.dba598d4-8f48-4790-bb89-a3a0c786e7cd@github.com>
Message-ID: <JVOHf1LXIY03KOZ9eG4pFjevPJTB6zewGReQc-hUNUk=.0e1fe35c-c3c2-4542-8362-5e9769324d3a@github.com>

On Wed, 17 Dec 2025 16:22:05 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
>> 
>> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
>> 
>> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
>> 
>> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add test for large primitive only flat arrays
>  - Assert fixes

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

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

PR Comment: https://git.openjdk.org/valhalla/pull/1811#issuecomment-3670943154

From mhaessig at openjdk.org  Thu Dec 18 15:57:03 2025
From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=)
Date: Thu, 18 Dec 2025 15:57:03 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <zI1on2eCpAwU8VXz4_PWrNf7wlx9HeVYPtlVEkij-H8=.c5470885-d740-40ea-8308-c7c7f23bbcf5@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
 <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>
 <zI1on2eCpAwU8VXz4_PWrNf7wlx9HeVYPtlVEkij-H8=.c5470885-d740-40ea-8308-c7c7f23bbcf5@github.com>
Message-ID: <ator3QJO9fd5-dPD6raFEtZoO3KG9WvLbhc2wh5OIhk=.b4903d96-2641-46a0-939d-3a46c15f84a5@github.com>

On Thu, 18 Dec 2025 15:22:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> src/hotspot/share/opto/inlinetypenode.cpp line 675:
>> 
>>> 673: bool InlineTypeNode::can_emit_substitutability_check(Node* other) const {
>>> 674:   if (other != nullptr && other->is_InlineType() && bottom_type() != other->bottom_type()) {
>>> 675:     // Different types, this is dead code because there's a check above that guarantees this.
>> 
>> Shouldn't this be an assert, then? Or at least call it a sanity check instead, just so no one gets an idea and removes it when they have not realized yet that the bottom type check is essential for the rest of the method.
>
> Maybe I'm misunderstanding your comment but with "dead code" I meant that the IR will be folded but didn't fold yet. We still need the checks in the C++ code to avoid optimizing dead code during IGVN (we would need all kinds of is_top checks further below).

Ah, my head was in pure C++ land and did not realize that IR would be dead.

>> src/hotspot/share/opto/inlinetypenode.cpp line 781:
>> 
>>> 779:     } else {
>>> 780:       assert(ft->is_primitive_type() || !ft->as_klass()->can_be_inline_klass(), "Needs substitutability test");
>>> 781:       acmp_val_guard(igvn, region, phi, ctrl, bt, BoolTest::ne, this_field, other_field);
>> 
>> Moving the primitive case to the top of this if chain and only having the assert case in the else branch would help readability a bit.
>
> Not sure if I'm following, do you mean by inverting the condition of `if (this_field->is_InlineType()) {`?

I meant
```c++
if (ft->is_primitive_type()) {
  acmp_val_guard();
} else if (this_type->is_InlineType()) {
  ...
} else {
  assert()
}

But now that I wrote it down, I fail to see the benefit.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631640846
PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631633310

From jsikstro at openjdk.org  Thu Dec 18 16:04:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 18 Dec 2025 16:04:19 GMT
Subject: [lworld] Integrated: 8373858: [lworld] Segmented clearing for
 flatArrays with no oops in ZGC
In-Reply-To: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
References: <-YnvdVnT6b8tsEgF3eA8M8IBJ6RA5I8e9g8OAx8PEGM=.8224dfea-ea69-4126-9728-de5a917212b5@github.com>
Message-ID: <IxO3iyLT3HlofL4_nPeTkacUsIZKmbjLr1MBzzKYB8A=.7f77d9af-0649-44a9-a05d-448b6c87837b@github.com>

On Wed, 17 Dec 2025 09:40:00 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> ZGC optimizes initialization by performing segmented clearing for objArrays, which reduces time-to-safepoint. In the lworld branch, we currently opt out of segmented clearing if the objArray being initialized is a flatArray. This prevents us from taking advantage of shorter time-to-safepoints when the flatArray could be cleared in segments.
> 
> The main question is: which types of flatArrays should support segmented clearing? Since ZGC only supports 64-bit atomic operations, flatArrays containing oops are not possible without relying on internal-only features like loose-consistency and null-restriction. A value object containing an oop and the added null-marker will always exceed 64 bits with ZGC, and therefore such objects will not be flattened in practice due to the 64-bit atomicity constraint.
> 
> Given this, we are currently missing the opportunity to use segmented clearing for flatArrays that contain only primitive types, which we should add support for. Support for flatArrays containing oops can be considered in the future, once features like loose-consistency and null-restriction are available to the user. 
> 
> Testing:
> * hotspot_valhalla, jdk_valhalla, tier1-4, with `-XX:+UseZGC`
> 
> * Some sanity testing in lldb to see if I get segmented clearing for any flatArrays, and I can see several flatArrays containing java/lang/Integer or java/lang/Character being cleared in segmentes.

This pull request has now been integrated.

Changeset: ba6560f1
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ba6560f1a31b37e05b8e2e1219b45ea83ad26659
Stats:     100 lines in 2 files changed: 94 ins; 1 del; 5 mod

8373858: [lworld] Segmented clearing for flatArrays with no oops in ZGC

Reviewed-by: aboldtch, stefank, phubner

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

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

From thartmann at openjdk.org  Thu Dec 18 16:05:42 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Thu, 18 Dec 2025 16:05:42 GMT
Subject: [lworld] RFR: 8228361: [lworld] Optimize the substitutability
 check in C2 [v3]
In-Reply-To: <ator3QJO9fd5-dPD6raFEtZoO3KG9WvLbhc2wh5OIhk=.b4903d96-2641-46a0-939d-3a46c15f84a5@github.com>
References: <MZrXwWhVYWSP841KWdhBItIB2X-Lat3xHJYm_d0CL1M=.b3e4a4f3-3a18-468d-87a8-7b7b3d48b53f@github.com>
 <Lm_g27SwUPQvGUYlkcpzfdRgHTdYLlgl3ebyvZggZIw=.c148f008-5ab6-4a37-888c-b7981d03dbc3@github.com>
 <RnZpYMXfFyrwDpz0fqc_OSH3_zHKMB8PzIytHE9SXlw=.e858b2e0-3e08-40f1-811a-239aa4b8dbfa@github.com>
 <zI1on2eCpAwU8VXz4_PWrNf7wlx9HeVYPtlVEkij-H8=.c5470885-d740-40ea-8308-c7c7f23bbcf5@github.com>
 <ator3QJO9fd5-dPD6raFEtZoO3KG9WvLbhc2wh5OIhk=.b4903d96-2641-46a0-939d-3a46c15f84a5@github.com>
Message-ID: <X2NIx7LthfyGEKWSmUYKg8z20ATEY2YGgu2-aYM_zDM=.87bd63fd-4f69-4d76-a1c6-c0190b6274be@github.com>

On Thu, 18 Dec 2025 15:52:23 GMT, Manuel H?ssig <mhaessig at openjdk.org> wrote:

>> Not sure if I'm following, do you mean by inverting the condition of `if (this_field->is_InlineType()) {`?
>
> I meant
> ```c++
> if (ft->is_primitive_type()) {
>   acmp_val_guard();
> } else if (this_type->is_InlineType()) {
>   ...
> } else {
>   assert()
> }
> 
> But now that I wrote it down, I fail to see the benefit.

I don't think that would be equivalent / correct though because we need to take that path as well when `!ft->is_primitive_type()`, right? The field can be of an object type that is `!ft->as_klass()->can_be_inline_klass()`.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1823#discussion_r2631668585

From mcimadamore at openjdk.org  Thu Dec 18 16:07:33 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Dec 2025 16:07:33 GMT
Subject: RFR: 8374027: Restrict parser to only accept null-restrictions in
 selected locations
Message-ID: <dxsr-0KuaH9a7YjQa0bZg7TPPDbX4EojtCYXxT1JBS0=.fae94479-d422-4887-9d19-279cf69c48aa@github.com>

Text here

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

Commit messages:
 - Clean up code and add comments
 - Revert tests
 - Initial push

Changes: https://git.openjdk.org/valhalla/pull/1830/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374027
  Stats: 141 lines in 7 files changed: 58 ins; 49 del; 34 mod
  Patch: https://git.openjdk.org/valhalla/pull/1830.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1830/head:pull/1830

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

From stefank at openjdk.org  Thu Dec 18 16:10:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Dec 2025 16:10:03 GMT
Subject: [lworld] RFR: 8374007: [lworld] Remove dead code in Symbol
In-Reply-To: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
References: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
Message-ID: <9jPpD90yz-Tk64enct26NSL5eSzy4xzwCsBVILrT9kw=.261aee94-5f9b-4316-b8b4-9db3891d90d9@github.com>

On Thu, 18 Dec 2025 13:45:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's dead code in Symbol that I propose that we remove.
> 
> FWIW, I stared at Symol::is_same_fundamental_type a bit and think that there's a bug in that function and that the second `ends_with` should have been `s->ends_with`.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/valhalla/pull/1829#issuecomment-3670999150

From stefank at openjdk.org  Thu Dec 18 16:10:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Dec 2025 16:10:04 GMT
Subject: [lworld] Integrated: 8374007: [lworld] Remove dead code in Symbol
In-Reply-To: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
References: <giR6QuH_faryIGsPTGHn08YiGhyKju6p3ldxphOYBt4=.4d811cdc-a526-4c4c-91f3-806877fd5658@github.com>
Message-ID: <qEqac9JOcZL00W5-ytPZ9Fk9S8Dm-bN6jtaEsHQHkDE=.9a8108f8-9aee-4360-861a-842a23649407@github.com>

On Thu, 18 Dec 2025 13:45:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> There's dead code in Symbol that I propose that we remove.
> 
> FWIW, I stared at Symol::is_same_fundamental_type a bit and think that there's a bug in that function and that the second `ends_with` should have been `s->ends_with`.

This pull request has now been integrated.

Changeset: 25248cbf
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/25248cbf00d968e38380f23018eb695773b2b498
Stats:     43 lines in 2 files changed: 0 ins; 43 del; 0 mod

8374007: [lworld] Remove dead code in Symbol

Reviewed-by: fparain, coleenp

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

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

From liach at openjdk.org  Thu Dec 18 16:29:30 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 16:29:30 GMT
Subject: [lworld] RFR: 8373989: [lworld] Since jdk-27+2
 java/lang/reflect/Modifier/toStringTest.java fails
Message-ID: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>

Don't include identity flag for `Modifier.toString` masking. This bit is reserved for synchronized already, and there are other flags on class not printed like sealed or interface, so not printing it here is fine.

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

Commit messages:
 - 8373989 Don't print identity

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

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

From iklam at openjdk.org  Thu Dec 18 17:12:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 18 Dec 2025 17:12:01 GMT
Subject: [lworld] RFR: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
In-Reply-To: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>
References: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>
Message-ID: <mk1a-YDBsFPCeFA8w_eY6yAjoXXGVjHx1sSWhbn5yC4=.9b7cd61e-5c37-496b-9a38-68b604bc97c2@github.com>

On Thu, 18 Dec 2025 13:11:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This replaces Locale with Calendar and removes BaseLocale to test loading with ClassFileLoadHook, like my previous pull request.  Also removes the test from the ProblemList-enable-valhalla.txt file.
> 
> BaseLocale is also loaded and I thought it was the migrated classes that caused early loading for Locale, but it was really the module patching that we used to do for --enable-preview.  See call stack in bug report.
> 
> Tested with the test on windows, where it failed.

LGTM.

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

Marked as reviewed by iklam (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1827#pullrequestreview-3594021883

From rriggs at openjdk.org  Thu Dec 18 17:28:23 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Dec 2025 17:28:23 GMT
Subject: [lworld] RFR: 8373989: [lworld] Since jdk-27+2
 java/lang/reflect/Modifier/toStringTest.java fails
In-Reply-To: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>
References: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>
Message-ID: <3nhmT3V5unlF7t7g0g0dlXTjGZ0B7ZSh8w4vp5HIdrs=.e99567ed-6df6-448a-8410-99a3af0ce116@github.com>

On Thu, 18 Dec 2025 16:23:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> Don't include identity flag for `Modifier.toString` masking. This bit is reserved for synchronized already, and there are other flags on class not printed like sealed or interface, so not printing it here is fine.

looks ok.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1831#pullrequestreview-3594093175

From vromero at openjdk.org  Thu Dec 18 17:52:24 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 17:52:24 GMT
Subject: RFR: 8374027: Restrict parser to only accept null-restrictions in
 selected locations
In-Reply-To: <dxsr-0KuaH9a7YjQa0bZg7TPPDbX4EojtCYXxT1JBS0=.fae94479-d422-4887-9d19-279cf69c48aa@github.com>
References: <dxsr-0KuaH9a7YjQa0bZg7TPPDbX4EojtCYXxT1JBS0=.fae94479-d422-4887-9d19-279cf69c48aa@github.com>
Message-ID: <Nq_wN8FVSNLgf5jE9shzqsA-ubZl3kkSWeb3i14d4FA=.94cd8ee1-bcfd-4eb4-8fa1-8a16db758a94@github.com>

On Thu, 18 Dec 2025 15:51:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Text here

lgtm

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

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1830#pullrequestreview-3594211743

From liach at openjdk.org  Thu Dec 18 18:06:25 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 18:06:25 GMT
Subject: [lworld] RFR: 8373989: [lworld] Since jdk-27+2
 java/lang/reflect/Modifier/toStringTest.java fails
In-Reply-To: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>
References: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>
Message-ID: <PE1vsR8rbozglrGp53KxJKqrmBCqNrEW-OOGYgFNUA4=.66e8de90-3722-4a6b-afd4-d077bcff3bfd@github.com>

On Thu, 18 Dec 2025 16:23:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> Don't include identity flag for `Modifier.toString` masking. This bit is reserved for synchronized already, and there are other flags on class not printed like sealed or interface, so not printing it here is fine.

Thanks for the review! Ran the java/lang/reflect and valhalla/valuetype tests.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1831#issuecomment-3671470241

From liach at openjdk.org  Thu Dec 18 18:06:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 18:06:26 GMT
Subject: [lworld] Integrated: 8373989: [lworld] Since jdk-27+2
 java/lang/reflect/Modifier/toStringTest.java fails
In-Reply-To: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>
References: <clRV5_kKGG5l0JG2gLe3FQynAez0IbccfR4ZSlmJVuA=.ef360d88-3003-4d44-ad3e-6d6a323352d7@github.com>
Message-ID: <-LjKcSZtBRrP1PSHruKZr55hCYET2PpYzQFNiklKD6o=.e59806f2-d1ed-48c7-aca0-38cf6e40c5a1@github.com>

On Thu, 18 Dec 2025 16:23:34 GMT, Chen Liang <liach at openjdk.org> wrote:

> Don't include identity flag for `Modifier.toString` masking. This bit is reserved for synchronized already, and there are other flags on class not printed like sealed or interface, so not printing it here is fine.

This pull request has now been integrated.

Changeset: 05f121e6
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/05f121e6a8dcf9c9ee0378c7998f89af418ab5f3
Stats:     3 lines in 2 files changed: 1 ins; 1 del; 1 mod

8373989: [lworld] Since jdk-27+2 java/lang/reflect/Modifier/toStringTest.java fails

Reviewed-by: rriggs

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

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

From coleenp at openjdk.org  Thu Dec 18 18:30:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 18:30:50 GMT
Subject: [lworld] Integrated: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
In-Reply-To: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>
References: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>
Message-ID: <nKEM0EtyI_c_3meDg9X_bzCjF1Ukb-vmK8mZOfYxLi8=.4191f7a3-1e47-49d6-85e2-732acfd21f51@github.com>

On Thu, 18 Dec 2025 13:11:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This replaces Locale with Calendar and removes BaseLocale to test loading with ClassFileLoadHook, like my previous pull request.  Also removes the test from the ProblemList-enable-valhalla.txt file.
> 
> BaseLocale is also loaded and I thought it was the migrated classes that caused early loading for Locale, but it was really the module patching that we used to do for --enable-preview.  See call stack in bug report.
> 
> Tested with the test on windows, where it failed.

This pull request has now been integrated.

Changeset: 1e6e72e2
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/1e6e72e246608d872d7733559da7ba29ed10f69a
Stats:     6 lines in 2 files changed: 0 ins; 2 del; 4 mod

8372686: [lworld] runtime/cds/serviceability/ReplaceCriticalClasses.java fails with --enable-preview

Reviewed-by: iklam

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

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

From coleenp at openjdk.org  Thu Dec 18 18:30:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 18:30:50 GMT
Subject: [lworld] RFR: 8372686: [lworld]
 runtime/cds/serviceability/ReplaceCriticalClasses.java fails with
 --enable-preview
In-Reply-To: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>
References: <0NLbmBkEN-IkZbWWf3EtomesG7ZkjP_uuy2P9G14J1g=.a38dd747-463f-4d55-9cee-909bf1af3dc7@github.com>
Message-ID: <j9ezxHhLOKkn3UTWPhLBB1aCAvNrYaMG9tAiB4Tl5iQ=.1d5ab995-9ec7-4068-b68b-3c56ee61fd50@github.com>

On Thu, 18 Dec 2025 13:11:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This replaces Locale with Calendar and removes BaseLocale to test loading with ClassFileLoadHook, like my previous pull request.  Also removes the test from the ProblemList-enable-valhalla.txt file.
> 
> BaseLocale is also loaded and I thought it was the migrated classes that caused early loading for Locale, but it was really the module patching that we used to do for --enable-preview.  See call stack in bug report.
> 
> Tested with the test on windows, where it failed.

Thanks Ioi.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1827#issuecomment-3671583162

From vromero at openjdk.org  Thu Dec 18 18:42:17 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 18:42:17 GMT
Subject: [lworld] RFR: 8374028: [lworld] LoadableDescriptors order should be
 deterministic
Message-ID: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>

Adding determinism to the order of descriptors referred to by the LoadableDescriptors attribute. Kind of hard to test, no regression test provided, tested it offline though, but we are basically making making the data structure holding the descriptors deterministic,

TIA

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

Commit messages:
 - 8374028: [lworld] LoadableDescriptors order should be deterministic

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

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

From mcimadamore at openjdk.org  Thu Dec 18 18:44:58 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Dec 2025 18:44:58 GMT
Subject: Integrated: 8374027: Restrict parser to only accept null-restrictions
 in selected locations
In-Reply-To: <dxsr-0KuaH9a7YjQa0bZg7TPPDbX4EojtCYXxT1JBS0=.fae94479-d422-4887-9d19-279cf69c48aa@github.com>
References: <dxsr-0KuaH9a7YjQa0bZg7TPPDbX4EojtCYXxT1JBS0=.fae94479-d422-4887-9d19-279cf69c48aa@github.com>
Message-ID: <0ica4hRwXQlddZIoo9FfUN3J82Ej4pMEEv3g4YUZ74k=.f5ae763a-2f33-400b-b7a2-56949f2e055c@github.com>

On Thu, 18 Dec 2025 15:51:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Text here

This pull request has now been integrated.

Changeset: c98961d6
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/c98961d66bd34a2a5fbd9b8e451581ad5b982d20
Stats:     141 lines in 7 files changed: 58 ins; 49 del; 34 mod

8374027: Restrict parser to only accept null-restrictions in selected locations

Reviewed-by: vromero

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

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

From liach at openjdk.org  Thu Dec 18 18:53:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Dec 2025 18:53:39 GMT
Subject: [lworld] RFR: 8374028: [lworld] LoadableDescriptors order should
 be deterministic
In-Reply-To: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
References: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
Message-ID: <aS9WsWvLfmxQzCY-Oime79ferVBppSmKiBfiQ6uOQKI=.b74fa4a0-1ee8-4e69-abc9-afb3f3f94a73@github.com>

On Thu, 18 Dec 2025 18:36:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Adding determinism to the order of descriptors referred to by the LoadableDescriptors attribute. Kind of hard to test, no regression test provided, tested it offline though, but we are basically making making the data structure holding the descriptors deterministic,
> 
> TIA

A surprising detail.

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

Marked as reviewed by liach (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1833#pullrequestreview-3594555983

From rriggs at openjdk.org  Thu Dec 18 18:57:34 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Dec 2025 18:57:34 GMT
Subject: [lworld] RFR: 8374028: [lworld] LoadableDescriptors order should
 be deterministic
In-Reply-To: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
References: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
Message-ID: <A0Fyaumq-uKiJcrm1sNatNZPEDGeV-ZohZQkNDe5VTs=.0c640f0b-1b3c-400a-a7f7-97d348ca2710@github.com>

On Thu, 18 Dec 2025 18:36:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Adding determinism to the order of descriptors referred to by the LoadableDescriptors attribute. Kind of hard to test, no regression test provided, tested it offline though, but we are basically making making the data structure holding the descriptors deterministic,
> 
> TIA

Looks good.

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

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1833#pullrequestreview-3594578910

From coleenp at openjdk.org  Thu Dec 18 19:29:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 19:29:11 GMT
Subject: [lworld] RFR: 8373875: [lworld]
 runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview
In-Reply-To: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
References: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
Message-ID: <qeTYqaWavj6Rvy3qwsMKVdcQN-HEKwNfZgUnz_M17r0=.9db1572b-fe28-477c-b90b-2ab9272590dc@github.com>

On Thu, 18 Dec 2025 16:49:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> After [JDK-8370904](https://bugs.openjdk.org/browse/JDK-8370904) was integrated, several problem listed tests should now work due thanks to heap dumping being enabled.

Looks good!

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

PR Review: https://git.openjdk.org/valhalla/pull/1832#pullrequestreview-3594701914

From matsaave at openjdk.org  Thu Dec 18 19:29:10 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 18 Dec 2025 19:29:10 GMT
Subject: [lworld] RFR: 8373875: [lworld]
 runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview
Message-ID: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>

After [JDK-8370904](https://bugs.openjdk.org/browse/JDK-8370904) was integrated, several problem listed tests should now work due thanks to heap dumping being enabled.

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

Commit messages:
 - Removed more tests from problem list
 - 8373875: [lworld] runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview

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

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

From vromero at openjdk.org  Thu Dec 18 20:03:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 20:03:03 GMT
Subject: [lworld] RFR: 8374028: [lworld] LoadableDescriptors order should
 be deterministic
In-Reply-To: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
References: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
Message-ID: <TDBpXwP1fgLWAOx-F95INz3YjACp-QAFLc-HPKBK0c8=.b2cb63d1-31fb-4ef3-9ff4-ba50f5d68338@github.com>

On Thu, 18 Dec 2025 18:36:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Adding determinism to the order of descriptors referred to by the LoadableDescriptors attribute. Kind of hard to test, no regression test provided, tested it offline though, but we are basically making making the data structure holding the descriptors deterministic,
> 
> TIA

thanks for the reviews

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

PR Comment: https://git.openjdk.org/valhalla/pull/1833#issuecomment-3672012016

From coleenp at openjdk.org  Thu Dec 18 20:07:54 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 20:07:54 GMT
Subject: [lworld] RFR: 8373875: [lworld]
 runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview
In-Reply-To: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
References: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
Message-ID: <oF7QRhpg_vWRlyv77FTptr8FbX0H1sOo6BdDZEDu3Ms=.42ca64bd-f03d-46f4-8916-e5fa69f3befb@github.com>

On Thu, 18 Dec 2025 16:49:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> After [JDK-8370904](https://bugs.openjdk.org/browse/JDK-8370904) was integrated, several problem listed tests should now work due thanks to heap dumping being enabled.

Marked as reviewed by coleenp (Committer).

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

PR Review: https://git.openjdk.org/valhalla/pull/1832#pullrequestreview-3594841750

From vromero at openjdk.org  Thu Dec 18 20:14:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 20:14:45 GMT
Subject: [lworld] Integrated: 8374028: [lworld] LoadableDescriptors order
 should be deterministic
In-Reply-To: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
References: <c5z6oJVer0y5PNqfeXaHcq8tbgHb2qqjxVf4pR_lNjc=.ab3fa20d-4589-437a-b4ed-7083a0fe5f45@github.com>
Message-ID: <Z-rdfs2VF8L4DAWmZXfStFDKNdpeJtMCrQJFc6a0Hsc=.cea8a053-3f39-4aba-b767-7dda43a73714@github.com>

On Thu, 18 Dec 2025 18:36:10 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Adding determinism to the order of descriptors referred to by the LoadableDescriptors attribute. Kind of hard to test, no regression test provided, tested it offline though, but we are basically making making the data structure holding the descriptors deterministic,
> 
> TIA

This pull request has now been integrated.

Changeset: e98a1493
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e98a14938b735d282c4335c67e2cd2201029b900
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8374028: [lworld] LoadableDescriptors order should be deterministic

Reviewed-by: liach, rriggs

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

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

From fparain at openjdk.org  Thu Dec 18 20:44:04 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 18 Dec 2025 20:44:04 GMT
Subject: [lworld] RFR: 8373708: [lworld] InstanceKlass::null_marker_offset(int
 i) is misleading
Message-ID: <Sesb7K9BhLA_iykequL74JoqQ6-M1lHInSG1pva2jxQ=.82b9d622-c5f3-4c05-883a-9e711d38b2f5@github.com>

Please review this very small change to rename InstanceKlass::null_marker_offset(int i) into InstanceKlass::field_null_marker_offset(int i) to highlight the fact that the method returns the null marker offset of a given field and not the null marker offset for the current class.

Thank you.

Fred

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

Commit messages:
 - Renaming of null_marker_offset(int index)

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

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

From rriggs at openjdk.org  Thu Dec 18 21:16:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Dec 2025 21:16:51 GMT
Subject: [lworld] RFR: 8362252: [lworld] Possible synchronization issue in
 jdk/internal/jimage/ImageReader.java
In-Reply-To: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com>
References: <6Tx7jSFas_nHB9RZY4Rsx6O6_P4jFZQvuQIMRVnU-3I=.c886f94e-8a39-491b-aa96-2d717f5a2073@github.com>
Message-ID: <xtbO6tYEKQxlBvjwN7aXmdbYerqmz1x99THjsXZQDvY=.799a91a1-7307-4035-9957-02893b978134@github.com>

On Thu, 18 Dec 2025 13:36:12 GMT, David Beaumont <duke at openjdk.org> wrote:

> Tidying up syncrhonization around shared image.

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

> 414:                     OPEN_FILES.put(key, sharedReader);
> 415:                 } else if (sharedReader.getByteOrder() != byteOrder) {
> 416:                     throw new IOException("\"" + sharedReader.getName() + "\" is not an image file");

Its pre-existing, but ...
Testing the byteOrder and then throwing an exception that says it is not an Image file doesn't make sense.

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

PR Review Comment: https://git.openjdk.org/valhalla/pull/1828#discussion_r2632646830

From stefank at openjdk.org  Thu Dec 18 21:18:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 18 Dec 2025 21:18:54 GMT
Subject: [lworld] RFR: 8373708: [lworld]
 InstanceKlass::null_marker_offset(int i) is misleading
In-Reply-To: <Sesb7K9BhLA_iykequL74JoqQ6-M1lHInSG1pva2jxQ=.82b9d622-c5f3-4c05-883a-9e711d38b2f5@github.com>
References: <Sesb7K9BhLA_iykequL74JoqQ6-M1lHInSG1pva2jxQ=.82b9d622-c5f3-4c05-883a-9e711d38b2f5@github.com>
Message-ID: <n5e-AggX2y-C-mFLjFHjEIuTpFn4LHyk0goF7AsYKqc=.31c1b3fc-d440-4b01-bc2c-9352e20cf776@github.com>

On Thu, 18 Dec 2025 20:32:27 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this very small change to rename InstanceKlass::null_marker_offset(int i) into InstanceKlass::field_null_marker_offset(int i) to highlight the fact that the method returns the null marker offset of a given field and not the null marker offset for the current class.
> 
> Thank you.
> 
> Fred

Looks good. Thanks for fixing!

-------------

Marked as reviewed by stefank (Author).

PR Review: https://git.openjdk.org/valhalla/pull/1835#pullrequestreview-3595090068

From rriggs at openjdk.org  Thu Dec 18 21:28:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 Dec 2025 21:28:52 GMT
Subject: [lworld] RFR: 8373930: [lworld] Restore Objects.equals use of identity
 check
Message-ID: <VFiPV1otEUIUioRnfUMPmYLtZSAyB1dVu8OAtOS4SiA=.1704af74-39d1-42ba-8c55-ef7b9fff12cd@github.com>

Revert "8366841: [lworld] Objects.equals without identity comparison".  (Almost all)
Removing the condition on --enable-preview.
Correct the .equals method in test SimplValueGraphs.SimpleValue.

-------------

Commit messages:
 - Restore the mainline implementation of Objects.equal

Changes: https://git.openjdk.org/valhalla/pull/1836/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1836&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373930
  Stats: 10 lines in 2 files changed: 0 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1836.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1836/head:pull/1836

PR: https://git.openjdk.org/valhalla/pull/1836

From vromero at openjdk.org  Thu Dec 18 22:52:24 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 22:52:24 GMT
Subject: RFR: 8374046: [bworld] Fix failing regression tests
Message-ID: <nwKPuK_XjmlePwqg4Ccbp4aBQQYncbMMu8sIgx9QQto=.5ebf29f8-b04f-48dd-ace2-67afcd94de71@github.com>

fixing a couple of regression tests that were failing since we cloned from lw5

-------------

Commit messages:
 - Merge branch 'bworld' into JDK-8374046
 - 8374046: [bworld] Fix failing regression tests

Changes: https://git.openjdk.org/valhalla/pull/1838/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1838&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374046
  Stats: 6 lines in 3 files changed: 3 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1838.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1838/head:pull/1838

PR: https://git.openjdk.org/valhalla/pull/1838

From coleenp at openjdk.org  Thu Dec 18 22:52:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 18 Dec 2025 22:52:30 GMT
Subject: [lworld] RFR: 8367408: [lworld]
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails
Message-ID: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>

This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class.  The sig_cc adapter for valhalla aren't saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348).  This change moves where they are regenerated to where the method is linked.

Testing with tier1-4. in progress, and with the failed test.

-------------

Commit messages:
 - 8367408: [lworld] runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails

Changes: https://git.openjdk.org/valhalla/pull/1837/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1837&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367408
  Stats: 31 lines in 3 files changed: 17 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1837.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1837/head:pull/1837

PR: https://git.openjdk.org/valhalla/pull/1837

From vromero at openjdk.org  Thu Dec 18 22:55:29 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 Dec 2025 22:55:29 GMT
Subject: Integrated: 8374046: [bworld] Fix failing regression tests
In-Reply-To: <nwKPuK_XjmlePwqg4Ccbp4aBQQYncbMMu8sIgx9QQto=.5ebf29f8-b04f-48dd-ace2-67afcd94de71@github.com>
References: <nwKPuK_XjmlePwqg4Ccbp4aBQQYncbMMu8sIgx9QQto=.5ebf29f8-b04f-48dd-ace2-67afcd94de71@github.com>
Message-ID: <UbQJLHWmXOlpOoaVOQi3sWtKqi0x4gkseV71iDhXBl8=.69565cad-fb55-473b-8bfd-07d8001301f4@github.com>

On Thu, 18 Dec 2025 22:46:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing a couple of regression tests that were failing since we cloned from lw5

This pull request has now been integrated.

Changeset: 045e0acb
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/045e0acb8ee6ca92595069fa63b2db30ae85cc0e
Stats:     6 lines in 3 files changed: 3 ins; 1 del; 2 mod

8374046: [bworld] Fix failing regression tests

-------------

PR: https://git.openjdk.org/valhalla/pull/1838

From matsaave at openjdk.org  Fri Dec 19 00:31:40 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 19 Dec 2025 00:31:40 GMT
Subject: [lworld] RFR: 8373875: [lworld]
 runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview
In-Reply-To: <oF7QRhpg_vWRlyv77FTptr8FbX0H1sOo6BdDZEDu3Ms=.42ca64bd-f03d-46f4-8916-e5fa69f3befb@github.com>
References: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
 <oF7QRhpg_vWRlyv77FTptr8FbX0H1sOo6BdDZEDu3Ms=.42ca64bd-f03d-46f4-8916-e5fa69f3befb@github.com>
Message-ID: <0jfVbdUczCNr9NmgwICWDJFdJZyIUAx8C7h7lsrbs78=.28527bdb-f7da-4c0c-9758-8ad91f46e24f@github.com>

On Thu, 18 Dec 2025 20:05:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> After [JDK-8370904](https://bugs.openjdk.org/browse/JDK-8370904) was integrated, several problem listed tests should now work due thanks to heap dumping being enabled.
>
> Marked as reviewed by coleenp (Committer).

Thanks for the review @coleenp!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1832#issuecomment-3672858468

From matsaave at openjdk.org  Fri Dec 19 00:31:41 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 19 Dec 2025 00:31:41 GMT
Subject: [lworld] Integrated: 8373875: [lworld]
 runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview
In-Reply-To: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
References: <ywo-PJLXOGg7B2eYBHLpPYYtX5fclxHQ0Jvi-KYZi_s=.d6acea90-36bd-4783-851d-a0ffb416bd9d@github.com>
Message-ID: <sriaFY3PRHvqMPr3VJNFjIrgC3pZL35EZMjSot3op0Y=.894ddb73-2642-4e9e-8b98-2483624489b5@github.com>

On Thu, 18 Dec 2025 16:49:47 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> After [JDK-8370904](https://bugs.openjdk.org/browse/JDK-8370904) was integrated, several problem listed tests should now work due thanks to heap dumping being enabled.

This pull request has now been integrated.

Changeset: 69399ced
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/69399cedf6fe208832a66c134d370af860154bc2
Stats:     10 lines in 3 files changed: 0 ins; 10 del; 0 mod

8373875: [lworld] runtime/cds/DumpSymbolAndStringTable.java fails with --enable-preview
8373596: [lworld] Various CDS crashes due to assert(_heap_load_mode != HeapArchiveMode::_uninitialized) failed: not initialized yet
8372743: [lworld] jdk/internal/misc/CDS/ArchivedEnumTest.java fails with --enable-preview
8372607: [lworld] runtime/cds/SharedStringsDedup.java fails with --enable-preview
8372606: [lworld] runtime/cds/SharedStringsRunAuto.java fails with --enable-preview
8372265: [lworld] HelloInlineClassApp "Static field rectangle not as expected"
8371456: [lworld] ResolvedConstants.java fails since jdk-26+22

Reviewed-by: coleenp

-------------

PR: https://git.openjdk.org/valhalla/pull/1832

From qamai at openjdk.org  Fri Dec 19 03:10:43 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 19 Dec 2025 03:10:43 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass [v3]
In-Reply-To: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
Message-ID: <EHcGM3NLBvylxMkBEgrD3Fun79eSQmVZdX2kMbjzlrg=.6012811d-ffa5-4e74-9038-4cd395bb5b33@github.com>

> Hi,
> 
> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
> 
> Please kindly review, 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 six commits:

 - wrong value is passed as flat
 - remove redundant changes
 - Merge branch 'lworld' into ciRefArray
 - Revert "can only infer klass if exact"
   
   This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24.
 - can only infer klass if exact
 - Refactor ciObjArrayKlass to align with the VM type

-------------

Changes: https://git.openjdk.org/valhalla/pull/1739/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1739&range=02
  Stats: 315 lines in 15 files changed: 110 ins; 146 del; 59 mod
  Patch: https://git.openjdk.org/valhalla/pull/1739.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1739/head:pull/1739

PR: https://git.openjdk.org/valhalla/pull/1739

From thartmann at openjdk.org  Fri Dec 19 03:10:45 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 03:10:45 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass [v2]
In-Reply-To: <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
 <jgXg0hf9ainiob6dHF4-wjae9V6Z3vxPLiX-NQqNwFU=.c8c2cd0f-4086-4c58-86d6-ef4cc1884b04@github.com>
Message-ID: <NL4RPRE98t3V0mqZ6y5ryR92JUKCdKluoKxyo7qO2F4=.1e59c402-a800-4fba-a1bc-0183ab59a2fd@github.com>

On Mon, 17 Nov 2025 14:38:02 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
>> 
>> Please kindly review, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   can only infer klass if exact

Right, I think so too, the latest version hits more issues :(

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1739#issuecomment-3543529572

From qamai at openjdk.org  Fri Dec 19 03:17:24 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 19 Dec 2025 03:17:24 GMT
Subject: [lworld] RFR: 8370880: [lworld] Split ciObjArrayKlass into
 ciRefArrayKlass and ciFlatArrayKlass [v3]
In-Reply-To: <EHcGM3NLBvylxMkBEgrD3Fun79eSQmVZdX2kMbjzlrg=.6012811d-ffa5-4e74-9038-4cd395bb5b33@github.com>
References: <Q8DDyvMJ21ZH5rBKBpgIQUhbcSmYYtdNVmVHnJhOKQg=.8268c713-c576-47fc-b6aa-f39e8a988965@github.com>
 <EHcGM3NLBvylxMkBEgrD3Fun79eSQmVZdX2kMbjzlrg=.6012811d-ffa5-4e74-9038-4cd395bb5b33@github.com>
Message-ID: <fkVhmx7cVfBjt2ZAwQOQA0aVbDxYCvTf3SKfqfhadcs=.e0395dcc-7d49-4a73-8fc8-a8612369a410@github.com>

On Fri, 19 Dec 2025 03:10:43 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This PR splits `ciObjArrayKlass` into `ciRefArrayKlass` and `ciFlatArrayKlass`, aligns the hierarchy with the corresponding types of the VM.
>> 
>> Please kindly review, 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 six commits:
> 
>  - wrong value is passed as flat
>  - remove redundant changes
>  - Merge branch 'lworld' into ciRefArray
>  - Revert "can only infer klass if exact"
>    
>    This reverts commit be6143624d30c9ebfa560dd8161aa70270c68d24.
>  - can only infer klass if exact
>  - Refactor ciObjArrayKlass to align with the VM type

I think this PR is ready for review again.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1739#issuecomment-3673310324

From mchevalier at openjdk.org  Fri Dec 19 08:04:07 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 08:04:07 GMT
Subject: [lworld] RFR: 8372806: [lworld] x64: save bad values instead of rfp
 and lr above the extension space
Message-ID: <fkJ2JyseqNFjLfzcUeInkDCEuO6bx5-UvrRisFh_Jo8=.30609121-047f-47fa-919c-03aacd572c62@github.com>

That's the x86 counterpart of [JDK-8371993](https://bugs.openjdk.org/browse/JDK-8371993).

I've added some comments, using the offsets given in `frame_x86.hpp` to make sure to put the frame start at the right place. In particular, the frame start is 2 pointer sizes under the sender's sp:

https://github.com/openjdk/valhalla/blob/3c41c2aa442076827cb4480373a1d481e481cdf1/src/hotspot/cpu/x86/frame_x86.hpp#L61-L62

Unlike aarch64, with x64 we have only one copy of rbp. As with aarch64, I had to get rid of an assert that can't be checked anymore. A small price to pay.

Now, in debug, instead of

pop    r13
sub    rsp,0x20
push   r13

we have

pop    r13
sub    rsp,0x20
mov    DWORD PTR [rsp-0x4],0xdeadda7a
mov    DWORD PTR [rsp-0x8],0xdeadda7a
sub    rsp,0x8

I've kept the `pop r13` to limit the difference of behavior between debug and product builds: both will overwrite `r13` with the return address, whether it's a good idea or not.

And at runtime, on my favorite `compiler/valhalla/inlinetypes/CorrectlyRestoreRfp.java` example, instead of the stack:

0x7fd7345fe660:	0x000000042724f5d0	0x00007fd7345fe750  <-- rsp
0x7fd7345fe670:	0xffffffffffffffff	0x00007fd740acc0f7
0x7fd7345fe680:	0x00007fd700000000	0x000000042724f5d0
0x7fd7345fe690:	0x000000056f517f28	0x00007fd7390002a6
0x7fd7345fe6a0:	0x00007fd72c90c8b3	0x0000000000000078  <--             #                | sp_inc
0x7fd7345fe6b0:	0x00007fd7345fe750	0x00007fd740541306  <-- rsp - 0x50  #            rbp | return address
0x7fd7345fe6c0:	0x000000056f49f4e0	0x000000042724f5d0  <--             #  String (arg2) | Object (arg3)
0x7fd7345fe6d0:	0x0000000000000000	0x00007fd740541306  <-- rsp - 0x70  # boolean (arg4) | return address
0x7fd7345fe6e0:	0x00007fd740541306	0x0000000000000000
0x7fd7345fe6f0:	0x000000042724f5d0	0x000000056f49f4e0

we have

0x7f93cfdfe660:	0x000000042724f5d0	0x00007f93cfdfe750  <-- rsp
0x7f93cfdfe670:	0xffffffffffffffff	0x00007f93e4acc107
0x7f93cfdfe680:	0x00007f9300000000	0x000000042724f5d0
0x7f93cfdfe690:	0x000000056f517fb0	0x00007f93dd0002a6
0x7f93cfdfe6a0:	0x00007f93d090c8b3	0x0000000000000078  <--             #                | sp_inc
0x7f93cfdfe6b0:	0x00007f93cfdfe750	0xdeadda7adeadda7a  <-- rsp - 0x50  #            rbp | >>>> bad word <<<<
0x7f93cfdfe6c0:	0x000000056f49f540	0x000000042724f5d0  <--             #  String (arg2) | Object (arg3)
0x7f93cfdfe6d0:	0x0000000000000000	0x00007f93e4541306  <-- rsp - 0x70  # boolean (arg4) | return address
0x7f93cfdfe6e0:	0x00007f93e4541306	0x0000000000000000
0x7f93cfdfe6f0:	0x000000042724f5d0	0x000000056f49f540


I had to problem list some virtual thread tests, in the same fashion as for aarch64, as it used the wrong return address. The assert I had to remove was a sign that only one of the return address is updated in case of deopt, so only one of them is reliable. To help with that, I've added `frame::compiled_frame_details` like for aarch64, that makes sure to do all the fixing internally.

Thanks,
Marc

-------------

Commit messages:
 - Add frame::compiled_frame_details + problem list
 - Comments and zap

Changes: https://git.openjdk.org/valhalla/pull/1839/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372806
  Stats: 158 lines in 7 files changed: 113 ins; 29 del; 16 mod
  Patch: https://git.openjdk.org/valhalla/pull/1839.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1839/head:pull/1839

PR: https://git.openjdk.org/valhalla/pull/1839

From thartmann at openjdk.org  Fri Dec 19 08:23:25 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 08:23:25 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996
In-Reply-To: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
Message-ID: <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>

On Thu, 18 Dec 2025 08:26:03 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Let's proceed piece by piece.
> 
> # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp`
> 
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220
> 
> `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are.
> 
> But let's dig a bit, that will be useful later!
> 
> 
>    push_call_clobbered_registers()
> => push_call_clobbered_registers_except(exclude = empty set)
> => push(call_clobbered_gp_registers() - exclude, sp)  // with exclude = empty set
> 
> So, we save at least `call_clobbered_gp_registers` which is defined as:
> 
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620
> 
> So, we save r0-r7 and r10-r17
> 
> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp`
> 
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124
> 
> Digging the history looks like it still makes sense, it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.
> 
> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_x86.cpp`
> 
> Same as before. But it's not even guarantee that `InlineTypePassFieldsAsArgs` is true. We can have such a backtrace:
> 
> CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
> CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
> MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
> do_oop_store (templateTable_x86.cpp:148)
> (called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))
> 
> where the last give `r8` for `tmp3`. It is not quite clear to me why we don't have a problem in mainline, because it looks like corrupting address base register is a bad idea given that we use it after.
> 
> # `MacroAssembler::unpack_inline_helper` in `macroAssembler_aarch64.cpp`
> 
> ## First part
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7163-L7166
> 
> Yes, these registers are saved, as we saw above! I've added some asserts to make sure that they are still in the `call_clobbered_gp_registers()` set. But it seems a bit ...

Thanks for the detailed analysis Marc! Changes look good to me, I just added a few comments.

src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp line 117:

> 115:     if (!precise || (dst.index() == noreg && dst.offset() == 0)) {
> 116:       if (tmp3 != noreg) {
> 117:         // When tmp3 is given, we cannot corrupt the dst.base() register (from MacroAssembler::pack_inline_helper or do_oop_store)

> it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.

It's only the `__ mov(tmp3, dst.base());` that could potentially be removed, right? Not the entire branch. If the `mov` is still needed, should it be guarded by `InlineTypePassFieldsAsArgs`?

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 7172:

> 7170:   assert(clobbered_gp_regs.contains(tmp1), "tmp1 must be saved explicitly if it's not a clobber");
> 7171:   assert(clobbered_gp_regs.contains(tmp2), "tmp2 must be saved explicitly if it's not a clobber");
> 7172:   assert(clobbered_gp_regs.contains(r14), "r14 must be saved explicitly if it's not a clobber");

Great idea with these asserts!

src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 241:

> 239:   // Barriers might be emitted when converting between (scalarized) calling conventions for inline
> 240:   // types. Save all argument registers before calling into the runtime.
> 241:   __ push_call_clobbered_registers();

I think this comment should just be reverted to the mainline state because it's not specific to the scalarized calling convention.

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1824#pullrequestreview-3597477751
PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634139562
PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634140381
PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634137724

From mchevalier at openjdk.org  Fri Dec 19 08:33:31 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 08:33:31 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996
In-Reply-To: <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
 <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
Message-ID: <gxMGgEDE8XQfTuVtnAtGx5maV9-9MKsUVGJqWi_rv58=.9a29dc11-593d-4bc4-807c-ec5884d1b969@github.com>

On Fri, 19 Dec 2025 08:15:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Let's proceed piece by piece.
>> 
>> # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp`
>> 
>> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220
>> 
>> `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are.
>> 
>> But let's dig a bit, that will be useful later!
>> 
>> 
>>    push_call_clobbered_registers()
>> => push_call_clobbered_registers_except(exclude = empty set)
>> => push(call_clobbered_gp_registers() - exclude, sp)  // with exclude = empty set
>> 
>> So, we save at least `call_clobbered_gp_registers` which is defined as:
>> 
>> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620
>> 
>> So, we save r0-r7 and r10-r17
>> 
>> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp`
>> 
>> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124
>> 
>> Digging the history looks like it still makes sense, it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.
>> 
>> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_x86.cpp`
>> 
>> Same as before. But it's not even guarantee that `InlineTypePassFieldsAsArgs` is true. We can have such a backtrace:
>> 
>> CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
>> CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
>> MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
>> do_oop_store (templateTable_x86.cpp:148)
>> (called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))
>> 
>> where the last give `r8` for `tmp3`. It is not quite clear to me why we don't have a problem in mainline, because it looks like corrupting address base register is a bad idea given that we use it after.
>> 
>> # `MacroAssembler::unpack_inline_helper` in `macroAssembler_aarch64.cpp`
>> 
>> ## First part
>> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7163-L7166
>> 
>> Yes, these registers are saved, as we saw above! I've added some asserts to mak...
>
> src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp line 117:
> 
>> 115:     if (!precise || (dst.index() == noreg && dst.offset() == 0)) {
>> 116:       if (tmp3 != noreg) {
>> 117:         // When tmp3 is given, we cannot corrupt the dst.base() register (from MacroAssembler::pack_inline_helper or do_oop_store)
> 
>> it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.
> 
> It's only the `__ mov(tmp3, dst.base());` that could potentially be removed, right? Not the entire branch. If the `mov` is still needed, should it be guarded by `InlineTypePassFieldsAsArgs`?

I don't think we can just remove the `mov` part.

I don't really understand how to interpret that. We have

        __ mov(tmp3, dst.base());
        store_check(masm, tmp3, dst);

do you suggest we write

        store_check(masm, tmp3, dst);

? But then, `tmp3` is not set to anything meaningful yet. Or 

        store_check(masm, dst.base(), dst);

But that is exactly the else-branch. Moreover, I've tried to guard and it makes some test fails. For instance, we can come from

CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
do_oop_store (templateTable_x86.cpp:148)
(called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))

that doesn't need `InlineTypePassFieldsAsArgs` but will give `tmp3` and if we don't use it here (for instance, if I replace the condition by `InlineTypePassFieldsAsArgs && tmp3 != noreg`), we get various test failures.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634178710

From mchevalier at openjdk.org  Fri Dec 19 08:44:08 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 08:44:08 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996 [v2]
In-Reply-To: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
Message-ID: <QWSlQpFOvrU06X9D6QTpxSWrDo5maJOAHz9bsg9O7I4=.2d39386f-4cfa-4267-8e9c-382a3c28e1c9@github.com>

> Let's proceed piece by piece.
> 
> # `G1BarrierSetAssembler::g1_write_barrier_pre` in `g1BarrierSetAssembler_aarch64.cpp`
> 
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/g1/g1BarrierSetAssembler_aarch64.cpp#L216-L220
> 
> `push_call_clobbered_registers`/`pop_call_clobbered_registers` should be enough around a runtime call, that's what clobbered registers are.
> 
> But let's dig a bit, that will be useful later!
> 
> 
>    push_call_clobbered_registers()
> => push_call_clobbered_registers_except(exclude = empty set)
> => push(call_clobbered_gp_registers() - exclude, sp)  // with exclude = empty set
> 
> So, we save at least `call_clobbered_gp_registers` which is defined as:
> 
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L3614-L3620
> 
> So, we save r0-r7 and r10-r17
> 
> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_aarch64.cpp`
> 
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp#L116-L124
> 
> Digging the history looks like it still makes sense, it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.
> 
> # `CardTableBarrierSetAssembler::oop_store_at` in `cardTableBarrierSetAssembler_x86.cpp`
> 
> Same as before. But it's not even guarantee that `InlineTypePassFieldsAsArgs` is true. We can have such a backtrace:
> 
> CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
> CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
> MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
> do_oop_store (templateTable_x86.cpp:148)
> (called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))
> 
> where the last give `r8` for `tmp3`. It is not quite clear to me why we don't have a problem in mainline, because it looks like corrupting address base register is a bad idea given that we use it after.
> 
> # `MacroAssembler::unpack_inline_helper` in `macroAssembler_aarch64.cpp`
> 
> ## First part
> https://github.com/openjdk/valhalla/blob/1077e4f9f06336af30d95fc28cbab4d31c9f2a44/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L7163-L7166
> 
> Yes, these registers are saved, as we saw above! I've added some asserts to make sure that they are still in the `call_clobbered_gp_registers()` set. But it seems a bit ...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  Pick the right comment again

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1824/files
  - new: https://git.openjdk.org/valhalla/pull/1824/files/3f013c81..bf65d118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1824&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1824&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1824.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1824/head:pull/1824

PR: https://git.openjdk.org/valhalla/pull/1824

From mchevalier at openjdk.org  Fri Dec 19 08:44:10 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 08:44:10 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996 [v2]
In-Reply-To: <gxMGgEDE8XQfTuVtnAtGx5maV9-9MKsUVGJqWi_rv58=.9a29dc11-593d-4bc4-807c-ec5884d1b969@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
 <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
 <gxMGgEDE8XQfTuVtnAtGx5maV9-9MKsUVGJqWi_rv58=.9a29dc11-593d-4bc4-807c-ec5884d1b969@github.com>
Message-ID: <tgzjIADOjr42MB_RL0vtTh7m1UFb-nRXFEjO_jLJWJg=.b58e86fc-a161-49a9-a669-05c4bd7cf402@github.com>

On Fri, 19 Dec 2025 08:30:37 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp line 117:
>> 
>>> 115:     if (!precise || (dst.index() == noreg && dst.offset() == 0)) {
>>> 116:       if (tmp3 != noreg) {
>>> 117:         // When tmp3 is given, we cannot corrupt the dst.base() register (from MacroAssembler::pack_inline_helper or do_oop_store)
>> 
>>> it doesn't look like an accident. If we remove the if-branch, tests are totally on fire. Let's keep it.
>> 
>> It's only the `__ mov(tmp3, dst.base());` that could potentially be removed, right? Not the entire branch. If the `mov` is still needed, should it be guarded by `InlineTypePassFieldsAsArgs`?
>
> I don't think we can just remove the `mov` part.
> 
> I don't really understand how to interpret that. We have
> 
>         __ mov(tmp3, dst.base());
>         store_check(masm, tmp3, dst);
> 
> do you suggest we write
> 
>         store_check(masm, tmp3, dst);
> 
> ? But then, `tmp3` is not set to anything meaningful yet. Or 
> 
>         store_check(masm, dst.base(), dst);
> 
> But that is exactly the else-branch. Moreover, I've tried to guard and it makes some test fails. For instance, we can come from
> 
> CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
> CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
> MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
> do_oop_store (templateTable_x86.cpp:148)
> (called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))
> 
> that doesn't need `InlineTypePassFieldsAsArgs` but will give `tmp3` and if we don't use it here (for instance, if I replace the condition by `InlineTypePassFieldsAsArgs && tmp3 != noreg`), we get various test failures.

I don't understand why it's not a problem on mainline, tho. And I agree it's weird. I've looked, but it's hard to investigate why something works rather than not (on a somewhat diverging codebase). I spent some time on that, but eventually decided it's not that critical, as long as we have a way to make it work for Valhalla too.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634193195

From mchevalier at openjdk.org  Fri Dec 19 08:44:12 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 08:44:12 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996 [v2]
In-Reply-To: <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
 <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
Message-ID: <7MSNoysU4saImer7tyqP6Bau0qDudC7488r1yD_HThA=.977daa5a-7320-4ee4-a0a1-253b0b114db1@github.com>

On Fri, 19 Dec 2025 08:14:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pick the right comment again
>
> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 241:
> 
>> 239:   // Barriers might be emitted when converting between (scalarized) calling conventions for inline
>> 240:   // types. Save all argument registers before calling into the runtime.
>> 241:   __ push_call_clobbered_registers();
> 
> I think this comment should just be reverted to the mainline state because it's not specific to the scalarized calling convention.

Right, a manual merge accident. Oops.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634201706

From thartmann at openjdk.org  Fri Dec 19 08:59:56 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 08:59:56 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996 [v2]
In-Reply-To: <tgzjIADOjr42MB_RL0vtTh7m1UFb-nRXFEjO_jLJWJg=.b58e86fc-a161-49a9-a669-05c4bd7cf402@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
 <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
 <gxMGgEDE8XQfTuVtnAtGx5maV9-9MKsUVGJqWi_rv58=.9a29dc11-593d-4bc4-807c-ec5884d1b969@github.com>
 <tgzjIADOjr42MB_RL0vtTh7m1UFb-nRXFEjO_jLJWJg=.b58e86fc-a161-49a9-a669-05c4bd7cf402@github.com>
Message-ID: <ZCHHd9AaP0M4uh405p7r5zZAXBnPfegjrSDHYjuGiK0=.71c6d511-2320-4d5c-9728-d95f31364dba@github.com>

On Fri, 19 Dec 2025 08:35:36 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> I don't think we can just remove the `mov` part.
>> 
>> I don't really understand how to interpret that. We have
>> 
>>         __ mov(tmp3, dst.base());
>>         store_check(masm, tmp3, dst);
>> 
>> do you suggest we write
>> 
>>         store_check(masm, tmp3, dst);
>> 
>> ? But then, `tmp3` is not set to anything meaningful yet. Or 
>> 
>>         store_check(masm, dst.base(), dst);
>> 
>> But that is exactly the else-branch. Moreover, I've tried to guard and it makes some test fails. For instance, we can come from
>> 
>> CardTableBarrierSetAssembler::oop_store_at (cardTableBarrierSetAssembler_x86.cpp:184)
>> CardTableBarrierSetAssembler::store_at (cardTableBarrierSetAssembler_x86.cpp:90)
>> MacroAssembler::store_heap_oop (macroAssembler_x86.cpp:5515)
>> do_oop_store (templateTable_x86.cpp:148)
>> (called, for instance, from TemplateTable::putfield_or_static_helper (templateTable_x86.cpp:2964))
>> 
>> that doesn't need `InlineTypePassFieldsAsArgs` but will give `tmp3` and if we don't use it here (for instance, if I replace the condition by `InlineTypePassFieldsAsArgs && tmp3 != noreg`), we get various test failures.
>
> I don't understand why it's not a problem on mainline, tho. And I agree it's weird. I've looked, but it's hard to investigate why something works rather than not (on a somewhat diverging codebase). I spent some time on that, but eventually decided it's not that critical, as long as we have a way to make it work for Valhalla too.

I was suggesting that we should do what mainline does if `!InlineTypePassFieldsAsArgs`, would that make sense?

I.e. do `store_check(masm, dst.base(), dst);`

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634255230

From mchevalier at openjdk.org  Fri Dec 19 09:06:11 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 09:06:11 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996 [v2]
In-Reply-To: <ZCHHd9AaP0M4uh405p7r5zZAXBnPfegjrSDHYjuGiK0=.71c6d511-2320-4d5c-9728-d95f31364dba@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
 <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
 <gxMGgEDE8XQfTuVtnAtGx5maV9-9MKsUVGJqWi_rv58=.9a29dc11-593d-4bc4-807c-ec5884d1b969@github.com>
 <tgzjIADOjr42MB_RL0vtTh7m1UFb-nRXFEjO_jLJWJg=.b58e86fc-a161-49a9-a669-05c4bd7cf402@github.com>
 <ZCHHd9AaP0M4uh405p7r5zZAXBnPfegjrSDHYjuGiK0=.71c6d511-2320-4d5c-9728-d95f31364dba@github.com>
Message-ID: <U2_Cr_KvVg_pJLqCa8DebQEVIEQ9SggH2QOhtLjGcMI=.ec687daa-7ed7-49bf-ad62-69f27ddc5e2b@github.com>

On Fri, 19 Dec 2025 08:56:27 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> I don't understand why it's not a problem on mainline, tho. And I agree it's weird. I've looked, but it's hard to investigate why something works rather than not (on a somewhat diverging codebase). I spent some time on that, but eventually decided it's not that critical, as long as we have a way to make it work for Valhalla too.
>
> I was suggesting that we should do what mainline does if `!InlineTypePassFieldsAsArgs`, would that make sense?
> 
> I.e. do `store_check(masm, dst.base(), dst);`

That is the else-branch, right? Right now we have

if (tmp3 != noreg) {
  __ mov(tmp3, dst.base());
  store_check(masm, tmp3, dst);
} else {
  // It's OK to corrupt the dst.base() register.
  store_check(masm, dst.base(), dst);
}

If I understand well, you're suggesting to write

if (InlineTypePassFieldsAsArgs) {
  if (tmp3 != noreg) {
    __ mov(tmp3, dst.base());
    store_check(masm, tmp3, dst);
  } else {
    // It's OK to corrupt the dst.base() register.
    store_check(masm, dst.base(), dst);
  }
} else {
  // as mainline
  store_check(masm, dst.base(), dst);
}

but to me, it looks equivalent to


if (InlineTypePassFieldsAsArgs && tmp3 != noreg) {
  __ mov(tmp3, dst.base());
  store_check(masm, tmp3, dst);
} else {
  // It's OK to corrupt the dst.base() register.
  store_check(masm, dst.base(), dst);
}

since both else-branch are identical.

And this, I experimentally found that it's failing quite a lot, with backtraces as I mentioned. Is there an obvious mistake in my logic I'm missing?

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634271672

From jsikstro at openjdk.org  Fri Dec 19 09:27:28 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 19 Dec 2025 09:27:28 GMT
Subject: [lworld] RFR: 8374093: [lworld] Cleanup and polish around
 vgetfield/vputfield
Message-ID: <cFyBr2gmZC1Iqo_h5hxpw2CjYueR9sAw8VMNwmcEfWU=.e17dc5e4-7fe2-478f-a7e9-2a413e298571@github.com>

Hello,

I've been looking at the new internal bytecodes vgetfield and vputfield and their callchains from the interpreter down to InlineKlass and have some cleanups. I've not looked at templateTable_x86 so far, only templateTable_aarch64.

Some notes:
* The `dest_is_initialized` parameter in InlineKlass::write_value_to_addr is `true` for all callers, so I've removed it and inlined `true` to the call to `copy_payload_to_addr`.
* There seems to be an unnecessary `mark_payload_as_non_null((address)src);` in InlineKlass::copy_payload_to_addr, as the payload should already be non_null if it doesn't match `is_payload_marked_as_null` in the if-statement just above.

Testing:
* hotspot_valhalla, jdk_valhalla and tier1

-------------

Commit messages:
 - 8374093: [lworld] Cleanup and polish around vgetfield/vputfield

Changes: https://git.openjdk.org/valhalla/pull/1840/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374093
  Stats: 35 lines in 10 files changed: 0 ins; 4 del; 31 mod
  Patch: https://git.openjdk.org/valhalla/pull/1840.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1840/head:pull/1840

PR: https://git.openjdk.org/valhalla/pull/1840

From thartmann at openjdk.org  Fri Dec 19 09:36:20 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 09:36:20 GMT
Subject: [lworld] RFR: 8366717: [lworld] Cleanup defensive fixing of
 JDK-8365996 [v2]
In-Reply-To: <U2_Cr_KvVg_pJLqCa8DebQEVIEQ9SggH2QOhtLjGcMI=.ec687daa-7ed7-49bf-ad62-69f27ddc5e2b@github.com>
References: <y6bb7KooXieGRIN0rErhaAZgbOmnU34Hu2vGpccvezM=.77b7da2f-e98d-423a-8249-f824417ca688@github.com>
 <jcirG4CXAPYePh8gM3byfY8cWx0aKJU2T5RkY2oat54=.4d6ff39f-3191-4f17-b0f3-5de6082cf407@github.com>
 <gxMGgEDE8XQfTuVtnAtGx5maV9-9MKsUVGJqWi_rv58=.9a29dc11-593d-4bc4-807c-ec5884d1b969@github.com>
 <tgzjIADOjr42MB_RL0vtTh7m1UFb-nRXFEjO_jLJWJg=.b58e86fc-a161-49a9-a669-05c4bd7cf402@github.com>
 <ZCHHd9AaP0M4uh405p7r5zZAXBnPfegjrSDHYjuGiK0=.71c6d511-2320-4d5c-9728-d95f31364dba@github.com>
 <U2_Cr_KvVg_pJLqCa8DebQEVIEQ9SggH2QOhtLjGcMI=.ec687daa-7ed7-49bf-ad62-69f27ddc5e2b@github.com>
Message-ID: <I7-KOSOXjYx3gtGt9FD76qJSOoSNtIb3N1lIUd3xyLM=.7b9496fd-b871-421f-a9d0-934cec00dedc@github.com>

On Fri, 19 Dec 2025 09:02:38 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> I was suggesting that we should do what mainline does if `!InlineTypePassFieldsAsArgs`, would that make sense?
>> 
>> I.e. do `store_check(masm, dst.base(), dst);`
>
> That is the else-branch, right? Right now we have
> 
> if (tmp3 != noreg) {
>   __ mov(tmp3, dst.base());
>   store_check(masm, tmp3, dst);
> } else {
>   // It's OK to corrupt the dst.base() register.
>   store_check(masm, dst.base(), dst);
> }
> 
> If I understand well, you're suggesting to write
> 
> if (InlineTypePassFieldsAsArgs) {
>   if (tmp3 != noreg) {
>     __ mov(tmp3, dst.base());
>     store_check(masm, tmp3, dst);
>   } else {
>     // It's OK to corrupt the dst.base() register.
>     store_check(masm, dst.base(), dst);
>   }
> } else {
>   // as mainline
>   store_check(masm, dst.base(), dst);
> }
> 
> but to me, it looks equivalent to
> 
> 
> if (InlineTypePassFieldsAsArgs && tmp3 != noreg) {
>   __ mov(tmp3, dst.base());
>   store_check(masm, tmp3, dst);
> } else {
>   // It's OK to corrupt the dst.base() register.
>   store_check(masm, dst.base(), dst);
> }
> 
> since both else-branch are identical.
> 
> And this, I experimentally found that it's failing quite a lot, with backtraces as I mentioned. Is there an obvious mistake in my logic I'm missing?

Ah, you are right. I missed the outer `if (tmp3 != noreg) {` which is Valhalla specific. As we discussed off-thread, it would be good to get a better understanding of why this fails in Valhalla. Thanks a lot!

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1824#discussion_r2634372893

From thartmann at openjdk.org  Fri Dec 19 09:44:53 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 09:44:53 GMT
Subject: [lworld] RFR: 8372806: [lworld] x64: save bad values instead of
 rfp and lr above the extension space
In-Reply-To: <fkJ2JyseqNFjLfzcUeInkDCEuO6bx5-UvrRisFh_Jo8=.30609121-047f-47fa-919c-03aacd572c62@github.com>
References: <fkJ2JyseqNFjLfzcUeInkDCEuO6bx5-UvrRisFh_Jo8=.30609121-047f-47fa-919c-03aacd572c62@github.com>
Message-ID: <tmXlz4rCdbHR1Zc7ndLnMlTGeWjrUdF8Sz9X4xWWYoc=.6a645fc6-064f-431d-994a-83e349ed7517@github.com>

On Fri, 19 Dec 2025 07:56:27 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> That's the x86 counterpart of [JDK-8371993](https://bugs.openjdk.org/browse/JDK-8371993).
> 
> I've added some comments, using the offsets given in `frame_x86.hpp` to make sure to put the frame start at the right place. In particular, the frame start is 2 pointer sizes under the sender's sp:
> 
> https://github.com/openjdk/valhalla/blob/3c41c2aa442076827cb4480373a1d481e481cdf1/src/hotspot/cpu/x86/frame_x86.hpp#L61-L62
> 
> Unlike aarch64, with x64 we have only one copy of rbp. As with aarch64, I had to get rid of an assert that can't be checked anymore. A small price to pay.
> 
> Now, in debug, instead of
> 
> pop    r13
> sub    rsp,0x20
> push   r13
> 
> we have
> 
> pop    r13
> sub    rsp,0x20
> mov    DWORD PTR [rsp-0x4],0xdeadda7a
> mov    DWORD PTR [rsp-0x8],0xdeadda7a
> sub    rsp,0x8
> 
> I've kept the `pop r13` to limit the difference of behavior between debug and product builds: both will overwrite `r13` with the return address, whether it's a good idea or not.
> 
> And at runtime, on my favorite `compiler/valhalla/inlinetypes/CorrectlyRestoreRfp.java` example, instead of the stack:
> 
> 0x7fd7345fe660:	0x000000042724f5d0	0x00007fd7345fe750  <-- rsp
> 0x7fd7345fe670:	0xffffffffffffffff	0x00007fd740acc0f7
> 0x7fd7345fe680:	0x00007fd700000000	0x000000042724f5d0
> 0x7fd7345fe690:	0x000000056f517f28	0x00007fd7390002a6
> 0x7fd7345fe6a0:	0x00007fd72c90c8b3	0x0000000000000078  <--             #                | sp_inc
> 0x7fd7345fe6b0:	0x00007fd7345fe750	0x00007fd740541306  <-- rsp - 0x50  #            rbp | return address
> 0x7fd7345fe6c0:	0x000000056f49f4e0	0x000000042724f5d0  <--             #  String (arg2) | Object (arg3)
> 0x7fd7345fe6d0:	0x0000000000000000	0x00007fd740541306  <-- rsp - 0x70  # boolean (arg4) | return address
> 0x7fd7345fe6e0:	0x00007fd740541306	0x0000000000000000
> 0x7fd7345fe6f0:	0x000000042724f5d0	0x000000056f49f4e0
> 
> we have
> 
> 0x7f93cfdfe660:	0x000000042724f5d0	0x00007f93cfdfe750  <-- rsp
> 0x7f93cfdfe670:	0xffffffffffffffff	0x00007f93e4acc107
> 0x7f93cfdfe680:	0x00007f9300000000	0x000000042724f5d0
> 0x7f93cfdfe690:	0x000000056f517fb0	0x00007f93dd0002a6
> 0x7f93cfdfe6a0:	0x00007f93d090c8b3	0x0000000000000078  <--             #                | sp_inc
> 0x7f93cfdfe6b0:	0x00007f93cfdfe750	0xdeadda7adeadda7a  <-- rsp - 0x50  #            rbp | >>>> bad word <<<<
> 0x7f93cfdfe6c0:	0x000000056f49f540	0x000000042724f5d0  <--             #  String (arg2) | Object (arg3)
> 0x7f93cfdfe6d0:	0x0000000000000000	0x00007f93e4541306  <-- rsp - 0x70  # boolean (arg4) | return address
> 0x7f93cfdfe6e0:	0x00007f93e4541306	0x00000...

Nice comments! The changes look good to me.

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1839#pullrequestreview-3597794053

From thartmann at openjdk.org  Fri Dec 19 09:56:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 09:56:18 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail
 with --enable-preview
In-Reply-To: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
References: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
Message-ID: <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>

On Thu, 18 Dec 2025 12:01:36 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.
> 
> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.
> 
> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have
> 
> value class MyValue {
>     int x;
> }
> class C {
>     MyValue v;  // assumed flat.
> }
> 
> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.
> 
> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.
> 
> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i...

I had a first quick look at this and left a few comments. Will do a full review after vacation.

I assume the folding should also work for arrays with different layouts, right? I think we need tests for all of them, i.e. all `ValueClass.new*Array()` variants.

src/hotspot/share/ci/ciFlatArray.cpp line 47:

> 45: }
> 46: 
> 47: ciConstant ciFlatArray::check_constant_null_marker_cache(int off) {

Do we really need a cache here?

src/hotspot/share/ci/ciFlatArray.hpp line 59:

> 57:   ciConstant check_constant_null_marker_cache(int off);
> 58:   void add_to_constant_null_marker_cache(int off, ciConstant val);
> 59:   //ciConstant element_value_impl(arrayOop ary, int index, int offset);

Should this be removed?

src/hotspot/share/ci/ciInstance.cpp line 106:

> 104: // Constant value of the null marker.
> 105: ciConstant ciInstance::null_marker_value() {
> 106:   if (!klass()->is_inlinetype()) {

Should this be an assert?

src/hotspot/share/opto/compile.cpp line 2132:

> 2130:     if (n->is_LoadFlat()) {
> 2131:       LoadFlatNode* loadn = n->as_LoadFlat();
> 2132:       bool non_atomic_is_fine = false;

Please add a high level comment here, explaining why we can sometimes access non-atomic.

src/hotspot/share/opto/compile.cpp line 2135:

> 2133:       if (FoldStableValues) {
> 2134:         const Type* base_type = igvn.type(loadn->base());
> 2135:         const TypeOopPtr* oopptr = base_type->isa_oopptr();

Suggestion:

        const TypeOopPtr* oopptr = igvn.type(loadn->base())->isa_oopptr();


Maybe rename `oopptr` to `base_type`.

src/hotspot/share/opto/compile.cpp line 2147:

> 2145:           ciField* nm_field = iklass->get_field_by_offset(field->null_marker_offset(), false);
> 2146:           ciConstant cst = nm_field != nullptr ? holder->field_value(nm_field) : ciConstant() /* invalid */;
> 2147:           non_atomic_is_fine = FoldStableValues && field->is_stable() && cst.is_valid() && cst.as_boolean();

You already check `FoldStableValues` above. Same below.

src/hotspot/share/opto/type.cpp line 395:

> 393:     bool is_narrow_oop = (loadbt == T_NARROWOOP);
> 394:     return Type::make_from_constant(con, /*require_constant=*/true, stable_dimension, is_narrow_oop, /*is_autobox_cache=*/false);
> 395:       }

Indentation is off here.

test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefArrayTest.java line 119:

> 117:     static int testPartialFold() {
> 118:         // Access should not be folded.
> 119:         // No barriers expected for plain fields.

Same comments as in `testNoFold`

test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefPlainTest.java line 82:

> 80:     @IR(counts = { IRNode.LOAD, ">0" })
> 81:     @IR(applyIf = {"enable-valhalla", "false"}, failOn = { IRNode.MEMBAR })
> 82:     @IR(applyIf = {"enable-valhalla", "true"}, counts = { IRNode.MEMBAR, ">0" })

This needs a comment explaining why barriers are sometimes observed.

test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefPlainTest.java line 85:

> 83:     static int testNoFold() {
> 84:         // Access should not be folded.
> 85:         // No barriers expected for plain fields.

This comment is outdated.

test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefPlainTest.java line 116:

> 114:     @IR(applyIf = {"enable-valhalla", "true"}, counts = { IRNode.MEMBAR, ">0" })
> 115:     static void testMethodInit() {
> 116:         // Reference inits do not have membars.

Same comments as in `testNoFold`.

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1826#pullrequestreview-3597631149
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634410594
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634261718
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634263552
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634400033
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634403965
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634408214
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634300042
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634293123
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634274343
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634274940
PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634276778

From thartmann at openjdk.org  Fri Dec 19 10:13:52 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Fri, 19 Dec 2025 10:13:52 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v7]
In-Reply-To: <J01FPSv46csJvEoB_Cg_gzdaf3Nd_LjdCFtff3ktBOw=.2bf5a5bc-fdd1-43c2-8349-b1145917a7ce@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
 <J01FPSv46csJvEoB_Cg_gzdaf3Nd_LjdCFtff3ktBOw=.2bf5a5bc-fdd1-43c2-8349-b1145917a7ce@github.com>
Message-ID: <R3qsDeywhvUonNi3udN3Ui5Uah-ULGul9rLu-wYubVs=.5541d2d0-a030-421f-baae-3cab2d25ceee@github.com>

On Wed, 17 Dec 2025 15:12:47 GMT, Damon Fenacci <dfenacci at openjdk.org> wrote:

>> # 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 ha...
>
> Damon Fenacci has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge branch 'lworld' into JDK-8369045
>  - JDK-8369045 remove another test from problemlist
>  - JDK-8369045 remove tests from problemlist
>  - Merge branch 'lworld' into JDK-8369045
>  - Merge branch 'JDK-8369045' of https://github.com/dafedafe/valhalla into JDK-8369045
>  - Update src/hotspot/share/opto/graphKit.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - JDK-8369045: don't re-add condition if stress-reducing
>  - Revert "JDK-8369045: remove strength reduction flag"
>    
>    This reverts commit ccf58125b13655bb6c15af747345efbd6791f93d.
>  - JDK-8369045: remove strength reduction flag
>  - JDK-8369045: remove new line
>  - ... and 5 more: https://git.openjdk.org/valhalla/compare/d586e57d...b2c399f4

Looks good to me!

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1768#pullrequestreview-3597935279

From vromero at openjdk.org  Fri Dec 19 10:41:15 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 10:41:15 GMT
Subject: RFR: 8374023: [bworld] Remove support for implicit constructors
Message-ID: <jvhzjvvWBi48GYqpFrnsnimV6uBrpmzbLBVJeMSTcqE=.32a320fa-be2f-4630-9044-016b840f09f2@github.com>

removing support for implicit constructors

-------------

Commit messages:
 - 8374023: [bworld] Remove support for implicit constructors

Changes: https://git.openjdk.org/valhalla/pull/1842/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1842&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374023
  Stats: 690 lines in 28 files changed: 0 ins; 662 del; 28 mod
  Patch: https://git.openjdk.org/valhalla/pull/1842.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1842/head:pull/1842

PR: https://git.openjdk.org/valhalla/pull/1842

From dsimms at openjdk.org  Fri Dec 19 11:08:49 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Dec 2025 11:08:49 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <tH9cfsUI7IqMXW1n1X7qdL-o2LPJ9oLSJ35BVsoUM4A=.a8e35a5b-4671-4c99-b7e5-35de500eb372@github.com>

Merge jdk-27+3

-------------

Commit messages:
 - Adjust testing
 - Avoid JDK-8374116
 - Avoid JDK-8374115
 - Merge tag 'jdk-27+3' into lworld_merge_jdk_27_3
 - 8373820: C2: Robust Node::uncast_helper infinite loop check
 - 8373866: Refactor java/net/httpclient/ThrowingSubscribers*.java tests to use JUnit5
 - 8373796: Refactor java/net/httpclient/ThrowingPublishers*.java tests to use JUnit5
 - 8373869: Refactor java/net/httpclient/ThrowingPushPromises*.java tests to use JUnit5
 - 8372348: Adjust some UL / JFR string deduplication output messages
 - 8373593: Support latest  VS2026 MSC_VER in abstract_vm_version.cpp
 - ... and 104 more: https://git.openjdk.org/valhalla/compare/69399ced...f115026d

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.org/?repo=valhalla&pr=1843&range=00.0
 - jdk: https://webrevs.openjdk.org/?repo=valhalla&pr=1843&range=00.1

Changes: https://git.openjdk.org/valhalla/pull/1843/files
  Stats: 17311 lines in 650 files changed: 11141 ins; 2361 del; 3809 mod
  Patch: https://git.openjdk.org/valhalla/pull/1843.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1843/head:pull/1843

PR: https://git.openjdk.org/valhalla/pull/1843

From mchevalier at openjdk.org  Fri Dec 19 11:37:25 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 11:37:25 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail
 with --enable-preview
In-Reply-To: <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>
References: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
 <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>
Message-ID: <ABQlu0Xontoz67_Dahq66skDg9fCoDNa7kJrx5GOkOo=.e34487b0-b589-4dc8-8e36-f1249d98e44d@github.com>

On Fri, 19 Dec 2025 09:03:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.
>> 
>> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.
>> 
>> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have
>> 
>> value class MyValue {
>>     int x;
>> }
>> class C {
>>     MyValue v;  // assumed flat.
>> }
>> 
>> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.
>> 
>> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.
>> 
>> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That ma...
>
> test/hotspot/jtreg/compiler/c2/irTests/stable/StableRefPlainTest.java line 82:
> 
>> 80:     @IR(counts = { IRNode.LOAD, ">0" })
>> 81:     @IR(applyIf = {"enable-valhalla", "false"}, failOn = { IRNode.MEMBAR })
>> 82:     @IR(applyIf = {"enable-valhalla", "true"}, counts = { IRNode.MEMBAR, ">0" })
> 
> This needs a comment explaining why barriers are sometimes observed.

I agree. The problem is that you told me it's expected, but I forgot the reason.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634809130

From mchevalier at openjdk.org  Fri Dec 19 11:53:06 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 11:53:06 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail
 with --enable-preview
In-Reply-To: <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>
References: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
 <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>
Message-ID: <YWRQL8H7re3XaD6eRpTFPhKqckyEMsXFE3fLJLjzT58=.6fdbb43d-b8ef-43ce-b313-d3ca1ef8cddb@github.com>

On Fri, 19 Dec 2025 08:59:35 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.
>> 
>> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.
>> 
>> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have
>> 
>> value class MyValue {
>>     int x;
>> }
>> class C {
>>     MyValue v;  // assumed flat.
>> }
>> 
>> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.
>> 
>> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.
>> 
>> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That ma...
>
> src/hotspot/share/ci/ciInstance.cpp line 106:
> 
>> 104: // Constant value of the null marker.
>> 105: ciConstant ciInstance::null_marker_value() {
>> 106:   if (!klass()->is_inlinetype()) {
> 
> Should this be an assert?

Matter of point of view. I prefer to have the semantics

if inlinetype => get the null marker
else return invalid constant (since it doesn't make sense).

rather than

check is inline type
get null marker

At call site, in the first case, I need to

nm = inst->null_marker_value();
nm is true? (might be false or invalid)

in the second, I need to do

is inst an inline type?
if so, nm = inst->null_marker_value();
nm is true? (might be false, but not invalid)


I prefer the first pattern, it's rather safer, and I think a lot of the code involving ciConstant have this behavior of "you get the constant if I can, otherwise, you get invalid".

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634847722

From mchevalier at openjdk.org  Fri Dec 19 12:07:41 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 12:07:41 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail
 with --enable-preview [v2]
In-Reply-To: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
References: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
Message-ID: <F3NfL_oVdIG4LQPD48tTWv3CIC50_lyUJOf4oHKwZ6w=.5883976c-d9e5-403c-a6ae-71eed4432715@github.com>

> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.
> 
> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.
> 
> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have
> 
> value class MyValue {
>     int x;
> }
> class C {
>     MyValue v;  // assumed flat.
> }
> 
> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.
> 
> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.
> 
> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i...

Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1826/files
  - new: https://git.openjdk.org/valhalla/pull/1826/files/9269cf54..80564f4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=00-01

  Stats: 19 lines in 5 files changed: 8 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/valhalla/pull/1826.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826

PR: https://git.openjdk.org/valhalla/pull/1826

From mchevalier at openjdk.org  Fri Dec 19 12:07:43 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 12:07:43 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail
 with --enable-preview [v2]
In-Reply-To: <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>
References: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
 <RJFPlDgTDDJnlpe37a_j4V1aVT1WnkpMq0yDj31hSz8=.ac17ce22-4763-41db-8d56-b187dee970e2@github.com>
Message-ID: <HkivIhs369BpIFpMwkhdCs1q2MmhZMLoqQ5oGnqp2x0=.6584c468-d8ae-4544-b32b-d68bb327b8f8@github.com>

On Fri, 19 Dec 2025 09:46:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Marc Chevalier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/ci/ciFlatArray.cpp line 47:
> 
>> 45: }
>> 46: 
>> 47: ciConstant ciFlatArray::check_constant_null_marker_cache(int off) {
> 
> Do we really need a cache here?

Maybe? I read
https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciObject.hpp#L62-L63
and
https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciObject.cpp#L173-L175

It seems to be more a correctness thing than a performance matter. It couldn't see why I wouldn't have a similar risk.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1826#discussion_r2634882449

From stefank at openjdk.org  Fri Dec 19 12:40:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 19 Dec 2025 12:40:08 GMT
Subject: [lworld] RFR: 8374016: [lworld] Too late checked_cast in
 ResolvedFieldEntry::set_flags
Message-ID: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>

In the lworld branch the `new_flags` type has been changed to u1 instead of int. We now perform a bunch of bit operations, which results in an int, and then we narrow that down into a u1. After the u1 has been created we check that this doesn't overflow a u1 with the checked_cast<u1> check. That's too late.

Mainline code looks like this:

int new_flags = ...
_flags = checked_cast<u1>(new_flags);


and Valhalla code looks like this:

u1 new_flags = ...
_flags = checked_cast<u1>(new_flags);


This voids the benefit of having a checked_cast here. I propose that we revert back to using `int new_flags` and keep the checked_cast<u1>.

While reading this code there were a few things that made the code harder to follow and I've tweaked it.

1) The `bool` `is_volatile_shift` is special-treated and instead of shifting it is directly casted to int. That hard codes a knowledge/assumption that the flag is always going to be 1 (and maybe also what value bools have).

That made me have to look at the actual values of these and at one point I thought that is_volatile_shift was `1` and not `0` and that the above was a bug. The main reason I thought that was this odd order here:

   u1 new_flags = ((is_final_flag ? 1 : 0) << is_final_shift) | static_cast<int>(is_volatile_flag) |
      ((is_flat_flag ? 1 : 0) << is_flat_shift) |
      ((is_null_free_inline_type_flag ? 1 : 0) << is_null_free_inline_type_shift) |
      ((has_null_marker_flag ? 1 : 0) << has_null_marker_shift);

Here the order of usage is

is_final_flag
is_volatile_flag
is_flat_flag
is_null_free_inline_type_flag
has_null_marker_flag


but the enum order has final and volatile swapped:

is_volatile_shift
is_final_shift
is_flat_shift
is_null_free_inline_type_shift
has_null_marker_shift


I'd prefer if we stayed consistent with the order, to lower the risk that some bugs sneak in here. So, I've replaced the cast with a shift (just like the other values are handled) and I  ordered functions, parameters, and operations in the same order as the enums.

2) Tweaked some alignments to make these kind of issues clearer.

Please tell me if I went to far with the style changes.

-------------

Commit messages:
 - Merge remote-tracking branch 'valhalla/lworld' into lworld_8374016_ResolvedFieldEntry
 - 8374016: [lworld] Too late checked_cast in ResolvedFieldEntry::set_flags
 - 8374007: [lworld] Remove dead code in Symbol

Changes: https://git.openjdk.org/valhalla/pull/1844/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374016
  Stats: 28 lines in 2 files changed: 8 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/valhalla/pull/1844.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1844/head:pull/1844

PR: https://git.openjdk.org/valhalla/pull/1844

From mchevalier at openjdk.org  Fri Dec 19 13:30:41 2025
From: mchevalier at openjdk.org (Marc Chevalier)
Date: Fri, 19 Dec 2025 13:30:41 GMT
Subject: [lworld] RFR: 8372700: [lworld] compiler/c2/irTests/stable/* fail
 with --enable-preview [v3]
In-Reply-To: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
References: <F5hgXmQ1IhJiUZ7OLHFYpumP1hTG3LyeGN4lkHxEfP0=.3d449528-806a-48f7-9119-be5fc092a1e2@github.com>
Message-ID: <CgeDF1GnToq-2rrhQvw4gQEc17rCayXC_fqjTsrdJ7I=.d565f769-d327-4331-85d9-f76863b95242@github.com>

> Flat accesses to a stable value can be expanded in a non-atomic way if the stable field is already initialized since they are read-only at this point. That allows to make more optimizations, and in particular to replace the access by a constant if it's known at compilation time.
> 
> There are 2 cases. First, flat stable non-array field. In this case, the value is known to be stable if the value is non-null, that is if the null-marker of the said field is 1. If we can find that the null marker has a constant value that is non zero, we expand non-atomically. That is done by finding the field we are trying to get from the offset. From the field, we can find the offset of the null marker, and then the null marker `ciField`, allowing to fetch its value if the holder is known to be a constant oop.
> 
> The other case is stable flat array. In this case, we need to find index of the containing element of the array, then with the offset, we can find the field we are trying to get. Finding the null marker here is a bit more tricky. Let's say we have
> 
> value class MyValue {
>     int x;
> }
> class C {
>     MyValue v;  // assumed flat.
> }
> 
> the null marker for `v` is somewhat a field of `C`, as well as `v.x`. So I can just use `field_value` to get the null marker. But in `MyValue[]`, there isn't a single field for the null marker, but one "field" for each cell of the array, and there isn't a nice containing type in which it lives. The only way to get each piece of the array is by index (or offset). So, I needed specialized functions to access the null marker of a cell given the index/offset.
> 
> I also had to implement of bit of accessors for `ciFlatArray`. First, implement `element_value_by_offset` in `ciFlatArray` since the implementation of `ciArray` (super-class) was used, which computes the index from the provided offset, assuming a size of elements that doesn't take flattening into account as it used only the basic type, and not the layout helper. But also helpers to get a field of the flattened value class in a cell, to allow constant folding to get the constant value in an array.
> 
> The last part of the puzzle, necessary to make constant folding happen (see `Type::make_constant_from_field`), is to say that a field of a flattened inline type field is constant if the containing field if constant. In the words of the previous example, that means `x` is constant in `C` if `v` is strict and final (already there), or if `v` is constant itself. That matches what we do in `void ciField::i...

Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - review
 - Solving conflict with myself: Merge remote-tracking branch 'lworld' into JDK-8372700
 - Un-problemlist
 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - Cleanup
 - Cleanup
 - Fix header size
 - damn is_null_or_zero assumes is_valid
 - Merge remote-tracking branch 'origin/lworld' into JDK-8372700
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/69399ced...b64ff8ce

-------------

Changes: https://git.openjdk.org/valhalla/pull/1826/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1826&range=02
  Stats: 301 lines in 20 files changed: 280 ins; 7 del; 14 mod
  Patch: https://git.openjdk.org/valhalla/pull/1826.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1826/head:pull/1826

PR: https://git.openjdk.org/valhalla/pull/1826

From mcimadamore at openjdk.org  Fri Dec 19 14:06:52 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 Dec 2025 14:06:52 GMT
Subject: RFR: 8374023: [bworld] Remove support for implicit constructors
In-Reply-To: <jvhzjvvWBi48GYqpFrnsnimV6uBrpmzbLBVJeMSTcqE=.32a320fa-be2f-4630-9044-016b840f09f2@github.com>
References: <jvhzjvvWBi48GYqpFrnsnimV6uBrpmzbLBVJeMSTcqE=.32a320fa-be2f-4630-9044-016b840f09f2@github.com>
Message-ID: <Cm83fXx_W17LVQXqu191mHRdkbnEyDJuVWsU_FgpGMs=.04c23a3e-2cf8-42f9-8ccd-8019c5f99027@github.com>

On Fri, 19 Dec 2025 10:35:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> removing support for implicit constructors

Looks good

-------------

Marked as reviewed by mcimadamore (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1842#pullrequestreview-3598736153

From vromero at openjdk.org  Fri Dec 19 14:24:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 14:24:34 GMT
Subject: Integrated: 8374023: [bworld] Remove support for implicit constructors
In-Reply-To: <jvhzjvvWBi48GYqpFrnsnimV6uBrpmzbLBVJeMSTcqE=.32a320fa-be2f-4630-9044-016b840f09f2@github.com>
References: <jvhzjvvWBi48GYqpFrnsnimV6uBrpmzbLBVJeMSTcqE=.32a320fa-be2f-4630-9044-016b840f09f2@github.com>
Message-ID: <yLIPLwxi3dwh8TAjEBonVz_aWJoX7ExNdi4zfmzdUSU=.82542d04-11f5-4087-a6c1-e5d0d0d4dd2a@github.com>

On Fri, 19 Dec 2025 10:35:25 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> removing support for implicit constructors

This pull request has now been integrated.

Changeset: 4280bdf4
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4280bdf4deb340f8111e95ce636eac7cace256d0
Stats:     690 lines in 28 files changed: 0 ins; 662 del; 28 mod

8374023: [bworld] Remove support for implicit constructors

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/valhalla/pull/1842

From jsikstro at openjdk.org  Fri Dec 19 14:33:13 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 19 Dec 2025 14:33:13 GMT
Subject: [lworld] RFR: 8374093: [lworld] Cleanup and polish around
 vgetfield/vputfield [v2]
In-Reply-To: <cFyBr2gmZC1Iqo_h5hxpw2CjYueR9sAw8VMNwmcEfWU=.e17dc5e4-7fe2-478f-a7e9-2a413e298571@github.com>
References: <cFyBr2gmZC1Iqo_h5hxpw2CjYueR9sAw8VMNwmcEfWU=.e17dc5e4-7fe2-478f-a7e9-2a413e298571@github.com>
Message-ID: <DtlfHImivcCOwIcQBRomT4172s_DATM4senabP5CINM=.3f6cf0f1-005e-4cc8-9903-21746e96dd49@github.com>

> Hello,
> 
> I've been looking at the new internal bytecodes vgetfield and vputfield and their callchains from the interpreter down to InlineKlass and have some cleanups. I've not looked at templateTable_x86 so far, only templateTable_aarch64.
> 
> Some notes:
> * The `dest_is_initialized` parameter in InlineKlass::write_value_to_addr is `true` for all callers, so I've removed it and inlined `true` to the call to `copy_payload_to_addr`.
> * There seems to be an unnecessary `mark_payload_as_non_null((address)src);` in InlineKlass::copy_payload_to_addr, as the payload should already be non_null if it doesn't match `is_payload_marked_as_null` in the if-statement just above.
> 
> Testing:
> * hotspot_valhalla, jdk_valhalla and tier1

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  More cleanup

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1840/files
  - new: https://git.openjdk.org/valhalla/pull/1840/files/8944d003..e1f1ffa6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1840&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1840&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/valhalla/pull/1840.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1840/head:pull/1840

PR: https://git.openjdk.org/valhalla/pull/1840

From fparain at openjdk.org  Fri Dec 19 15:44:47 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 Dec 2025 15:44:47 GMT
Subject: [lworld] RFR: 8374016: [lworld] Too late checked_cast in
 ResolvedFieldEntry::set_flags
In-Reply-To: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
References: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
Message-ID: <HtxE_Va5t7p25fiQ2hORXyGLUk2VGx9TYSdbVk_Jrsg=.5f5a1c2c-23ad-4ade-b3dd-71aed256d1fc@github.com>

On Fri, 19 Dec 2025 12:32:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the lworld branch the `new_flags` type has been changed to u1 instead of int. We now perform a bunch of bit operations, which results in an int, and then we narrow that down into a u1. After the u1 has been created we check that this doesn't overflow a u1 with the checked_cast<u1> check. That's too late.
> 
> Mainline code looks like this:
> 
> int new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> and Valhalla code looks like this:
> 
> u1 new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> This voids the benefit of having a checked_cast here. I propose that we revert back to using `int new_flags` and keep the checked_cast<u1>.
> 
> While reading this code there were a few things that made the code harder to follow and I've tweaked it.
> 
> 1) The `bool` `is_volatile_shift` is special-treated and instead of shifting it is directly casted to int. That hard codes a knowledge/assumption that the flag is always going to be 1 (and maybe also what value bools have).
> 
> That made me have to look at the actual values of these and at one point I thought that is_volatile_shift was `1` and not `0` and that the above was a bug. The main reason I thought that was this odd order here:
> 
>    u1 new_flags = ((is_final_flag ? 1 : 0) << is_final_shift) | static_cast<int>(is_volatile_flag) |
>       ((is_flat_flag ? 1 : 0) << is_flat_shift) |
>       ((is_null_free_inline_type_flag ? 1 : 0) << is_null_free_inline_type_shift) |
>       ((has_null_marker_flag ? 1 : 0) << has_null_marker_shift);
> 
> Here the order of usage is
> 
> is_final_flag
> is_volatile_flag
> is_flat_flag
> is_null_free_inline_type_flag
> has_null_marker_flag
> 
> 
> but the enum order has final and volatile swapped:
> 
> is_volatile_shift
> is_final_shift
> is_flat_shift
> is_null_free_inline_type_shift
> has_null_marker_shift
> 
> 
> I'd prefer if we stayed consistent with the order, to lower the risk that some bugs sneak in here. So, I've replaced the cast with a shift (just like the other values are handled) and I  ordered functions, parameters, and operations in the same order as the enums.
> 
> 2) Tweaked some alignments to make these kind of issues clearer.
> 
> Please tell me if I went to far with the style changes.

Good point about the checked_cast.
Style changes are good if they make the code more explicit to the reader.
Thank you for these fixes.

-------------

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1844#pullrequestreview-3599070561

From dsimms at openjdk.org  Fri Dec 19 15:47:40 2025
From: dsimms at openjdk.org (David Simms)
Date: Fri, 19 Dec 2025 15:47:40 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <tH9cfsUI7IqMXW1n1X7qdL-o2LPJ9oLSJ35BVsoUM4A=.a8e35a5b-4671-4c99-b7e5-35de500eb372@github.com>
References: <tH9cfsUI7IqMXW1n1X7qdL-o2LPJ9oLSJ35BVsoUM4A=.a8e35a5b-4671-4c99-b7e5-35de500eb372@github.com>
Message-ID: <dA78APKhlbQr0rs99A2Nz9v5lgFJJtiZKLyKUISPJ2I=.7a27b0ab-69bb-460c-a0c0-351e466ce904@github.com>

On Fri, 19 Dec 2025 11:00:27 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge jdk-27+3

This pull request has now been integrated.

Changeset: 4b318c81
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/4b318c818597a6e53812de95bdcc4fbdc0a10793
Stats:     17311 lines in 650 files changed: 11141 ins; 2361 del; 3809 mod

Merge

Merge jdk-27+3

-------------

PR: https://git.openjdk.org/valhalla/pull/1843

From chagedorn at openjdk.org  Fri Dec 19 15:50:08 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 19 Dec 2025 15:50:08 GMT
Subject: [lworld] RFR: 8374117: [lworld] Disable Valhalla specific VM flags
 when --enable-preview is not set
Message-ID: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>

There are currently a lot of failures in the CI with the following assert:

 assert(UseArrayFlattening && is_reference_type(bt) && element_ptr->can_be_inline_type() && (!element_ptr->is_inlinetypeptr() || element_ptr->inline_klass()->maybe_flat_in_array())) failed: array can't be flat


The reason is that C2 is using `UseArrayFlattening` to decide if some array type is known to be not flat. For example here:
https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/opto/library_call.cpp#L5197-L5198


When `--enable-preview` is not provided, we know that nothing is flat (i.e. all array types are known to be not flat). However, since `UseArrayFlattening` is still set to true by default, the C2 code above, for example, checks the flag and then assumes some array is not known to be non-flat. This clashes with other code that does an `--enable-preview` check as for example here:
https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciInstanceKlass.cpp#L729-L732

and we get inconsistent results, leading to the assertion failure below.

We could fix all the places where we use Valhalla specific flags and make sure it works without setting `--enable-preview`. But I propose the easier fix to just disable Valhalla specific flags when `--enable-preview` is not set. This also protects us from future uses of the flag in shared code.

#### Additional Fix
`LibraryCallKit::inline_array_copyOf()` unconditionally sets "not-null-free" of a `TypeAryKlassPtr` to false because we don't know anything about it. However, when we run without `--enable-preview`, then we will not have null-free arrays. Therefore, we can set it to true in this case. When we don't do that, we will later assert where we check that when an array is NOT not-null-free, then we must be dealing with some kind of value class, which is not the case.

#### Implementation
I defined local macros in order to set the Valhalla flags to false and emit a warning when we set any of the flags added for Valhalla that they don't have an effect.

#### Future Work
We might want to add more sanity assertion checks for flat and nullness information when we create new type instances in the code. But since this is a bug fix for the CI, I'm leaving that as follow-up work.

#### Testing
- t1-3 (still running)
- previously failing t4 AOT tests (still running)

#### Alternative Fix
Fix all the mismatched cases directly in the code and allow Valhalla flags to be set even though they have no meaning without `--enable-preview`. We could also do that but it felt safer to just disable all the Valhalla specific flags without `--enable-preview`.

Thanks,
Christian

-------------

Commit messages:
 - new line
 - update warning message
 - not-null-free fix
 - 8374117: [lworld] Disable Valhalla specific VM flags when --enable-preview is not set

Changes: https://git.openjdk.org/valhalla/pull/1846/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374117
  Stats: 50 lines in 2 files changed: 38 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/valhalla/pull/1846.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1846/head:pull/1846

PR: https://git.openjdk.org/valhalla/pull/1846

From duke at openjdk.org  Fri Dec 19 15:59:14 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 19 Dec 2025 15:59:14 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
Message-ID: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>

Hopefully a fix for preview mode with exploded images in classLoader.cpp.

I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

-------------

Commit messages:
 - Seems to work ...

Changes: https://git.openjdk.org/valhalla/pull/1845/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1845&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373987
  Stats: 61 lines in 3 files changed: 28 ins; 9 del; 24 mod
  Patch: https://git.openjdk.org/valhalla/pull/1845.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1845/head:pull/1845

PR: https://git.openjdk.org/valhalla/pull/1845

From duke at openjdk.org  Fri Dec 19 15:59:17 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 19 Dec 2025 15:59:17 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
Message-ID: <fRIF2npmWCxhB2W4BMp1aIlOiJZg0lycBfcybN9IaJU=.9f4fd79f-854a-4861-9b5d-1997401df8f2@github.com>

On Fri, 19 Dec 2025 15:36:35 GMT, David Beaumont <duke at openjdk.org> wrote:

> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
> 
> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

src/hotspot/share/classfile/classLoader.cpp line 102:

> 100: static JImageFile*                     JImage_file            = nullptr;
> 101: 
> 102: // PreviewMode status to control preview behaviour. JImage_file is unusable

Totally automated search & replace.

src/hotspot/share/classfile/classLoader.cpp line 999:

> 997: }
> 998: 
> 999: // caller needs ResourceMark

Based on the code above. Both these should probably use stringStream and format specifiers according to several people. I don't want to do that in this PR though.

src/hotspot/share/classfile/classLoader.cpp line 1157:

> 1155:       assert(_exploded_entries != nullptr, "No exploded build entries present");
> 1156:       assert(!CDSConfig::is_dumping_archive(), "CDS dumping doesn't support exploded build");
> 1157:       const char* preview_file_name = is_preview_enabled() ? create_preview_file_name(file_name) : nullptr;

Making this out here seems best, but I could also pass the flag in and make it in search_module_entries(), but that's called from two places, so the less complexity in there the better.

src/hotspot/share/classfile/classLoader.cpp line 1513:

> 1511: // Finishes initializing the JImageFile (if present) by setting the access mode.
> 1512: void ClassLoader::set_preview_mode(bool enable_preview) {
> 1513:   assert(Preview_mode == PREVIEW_MODE_UNINITIALIZED, "set_preview_mode must not be called twice");

Don't check for jimage now since it won't be there when using exploded image.

src/hotspot/share/classfile/classLoader.hpp line 252:

> 250:   static const char* file_name_for_class_name(const char* class_name,
> 251:                                               int class_name_len);
> 252:   // REVIEWER-NOTE: Where best to put this - it should be private!

I don't think this should be here, but several other "private looking" functions are in the public section so I'm not sure. Advice requested...

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635489822
PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635493068
PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635497142
PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635498605
PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635500894

From rriggs at openjdk.org  Fri Dec 19 16:24:20 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Dec 2025 16:24:20 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
Message-ID: <s9bA96uYAaPMw6CEcDbgl4MbYSOOSwyvyZYLLp3yAKM=.58892d71-eccd-4aed-9748-50614b808ecf@github.com>

On Fri, 19 Dec 2025 15:36:35 GMT, David Beaumont <duke at openjdk.org> wrote:

> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
> 
> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

src/hotspot/share/classfile/classLoader.cpp line 1077:

> 1075:     if (nullptr == stream) {
> 1076:       stream = e->open_stream(current, file_name);
> 1077:     }

Why not pass in the preview flag to search_module_entries (or use the global) and create and preview file name here?
Its better encapsulated, with a smaller scope knowing about META-INF.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635601534

From fparain at openjdk.org  Fri Dec 19 16:44:22 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 Dec 2025 16:44:22 GMT
Subject: [lworld] RFR: 8374117: [lworld] Disable Valhalla specific VM flags
 when --enable-preview is not set
In-Reply-To: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>
References: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>
Message-ID: <Vuw0iRPxC66lbyMI_FlA5WdnX2tMgyw0SpMBBgVhLSU=.939665ff-d2fe-4045-87d3-38cbef13cbc4@github.com>

On Fri, 19 Dec 2025 15:38:29 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are currently a lot of failures in the CI with the following assert:
> 
>  assert(UseArrayFlattening && is_reference_type(bt) && element_ptr->can_be_inline_type() && (!element_ptr->is_inlinetypeptr() || element_ptr->inline_klass()->maybe_flat_in_array())) failed: array can't be flat
> 
> 
> The reason is that C2 is using `UseArrayFlattening` to decide if some array type is known to be not flat. For example here:
> https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/opto/library_call.cpp#L5197-L5198
> 
> 
> When `--enable-preview` is not provided, we know that nothing is flat (i.e. all array types are known to be not flat). However, since `UseArrayFlattening` is still set to true by default, the C2 code above, for example, checks the flag and then assumes some array is not known to be non-flat. This clashes with other code that does an `--enable-preview` check as for example here:
> https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciInstanceKlass.cpp#L729-L732
> 
> and we get inconsistent results, leading to the assertion failure below.
> 
> We could fix all the places where we use Valhalla specific flags and make sure it works without setting `--enable-preview`. But I propose the easier fix to just disable Valhalla specific flags when `--enable-preview` is not set. This also protects us from future uses of the flag in shared code.
> 
> #### Additional Fix
> `LibraryCallKit::inline_array_copyOf()` unconditionally sets "not-null-free" of a `TypeAryKlassPtr` to false because we don't know anything about it. However, when we run without `--enable-preview`, then we will not have null-free arrays. Therefore, we can set it to true in this case. When we don't do that, we will later assert where we check that when an array is NOT not-null-free, then we must be dealing with some kind of value class, which is not the case.
> 
> #### Implementation
> I defined local macros in order to set the Valhalla flags to false and emit a warning when we set any of the flags added for Valhalla that they don't have an effect.
> 
> #### Future Work
> We might want to add more sanity assertion checks for flat and nullness information when we create new type instances in the code. But since this is a bug fix for the CI, I'm leaving that as follow-up work.
> 
> #### Testing
> - t1-3 (still running)
> - previously failing t4 AOT tests (still running)
> 
> #### Alternative Fix
> Fix all the mismatched cases directly in the code and allow V...

Looks reasonable to me.
Disabling all the Valhalla flags when preview mode is not enabled would reduce the risks for the normal mode to encounter a bug introduced by Valhalla, which would be very important after the integration with mainline.

-------------

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1846#pullrequestreview-3599272660

From chagedorn at openjdk.org  Fri Dec 19 16:44:22 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 19 Dec 2025 16:44:22 GMT
Subject: [lworld] RFR: 8374117: [lworld] Disable Valhalla specific VM flags
 when --enable-preview is not set
In-Reply-To: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>
References: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>
Message-ID: <nt9YhUDbB2QpNs2wC5xnema1-aqcQRmWfoJJr-VML18=.ed2e57dd-a3bb-4b41-bd91-95dd2a65ff5f@github.com>

On Fri, 19 Dec 2025 15:38:29 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are currently a lot of failures in the CI with the following assert:
> 
>  assert(UseArrayFlattening && is_reference_type(bt) && element_ptr->can_be_inline_type() && (!element_ptr->is_inlinetypeptr() || element_ptr->inline_klass()->maybe_flat_in_array())) failed: array can't be flat
> 
> 
> The reason is that C2 is using `UseArrayFlattening` to decide if some array type is known to be not flat. For example here:
> https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/opto/library_call.cpp#L5197-L5198
> 
> 
> When `--enable-preview` is not provided, we know that nothing is flat (i.e. all array types are known to be not flat). However, since `UseArrayFlattening` is still set to true by default, the C2 code above, for example, checks the flag and then assumes some array is not known to be non-flat. This clashes with other code that does an `--enable-preview` check as for example here:
> https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciInstanceKlass.cpp#L729-L732
> 
> and we get inconsistent results, leading to the assertion failure below.
> 
> We could fix all the places where we use Valhalla specific flags and make sure it works without setting `--enable-preview`. But I propose the easier fix to just disable Valhalla specific flags when `--enable-preview` is not set. This also protects us from future uses of the flag in shared code.
> 
> #### Additional Fix
> `LibraryCallKit::inline_array_copyOf()` unconditionally sets "not-null-free" of a `TypeAryKlassPtr` to false because we don't know anything about it. However, when we run without `--enable-preview`, then we will not have null-free arrays. Therefore, we can set it to true in this case. When we don't do that, we will later assert where we check that when an array is NOT not-null-free, then we must be dealing with some kind of value class, which is not the case.
> 
> #### Implementation
> I defined local macros in order to set the Valhalla flags to false and emit a warning when we set any of the flags added for Valhalla that they don't have an effect.
> 
> #### Future Work
> We might want to add more sanity assertion checks for flat and nullness information when we create new type instances in the code. But since this is a bug fix for the CI, I'm leaving that as follow-up work.
> 
> #### Testing
> - t1-3 (still running)
> - previously failing t4 AOT tests (still running)
> 
> #### Alternative Fix
> Fix all the mismatched cases directly in the code and allow V...

Thanks Fred for your review! 

> Disabling all the Valhalla flags when preview mode is not enabled would reduce the risks for the normal mode to encounter a bug introduced by Valhalla, which would be very important after the integration with mainline.

Yes, absolutely, I agree with that.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1846#issuecomment-3675756903

From duke at openjdk.org  Fri Dec 19 16:53:22 2025
From: duke at openjdk.org (David Beaumont)
Date: Fri, 19 Dec 2025 16:53:22 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <s9bA96uYAaPMw6CEcDbgl4MbYSOOSwyvyZYLLp3yAKM=.58892d71-eccd-4aed-9748-50614b808ecf@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
 <s9bA96uYAaPMw6CEcDbgl4MbYSOOSwyvyZYLLp3yAKM=.58892d71-eccd-4aed-9748-50614b808ecf@github.com>
Message-ID: <oDpWeR8J7qoUyuMzhw0GT9eadp7VnvPoW77ZszVCePg=.c90248f0-d437-45ef-8dea-afef2f674a13@github.com>

On Fri, 19 Dec 2025 16:21:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
>> 
>> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.
>
> src/hotspot/share/classfile/classLoader.cpp line 1077:
> 
>> 1075:     if (nullptr == stream) {
>> 1076:       stream = e->open_stream(current, file_name);
>> 1077:     }
> 
> Why not pass in the preview flag to search_module_entries (or use the global) and create and preview file name here?
> Its better encapsulated, with a smaller scope knowing about META-INF.

As I said in the comment, I could. I didn't because search_module_entries is called in two places, and the call for exploded image is the edge case. So passing just a "try this first" path without the logic of accessing the preview mode flag and building the preview path felt simpler for the normal case.
I can't use the global flag inside the method of course, because that triggers it in the non-exploded image case.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635702622

From mcimadamore at openjdk.org  Fri Dec 19 17:04:55 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 Dec 2025 17:04:55 GMT
Subject: RFR: Update parser tests
Message-ID: <YCX2pzrq1H56SJ8scF28lknvcudOTNJ8qpj2a1CShlk=.c831c19a-a587-4e9e-acaa-b617f0cffc54@github.com>

This PR updates the parser tests to reflect the latest changes in the programming model.
This led to minor parser tweaks to javac parser, to make sure that sensible error messgaes were being reported when null-restricted types are used in the wrong place.

-------------

Commit messages:
 - Update parser tests

Changes: https://git.openjdk.org/valhalla/pull/1847/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1847&range=00
  Stats: 707 lines in 6 files changed: 295 ins; 397 del; 15 mod
  Patch: https://git.openjdk.org/valhalla/pull/1847.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1847/head:pull/1847

PR: https://git.openjdk.org/valhalla/pull/1847

From coleenp at openjdk.org  Fri Dec 19 17:07:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Dec 2025 17:07:35 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <fRIF2npmWCxhB2W4BMp1aIlOiJZg0lycBfcybN9IaJU=.9f4fd79f-854a-4861-9b5d-1997401df8f2@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
 <fRIF2npmWCxhB2W4BMp1aIlOiJZg0lycBfcybN9IaJU=.9f4fd79f-854a-4861-9b5d-1997401df8f2@github.com>
Message-ID: <MGtULFDq2YSxaoy_yyjtUdx_kYXx0ddgmjOiZeUQDHE=.9b9996f1-c9a6-4bee-871c-150e7ca6a099@github.com>

On Fri, 19 Dec 2025 15:42:24 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
>> 
>> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.
>
> src/hotspot/share/classfile/classLoader.cpp line 999:
> 
>> 997: }
>> 998: 
>> 999: // caller needs ResourceMark
> 
> Based on the code above. Both these should probably use stringStream and format specifiers according to several people. I don't want to do that in this PR though.

As long as it doesn't have a buffer overrun, it's fine to fix later.  It seems okay.

> src/hotspot/share/classfile/classLoader.hpp line 252:
> 
>> 250:   static const char* file_name_for_class_name(const char* class_name,
>> 251:                                               int class_name_len);
>> 252:   // REVIEWER-NOTE: Where best to put this - it should be private!
> 
> I don't think this should be here, but several other "private looking" functions are in the public section so I'm not sure. Advice requested...

Move it up to the private section.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635737050
PR Review Comment: https://git.openjdk.org/valhalla/pull/1845#discussion_r2635574286

From matsaave at openjdk.org  Fri Dec 19 17:11:26 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 19 Dec 2025 17:11:26 GMT
Subject: [lworld] RFR: 8374016: [lworld] Too late checked_cast in
 ResolvedFieldEntry::set_flags
In-Reply-To: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
References: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
Message-ID: <EJhilRK70Z_hNQy0TQHhsUbg0mYyN_9CBvfZjSfiS64=.c1918395-37de-4b26-a363-5590e890aabe@github.com>

On Fri, 19 Dec 2025 12:32:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the lworld branch the `new_flags` type has been changed to u1 instead of int. We now perform a bunch of bit operations, which results in an int, and then we narrow that down into a u1. After the u1 has been created we check that this doesn't overflow a u1 with the checked_cast<u1> check. That's too late.
> 
> Mainline code looks like this:
> 
> int new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> and Valhalla code looks like this:
> 
> u1 new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> This voids the benefit of having a checked_cast here. I propose that we revert back to using `int new_flags` and keep the checked_cast<u1>.
> 
> While reading this code there were a few things that made the code harder to follow and I've tweaked it.
> 
> 1) The `bool` `is_volatile_shift` is special-treated and instead of shifting it is directly casted to int. That hard codes a knowledge/assumption that the flag is always going to be 1 (and maybe also what value bools have).
> 
> That made me have to look at the actual values of these and at one point I thought that is_volatile_shift was `1` and not `0` and that the above was a bug. The main reason I thought that was this odd order here:
> 
>    u1 new_flags = ((is_final_flag ? 1 : 0) << is_final_shift) | static_cast<int>(is_volatile_flag) |
>       ((is_flat_flag ? 1 : 0) << is_flat_shift) |
>       ((is_null_free_inline_type_flag ? 1 : 0) << is_null_free_inline_type_shift) |
>       ((has_null_marker_flag ? 1 : 0) << has_null_marker_shift);
> 
> Here the order of usage is
> 
> is_final_flag
> is_volatile_flag
> is_flat_flag
> is_null_free_inline_type_flag
> has_null_marker_flag
> 
> 
> but the enum order has final and volatile swapped:
> 
> is_volatile_shift
> is_final_shift
> is_flat_shift
> is_null_free_inline_type_shift
> has_null_marker_shift
> 
> 
> I'd prefer if we stayed consistent with the order, to lower the risk that some bugs sneak in here. So, I've replaced the cast with a shift (just like the other values are handled) and I  ordered functions, parameters, and operations in the same order as the enums.
> 
> 2) Tweaked some alignments to make these kind of issues clearer.
> 
> Please tell me if I went to far with the style changes.

Change looks good and makes the code more clear, thanks!

-------------

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1844#pullrequestreview-3599398946

From coleenp at openjdk.org  Fri Dec 19 17:07:35 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Dec 2025 17:07:35 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
Message-ID: <lTWspvny-H2L5ypMQB-bSEoWq1XSs5Ol6WXsPmygAr8=.f6c70fdb-7761-456b-9707-55f8c4ba2adb@github.com>

On Fri, 19 Dec 2025 15:36:35 GMT, David Beaumont <duke at openjdk.org> wrote:

> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
> 
> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

This seems all right.

-------------

Marked as reviewed by coleenp (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1845#pullrequestreview-3599164750

From vromero at openjdk.org  Fri Dec 19 17:21:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 17:21:34 GMT
Subject: RFR: Update parser tests
In-Reply-To: <YCX2pzrq1H56SJ8scF28lknvcudOTNJ8qpj2a1CShlk=.c831c19a-a587-4e9e-acaa-b617f0cffc54@github.com>
References: <YCX2pzrq1H56SJ8scF28lknvcudOTNJ8qpj2a1CShlk=.c831c19a-a587-4e9e-acaa-b617f0cffc54@github.com>
Message-ID: <1Fp_yWDCLWMUIFIiNBu7PKHzuhz80iRCL30EJSsQ39M=.bbffafc4-ab59-4a13-95d4-5f89296bfaf8@github.com>

On Fri, 19 Dec 2025 16:58:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR updates the parser tests to reflect the latest changes in the programming model.
> This led to minor parser tweaks to javac parser, to make sure that sensible error messgaes were being reported when null-restricted types are used in the wrong place.

lgtm

-------------

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1847#pullrequestreview-3599430496

From rriggs at openjdk.org  Fri Dec 19 17:29:01 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Dec 2025 17:29:01 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
Message-ID: <wG6uA1WlqhFrGIx9Ty3c-B1epRTXVpWyn19pj7hwcTA=.b3a31d83-6d77-4a67-8f90-5c109750f207@github.com>

On Fri, 19 Dec 2025 15:36:35 GMT, David Beaumont <duke at openjdk.org> wrote:

> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
> 
> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

Looks fine.

-------------

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1845#pullrequestreview-3599447921

From mcimadamore at openjdk.org  Fri Dec 19 17:29:02 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 Dec 2025 17:29:02 GMT
Subject: Integrated: Update parser tests
In-Reply-To: <YCX2pzrq1H56SJ8scF28lknvcudOTNJ8qpj2a1CShlk=.c831c19a-a587-4e9e-acaa-b617f0cffc54@github.com>
References: <YCX2pzrq1H56SJ8scF28lknvcudOTNJ8qpj2a1CShlk=.c831c19a-a587-4e9e-acaa-b617f0cffc54@github.com>
Message-ID: <qiKqtqB-kHPBRMeCyKd52cgj-YTnEMZTkH-9Sjtiek0=.7eb7ee49-f7b1-4654-a8de-ba082e871104@github.com>

On Fri, 19 Dec 2025 16:58:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR updates the parser tests to reflect the latest changes in the programming model.
> This led to minor parser tweaks to javac parser, to make sure that sensible error messgaes were being reported when null-restricted types are used in the wrong place.

This pull request has now been integrated.

Changeset: 895fe561
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/895fe561746ca3ce48481bde284ec3a3e1b84fd3
Stats:     707 lines in 6 files changed: 295 ins; 397 del; 15 mod

Update parser tests

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/valhalla/pull/1847

From matsaave at openjdk.org  Fri Dec 19 17:36:00 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Fri, 19 Dec 2025 17:36:00 GMT
Subject: [lworld] RFR: 8367408: [lworld]
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails
In-Reply-To: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
References: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
Message-ID: <gJGf6fOq5_O3c5174yLl08dI6b9qo_dcwn__pbHnT1g=.3b6d6bda-7d89-44db-8116-941c350c960a@github.com>

On Thu, 18 Dec 2025 22:46:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class.  The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348).  This change moves where they are regenerated to where the method is linked.
> 
> Testing with tier1-4. in progress, and with the failed test.

Thanks for fixing this, looks good!

-------------

Marked as reviewed by matsaave (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1837#pullrequestreview-3599467841

From coleenp at openjdk.org  Fri Dec 19 17:55:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Dec 2025 17:55:23 GMT
Subject: [lworld] RFR: 8367408: [lworld]
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails [v2]
In-Reply-To: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
References: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
Message-ID: <QIb414U4w2GRNE-mrVpEgqVCHndHTKB_Swmm-ZbuN8w=.ad4c93c6-b6f9-45d9-825a-856d23e44c31@github.com>

> This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class.  The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348).  This change moves where they are regenerated to where the method is linked.
> 
> Testing with tier1-4. in progress, and with the failed test.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'lworld' into method-handles
 - 8367408: [lworld] runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails

-------------

Changes: https://git.openjdk.org/valhalla/pull/1837/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1837&range=01
  Stats: 32 lines in 3 files changed: 17 ins; 15 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1837.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1837/head:pull/1837

PR: https://git.openjdk.org/valhalla/pull/1837

From mcimadamore at openjdk.org  Fri Dec 19 18:30:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 Dec 2025 18:30:38 GMT
Subject: Integrated: Fix signature attribute generation for null restrictions
Message-ID: <ixrZUPe_g-cVkZCPTMxaFOeKuqNvbZYuDOjcJZh68AE=.9dc4ea3a-7f91-4439-85ee-ec93e6d5f20a@github.com>

The code in `Types` is already correctly handling null restrictions.
There's only a minor problem with the flag to enable null restriction not being passed recursively in nested call (e.g. for method signatures).

Since I was there, I also dropped signature generation code for type variable declarations.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/valhalla/pull/1848/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1848&range=00
  Stats: 24 lines in 1 file changed: 0 ins; 20 del; 4 mod
  Patch: https://git.openjdk.org/valhalla/pull/1848.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1848/head:pull/1848

PR: https://git.openjdk.org/valhalla/pull/1848

From vromero at openjdk.org  Fri Dec 19 18:30:38 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 18:30:38 GMT
Subject: Integrated: Fix signature attribute generation for null
 restrictions
In-Reply-To: <ixrZUPe_g-cVkZCPTMxaFOeKuqNvbZYuDOjcJZh68AE=.9dc4ea3a-7f91-4439-85ee-ec93e6d5f20a@github.com>
References: <ixrZUPe_g-cVkZCPTMxaFOeKuqNvbZYuDOjcJZh68AE=.9dc4ea3a-7f91-4439-85ee-ec93e6d5f20a@github.com>
Message-ID: <lzKx3_5cpu8VQzJAxgk9ryA29lB-J8ObtUwY-rRumZU=.5de30630-bd02-4485-a2ab-2524dcafef33@github.com>

On Fri, 19 Dec 2025 18:21:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The code in `Types` is already correctly handling null restrictions.
> There's only a minor problem with the flag to enable null restriction not being passed recursively in nested call (e.g. for method signatures).
> 
> Since I was there, I also dropped signature generation code for type variable declarations.

lgtm

-------------

Marked as reviewed by vromero (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1848#pullrequestreview-3599593952

From mcimadamore at openjdk.org  Fri Dec 19 18:30:38 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 Dec 2025 18:30:38 GMT
Subject: Integrated: Fix signature attribute generation for null restrictions
In-Reply-To: <ixrZUPe_g-cVkZCPTMxaFOeKuqNvbZYuDOjcJZh68AE=.9dc4ea3a-7f91-4439-85ee-ec93e6d5f20a@github.com>
References: <ixrZUPe_g-cVkZCPTMxaFOeKuqNvbZYuDOjcJZh68AE=.9dc4ea3a-7f91-4439-85ee-ec93e6d5f20a@github.com>
Message-ID: <Rrc-e88HgtAlugySooFajTKiKcWDtSQdOb-o36v1vGI=.772fccad-dffe-41fa-bc21-96b630924c9c@github.com>

On Fri, 19 Dec 2025 18:21:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The code in `Types` is already correctly handling null restrictions.
> There's only a minor problem with the flag to enable null restriction not being passed recursively in nested call (e.g. for method signatures).
> 
> Since I was there, I also dropped signature generation code for type variable declarations.

This pull request has now been integrated.

Changeset: e578dced
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/e578dced80e295dbe756970db5b685a038384be1
Stats:     24 lines in 1 file changed: 0 ins; 20 del; 4 mod

Fix signature attribute generation for null restrictions

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/valhalla/pull/1848

From coleenp at openjdk.org  Fri Dec 19 19:12:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Dec 2025 19:12:03 GMT
Subject: [lworld] RFR: 8367408: [lworld]
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails [v2]
In-Reply-To: <QIb414U4w2GRNE-mrVpEgqVCHndHTKB_Swmm-ZbuN8w=.ad4c93c6-b6f9-45d9-825a-856d23e44c31@github.com>
References: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
 <QIb414U4w2GRNE-mrVpEgqVCHndHTKB_Swmm-ZbuN8w=.ad4c93c6-b6f9-45d9-825a-856d23e44c31@github.com>
Message-ID: <AuoQSWV-rVH9iVF_vg6ATHjpcE7Kf13GdPNUanfFD30=.71611134-4ebd-471c-8413-8e2d3a547eb9@github.com>

On Fri, 19 Dec 2025 17:55:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class.  The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348).  This change moves where they are regenerated to where the method is linked.
>> 
>> Testing with tier1-4. in progress, and with the failed test.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'lworld' into method-handles
>  - 8367408: [lworld] runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails

Thanks Matias for reviewing.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1837#issuecomment-3676195549

From vromero at openjdk.org  Fri Dec 19 19:26:27 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 19:26:27 GMT
Subject: RFR: Fixing nullability regression tests
Message-ID: <7XPP4b4jYvl1qiA5cqjl42OWIgC3wGECw3Yb_TKZGl8=.3703ca1e-0da6-4aea-8abb-6119245df141@github.com>

fixing nullability regression tests

-------------

Commit messages:
 - Merge branch 'bworld' into fixing.regression.tests.in.bworld
 - fixing nullability regression tests
 - fixing regression tests in bworld

Changes: https://git.openjdk.org/valhalla/pull/1849/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1849&range=00
  Stats: 747 lines in 10 files changed: 3 ins; 711 del; 33 mod
  Patch: https://git.openjdk.org/valhalla/pull/1849.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1849/head:pull/1849

PR: https://git.openjdk.org/valhalla/pull/1849

From vromero at openjdk.org  Fri Dec 19 19:42:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 19:42:45 GMT
Subject: Integrated: Fixing nullability regression tests
In-Reply-To: <7XPP4b4jYvl1qiA5cqjl42OWIgC3wGECw3Yb_TKZGl8=.3703ca1e-0da6-4aea-8abb-6119245df141@github.com>
References: <7XPP4b4jYvl1qiA5cqjl42OWIgC3wGECw3Yb_TKZGl8=.3703ca1e-0da6-4aea-8abb-6119245df141@github.com>
Message-ID: <55DLCDNafX2nPGRNi_RRWYijTzfgXnYWpbe5-AuH-iI=.ca400348-3bd1-4399-b91d-f385d9c1fabe@github.com>

On Fri, 19 Dec 2025 19:11:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing nullability regression tests

This pull request has now been integrated.

Changeset: 87f7a408
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/87f7a4088fb34ec5e1bd43770c36fca3a68e628d
Stats:     747 lines in 10 files changed: 3 ins; 711 del; 33 mod

Fixing nullability regression tests

-------------

PR: https://git.openjdk.org/valhalla/pull/1849

From coleenp at openjdk.org  Fri Dec 19 20:50:01 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 19 Dec 2025 20:50:01 GMT
Subject: [lworld] RFR: 8367408: [lworld]
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails [v3]
In-Reply-To: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
References: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
Message-ID: <0sVoepdRGolHCeuFrNJMcSeyLs_dX9Wxbh0MIV46iWI=.25ada8a3-b9b8-4ba5-825c-f330e89be863@github.com>

> This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class.  The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348).  This change moves where they are regenerated to where the method is linked.
> 
> Testing with tier1-4. in progress, and with the failed test.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Removing two tests from ProblemList-enable-valhalla.txt that pass with this fix.

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1837/files
  - new: https://git.openjdk.org/valhalla/pull/1837/files/7c16d8df..f8c23ab7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1837&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1837&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1837.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1837/head:pull/1837

PR: https://git.openjdk.org/valhalla/pull/1837

From vromero at openjdk.org  Fri Dec 19 21:04:45 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 21:04:45 GMT
Subject: Integrated: fixing regression test CheckExamples
Message-ID: <hps3ch3cNGRLufzltkgD66nk8--SJGfCkLPY12JJiY4=.f2cae048-88a2-4067-b209-f740d3e53368@github.com>

fixing CheckExamples

-------------

Commit messages:
 - fixing regression test CheckExamples

Changes: https://git.openjdk.org/valhalla/pull/1850/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1850&range=00
  Stats: 103 lines in 4 files changed: 31 ins; 71 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1850.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1850/head:pull/1850

PR: https://git.openjdk.org/valhalla/pull/1850

From vromero at openjdk.org  Fri Dec 19 21:04:46 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 21:04:46 GMT
Subject: Integrated: fixing regression test CheckExamples
In-Reply-To: <hps3ch3cNGRLufzltkgD66nk8--SJGfCkLPY12JJiY4=.f2cae048-88a2-4067-b209-f740d3e53368@github.com>
References: <hps3ch3cNGRLufzltkgD66nk8--SJGfCkLPY12JJiY4=.f2cae048-88a2-4067-b209-f740d3e53368@github.com>
Message-ID: <m3mwvykc6qMy95kkl1pZgdAff9ieQ3l-wegDD_WU0SY=.14c5ab81-9ba3-4e63-aeb2-acfa7cec7c7e@github.com>

On Fri, 19 Dec 2025 20:58:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> fixing CheckExamples

This pull request has now been integrated.

Changeset: 08e91284
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/08e9128448b67fe4037e8d54b8f894bcee02a8b8
Stats:     103 lines in 4 files changed: 31 ins; 71 del; 1 mod

fixing regression test CheckExamples

-------------

PR: https://git.openjdk.org/valhalla/pull/1850

From fparain at openjdk.org  Fri Dec 19 21:33:32 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 19 Dec 2025 21:33:32 GMT
Subject: [lworld] RFR: 8367408: [lworld]
 runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java#aot fails [v3]
In-Reply-To: <0sVoepdRGolHCeuFrNJMcSeyLs_dX9Wxbh0MIV46iWI=.25ada8a3-b9b8-4ba5-825c-f330e89be863@github.com>
References: <YOmwKiIWJXGE8YyJlLnsWTeat47n-p8GqjQDSIRhoN8=.3168a635-06d7-4ea7-8f21-6d451488bb59@github.com>
 <0sVoepdRGolHCeuFrNJMcSeyLs_dX9Wxbh0MIV46iWI=.25ada8a3-b9b8-4ba5-825c-f330e89be863@github.com>
Message-ID: <8KET9B0XYH4oOxuruN0xY6WR4m6BNpKbeMscbGdM-dU=.67cdf55b-231e-4886-98df-a46e9017d305@github.com>

On Fri, 19 Dec 2025 20:50:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This test has failed for various reasons, but the last of the reasons was that sig_cc - calling convention adapter for scalarized parameters was null for a value class.  The sig_cc adapter for valhalla won't be saved with AOT until [JDK-8373348](https://bugs.openjdk.org/browse/JDK-8373348).  This change moves where they are regenerated to where the method is linked.
>> 
>> Testing with tier1-4. in progress, and with the failed test.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing two tests from ProblemList-enable-valhalla.txt that pass with this fix.

LGTM

-------------

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1837#pullrequestreview-3600196783

From chagedorn at openjdk.org  Fri Dec 19 21:36:19 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Fri, 19 Dec 2025 21:36:19 GMT
Subject: [lworld] Integrated: 8374117: [lworld] Disable Valhalla specific VM
 flags when --enable-preview is not set
In-Reply-To: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>
References: <c-ebG2_xThJyEjAutDIEh5t8rlC242xzsoKBNqqVizU=.ebcbc651-c0d7-4dd4-908d-25594ff176f9@github.com>
Message-ID: <fkLt9-Trdz46he7MqEmGdqDyJL838TjTkbFUd2IbUqU=.d850166e-cc01-4123-aa87-d4264d790675@github.com>

On Fri, 19 Dec 2025 15:38:29 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> There are currently a lot of failures in the CI with the following assert:
> 
>  assert(UseArrayFlattening && is_reference_type(bt) && element_ptr->can_be_inline_type() && (!element_ptr->is_inlinetypeptr() || element_ptr->inline_klass()->maybe_flat_in_array())) failed: array can't be flat
> 
> 
> The reason is that C2 is using `UseArrayFlattening` to decide if some array type is known to be not flat. For example here:
> https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/opto/library_call.cpp#L5197-L5198
> 
> 
> When `--enable-preview` is not provided, we know that nothing is flat (i.e. all array types are known to be not flat). However, since `UseArrayFlattening` is still set to true by default, the C2 code above, for example, checks the flag and then assumes some array is not known to be non-flat. This clashes with other code that does an `--enable-preview` check as for example here:
> https://github.com/openjdk/valhalla/blob/69399cedf6fe208832a66c134d370af860154bc2/src/hotspot/share/ci/ciInstanceKlass.cpp#L729-L732
> 
> and we get inconsistent results, leading to the assertion failure below.
> 
> We could fix all the places where we use Valhalla specific flags and make sure it works without setting `--enable-preview`. But I propose the easier fix to just disable Valhalla specific flags when `--enable-preview` is not set. This also protects us from future uses of the flag in shared code.
> 
> #### Additional Fix
> `LibraryCallKit::inline_array_copyOf()` unconditionally sets "not-null-free" of a `TypeAryKlassPtr` to false because we don't know anything about it. However, when we run without `--enable-preview`, then we will not have null-free arrays. Therefore, we can set it to true in this case. When we don't do that, we will later assert where we check that when an array is NOT not-null-free, then we must be dealing with some kind of value class, which is not the case.
> 
> #### Implementation
> I defined local macros in order to set the Valhalla flags to false and emit a warning when we set any of the flags added for Valhalla that they don't have an effect.
> 
> #### Future Work
> We might want to add more sanity assertion checks for flat and nullness information when we create new type instances in the code. But since this is a bug fix for the CI, I'm leaving that as follow-up work.
> 
> #### Testing
> - t1-3 (still running)
> - previously failing t4 AOT tests (still running)
> 
> #### Alternative Fix
> Fix all the mismatched cases directly in the code and allow V...

This pull request has now been integrated.

Changeset: 6886e815
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/6886e815f01f1e553718460deecf4aefa2b0dad6
Stats:     50 lines in 2 files changed: 38 ins; 0 del; 12 mod

8374117: [lworld] Disable Valhalla specific VM flags when --enable-preview is not set

Reviewed-by: fparain

-------------

PR: https://git.openjdk.org/valhalla/pull/1846

From vromero at openjdk.org  Fri Dec 19 23:33:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 23:33:04 GMT
Subject: Integrated: remove hidden option
 allowNullRestrictedTypesForValueClassesOnly
Message-ID: <z4URxvG-sspPTwR_r_Jz_rvKBwjjYraPVOamfoCMJFc=.ea325f0c-67cc-45d5-aa83-173a6229f12c@github.com>

just removing a hidden option that is not meaningful anymore

-------------

Commit messages:
 - remove hidden option allowNullRestrictedTypesForValueClassesOnly

Changes: https://git.openjdk.org/valhalla/pull/1851/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1851&range=00
  Stats: 56 lines in 3 files changed: 0 ins; 56 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1851.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1851/head:pull/1851

PR: https://git.openjdk.org/valhalla/pull/1851

From vromero at openjdk.org  Fri Dec 19 23:33:04 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 19 Dec 2025 23:33:04 GMT
Subject: Integrated: remove hidden option
 allowNullRestrictedTypesForValueClassesOnly
In-Reply-To: <z4URxvG-sspPTwR_r_Jz_rvKBwjjYraPVOamfoCMJFc=.ea325f0c-67cc-45d5-aa83-173a6229f12c@github.com>
References: <z4URxvG-sspPTwR_r_Jz_rvKBwjjYraPVOamfoCMJFc=.ea325f0c-67cc-45d5-aa83-173a6229f12c@github.com>
Message-ID: <a-1jg_qF12LvmJFUPX1DxBcBG_Pwa7zaMGAuefzBwLc=.a15c47bf-68a6-4d02-ae25-5870874283f8@github.com>

On Fri, 19 Dec 2025 23:26:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just removing a hidden option that is not meaningful anymore

This pull request has now been integrated.

Changeset: 0ed7b829
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ed7b8299fc4d53f23730777ed5c7fd29e4eef83
Stats:     56 lines in 3 files changed: 0 ins; 56 del; 0 mod

remove hidden option allowNullRestrictedTypesForValueClassesOnly

-------------

PR: https://git.openjdk.org/valhalla/pull/1851

From vromero at openjdk.org  Sat Dec 20 03:19:34 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 20 Dec 2025 03:19:34 GMT
Subject: Integrated: Remove parametric nullity and nullable marker
Message-ID: <vtWdqYYG_xskcrG-g6xGGZVyzS49qt7SqeTlrgVA2tQ=.e86c44f3-bc7a-4f9f-9eb3-267a386308fa@github.com>

Remove parametric nullity

-------------

Commit messages:
 - remove parametric nullity

Changes: https://git.openjdk.org/valhalla/pull/1853/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1853&range=00
  Stats: 73 lines in 10 files changed: 0 ins; 65 del; 8 mod
  Patch: https://git.openjdk.org/valhalla/pull/1853.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1853/head:pull/1853

PR: https://git.openjdk.org/valhalla/pull/1853

From vromero at openjdk.org  Sat Dec 20 03:19:35 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 20 Dec 2025 03:19:35 GMT
Subject: Integrated: Remove parametric nullity and nullable marker
In-Reply-To: <vtWdqYYG_xskcrG-g6xGGZVyzS49qt7SqeTlrgVA2tQ=.e86c44f3-bc7a-4f9f-9eb3-267a386308fa@github.com>
References: <vtWdqYYG_xskcrG-g6xGGZVyzS49qt7SqeTlrgVA2tQ=.e86c44f3-bc7a-4f9f-9eb3-267a386308fa@github.com>
Message-ID: <1qaqYqVIvhXxuZOy31VcPfhlxDMX93U9dvHRo65NhGc=.99276df6-36b5-445e-9692-a3977090a29d@github.com>

On Sat, 20 Dec 2025 03:09:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Remove parametric nullity

This pull request has now been integrated.

Changeset: 2816de0c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/2816de0c64a9da712292aebeb135b594d27cc1da
Stats:     73 lines in 10 files changed: 0 ins; 65 del; 8 mod

Remove parametric nullity and nullable marker

-------------

PR: https://git.openjdk.org/valhalla/pull/1853

From duke at openjdk.org  Sat Dec 20 15:01:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Sat, 20 Dec 2025 15:01:10 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
Message-ID: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>

Preview mode support for exploded build.

This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

-------------

Commit messages:
 - remove redundant function definition
 - Alternate preview mode support for exploded build

Changes: https://git.openjdk.org/valhalla/pull/1854/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1854&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373987
  Stats: 55 lines in 3 files changed: 25 ins; 11 del; 19 mod
  Patch: https://git.openjdk.org/valhalla/pull/1854.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1854/head:pull/1854

PR: https://git.openjdk.org/valhalla/pull/1854

From duke at openjdk.org  Sat Dec 20 15:18:54 2025
From: duke at openjdk.org (David Beaumont)
Date: Sat, 20 Dec 2025 15:18:54 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
Message-ID: <NxgkOHeNfTIe0Urb9vmMwEJG1E7zA-QOEYo_H7cqzOs=.69fdda5f-e403-4e57-8814-bc51e5007ace@github.com>

On Fri, 19 Dec 2025 15:36:35 GMT, David Beaumont <duke at openjdk.org> wrote:

> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
> 
> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

A better version of the fix is: https://github.com/openjdk/valhalla/pull/1854

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1845#issuecomment-3677892330

From duke at openjdk.org  Sun Dec 21 18:35:25 2025
From: duke at openjdk.org (Christopher Sahnwaldt)
Date: Sun, 21 Dec 2025 18:35:25 GMT
Subject: [valhalla-docs] RFR: site/_index.md: Fix JEP 401 link
Message-ID: <ecH8k52SaQ-81d7Opk0DmVYdNrMwE4upgmsXk74spiE=.aa9a1967-c173-407a-bedb-3288fb3e571a@github.com>

typo: link should point to 401, not 390

-------------

Commit messages:
 - site/_index.md: remove line break added by GitHub editor
 - try to remove line break added by GitHub editor
 - site/_index.md: Fix JEP 401 link

Changes: https://git.openjdk.org/valhalla-docs/pull/15/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla-docs&pr=15&range=00
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla-docs/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/valhalla-docs.git pull/15/head:pull/15

PR: https://git.openjdk.org/valhalla-docs/pull/15

From duke at openjdk.org  Sun Dec 21 18:38:48 2025
From: duke at openjdk.org (duke)
Date: Sun, 21 Dec 2025 18:38:48 GMT
Subject: [valhalla-docs] RFR: site/_index.md: Fix JEP 401 link
In-Reply-To: <ecH8k52SaQ-81d7Opk0DmVYdNrMwE4upgmsXk74spiE=.aa9a1967-c173-407a-bedb-3288fb3e571a@github.com>
References: <ecH8k52SaQ-81d7Opk0DmVYdNrMwE4upgmsXk74spiE=.aa9a1967-c173-407a-bedb-3288fb3e571a@github.com>
Message-ID: <yduC7e1AZGFwm1K-PniGOAGc55HGmRETwGgpptSU0Vo=.6e9d31a4-17ec-4ecb-892a-9e9ebf954113@github.com>

On Sun, 21 Dec 2025 18:28:24 GMT, Christopher Sahnwaldt <duke at openjdk.org> wrote:

> typo: link should point to 401, not 390

@jcsahnwaldt 
Your change (at version ff1997606fbe3094419d2c82086ff4c693cb37ed) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla-docs/pull/15#issuecomment-3679278395

From dfenacci at openjdk.org  Mon Dec 22 09:07:18 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 22 Dec 2025 09:07:18 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v8]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <TbXXYRVLZiVQanVVdp1wzwiCVlrSBmKHuK4YaHo3yOo=.1e829d6b-e60e-41b3-ad98-b0556ed59493@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 ca...

Damon Fenacci has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'lworld' into JDK-8369045
 - Merge branch 'lworld' into JDK-8369045
 - JDK-8369045 remove another test from problemlist
 - JDK-8369045 remove tests from problemlist
 - Merge branch 'lworld' into JDK-8369045
 - Merge branch 'JDK-8369045' of https://github.com/dafedafe/valhalla into JDK-8369045
 - Update src/hotspot/share/opto/graphKit.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - JDK-8369045: don't re-add condition if stress-reducing
 - Revert "JDK-8369045: remove strength reduction flag"
   
   This reverts commit ccf58125b13655bb6c15af747345efbd6791f93d.
 - JDK-8369045: remove strength reduction flag
 - ... and 6 more: https://git.openjdk.org/valhalla/compare/6886e815...ab535b4d

-------------

Changes: https://git.openjdk.org/valhalla/pull/1768/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1768&range=07
  Stats: 70 lines in 5 files changed: 27 ins; 8 del; 35 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 dfenacci at openjdk.org  Mon Dec 22 09:43:09 2025
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Mon, 22 Dec 2025 09:43:09 GMT
Subject: [lworld] RFR: 8369045: [lworld]
 valhalla/valuetypes/WeakReferenceTest.java has an unschedulable graph [v9]
In-Reply-To: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
References: <PAIYu82HtGuJhEEKdulDwqhER_1SBPyLb1Yf3jdyK0o=.69ce851e-489d-42e1-81c3-5d6011bb05f2@github.com>
Message-ID: <pze-CsB51jKU2ffoZIRj6DnujjcbQEi00EQ1BzQWZZ0=.8fe2e5cf-1899-4b7f-a5d1-adb70e5883a3@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 ca...

Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8369045 remove more tests from problemlist

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1768/files
  - new: https://git.openjdk.org/valhalla/pull/1768/files/ab535b4d..b0c496af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1768&range=08
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1768&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 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 stefank at openjdk.org  Mon Dec 22 09:54:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 09:54:21 GMT
Subject: [lworld] RFR: 8374016: [lworld] Too late checked_cast in
 ResolvedFieldEntry::set_flags
In-Reply-To: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
References: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
Message-ID: <RhnYPH9JOzeYoo85YN121jKJK6hhiZdKA0R7wELMPzM=.b721f1ed-91f6-49a8-b50d-79888a111ee7@github.com>

On Fri, 19 Dec 2025 12:32:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the lworld branch the `new_flags` type has been changed to u1 instead of int. We now perform a bunch of bit operations, which results in an int, and then we narrow that down into a u1. After the u1 has been created we check that this doesn't overflow a u1 with the checked_cast<u1> check. That's too late.
> 
> Mainline code looks like this:
> 
> int new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> and Valhalla code looks like this:
> 
> u1 new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> This voids the benefit of having a checked_cast here. I propose that we revert back to using `int new_flags` and keep the checked_cast<u1>.
> 
> While reading this code there were a few things that made the code harder to follow and I've tweaked it.
> 
> 1) The `bool` `is_volatile_shift` is special-treated and instead of shifting it is directly casted to int. That hard codes a knowledge/assumption that the flag is always going to be 1 (and maybe also what value bools have).
> 
> That made me have to look at the actual values of these and at one point I thought that is_volatile_shift was `1` and not `0` and that the above was a bug. The main reason I thought that was this odd order here:
> 
>    u1 new_flags = ((is_final_flag ? 1 : 0) << is_final_shift) | static_cast<int>(is_volatile_flag) |
>       ((is_flat_flag ? 1 : 0) << is_flat_shift) |
>       ((is_null_free_inline_type_flag ? 1 : 0) << is_null_free_inline_type_shift) |
>       ((has_null_marker_flag ? 1 : 0) << has_null_marker_shift);
> 
> Here the order of usage is
> 
> is_final_flag
> is_volatile_flag
> is_flat_flag
> is_null_free_inline_type_flag
> has_null_marker_flag
> 
> 
> but the enum order has final and volatile swapped:
> 
> is_volatile_shift
> is_final_shift
> is_flat_shift
> is_null_free_inline_type_shift
> has_null_marker_shift
> 
> 
> I'd prefer if we stayed consistent with the order, to lower the risk that some bugs sneak in here. So, I've replaced the cast with a shift (just like the other values are handled) and I  ordered functions, parameters, and operations in the same order as the enums.
> 
> 2) Tweaked some alignments to make these kind of issues clearer.
> 
> Please tell me if I went to far with the style changes.

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1844#issuecomment-3681283100

From duke at openjdk.org  Mon Dec 22 09:54:21 2025
From: duke at openjdk.org (duke)
Date: Mon, 22 Dec 2025 09:54:21 GMT
Subject: [lworld] RFR: 8374016: [lworld] Too late checked_cast in
 ResolvedFieldEntry::set_flags
In-Reply-To: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
References: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
Message-ID: <AJMMKDssLsXdUjgs5RmMbE0GRNP2582rEXWasFpnrmw=.eafd4e5d-8aa3-493c-b37f-10c39fc5917a@github.com>

On Fri, 19 Dec 2025 12:32:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the lworld branch the `new_flags` type has been changed to u1 instead of int. We now perform a bunch of bit operations, which results in an int, and then we narrow that down into a u1. After the u1 has been created we check that this doesn't overflow a u1 with the checked_cast<u1> check. That's too late.
> 
> Mainline code looks like this:
> 
> int new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> and Valhalla code looks like this:
> 
> u1 new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> This voids the benefit of having a checked_cast here. I propose that we revert back to using `int new_flags` and keep the checked_cast<u1>.
> 
> While reading this code there were a few things that made the code harder to follow and I've tweaked it.
> 
> 1) The `bool` `is_volatile_shift` is special-treated and instead of shifting it is directly casted to int. That hard codes a knowledge/assumption that the flag is always going to be 1 (and maybe also what value bools have).
> 
> That made me have to look at the actual values of these and at one point I thought that is_volatile_shift was `1` and not `0` and that the above was a bug. The main reason I thought that was this odd order here:
> 
>    u1 new_flags = ((is_final_flag ? 1 : 0) << is_final_shift) | static_cast<int>(is_volatile_flag) |
>       ((is_flat_flag ? 1 : 0) << is_flat_shift) |
>       ((is_null_free_inline_type_flag ? 1 : 0) << is_null_free_inline_type_shift) |
>       ((has_null_marker_flag ? 1 : 0) << has_null_marker_shift);
> 
> Here the order of usage is
> 
> is_final_flag
> is_volatile_flag
> is_flat_flag
> is_null_free_inline_type_flag
> has_null_marker_flag
> 
> 
> but the enum order has final and volatile swapped:
> 
> is_volatile_shift
> is_final_shift
> is_flat_shift
> is_null_free_inline_type_shift
> has_null_marker_shift
> 
> 
> I'd prefer if we stayed consistent with the order, to lower the risk that some bugs sneak in here. So, I've replaced the cast with a shift (just like the other values are handled) and I  ordered functions, parameters, and operations in the same order as the enums.
> 
> 2) Tweaked some alignments to make these kind of issues clearer.
> 
> Please tell me if I went to far with the style changes.

@stefank 
Your change (at version c7001418690f911819ae6de40ebeefd37e90e566) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1844#issuecomment-3681290585

From lfoltan at openjdk.org  Mon Dec 22 14:47:26 2025
From: lfoltan at openjdk.org (Lois Foltan)
Date: Mon, 22 Dec 2025 14:47:26 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
Message-ID: <wdrWr67Ycj8ZcsmQqe7ShTuQ59hudNGahqW91zYVkss=.61ab307d-f23f-4afd-b882-9e1c6ba4ab63@github.com>

On Sat, 20 Dec 2025 14:54:27 GMT, David Beaumont <duke at openjdk.org> wrote:

> Preview mode support for exploded build.
> 
> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

LGTM.

One nit at line #735 in classLoader.cpp, the convention within the file is to specify the variable that you are checking nullptr against first, if (preview_entry != nullptr)...

Thanks,
Lois

Marked as reviewed by lfoltan (Committer).

-------------

Marked as reviewed by lfoltan (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1854#pullrequestreview-3604345803
PR Review: https://git.openjdk.org/valhalla/pull/1854#pullrequestreview-3604348116

From rriggs at openjdk.org  Mon Dec 22 15:00:57 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Dec 2025 15:00:57 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
Message-ID: <0ffYPwWxQ6AmLVQS8uAlUW2YNo6MXGUTjp987DNr-lk=.e66767c5-f406-420f-9514-f830296f254d@github.com>

On Sat, 20 Dec 2025 14:54:27 GMT, David Beaumont <duke at openjdk.org> wrote:

> Preview mode support for exploded build.
> 
> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

src/hotspot/share/classfile/classLoader.cpp line 276:

> 274: 
> 275: // Returns the access mode for an initialized JImage file (reflects --enable-preview).
> 276: static bool is_preview_enabled() {

Previously, the preview related names were associated with jimage mode, expanding that to the exploded image raises a question about the name and the name set_preview_mode ; there may be some ambiguity in this is_preview_enabled() and the vm wide method(s) indicating --enable-preview across all HotSpot functions.
It would be good if this name could reflect the mode of loading classes.
Maybe...
is_class_loading_mode_preview() based on class_loading_mode.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1854#discussion_r2640102161

From stefank at openjdk.org  Mon Dec 22 15:24:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 22 Dec 2025 15:24:26 GMT
Subject: [lworld] Integrated: 8374016: [lworld] Too late checked_cast in
 ResolvedFieldEntry::set_flags
In-Reply-To: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
References: <5wwbfj35oDX-YDvJOn09R1-g7Fb_0MMzo7E4KHdyx7M=.7ef9bb46-1203-45d2-a278-3afb99fc1c88@github.com>
Message-ID: <lELeC9niQebUDXm1PGogajr_Ni_Zg0CJ36AlaPGRCKw=.23293a16-9045-4a63-b345-87f0ef787269@github.com>

On Fri, 19 Dec 2025 12:32:03 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In the lworld branch the `new_flags` type has been changed to u1 instead of int. We now perform a bunch of bit operations, which results in an int, and then we narrow that down into a u1. After the u1 has been created we check that this doesn't overflow a u1 with the checked_cast<u1> check. That's too late.
> 
> Mainline code looks like this:
> 
> int new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> and Valhalla code looks like this:
> 
> u1 new_flags = ...
> _flags = checked_cast<u1>(new_flags);
> 
> 
> This voids the benefit of having a checked_cast here. I propose that we revert back to using `int new_flags` and keep the checked_cast<u1>.
> 
> While reading this code there were a few things that made the code harder to follow and I've tweaked it.
> 
> 1) The `bool` `is_volatile_shift` is special-treated and instead of shifting it is directly casted to int. That hard codes a knowledge/assumption that the flag is always going to be 1 (and maybe also what value bools have).
> 
> That made me have to look at the actual values of these and at one point I thought that is_volatile_shift was `1` and not `0` and that the above was a bug. The main reason I thought that was this odd order here:
> 
>    u1 new_flags = ((is_final_flag ? 1 : 0) << is_final_shift) | static_cast<int>(is_volatile_flag) |
>       ((is_flat_flag ? 1 : 0) << is_flat_shift) |
>       ((is_null_free_inline_type_flag ? 1 : 0) << is_null_free_inline_type_shift) |
>       ((has_null_marker_flag ? 1 : 0) << has_null_marker_shift);
> 
> Here the order of usage is
> 
> is_final_flag
> is_volatile_flag
> is_flat_flag
> is_null_free_inline_type_flag
> has_null_marker_flag
> 
> 
> but the enum order has final and volatile swapped:
> 
> is_volatile_shift
> is_final_shift
> is_flat_shift
> is_null_free_inline_type_shift
> has_null_marker_shift
> 
> 
> I'd prefer if we stayed consistent with the order, to lower the risk that some bugs sneak in here. So, I've replaced the cast with a shift (just like the other values are handled) and I  ordered functions, parameters, and operations in the same order as the enums.
> 
> 2) Tweaked some alignments to make these kind of issues clearer.
> 
> Please tell me if I went to far with the style changes.

This pull request has now been integrated.

Changeset: 27a8cbeb
Author:    Stefan Karlsson <stefank at openjdk.org>
Committer: Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/27a8cbeb6c968e8636ef07c01202dc9f18598251
Stats:     28 lines in 2 files changed: 8 ins; 2 del; 18 mod

8374016: [lworld] Too late checked_cast in ResolvedFieldEntry::set_flags

Reviewed-by: fparain, matsaave

-------------

PR: https://git.openjdk.org/valhalla/pull/1844

From fparain at openjdk.org  Mon Dec 22 16:10:24 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 22 Dec 2025 16:10:24 GMT
Subject: [lworld] RFR: 8374093: [lworld] Cleanup and polish around
 vgetfield/vputfield [v2]
In-Reply-To: <DtlfHImivcCOwIcQBRomT4172s_DATM4senabP5CINM=.3f6cf0f1-005e-4cc8-9903-21746e96dd49@github.com>
References: <cFyBr2gmZC1Iqo_h5hxpw2CjYueR9sAw8VMNwmcEfWU=.e17dc5e4-7fe2-478f-a7e9-2a413e298571@github.com>
 <DtlfHImivcCOwIcQBRomT4172s_DATM4senabP5CINM=.3f6cf0f1-005e-4cc8-9903-21746e96dd49@github.com>
Message-ID: <ggdxNl1mHnSTZ0iUfSdWaCjmhALCU6n_nKOqKX1XehA=.c471e7e6-64fd-4817-baec-d603e6a1eec5@github.com>

On Fri, 19 Dec 2025 14:33:13 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> I've been looking at the new internal bytecodes vgetfield and vputfield and their callchains from the interpreter down to InlineKlass and have some cleanups. I've not looked at templateTable_x86 so far, only templateTable_aarch64.
>> 
>> Some notes:
>> * The `dest_is_initialized` parameter in InlineKlass::write_value_to_addr is `true` for all callers, so I've removed it and inlined `true` to the call to `copy_payload_to_addr`.
>> * There seems to be an unnecessary `mark_payload_as_non_null((address)src);` in InlineKlass::copy_payload_to_addr, as the payload should already be non_null if it doesn't match `is_payload_marked_as_null` in the if-statement just above.
>> 
>> Testing:
>> * hotspot_valhalla, jdk_valhalla and tier1
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanup

LGTM.
Thank you for this cleanup.

-------------

Marked as reviewed by fparain (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1840#pullrequestreview-3604693837

From rriggs at openjdk.org  Mon Dec 22 18:10:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Dec 2025 18:10:52 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
Message-ID: <zfqUrjM7GuZHlV-oWret69_5PHfjBmh0qRWkih3-Ito=.726d92c7-bcad-424a-9c23-25625d082f6c@github.com>

On Sat, 20 Dec 2025 14:54:27 GMT, David Beaumont <duke at openjdk.org> wrote:

> Preview mode support for exploded build.
> 
> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

Lets go with this version. It has a Hotspot approval.

-------------

Marked as reviewed by rriggs (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1854#pullrequestreview-3605163734

From duke at openjdk.org  Mon Dec 22 18:52:33 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Dec 2025 18:52:33 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <wdrWr67Ycj8ZcsmQqe7ShTuQ59hudNGahqW91zYVkss=.61ab307d-f23f-4afd-b882-9e1c6ba4ab63@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
 <wdrWr67Ycj8ZcsmQqe7ShTuQ59hudNGahqW91zYVkss=.61ab307d-f23f-4afd-b882-9e1c6ba4ab63@github.com>
Message-ID: <W-eW8CcCy602_O9L3-kAQt1Wrrcc6NQZtndEG72gKjU=.30824e41-6c96-42ea-a14c-1b8b50e13e46@github.com>

On Mon, 22 Dec 2025 14:43:41 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

> LGTM.
> 
> One nit at line #735 in classLoader.cpp, the convention within the file is to specify the variable that you are checking nullptr against first, if (preview_entry != nullptr)...
> 
> Thanks, Lois

I was just following what I saw code around doing (I don't know if you'd catch "(x = nullptr)" and assumed the reversed/"yoda" style was a guard against that.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1854#issuecomment-3683603422

From duke at openjdk.org  Mon Dec 22 18:57:27 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Dec 2025 18:57:27 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <0ffYPwWxQ6AmLVQS8uAlUW2YNo6MXGUTjp987DNr-lk=.e66767c5-f406-420f-9514-f830296f254d@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
 <0ffYPwWxQ6AmLVQS8uAlUW2YNo6MXGUTjp987DNr-lk=.e66767c5-f406-420f-9514-f830296f254d@github.com>
Message-ID: <rMNL90D1j-0ENZDPZd2CWId8oq8fmnpi_9VzqiWUiCQ=.781ba198-11ac-44c8-a6da-3e711a66b1e6@github.com>

On Mon, 22 Dec 2025 14:44:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Preview mode support for exploded build.
>> 
>> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.
>
> src/hotspot/share/classfile/classLoader.cpp line 276:
> 
>> 274: 
>> 275: // Returns the access mode for an initialized JImage file (reflects --enable-preview).
>> 276: static bool is_preview_enabled() {
> 
> Previously, the preview related names were associated with jimage mode, expanding that to the exploded image raises a question about the name and the name set_preview_mode ; there may be some ambiguity in this is_preview_enabled() and the vm wide method(s) indicating --enable-preview across all HotSpot functions.
> It would be good if this name could reflect the mode of loading classes.
> Maybe...
> is_class_loading_mode_preview() based on class_loading_mode.

I mean it is the "class loader", so to me the question "is preview enabled?" in this class would mean (implicitly) "for class loading". I guess "should_load_preview_classes()" and "set_preview_class_loading()" are more descriptive, but then again the flag controlling this is "--enable-preview", so "is preview enabled" ties back very nicely.

I'd vote to not change it in this PR and we can discuss the finer points of this after Xmas.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/1854#discussion_r2640918126

From duke at openjdk.org  Mon Dec 22 19:00:29 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Dec 2025 19:00:29 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
Message-ID: <pAxQLkZqdNfoQvT6UzHe_yh8Jr9uPgMKurS6IoZ8rE4=.2dcc353c-b715-4ab7-aceb-cb6478f1d32e@github.com>

On Sat, 20 Dec 2025 14:54:27 GMT, David Beaumont <duke at openjdk.org> wrote:

> Preview mode support for exploded build.
> 
> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

Looking again, you're right that the commonest case is (x == nullptr). I was just unlucky enough to be near some of the small number of violations of that convention.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1854#issuecomment-3683661152

From duke at openjdk.org  Mon Dec 22 19:08:08 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Dec 2025 19:08:08 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806) [v2]
In-Reply-To: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
Message-ID: <VAoLovqO1A6uF9UcIWPOmgfceAx2oWOXx36tCKJCoPM=.38b9925b-16ae-4cb9-bc23-9dfcbdbb7bf5@github.com>

> Preview mode support for exploded build.
> 
> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

David Beaumont has updated the pull request incrementally with one additional commit since the last revision:

  flip guard for consistency

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/1854/files
  - new: https://git.openjdk.org/valhalla/pull/1854/files/153604cc..8a0ce1a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=1854&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=1854&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/1854.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1854/head:pull/1854

PR: https://git.openjdk.org/valhalla/pull/1854

From duke at openjdk.org  Mon Dec 22 19:14:22 2025
From: duke at openjdk.org (duke)
Date: Mon, 22 Dec 2025 19:14:22 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806) [v2]
In-Reply-To: <VAoLovqO1A6uF9UcIWPOmgfceAx2oWOXx36tCKJCoPM=.38b9925b-16ae-4cb9-bc23-9dfcbdbb7bf5@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
 <VAoLovqO1A6uF9UcIWPOmgfceAx2oWOXx36tCKJCoPM=.38b9925b-16ae-4cb9-bc23-9dfcbdbb7bf5@github.com>
Message-ID: <V4FjMvO0shTS2BKI68OtD0_HdoIuHu6HA9kV4VC79vE=.3a0aca16-f51f-4914-8401-324eab9e71ed@github.com>

On Mon, 22 Dec 2025 19:08:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Preview mode support for exploded build.
>> 
>> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flip guard for consistency

@david-beaumont 
Your change (at version 8a0ce1a76ff175679f60b241f45d53f200d80cae) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1854#issuecomment-3683766534

From duke at openjdk.org  Mon Dec 22 19:46:01 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Dec 2025 19:46:01 GMT
Subject: [lworld] Withdrawn: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806)
In-Reply-To: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
References: <v0Eq-_4gbXf84stLz9cSLVVGJ3TylFMRak6a9Egy30c=.f11c4af9-8ecf-4cf5-848c-a77d7b31f35c@github.com>
Message-ID: <VlByf3lumim-aHcWpugiETiF7Jrfh1X8czwEE86r8ys=.9edc5a7e-c2bc-47e5-a30d-3bcfe52eab1c@github.com>

On Fri, 19 Dec 2025 15:36:35 GMT, David Beaumont <duke at openjdk.org> wrote:

> Hopefully a fix for preview mode with exploded images in classLoader.cpp.
> 
> I did a little renaming since now it's clear that "preview mode" isn't a thing that's limited only to a jimage being present.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/valhalla/pull/1845

From amenkov at openjdk.org  Mon Dec 22 20:50:20 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 22 Dec 2025 20:50:20 GMT
Subject: [lworld] RFR: 8368799: [lworld] Heapwalking functions may report array
 classes several times
Message-ID: <Eh0sz_VE-IfU33jwb-_rVRgx-wK1DuIvNNVmfTa1BfA=.45d4195b-6e50-49ca-a114-da05f5bbd2e6@github.com>

The change adds test to verify heap walking API (FollowReferences and IterateOverReachableObjects) do not reports array classes several times

-------------

Commit messages:
 - jcheck
 - heapwalk_dup_classes
 - Merge branch 'openjdk:lworld' into lworld
 - Revert "ctor_debug"
 - ctor_debug

Changes: https://git.openjdk.org/valhalla/pull/1852/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1852&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8368799
  Stats: 226 lines in 2 files changed: 226 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/1852.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1852/head:pull/1852

PR: https://git.openjdk.org/valhalla/pull/1852

From fparain at openjdk.org  Mon Dec 22 20:50:20 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 22 Dec 2025 20:50:20 GMT
Subject: [lworld] RFR: 8368799: [lworld] Heapwalking functions may report
 array classes several times
In-Reply-To: <Eh0sz_VE-IfU33jwb-_rVRgx-wK1DuIvNNVmfTa1BfA=.45d4195b-6e50-49ca-a114-da05f5bbd2e6@github.com>
References: <Eh0sz_VE-IfU33jwb-_rVRgx-wK1DuIvNNVmfTa1BfA=.45d4195b-6e50-49ca-a114-da05f5bbd2e6@github.com>
Message-ID: <sy3_sYB6n4HEcFoAAPnfaWK7_SA6ASrV01ZIVXcoEAg=.3a1e16ca-968c-4c45-a6e3-704bfc6d1c64@github.com>

On Sat, 20 Dec 2025 01:24:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change adds test to verify heap walking API (FollowReferences and IterateOverReachableObjects) do not reports array classes several times

Marked as reviewed by fparain (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1852#pullrequestreview-3604881276

From rriggs at openjdk.org  Mon Dec 22 21:23:31 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Dec 2025 21:23:31 GMT
Subject: [lworld] RFR: 8373987: [lworld] exploded-image/test broken since
 disable patching (JDK-8373806) [v2]
In-Reply-To: <VAoLovqO1A6uF9UcIWPOmgfceAx2oWOXx36tCKJCoPM=.38b9925b-16ae-4cb9-bc23-9dfcbdbb7bf5@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
 <VAoLovqO1A6uF9UcIWPOmgfceAx2oWOXx36tCKJCoPM=.38b9925b-16ae-4cb9-bc23-9dfcbdbb7bf5@github.com>
Message-ID: <JrOxCHLDFj6NlP3O8rf9tS1YslQHJa49bqSfFXym2OA=.296648b1-0af0-4274-bc9c-84737dc60326@github.com>

On Mon, 22 Dec 2025 19:08:08 GMT, David Beaumont <duke at openjdk.org> wrote:

>> Preview mode support for exploded build.
>> 
>> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.
>
> David Beaumont has updated the pull request incrementally with one additional commit since the last revision:
> 
>   flip guard for consistency

Marked as reviewed by rriggs (Committer).

-------------

PR Review: https://git.openjdk.org/valhalla/pull/1854#pullrequestreview-3605787972

From duke at openjdk.org  Mon Dec 22 21:26:21 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 22 Dec 2025 21:26:21 GMT
Subject: [lworld] Integrated: 8373987: [lworld] exploded-image/test broken
 since disable patching (JDK-8373806)
In-Reply-To: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
References: <V_7byldtp6wSmcC-D2gLJSDqnIEGmrZNCtv7zsq9a7g=.2cfb799f-b352-4b5d-897d-be8b1d5a3077@github.com>
Message-ID: <-eV-LPC0Uzvy6MB931DLSkL3JVIAkhcO8rxX-YnuTe0=.a6b0648f-f630-446c-af70-18f8dda5f0e1@github.com>

On Sat, 20 Dec 2025 14:54:27 GMT, David Beaumont <duke at openjdk.org> wrote:

> Preview mode support for exploded build.
> 
> This is an alternate approach from https://github.com/openjdk/valhalla/pull/1845 which I think is actually cleaner and more robust.

This pull request has now been integrated.

Changeset: 423e6934
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/423e6934ad7e50f8c13ec2a79a2f6adf36584856
Stats:     55 lines in 3 files changed: 25 ins; 11 del; 19 mod

8373987: [lworld] exploded-image/test broken since disable patching (JDK-8373806)

Reviewed-by: lfoltan, rriggs

-------------

PR: https://git.openjdk.org/valhalla/pull/1854

From amenkov at openjdk.org  Tue Dec 23 20:05:41 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 23 Dec 2025 20:05:41 GMT
Subject: [lworld] Integrated: 8368799: [lworld] Heapwalking functions may
 report array classes several times
In-Reply-To: <Eh0sz_VE-IfU33jwb-_rVRgx-wK1DuIvNNVmfTa1BfA=.45d4195b-6e50-49ca-a114-da05f5bbd2e6@github.com>
References: <Eh0sz_VE-IfU33jwb-_rVRgx-wK1DuIvNNVmfTa1BfA=.45d4195b-6e50-49ca-a114-da05f5bbd2e6@github.com>
Message-ID: <G16FBwzmMhfZtbveh5XRtu0iEx5MYExnPy25vy2iNgI=.c465a104-528b-4dbc-a53e-6093df05a71a@github.com>

On Sat, 20 Dec 2025 01:24:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change adds test to verify heap walking API (FollowReferences and IterateOverReachableObjects) do not reports array classes several times

This pull request has now been integrated.

Changeset: f682e448
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f682e4488ba6d7970cb6450037c4241e79f61018
Stats:     226 lines in 2 files changed: 226 ins; 0 del; 0 mod

8368799: [lworld] Heapwalking functions may report array classes several times

Reviewed-by: fparain

-------------

PR: https://git.openjdk.org/valhalla/pull/1852

From qamai at openjdk.org  Thu Dec 25 13:42:26 2025
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 25 Dec 2025 13:42:26 GMT
Subject: [lworld] RFR: 8227588: [lworld] Better optimize non-flattened inline
 type array accesses
Message-ID: <rsIHZxJmFGQPnCt-Myv9YH-oJySnWKWThXt24GPolQs=.66020e47-fa95-4f18-ae8e-b2551005098c@github.com>

Hi,

This PR removes all the `// TODO 8227588`. Either the problem has already been solved, or I analysed and changed the `TODO` to a more detailed issue.

Please kindly review, thanks a lot.

-------------

Commit messages:
 - Fix JDK-8227588

Changes: https://git.openjdk.org/valhalla/pull/1855/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8227588
  Stats: 6 lines in 3 files changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/valhalla/pull/1855.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1855/head:pull/1855

PR: https://git.openjdk.org/valhalla/pull/1855

From david.simms at oracle.com  Fri Dec 26 12:07:42 2025
From: david.simms at oracle.com (David Simms)
Date: Fri, 26 Dec 2025 12:07:42 +0000
Subject: Result: New Valhalla Committer: Stefan Karlsson
Message-ID: <SA2PR10MB44591C3B9C7A419849D6389F9AB0A@SA2PR10MB4459.namprd10.prod.outlook.com>

Voting for Stefan Karlsson [1] is now closed.

Yes: 8
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-December/016537.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251226/f3dfedb0/attachment.htm>

From david.simms at oracle.com  Fri Dec 26 12:10:12 2025
From: david.simms at oracle.com (David Simms)
Date: Fri, 26 Dec 2025 12:10:12 +0000
Subject: Result: New Valhalla Committer: Axel Boldt-Christmas
Message-ID: <SA2PR10MB4459D59A4BC8AAF25FFB90089AB0A@SA2PR10MB4459.namprd10.prod.outlook.com>

Voting for Axel Boldt-Christmas [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-December/016536.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20251226/1a59e23d/attachment.htm>