Civilizer - let's civilize those primitive types !

[forax at univ-mlv.fr]

> From: "Red IO" <redio.development at gmail.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Anderson Vasconcelos Pires" <andvasp at gmail.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>, "Brian Goetz" <brian.goetz at oracle.com>
> Sent: Thursday, January 12, 2023 8:55:25 PM
> Subject: Re: Civilizer - let's civilize those primitive types !

> On your last point.
> Identity != memory location
> Identity only means that you can identify the object and all references point to
> the same location in memory (heap or stack).

Your definition of identity uses "identify" :) 

> Everything has a memory address period. Rather something lives on the stack or
> heap every byte of data has a memory address. The runtime is already free to
> keep a current standard reference type on the stack if it can confirm that it
> will a) benefit performance and or memory efficiency and b) a situation where a
> reference to this stack value outside its stackframe exist is impossible.

Not everything has a memory address. By example, Hotspot never allocates objects on stack but uses scalar replacement instead (this may be not true in the future), 
see [ https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacement/ | https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacement/ ] 

> The big benefit of having no identity and therefore being immutable is that the
> object can be copied without any analysis of multiple references.

yes 

> Since different references to the same object can actually point to different
> spots in memory. This might sound memory inefficient but remember, stack memory
> is cheap heap isn't. The idea is that objects without identity can be allocated
> on the stack most of the time and packed in objects since they don't need to
> track their references since copies of themselves are interchangeable and
> indistinguishable.
> Please correct me if I'm wrong with something I'm still learning.

see above. 

> Great regards
> RedIODev

regards, 
Rémi 

> On Wed, Jan 11, 2023, 23:03 < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
> wrote:

>>> From: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ]
>>> >
>>> To: "Anderson Vasconcelos Pires" < [ mailto:andvasp at gmail.com |
>>> andvasp at gmail.com ] >
>>> Cc: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >,
>>> "valhalla-dev" < [ mailto:valhalla-dev at openjdk.java.net |
>>> 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/20230112/9f55599e/attachment.htm>