----- Mail original -----
> De: "Daniel Heidinga" <daniel_heidi...@ca.ibm.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Jeudi 2 Août 2018 17:12:45
> Objet: Re: value based class vs nullable value type
>>Hi all,
>>just to write my current state of thinking somewhere,
>>
>>I see 3 ways to implement value based class which all have their pros
>>and cons
>
> Thanks for writing this up, Remi. I've responded with some initial
> questions (and concerns). Hopefully we'll get a chance to discuss
> further in person while many of us are here at jvmls / ocw.
>
>>
>>- the value based class bit,
>> a value based class is tagged with ACC_VALUE_BASED, which means
>>that they have no identity. It's not a value class so instances of a
>>value based class are not flattened for fields and arrays but the JIT
>>can flattened them and re-materialize them.
>
> This sounds similar to the heisenbox proposals where identity was accidental
> and could come and go, correct? Or are all identity-ful operations
> (acmp, synchronization, etc) on these tagged classes rejected?
yes, correct.
>
> If this is the same as the heisenbox proposal, then the previous concerns
> about the about the user model when identity can come and go still apply.
The value based class semantics is currently defined by the javadoc [1] which
contains this sentence
"are freely substitutable when equal, meaning that interchanging any two
instances x and y that are equal according to equals() in any computation or
method invocation should produce no visible change in behavior". The heisenbox
semantics is a technically a subset of the described semantics because a value
based class doesn't allow to use any identity based operation, ==,
synchronized() etc while the heisenbox semantics allow such operation but
provides dubious result.
In my opinion, javac should enforce the stricter value based class semantics
while the VM should only implement the heisenbox semantics.
I agree that the semantics may be weird if seen in isolation but we are
introducing the value type semantics at the same time.
As Mr Simms said, actually we are removing properties if you compare to a
reference type, so the value type semantics or the value based class emantics,
so users will need to cope with that.
Also note that a VM is free to not implement the heisenbox model and consider
all value based class as reference because the plain old class semantics is a
valid mapping to the value based class semantics as we have actually.
>>
>>- the interface trick,
>> a nullable value type is like an interface that contains a value
>>class. The idea is to change the semantics of invokevirtual to be
>>able to call methods of an interface.
>
> Would this apply to all interfaces?
yes, i think we need a marker (a flag) in the interface because javac need to
know if it's a value based class or not but the VM doesn't need to enforce
that.
> Would invokevirtual now need to do both virtual and interface style invokes
> for all types of classes?
you mean all type of interfaces ? yes !
>
> From a VM perspective, I'm not a fan of merging the semantics of
> invokevirtual and invokeinterface. These kinds of merges usually
> come with a performance cost which is especially evident at startup.
yes and no.
the separation between invokevirtual and invokeinterface (and their
corresponding constant pool constant) is a kind of premature optimization,
we have already invokeinterface that can act as invokevirtual, so in my
opinion, it's more like aligning the two semantics than overloading the meaning
of invokevirtual for no good reason.
BTW, we have already agree on that :)
by only providing Lookup.findVirtual to map either invokevirtual or
invokeinterface, a method handle semantics is the semantics of the equivalent
bytecode, here, we should align the semantics of invokevirtual to the semantics
of findVirtual.
And yes, it means that there is a small cost at startup time.
>
>> This way we can swap the
>>implementation of the value based classes to use interfaces instead.
>>Like the previous proposal it means that because it's an interface
>>there is no flattening for fields and array but the JIT is able to
>>remove allocation on stack because the interface implementation is a
>>value type.
>
> Others could implement the same interface as well so there would either
> need to be two paths or a fallback option when a non-valuetype receiver
> was passed.
You may need a CHA to know if the interface has more that one implementation or
not, note that here having the interface marked with a bit saying
ACC_VALUE_BASED (here the name is wrong!) helps to make the difference between
a classical interface and a retrofitted one.
On the plus side, it muddies the question of using an interface or a class when
designing a library because you can move from one to another and still be
binary compatible, this is by itself a huge win.
>
> I'm hesitant about this approach given the extra costs it puts on
> invokevirtual.
even for completeness ?
>
>>
>>- nullable value type,
>> as decribed before on this list, the developer that create a value
>>based class indicate a field which if is zero encodes null. A
>>nullable value type is flattened for fields and arrays. The main
>>drawback of this approach is that non nullable value type pay the
>>cost of the possibility to having nullable value type on operation
>>like acmp. This model is also far more complex to implement because
>>it introduce another kind of world, the N-world.
>
> Modifying the descriptors comes at a high cost in terms of determining
> overriding, bridges, vtable packing, etc as discovered by the Q world
> prototypes.
yes,
i was thinking of something like adding a boolean in the ValueTypes attribute,
anyway, it comes it still have a great cost.
>
>>
>>To summarize, the first two proposals allow a value based class to be
>>null with the cost of not having their values being flattened if not
>>on stack the last proposal allow value based class to be fully
>>flattened with the cost of making the VM more complex and slowing
>>Object operations because it introduce a new world.
>>
>>Given that we want to support value based class only for retrofitting
>>purpose, my money is on 2 actually :)
>>
>>Rémi
Rémi
[1]
https://docs.oracle.com/javase/10/docs/api/java/lang/doc-files/ValueBased.html
