Updated JEP: nestmates

[David Holmes]

Hi Remi,

On 14/04/2017 8:14 PM, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> À: forax at univ-mlv.fr
>> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "John Rose" <john.r.rose at oracle.com>, valhalla-dev at openjdk.java.net
>> Envoyé: Vendredi 14 Avril 2017 05:24:49
>> Objet: Re: Updated JEP: nestmates
>
>> On 14/04/2017 8:21 AM, forax at univ-mlv.fr wrote:
>>> [...]
>>>
>>>>>> 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.
>>>>
>>>
>>> sorry, i was not clear enough here.
>>> Being lazier than linking time in my mind means doing the check at runtime the
>>> first time you access to the member.
>>> i.e. during link time (at any phase) you mark that you can not do the full
>>> access check but because you have a nest-top, and you delay a part of the
>>> access check at runtime.
>>>
>>> that is what i was thinking when i write 'the first time you need'.
>>
>> You can't do that if verification is involved. As it stands the use of
>> invokespecial to access a private nestmate method will not pass the
>> verifier. So we have to relax the rule in the verifier to allow for
>> nestmate access - which means we need to resolve (and validate) the
>> nest-top when verification occurs. Otherwise you've opened up a hole in
>> the verification process.
>>
>
> yes, there is a hole in the verification if you do not add a check at runtime.

Philosophically I have problems with very loose verification rules - 
their laxity seems to me to defeat the purpose of verification ("thou 
shalt not pass!"). In this case though we only get into the verifier due 
to the existing knot of rules around invokespecial that we need to 
circumvent.

> First, i'm not advocating that i should be implemented that way, i'm just saying that if you delay the class loading, you will have less spurious classloading from the user POV.
>
> When doing the verification of invokespecial:
>  - if the verification fail if you do not consider nestmate
>  - if invokespecial is a call to a class with an attribute MemberOfNest and the callsite class also an attribute MemberOfNest,
>    and both attributes have the same value
> then instead of loading the nest-top at that point, the verifier can mark that invokespecial and delay the loading of the nest-top to the first time the invokespecial is executed.

This seems quite reasonable - reduce from a strict "are nestmates" to 
"may possibly be nestmates" (or more strictly "are not definitely not 
nestmates).

Though I'm not certain exactly where the full check would have to be 
introduced.

Thanks,
David
-----

> This is very similar to what the VM currently does when checking a cast to an interface.
>
> And again, i may significantly reduce the number of nest-tops loaded or do not worth the trouble to implement that.
>
>> David
>>
>
> regards,
> Rémi
>