<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"-" <liangchenblue@gmail.com><br><b>To: </b>"Remi Forax" <forax@univ-mlv.fr><br><b>Cc: </b>"valhalla-dev" <valhalla-dev@openjdk.org><br><b>Sent: </b>Tuesday, April 25, 2023 5:10:06 PM<br><b>Subject: </b>Re: Reference pointers in compact value objects (primitive classes)<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto">Thanks Remí!<div dir="auto">One more question: can a value class with default constructor (inlined in heap and arrays) declare a nullable reference field? I don't think we've talked about this detail anywhere before.</div></div></blockquote><div><br></div><div>yes, a value class (with a default constructor or without) can have fields that are a String or any other nullable type, not only primitives.<br></div><div>The GC have been enhanced to correctly deal with them.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="auto"><div dir="auto">Curious,</div><div dir="auto">Chen</div></div></blockquote><div><br></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 25, 2023, 9:46 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "-" <<a href="mailto:liangchenblue@gmail.com" target="_blank" rel="noreferrer">liangchenblue@gmail.com</a>><br>
> To: <a href="mailto:valhalla-dev@openjdk.org" target="_blank" rel="noreferrer">valhalla-dev@openjdk.org</a><br>
> Sent: Tuesday, April 25, 2023 3:38:20 PM<br>
> Subject: Reference pointers in compact value objects (primitive classes)<br>
<br>
> Hello,<br>
> I just wonder if nullable reference pointers can be part of compact<br>
> value objects.<br>
<br>
It depends if it's on the stack or on the heap.<br>
On stack, a nullable reference to a value class if fully scalarized.<br>
On heap, a nullable reference is not flattened, non null reference of value class with a default instance are flattened.<br>
<br>
On stack, declaring a class as a value class is enough<br>
value record Point (int x, int y) {}<br>
<br>
On heap, the value class also need a default constructor<br>
value record Point (int x, int y) {<br>
default Point(); // the default value is not null but Point(0,0)<br>
} <br>
<br>
and when used, a field has to declare that the field is not nullable using '!'<br>
record Rectangle(Point! topLeft, Point! bottonRight) { }<br>
<br>
<br>
> <br>
> For instance, in the Classfile API, there is StackMapGenerator.Type, a<br>
> record with (int type, ClassDesc reference, int bci). The default<br>
> state (0, null, 0) is valid and a desirable default (0 type means<br>
> top-type). If the ClassDesc field can be part of the compact<br>
> representation, then the whole structure can be optimized, which looks<br>
> promising to me.<br>
<br>
Most values of the ClassFile API are values on stack so they should be scalarized.<br>
Note that, this is not yet true, currently a switch on a sealed interface forces the rematerialization.<br>
<br>
> <br>
> Meanwhile, I have another question about nullable object<br>
> representation in value classes: Suppose we have<br>
> Optional<Optional<Optional<String>>>, what will the representation be?<br>
> How will we distinguish Optional.empty() with<br>
> Optional.of(Optional.empty())?<br>
<br>
Let suppose that Optional is declared with a default instance like this<br>
value class Optional<T> {<br>
private final T value;<br>
<br>
default Optional();<br>
...<br>
}<br>
<br>
Then you need a '!' to ask for flattening, so Optional<Optional!<String>><br>
<br>
Now to answer to your question, the VM tracks the class (here Optional is specialized class), so even if the memory layout is the same between Optional<String> and Optional<Optional!<String>>, the specialized classes (sometimes also called the species) at runtime are not the same.<br>
<br>
> <br>
> Thanks,<br>
> Chen Liang<br>
<br>
regards,<br>
Rémi<br>
</blockquote></div><br></blockquote></div></div></body></html>