Civilizer - let's civilize those primitive types !

[Red IO]

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).
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. The big benefit of having no identity and therefore
being immutable is that the object can be copied without any analysis of
multiple references. 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.

Great regards
RedIODev

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

>
>
> ------------------------------
>
> *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 <
> 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
>>
>
> 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/42ea814b/attachment.htm>