value based class vs nullable value type

[Daniel Heidinga]

>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?

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 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? Would invokevirtual now need to do
both virtual and interface style invokes for all types of classes?

>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.

> 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.

I'm hesitant about this approach given the extra costs it puts on
invokevirtual. 

>
>- 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.

>
>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
>