----- Mail original ----- > De: "John Rose" <[email protected]> > À: "Brian Goetz" <[email protected]> > Cc: "valhalla-spec-experts" <[email protected]> > 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 <[email protected]> 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
