Value objects performance with libraries

[Chen Liang]

> Does that mean applications using libraries compiled targeting older versions of Java will miss out on some possible optimizations even if they're using JDK classes that are migrated value classes?

Yes, in general, the text you've quoted are talking about the object layout optimizations provided by final value class-typed fields.

> If the value class V is loaded before class C where it is used, will the optimizations be possible even without the LoadableDescriptors attribute? If so, would it be fruitful for applications (or application frameworks) to eagerly load known value classes early?

Yes, loading these value classes before the classes that declare fields of these value class types is a viable approach to ensure optimal layout.

The reason such early loading are not default but must be opt-in from newly-compiled class files is that this affects custom class loaders. You might also notice incompatibility or behavioral change in your application if you perform eager loading.

Regards,
Chen Liang

________________________________
From: valhalla-dev on behalf of Tommy Ludwig
Sent: Monday, January 19, 2026 1:50 AM
To: valhalla-dev at openjdk.org
Subject: Value objects performance with libraries

In the "Value Object Performance" section of the Project Valhalla
Value Objects page[1], it has a bullet point reading:

> Older class files that use a migrated value class may not be fully optimized. For best performance, compile all classes that refer to a value class with --enable-preview.

Does that mean applications using libraries compiled targeting older
versions of Java will miss out on some possible optimizations even if
they're using JDK classes that are migrated value classes? I see some
more explanation in JEP 401 at the end of this section[2].

> If a value class V is not listed by the LoadableDescriptors attribute in, e.g., C.class, then when C is loaded, the JVM may not know that V is a value class. A field of type V may be encoded like any other field, storing pointers to objects in memory instead of flattened references. A method with a parameter of type V may not be JIT-compiled to accept scalarized calls, forcing callers to allocate objects on the heap and pass pointers to them.

> In practice, this means that if a class V was migrated to become a value class, other classes that were compiled against an older version of V should be recompiled for optimal performance.

On both pages, the word "may" is used. Could someone provide
clarification on what the necessary condition is for the
optimizations? If the value class V is loaded before class C where it
is used, will the optimizations be possible even without the
LoadableDescriptors attribute? If so, would it be fruitful for
applications (or application frameworks) to eagerly load known value
classes early? It seems like that may help performance in applications
using libraries that have not released a new version yet that is
compiled targeting a version of Java with value types.

I also noticed in Frederic Parain's JVMLS talk on Value Classes Heap
Flattening, he mentions at this point[3] that there is special
handling of JDK migrated value classes, so they can be optimized even
if class files are lacking the LoadableDescriptors attribute. This
seems like important information that is missing mention in JEP 401,
and I think it would be worth adding it.

[1] https://openjdk.org/projects/valhalla/value-objects#value-object-performance
[2] https://openjdk.org/jeps/401#When-flattening-and-scalarization-can-occur
[3] https://youtu.be/NF4CpL_EWFI?si=yO-Xtw--YvcwNIiS&t=998
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260119/fefff5af/attachment-0001.htm>