Valhalla EG notes April 10, 2019

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 19 Avril 2019 01:30:44
> Objet: Re: Valhalla EG notes April 10, 2019

> On Apr 18, 2019, at 3:33 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> - it should be vectorized in registers if on stack, i.e. V? should still be a
>> mark for the JIT that the value doesn't escape because it can always be
>> reconstructed when necessary.
>> - acmp, System.identityHashCode(), etc, have the same meaning as V if the value
>> is non null.
> 
> Yes, thanks for clarifying that.  The L-descriptor contracts
> are mainly about containers per se, and only secondarily
> about the objects referred to by those containers.
> 
> The treatment of acmp does not depend on the container
> but rather on the intrinsic properties of the object referred
> to by the reference stored in the container.
> 
> And the JIT can cheat all it wants, as long as it upholds
> the user-visible contracts.  That includes today's EA
> of today's "identity" objects, plus tomorrow's more robust
> scalarization of inline objects.
> 
> Bottom line:  When you see "V?" in the source code, you
> are looking at an L-descriptor in the class file, no matter
> what V is.  When you see a flattenable or scalarizable "V"
> in the source code, you are looking at something new,
> with new capabilities and new restrictions:  A new contract.
> 
> Even when we add in null-default types NV, NV? should still
> translate to an L-descriptor (no L*) with legacy semantics.
> 
> This may be a subtle contractual difference between NV? and
> NV, which we still need to talk through.  A field of type NV is
> flattenable and must not be circular.  A field of type NV?
> is not flattenable, as far as the user can see, and may be
> circular, if we take circularity as part of the inherent
> expressiveness of L-types.  That's the way I see it.
> 
> We can make 99% of the difference between NV and NV?
> disappear, starting with the observation that they have
> the same value sets.  But the last 1% will, I think, be
> tricky to suppress.  If we can make 100% of the
> semantic differences between NV and NV? disappear,
> then the distinct usage of legacy L-descriptors and
> new L*-descriptors (G-descriptors in a forthcoming
> document) will appear only as a distinction in translation
> strategy, which will uphold the unified semantic contract
> of NV and its alias NV?.

I'm not sure we need a 'G' because NV is a property of the container too.

NV is a value type + a null value check, i.e each time you call a method and NV has the encoding of the null value, a NPE is thrown.
NV? is a nullable value type + a null value check, i.e. each time you call a method and NV? is null or NV? has the encoding of the null value, a NPE is thrown.

Conceptually, a NV behave as if each instance method (resp field access) first checks if it's the encoding of null value before entering the method (before accessing the field).

Rémi