Updated JEP: nestmates
david.holmes at oracle.com
Fri Apr 14 03:16:48 UTC 2017
On 14/04/2017 8:12 AM, Brian Goetz wrote:
> I was trying to make the model simpler to reason about. My mathematical
> model is that nests form a partition over classes, meaning:
> - every class belongs to a nest
> - no two nests have any members in common
> - every nest has a canonical member
> We can't rely on javac (or other compilers) to always generate "nest of
> one" attributes, so the VM would have to, on seeing a class with no nest
> attributes, set "nestTop = me". But I think that would be the only
> change in the implementation? And then nestTop(C) becomes a total
> function, which simplifies things.
The implementation already sets nestTop='me'. But it never expects to
see a MemberOfNest attribute already set to 'me'. It complicates things
if the specification both allows no nestmate attributes and allows
MemberOfNest='me' (at parsing time there is not yet a 'me' so this would
based on the name in the constant pool.)
> I'm fine if the spec says this; in fact, I like it.
> On 4/13/2017 5:57 PM, David Holmes wrote:
>> On 14/04/2017 7:50 AM, Brian Goetz wrote:
>>>> The second part most certainly is necessary as a nest-top does not
>>>> itself have a nest-top!
>>> I would think we'd consider a nest-top as its own nest-top. That way,
>>> every nest has a top, which acts as a canonical element for that nest.
>> From an implementation perspective certainly that simplifies
>> nest-membership checks. but do you want that in the spec? Do you want
>> javac to generate a self-referential MemberOfNest attribute? If you
>> want this then the definitions need a rewrite. This is not where we
>> are today.
>>>> 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.)
>>> Similarly, I'd think that every class that has neither a NestMembers or
>>> MemberOfNest attribute constitutes a nest of one.
>> Sure logically you can consider it that way. Not sure it has any real
>> affect on anything.
>>> Taken together, now:
>>> - Every class belongs to exactly one nest;
>>> - Every nest has a canonical, consistent nest-top (every member of the
>>> nest agrees on the nest top)
>>> This will become relevant when we extend this to support
>>> Lookup.defineClass with a private lookup, which has the effect of
>>> injecting a new class into an existing nest. If every class is already
>>> in a nest, this injection is simplified.
>> I don't really see how it makes a difference, but you presumably have
>> something in mind here.
More information about the valhalla-dev