Value array flattening in L-world

[forax at univ-mlv.fr]

Playing with the MVT, i've develop a bytecode rewriter [1] that takes bytecode with L and insert Q if the class is tagged with the annotation @ValueCapableClass,
so basically it's like writing the code in the R-world and having the bytecode rewritten to making it live in the MVT world. 

One thing that surprise me first, is that it was hard to write the same code that work in the R-word and in the MVT world,
the main offender is the behavior of array that are initialized with null in the R-world and a default value in the MVT world,
i believe that if we want to support that a R-class can be changed to a Q-class, we have to have null to default value conversion in both direction when loading/storing array element.

The other solution i can see is to dynamically tranform an array of value type to an array of reference type when null is stored in it, a kind of buffering of the whole array by buffering all elements in it.

Rémi

[1] https://github.com/forax/valuetypify

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>, "David Simms" <david.simms at oracle.com>
> Envoyé: Vendredi 23 Février 2018 02:35:31
> Objet: Re: Value array flattening in L-world

> On Feb 22, 2018, at 9:29 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> One solution is to consider that doesn't mean literally null like Object doesn't
>> mean ref anymore.
>> 
>> In that case, null means default value and remove() and isEmpty() works.
>> 
>> If we go with this semantics, we may also have to revisit the semantics of
>> putfield with null.
> 
> This is the semantics given by MethodHandles.explicitCastArguments,
> when (say) an Object reference that is null must be cast to (say) an int.
> It is useful sometimes, but mapping nulls to other default values is a
> long slippery slope that I'm afraid of.  It feels safer to take our NPEs
> and treat them as bugs, rather than paper over them by substituting
> other values.  Also, code which throws on corner cases can be more
> easily optimized than code which does ad hoc value fixups.