performance issue with nullable value type

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Tobias Hartmann" <tobias.hartmann at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoyé: Jeudi 10 Janvier 2019 02:38:00
> Objet: Re: performance issue with nullable value type

> On Jan 8, 2019, at 1:06 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
> wrote:

>> all boxes should have a scalarized representation for local variables
>> independently

> That's OK as long as the scalarized representation can go dead (in the IR)
> if it's not used. That way, in code where a value is just passed from point A
> to point B, there's no need to dereference it or check for null.

> Likewise, if a scalarized representation *is* used (because of field access),
> it's also desirable to keep around a "souvenir" of any known reference
> from which the scalarized representation was originally loaded, if it
> can be reloaded from there. That way, in code which looks at a field
> and then forwards the value unchanged to another place B, the code
> can use the "souvenir" if needed (if the other place B needs a reference).
> The "souvenir" might also be useful for reloading registers after a spill.

> All this points to the IR design where we keep *both* a base pointer
> (if available) *and* the field values (if needed) in a tuple, but we generate
> code only for the parts we need.

To represent a box, the base pointer should be a three state value, a pointer if there is a 'souvenir', 'UNKNOWN' because there is no souvenir and 'NULL' because the nullable value type is null. 
And access to the exploded field values should be guarded by a 'NULL' check. 

> — John

Rémi