Valhalla EG notes April 10, 2019

[forax at univ-mlv.fr]

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 19 Avril 2019 02:42:45
> Objet: Re: Valhalla EG notes April 10, 2019

> On Apr 18, 2019, at 5:09 PM, forax at univ-mlv.fr wrote:
>> 
>> I'm not sure we need a 'G' because NV is a property of the container too.
> 
> The flattened layout is not a visible property of the container,
> if the container is typed using the legacy L-descxriptor.
> If the container is flattened, you need an extra signal ("L*-NV"
> not "L-NV").  (It took us four days last month to realize
> this and to discard a long list of workarounds.)
> 
> The L*-NV descriptor (perhaps a descriptor augmented by a
> load-it-now side channel that carries the starts) gives the JVM
> permission to do the following extra steps.
> 
> 1. Load NV.class when it lays out the container (of type L*-NV).
> 1a. Execute any class loader side effects due to that loading.
> 2. Throw a class circularity error if loading NV.class needs to lay out the
> container recursively.
> 
> We generally agree to disregard effects in 1a.  But the effect of
> 2 is a real departure from the standard contract of L-descriptors,
> and it needs a new contract.
> 
> You could separate the "*" from "L*-NV" and instead put all
> the stars into a PreloadClasses attribute, as we once discussed.
> This is (a) too fragile to ensure robust flattening, and (b) not
> fine-grained enough, since some occurrences of "L*-NV"
> need the star, and others need to *omit* the star.
> 
> This is why we are moving towards keeping the star in the
> descriptor, in effect.  Physically, "L*" should be spelled with
> a single letter, of course; the working title was "Q" but is
> now "G" (meaning "go and look", since it applies to both
> inlines and templates).


I don't see an usage for 'G', '?' is for supporting codes that contains existing references to L.

Introducing NV, we have to take care about existing 'L' aka NV?, it seems that no support is possible, so the VM should throw an IncompatibleClassChange.
And as a user either there is an existing 'L' and you can use V? to be "backward compatible" or there is no existing refs to L and you can use V or NV.

Rémi