Updated JEP: nestmates

[David Holmes]

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. 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. 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.

>   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.

> 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.

>   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.

Cheers,
David

> 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