> 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: [email protected] 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
