Reference pointers in compact value objects (primitive classes)

[forax at univ-mlv.fr]

> From: "-" <liangchenblue at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.org>
> Sent: Tuesday, April 25, 2023 5:10:06 PM
> Subject: Re: Reference pointers in compact value objects (primitive classes)

> Thanks Remí!
> 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.

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. 
The GC have been enhanced to correctly deal with them. 

> Curious,
> Chen

Rémi 

> On Tue, Apr 25, 2023, 9:46 AM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> ----- Original Message -----
>> > From: "-" < [ mailto:liangchenblue at gmail.com | liangchenblue at gmail.com ] >
>> > To: [ mailto:valhalla-dev at openjdk.org | valhalla-dev at openjdk.org ]
>> > Sent: Tuesday, April 25, 2023 3:38:20 PM
>> > Subject: Reference pointers in compact value objects (primitive classes)

>> > Hello,
>> > I just wonder if nullable reference pointers can be part of compact
>> > value objects.

>> It depends if it's on the stack or on the heap.
>> On stack, a nullable reference to a value class if fully scalarized.
>> On heap, a nullable reference is not flattened, non null reference of value
>> class with a default instance are flattened.

>> On stack, declaring a class as a value class is enough
>> value record Point (int x, int y) {}

>> On heap, the value class also need a default constructor
>> value record Point (int x, int y) {
>> default Point(); // the default value is not null but Point(0,0)
>> }

>> and when used, a field has to declare that the field is not nullable using '!'
>> record Rectangle(Point! topLeft, Point! bottonRight) { }


>> > For instance, in the Classfile API, there is StackMapGenerator.Type, a
>> > record with (int type, ClassDesc reference, int bci). The default
>> > state (0, null, 0) is valid and a desirable default (0 type means
>> > top-type). If the ClassDesc field can be part of the compact
>> > representation, then the whole structure can be optimized, which looks
>> > promising to me.

>> Most values of the ClassFile API are values on stack so they should be
>> scalarized.
>> Note that, this is not yet true, currently a switch on a sealed interface forces
>> the rematerialization.


>> > Meanwhile, I have another question about nullable object
>> > representation in value classes: Suppose we have
>> > Optional<Optional<Optional<String>>>, what will the representation be?
>> > How will we distinguish Optional.empty() with
>> > Optional.of(Optional.empty())?

>> Let suppose that Optional is declared with a default instance like this
>> value class Optional<T> {
>> private final T value;

>> default Optional();
>> ...
>> }

>> Then you need a '!' to ask for flattening, so Optional<Optional!<String>>

>> 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.


>> > Thanks,
>> > Chen Liang

>> regards,
>> Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230425/ed541858/attachment.htm>