Valhalla EG notes April 10, 2019

[Remi Forax]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 18 Avril 2019 23:43:55
> Objet: Re: Valhalla EG notes April 10, 2019

> On Apr 11, 2019, at 1:44 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> To me, getting fancy here sounds like borrowing trouble; it seems much simpler
>> -- and perfectly reasonable -- to reject cycles at both compile and runtime,
>> and let users use `V?` in the place they want to break their cycles.  (Assuming
>> we're comfortable with `V?` means not flattened, which is the choice we're also
>> making for specialization.)
> 
> For the record, I share Brian's take here.

so am i.

> 
> Also, FTR, I'm comfortable saying V? means not flattened.
> 
> I'll go further than that:  I'd be *uncomfortable* if the
> meaning of V? diverged (unnecessarily) from the meaning
> of mentioning an equivalent non-inline class V2.  That
> means V?, if translated to a descriptor, should translate
> to a simple legacy-style L-descriptor.
> 
> IOW, I think V? is most useful if it means "behaves exactly
> like a legacy variable", which means not only "nullable"
> but also "not eagerly loaded".  At the VM level, V? should
> be the way to avoid bridging to old L-descriptors (without
> any "L*" decoration).
> 
> IOW again, the contract of V?, at least at the JVM level, should
> be exactly fulfillable by the L-V descriptor (without any extra
> signal).

I mostly agree,
V? should be not eagerly resolved, not flattenable in fields and arrays but
- 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.

> 
> — John

Rémi