Valhalla EG notes April 10, 2019

[John Rose]

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