Valhalla EG notes April 10, 2019
forax at univ-mlv.fr
Thu Apr 18 22:33:32 UTC 2019
----- 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
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
More information about the valhalla-spec-observers