Civilizer - let's civilize those primitive types !

[forax at univ-mlv.fr]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Anderson Vasconcelos Pires" <andvasp at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Sent: Wednesday, January 11, 2023 6:35:01 PM
> Subject: Re: Civilizer - let's civilize those primitive types !

> I think you may be missing out on the goal here. This is not an exploration of
> the user model (value vs primitive class, val/ref/bang/etc), this is an
> exploration of the underlying translation / implementation scheme *that might
> inform* future evolution of the user model.
yes, 

>> On Jan 11, 2023, at 12:29 PM, Anderson Vasconcelos Pires < [
>> mailto:andvasp at gmail.com | andvasp at gmail.com ] > wrote:

>> Thanks for the prompt response!

>>>> Mostly prototyping a proposal to remove Q-types (descriptor that starts with
>>>> Q...;) and replace them by an attribute on methods and fields indicating if the
>>>> value can be null.

>>> see [
>>> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-January/002217.html
>>> |
>>> https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-January/002217.html
>>> ]

>> So if you want to remove Q types it means that L type does not need the identity
>> information, right?

Currently when you have a primitive class, you need to declare the class as a private class *and* you need to use a Q-type each time you mention that class (in a method descriptor, a field descriptor, in a checkcast, see JEP 401). 
The idea here is when you need to declare the class as a private class but instead of using a Q-type, you use a side attribute that indicates if null is a valid value or not. 

To answer your question, you do not need the identity information at use site, what you need to know is if it is a zero-default value class and if null is not a valid value. Previous both information where grouped together inside the Q-type, i'm proposing to keep them into two location and let the VM gathers those information together. 

>>> There is no notion of .val or .ref, if you want a field to be flattened, use a
>>> @Zero-Default and declare the field @NonNull.

>> Pretty good if we do not need to use .val or .ref!

>> Could the @NonNull be replaced by "!" but writing the attribute in the class
>> file?

>> I Like @NonNull but I believe the "!" would be more practical.

See Brian answer, 

>> As @Nullable is the default, maybe it would not be necessary to have it.

We will need a way to say that Map<String, @NonNull Foo>.get() return type is a nullable Foo, even if the V (in Map<K,V>) is a non-null Foo. 

>>>> yes, the prototype does not do any verification that the compiler does, i'm too
>>>> lazy for that but the VM will catch you and throw an Error

>> Pretty good for a prototype!

>>> About the mutability of fields, fundamentally, value type is about saying, i
>>> give up the notion of identity, if you have no identity, you have no location
>>> in memory (you can have more than one if you prefer) so the VM is free to pass
>>> by reference or pass by value. So you can not mutate a field, because you can
>>> only do that if you have one location in memory.

>> Ok for mutability but now I am a little bit confused about references, identity
>> and memory location.

You are not alone :) 

In Java, all classes have references / instances / objects. This does not change with the introduction of value class. 
Identity class have references which have an identity, so == will compare the address in memory. 
Value class have references which does not have an identity, so == will compare the content on the object. 

>> Value class is a reference type that does not have identity. So it means that it
>> can be allocated in the heap, right?

No, it means the opposite. Having an identity is equivalent to saying having an address in memory in the heap. 
So having no identity means that the VM is free to chose to allocate it in the heap, to not allocate it in the heap, or even to allocate it multiple time in the heap, because from the user POV all these objects can not be distinguished one from another, thus they are one. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230111/5a650693/attachment.htm>