<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
> 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? </div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Yes, in general, the text you've quoted are talking about the object layout optimizations provided by final value class-typed fields.</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
> 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?</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Yes, loading these value classes before the classes that declare fields of these value class types is a viable approach to ensure optimal layout.</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
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.</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Regards,</div>
<div style="font-family: "Calibri Light", "Helvetica Light", sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Chen Liang</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>From:</b> valhalla-dev on behalf of Tommy Ludwig<br>
<b>Sent:</b> Monday, January 19, 2026 1:50 AM<br>
<b>To:</b> valhalla-dev@openjdk.org<br>
<b>Subject:</b> Value objects performance with libraries </div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-size: 11pt;">In the "Value Object Performance" section of the Project Valhalla<br>
Value Objects page[1], it has a bullet point reading:<br>
<br>
> 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.<br>
<br>
Does that mean applications using libraries compiled targeting older<br>
versions of Java will miss out on some possible optimizations even if<br>
they're using JDK classes that are migrated value classes? I see some<br>
more explanation in JEP 401 at the end of this section[2].<br>
<br>
> 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.<br>
<br>
> 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.<br>
<br>
On both pages, the word "may" is used. Could someone provide<br>
clarification on what the necessary condition is for the<br>
optimizations? If the value class V is loaded before class C where it<br>
is used, will the optimizations be possible even without the<br>
LoadableDescriptors attribute? If so, would it be fruitful for<br>
applications (or application frameworks) to eagerly load known value<br>
classes early? It seems like that may help performance in applications<br>
using libraries that have not released a new version yet that is<br>
compiled targeting a version of Java with value types.<br>
<br>
I also noticed in Frederic Parain's JVMLS talk on Value Classes Heap<br>
Flattening, he mentions at this point[3] that there is special<br>
handling of JDK migrated value classes, so they can be optimized even<br>
if class files are lacking the LoadableDescriptors attribute. This<br>
seems like important information that is missing mention in JEP 401,<br>
and I think it would be worth adding it.<br>
<br>
[1] <a data-auth="NotApplicable" rel="noopener noreferrer" class="OWAAutoLink" id="OWA4409e6d9-a2b2-a6c6-b2e2-b530c83d9746" target="_blank" href="https://openjdk.org/projects/valhalla/value-objects#value-object-performance">
https://openjdk.org/projects/valhalla/value-objects#value-object-performance</a><br>
[2] <a data-auth="NotApplicable" rel="noopener noreferrer" class="OWAAutoLink" id="OWA09647a61-6b62-f110-5102-4735e5f8bf9a" target="_blank" href="https://openjdk.org/jeps/401#When-flattening-and-scalarization-can-occur">
https://openjdk.org/jeps/401#When-flattening-and-scalarization-can-occur</a><br>
[3] <a data-auth="NotApplicable" rel="noopener noreferrer" class="OWAAutoLink" id="OWA66108bb1-4612-207a-317a-c1a535799538" target="_blank" href="https://youtu.be/NF4CpL_EWFI?si=yO-Xtw--YvcwNIiS&t=998">
https://youtu.be/NF4CpL_EWFI?si=yO-Xtw--YvcwNIiS&t=998</a><br>
</div>
</body>
</html>