Civilizer - let's civilize those primitive types !

[Brian Goetz]

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.


On Jan 11, 2023, at 12:29 PM, Anderson Vasconcelos Pires <andvasp at gmail.com<mailto: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?

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.

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

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. Value class is a reference type that does not have identity. So it means that it can be allocated in the heap, right? So allocating it in the heap will have a memory location, do not?
regards,
Rémi


Thanks for the explanation!

Regards,
Anderson.

On Tue, Jan 10, 2023 at 7:39 PM Remi Forax <forax at univ-mlv.fr<mailto:forax at univ-mlv.fr>> wrote:
Hi all,
i've developed a small prototype of what the semantics for the next round could be
  https://github.com/forax/civilizer/

The prototype works with the latest valhalla early access build
  https://jdk.java.net/valhalla/

Basically, everything is an object, using @Value in front of a class or a record transforms it to a value class, a class with no identity
(== compares the fields, synchronized throws an IllegalMonitorStateException, new WeakRef<>(...) throws an IdentityException).
Adding @ZeroDefault means that the default value of the value class which is not null is all fields filled with zero.

@NonNull allows to declare a non-null type (there is also @Nullable which is the default if there is no null aware annotation).
For parameters, like Kotlin, sending null to a parameter of a method annotated with @NonNull throws a NPE.
For a field a zero-default annotated with @NonNull ask for flattening, trying to store null also throws a NPE.
For a field which is not a zero-default, even if declared @NonNull, the runtime will *not* throw a NPE because the field is null before reaching its initialization assignment in the constructor (and a constructor can call any methods).

From the VM POV, a Q-type never appears inside a method descriptor. It appears inside field descriptor but putfield, getfield and withfield allows a field declared as a Q-type to be accessed as a L-type (this is currently simulated for getfield and putfield with an invokedynamic). This is very similar to the way the VM deals with arrays. And the VM knows if a parameter is a Q-type or not despite the fact that only L-type appears in the method descriptor because the Q-type are declared in the Preload table of the class.

It means that if a class/record is not accessed directly by a constructor but by some static factories (like Optional) then moving in between an identity type, a value type (with zero-default or not) are backward compatible changes.

regards,
Rémi


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