Updated JEP: nestmates

[David Holmes]

On 14/04/2017 2:25 AM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>, "Brian Goetz" <brian.goetz at oracle.com>, "John Rose" <john.r.rose at oracle.com>
>> Cc: valhalla-dev at openjdk.java.net
>> Envoyé: Jeudi 13 Avril 2017 13:59:17
>> Objet: Re: Updated JEP: nestmates
>
>> On 13/04/2017 8:37 PM, Remi Forax wrote:
>>> Re-reading the spec again,
>>> i think it would be clearer if you introduce T the nest-top, and modifying the
>>> classloading order has to be listed in the "Risks and Assumptions" section.
>>>
>>> Description:
>>>   "The Java compiler compiles a group of nested types into a corresponding group
>>>   of class files; it uses the InnerClasses and EnclosingMethod attributes to
>>>   reify the nesting relationship (JVMS 4.7.6 and 4.7.7)."
>>>   We can not re-use these attributes to describe nesting relationship because
>>>   being part of a nest has to be verified, triggering classloading of the
>>>   nest-top, thus changing the semantics of the existing attributes.
>>>   ...
>>>
>>>   "For types C and D to be nestmates they must either have the same nest-top T. A
>>>   type C claims to be a member of the nest of D, if both C and D list T in their
>>>   MemberOfNest attribute. The membership is validated during class loading if T
>>>   also lists C and D in its NestMembers attribute. This may require loading of
>>>   nest-top types earlier than might otherwise occur."
>>
>> That paragraph in the JEP got modified slightly from my original. There
>> was no intent at that point to introduce a third type. My original is:
>>
>> "For types <i>C</i> and <i>D</i> to be nestmates they must either have
>> the same nest-top, or else one must be the nest-top of the other.
>
> ok, agree with this one, even if the second part of this sentence is not necessary.

The second part most certainly is necessary as a nest-top does not 
itself have a nest-top!

>> A type <i>C</i> claims to be a member of the nest of <i>D</i>, if it
>> lists <i>D</i> in it's `MemberOfNest` attribute.
>
> while i understand this sentence, i'm not sure everybody will be able to parse it,
> apart from the 'it's' -> its, "member of the nest of D" is ambiguous, at least for me, it can be read as "member of the same nest as D" or as "member of the nest named D".
> Perhaps removing the "of" is enough.
>   A type <i>C</i> claims to be a member of the nest <i>D</i>, if it lists <i>D</i> in it's `MemberOfNest` attribute.

D is not a nest! D is a type that may be in a nest. "nest of D" is 
perfectly correct. We could rephrase to "of the same nest as D".

>> The membership is validated
>> during class loading if <i>D</i> also lists <i>C</i> in its
>> `NestMembers` attribute. This may require loading of nest-top types
>> earlier than might otherwise occur."
>>
>> Also note that "loading" is being used to allow some flexibility. What I
>> currently do is validate during class linking, prior to verification (if
>> enabled). But specifying it to happen at that exact point may be too
>> constraining.
>
> yes agree about what "loading" means here,
> in term of implementation, i think it should be validated the first time you need the nestmate relationship, it will be less disruptive (see below)

Note that may be during verification of another class. Any way the 
details here can be further explored. I don't think lazier than 
link-time buys you anything when you may need it earlier anyway.

>>
>>>   A type classfile has zero or one MemberOfNest attribute and zero or one
>>>   NestMembers. So a type can only be part of zero or one nest.
>>
>> But it can not have both a MemberOfNest and a NestMembers attribute.
>
> The fact that you can not have a MemberOfNest attribute if you have a NestMembers attribute is an optimization, if you have a NestMembers attribute, you are a nest-top thus you do not need a MemberOfNest on yourself.
> It's mandatory by the spec, but i think it should also be explained.

It is not an optimization! You are either a nest-top (and so have a 
NestMembers attribute) or you are a nested type and so have a 
MemberOfNest attribute. (Of course you can be neither.)

>>
>>> Risks and Assumptions
>>>   This proposal modifies the classloading order because a nest-top of a type needs
>>>   to be loaded either eagerly when a member of a nest is loaded or more lazily
>>>   when a member of a nest try to access to another member of a nest.
>>
>> The interesting case is where the nest-top class never actually gets
>> used in the execution of the application, and so presently is not
>> loaded. I've encountered several tests that fail because they are now
>> forced to load the nest-top class but can't locate it due to the way the
>> test has arranged classes on boot/classpath or via classloaders. In
>> those cases it makes no difference how eagerly or lazily you load the
>> nest-top class.
>
> Yes and No.
> Currently in Java 9 a code that's work do not requires any access check that requires to check if a class is a nest mate of another class.
> So if lazy means validating the nest-top/nest-members relationship only the first time you need to check a nest-mate access, every Java 9 applications should not load nest-top classes.
> (obviously, here i do not consider Java 9 tests that check that an access check exception is raised, those will load more classes).

In Java 9 there is never a nestmate-access-check because of the 
accessors that are generated. So I'm not sure what you are trying to 
say. My point was that there are cases where the application logic never 
requires the nest-top to be loaded today, but with nest-mates it would 
be loaded. In that context it makes no difference whether the class is 
lazily or eagerly loaded, given it was previously never loaded at all.

>>
>>>   This is not a problem for an inner-class because it also has a reference to the
>>>   enclosing class, so the nest-top class is already loaded, for non inner class
>>>   (static enclosed class), it will depend on the java compiler implementation,
>>>   i.e. if the compiler eagerly add nestmates that mirror the InnerClasses
>>>   attribute even if the enclosed class/interface do not access to a nestmate
>>>   member or if the compiler add nestmates to the nest only when necessary (like
>>>   currently it only generates bridges when necessary).
>>
>> Yes a compiler could elide the nest attributes if being nestmates is not
>> relied upon by the code. But to the VM they would not be nestmates so
>> any dynamic lookup that required nestmate access would fail.
>
> yes, i've forgotten the reflection.
> So the Java compiler can not be smart, so the VM has to be smart.
> The validation of the nest-top/nest members relationship has to be as late as possible to avoid loading classes that will break "compatibility".

Not sure what you mean here with "compatability".

Cheers,
David

>>
>> Cheers,
>> David
>
> Rémi
>
>>
>>> cheers,
>>> Rémi
>>>
>>> ----- Mail original -----
>>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>>> À: valhalla-dev at openjdk.java.net
>>>> Envoyé: Mercredi 12 Avril 2017 23:28:17
>>>> Objet: Updated JEP: nestmates
>>>
>>>> The "Nestmates" JEP has been updated:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-8046171