<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 dir="auto"><br></div><div dir="auto">Curious,</div><div dir="auto">Chen</div></div><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">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>