More on seeing the L world as a U world

[Remi Forax]

Operations:
as in Dan's proposal (lets call it that way), checkcast, putfield, monitorenter/monitorexit, ic_acmpeq, if_acmpne, aload, astore, areturn, anewarray, multianewarray, aaload and aastore have their semantics enhanced.

unlike the Dan proposal, newly introduced opcodes, adefault and withfield have their semantics defined on value type and also on reference type, adefault throws an exception on a reference value (to not allow to bypass the constructors) and withfield works the same way for value type and reference type.

note that isValue is not necessary because it's getClass() + isValueType().

Primitive types:
primitive types are seen by the VM as value types, int.class.isValueType() returns true.
there is no need to see those class in the JDK, so like currently there are synthetize by the VM. So storing an int as an Object is equivalent to box/buffer the int like any value type. 

Performance:
If we have U types everywhere, doesn't it introduce perf issues, by example, what about acmp now having to test if it operates on value types or reference types.

There are two facts that save us here, with acmp as example,
- first for one execution, a type is either a value type or a reference type, so it enables the kind of optimization we do with quick opcodes, i.e. the slow path is if you do not know if the type is a reference type or a value type, but once you have do the test for a type, you can install a fast path for all acmp on the same type.
- if the cost is too important we can have say that acmp will always do a pointer check (here we are saved by the fact that in hotspot a value type is also a machine word pointer) and introduces a new opcode, ucmp that have a bigger overhead. The semantics of acmp on value type in that case is garbage, but not less garbage that the current boxing semantics specified by the JLS. 

So in my opinion, we are no in a better position in term of performance compared to Dan's proposal but we are not in a worst position too. I think the weakest point of the Dan's proposal is that the model is really complex, which means that it will impose a real burden when we will want to maintain or tweak it again in the future.

The model i propose is far simpler.

Rémi

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: "daniel smith" <daniel.smith at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 22 Novembre 2017 10:42:36
> Objet: Re: Design notes for next values iteration

> Interesting !
> here is my current view of the problem.
> 
> Lets say we are in the R/Q/U world, we want U interface to abstract over a
> reference type or a value type, we want UObject because object is basically an
> interface, we also want U object like UOptional to be able to painlessly move a
> reference type to a value type and vice-versa (no bridge-o-matic).
> 
> But why we want Q type BTW, we want Q type because
>  1/ you can not apply the same opcodes on Q types and R types (more or less, some
>  ops are not defined on Q types)
>  2/ we want the VM to flatten array and not box Q type.
>  3/ the VM need a clean separation between Q type and R type
> 
> For 1/ we can extends the semantics of the opcodes that only works on R types to
> work on Q types, we need that anyway for U types and at worst a valid semantics
> is to throw an exception
> For 2/ even if we sak for flatten array or no box, there are case where the VM
> will not flatten the array or the q type, so it's like a hint than a strict
> requirement.
> For 3/ the current prototype has shown that the VM is able to box/buffer value
> types where needed, so no !
> 
> I think we do not need Q types, Q types are use site annotations, and here we
> want declaration site annotations (let say that this class is a value class,
> the ACC_VALUE).
> 
> If we have no Q type, it means that R types and U types are the same thing,
> everything is a U type. In term of migration, it means that L types need to
> have their semantics extended to work as U types.
> 
> Obviously, the devil is in the details, but i think from the VM POV, we should
> extends L types to behave like U types.
> From Java the language POV, we may want to not compile when a variable is typed
> with value type is assigned to null, same with generics, you may want to
> declare a type variable any but from the VM POV, this should be possible and
> either throw an exception, return false, etc.
> 
> Let's make the VM powerful and let's Java the language helps users to not have
> too many exceptions.
>     
> regards,
> Rémi
> 
> ----- Mail original -----
>> De: "daniel smith" <daniel.smith at oracle.com>
>> À: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
>> Envoyé: Mercredi 22 Novembre 2017 06:54:55
>> Objet: Design notes for next values iteration
> 
>> Following up on John's mail, here are some detailed notes about the design
>> choices for "U types", and the concrete proposal we settled on last week.
>> 
>> http://cr.openjdk.java.net/~dlsmith/values-notes.html
>> 
>> John may have raised additional points I didn't cover in this document. I'll do
>> another review of his mail and make any needed updates; or feel free to call
>> them out. :-)
>> 
> > —Dan