Valhalla EG notes April 10, 2019
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Apr 19 00:09:57 UTC 2019
----- 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).
More information about the valhalla-spec-observers