Draft JVMS changes for Nestmates

[David Holmes]

Hi John,

Aside: my replies to the experts list are held up for moderation.

On 19/04/2017 4:45 PM, John Rose wrote:
> On Apr 18, 2017, at 1:49 PM, Dan Smith <daniel.smith at oracle.com
> <mailto:daniel.smith at oracle.com>> wrote:
>>
>>
>>> On Apr 18, 2017, at 2:12 PM, Remi Forax <forax at univ-mlv.fr
>>> <mailto:forax at univ-mlv.fr>> wrote:
>>>
>>>>> Verification of MemberOfNest
>>>>>
>>>>> I include a discussion block about different options of validating
>>>>> MemberOfNest.
>>>>> I think the consensus, and my preference, is to do it during
>>>>> verification of
>>>>> the member class. (NestMembers, on the other hand, is never
>>>>> validated, except
>>>>> as a side-effect of checking MemberOfNest.)
>>>
>>> It means that a NestMembers can contains Class that are not yet/never
>>> defined.
>>> It's not a problem for me.
>>
>> Yep. Also, multiple classes can claim the same nest member class in
>> their NestMembers attributes. Not a problem as long as the
>> MemberOfNest attribute (if any) of the member class points to a host
>> class that claims it.
>
> We need to specify more structural constraints on the new attributes.
> If we make them more strongly normalizing, there will be fewer chances
> for semantic bugs on unexpected inputs.  Also, making them structural
> constraints means we check them early, during class file loading.
>
> These are good, I think:
>
>  - NMs must be non-empty (degenerate nest is never explicit)
>  - NMs may not contain duplicates (cf. treatment of ClassFile.interfaces)
>  - NMs may not contain the current class (i.e., an index to a class with
> the same name as this_class)
>  - MoN may not contain the current class (ditto)
>  - MoN may contain only a package sibling (i.e., a referenced class name
> must have the same package prefix as this_class)
>  - NMs may contain only package siblings (ditto)
>  - NMs and MoN may not refer to array classes (this is probably implied
> by the package prefix checks)
>
> You already covered:
>  - a class may have exactly one or zero of NMs or MoN (no double dipping
> of any kind)
>  - NMs and MoN may only have CONSTANT_Class attributes (implies no
> nulls, well-formed names)
>
> David's prototype has the duplication check, and some of the other
> checks happen later.  I think they should all happen during class loading.

Some of these are a lot more awkward to do during classfile parsing and 
will require symbol comparisons. I was wanting to avoid "deep 
validation" of NMs as it penalizes all the good code. Having a "bad" NM 
entry seems harmless as these entries are only used to validate the 
initial claim of nest membership. If an entry is "bad" then by 
definition it will not match with any claimee.

David
-----

> — John