----- Mail original ----- > De: "John Rose" <[email protected]> > À: "Remi Forax" <[email protected]> > Cc: "Brian Goetz" <[email protected]>, "valhalla-spec-experts" > <[email protected]> > 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 <[email protected]> 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). Rémi
