Re: RSVP please: Re: Nestmates JVMS changes to selection and behavior implications

[Doug Lea]

On 01/15/2018 10:43 AM, Karen Kinnear wrote:
> EG members - could you possibly review this change and reply in an email?
> We believe this is the last step to finalizing the nestmates JVMS changes.

Seems OK to me. My only meta-thought is that nestmates might
now hold the record for the most subtle details that needed
addressing per unit of benefit to the platform...

-Doug

> 
> thanks,
> Karen
> 
> p.s. changes are relative
> to: http://cr.openjdk.java.net/~dlsmith/nestmates.html
> 
>> On Jan 10, 2018, at 9:34 AM, Karen Kinnear > > wrote:
>>
>> David Holmes and I are good with Dan’s proposal here.
>>
>> thanks,
>> Karen
>>
>>> On Jan 9, 2018, at 5:27 PM, Dan Smith >> > wrote:
>>>
 On Jan 3, 2018, at 9:16 AM, Karen Kinnear > wrote:

 In studying the details of these changes, there are three sets of
 changes that change the behavior of invokeinterface.

  1. Invokeinterface is allowed to resolve to a private member of the
 reference class, and the resolved method becomes the selected
 method. 
  2. The removal of the invokeinterface selection runtime access
 check, allows selection of a package-private or protected
 method, since they can override a public method from the
 resolution step.
  3. The combining of the invokeinterface selection and invokevirtual
 selection (and equivalent preparation modifications) add the
 concept of "overrides" to the invokeinterface selection lookup
 steps. Note that private methods never override and are never
 overridden. The consequence of this change is that the
 invokeinterface selection lookup will now SKIP private methods
 as invokevirtual does, where before it would find the private
 method and throw an IllegalAccessError.

 I am proposing that for nestmates we do not need the second change,
 and that we could continue to have invokeinterface and invokevirtual
 selection be aligned, while keeping the restriction that if the
 selection lookup procedure selects a method that is not public,
 invokeinterface throws an IllegalAccessError. (This would continue
 to allow resolution to a private member, select the same private
 member). This prevents adding additional cases in which the caller
 is able to invoke a method it can not directly access.

>>>
>>> This is a good change; see details below.
>>>
>>> Eventually, I would like to entirely get rid of this rule, but to do
>>> so we need a more comprehensive solution to JDK-8021581.
>>>
 For the 3rd change we have two ways to approach this. We can leave
 the existing invokeinterface selection/preparation alone, find
 private methods in the receiver and its superclasses, and throw an
 IllegalAccessError, or we can make the proposed changes and skip
 private methods as we do for invokevirtual (because of the term
 "overrides") and potentially find a public method that overrides the
 resolved method.


>>>
>>> I have not yet heard a concrete proposal to make changes here, and
>>> continue to think the best thing to do is merge the selection logic
>>> into one set of rules, as described in the nestmates spec document.
>>> (It is *possible* to achieve our goals through other means, but there
>>> are many pitfalls, and I haven't seen anyone arguing for a specific
>>> alternative. From where I sit, the current proposed approach seems best.)


   Run-time Exceptions

 Otherwise, if step 1 or step 2 of the lookup procedure selects a
 method that is not |public|, |invokeinterface| throws
 an |IllegalAccessError|.

 This is the line that we believe could be restored,
 slightly modified to apply to the selection lookup procedure steps
 in 5.4.5, so that the only non-public selected method would be a
 private method which is the referenced method as well as the
 selected method.

>>>
>>> Concretely, we would undo this deletion, and instead modify the rule
>>> as follows:
>>>
>>> "Otherwise, if step 1 or step 2 of the lookup procedure selects a
>>> method that is ~~not public~~ **neither public nor private**,
>>> invokeinterface throws an IllegalAccessError."
>>>
>>> The motivation here is that invokeinterface is uniquely able to i)
>>> resolve to a public interface method, and ii) select a
>>> protected/package method of a superclass that would otherwise be
>>> inaccessible to the caller. The fact that the referenced method is in
>>> an interface is important, because anyone with the ability to extend
>>> a class can also declare a fresh superinterface that includes any
>>> method names+descriptors they're interested in.
>>>
>>> —Dan
>>
> 

Re: Nestmates JVMS changes to selection and behavior implications

[Dan Smith]

> On Jan 3, 2018, at 9:16 AM, Karen Kinnear  wrote:
> 
> In studying the details of these changes, there are three sets of changes 
> that change the behavior of invokeinterface.
> Invokeinterface is allowed to resolve to a private member of the reference 
> class, and the resolved method becomes the selected method. 
> The removal of the invokeinterface selection runtime access check, allows 
> selection of a package-private or protected method, since they can override a 
> public method from the resolution step.
> The combining of the invokeinterface selection and invokevirtual selection 
> (and equivalent preparation modifications) add the concept of "overrides" to 
> the invokeinterface selection lookup steps. Note that private methods never 
> override and are never overridden. The consequence of this change is that the 
> invokeinterface selection lookup will now SKIP private methods as 
> invokevirtual does, where before it would find the private method and throw 
> an IllegalAccessError.
> I am proposing that for nestmates we do not need the second change, and that 
> we could continue to have invokeinterface and invokevirtual selection be 
> aligned, while keeping the restriction that if the selection lookup procedure 
> selects a method that is not public, invokeinterface throws an 
> IllegalAccessError. (This would continue to allow resolution to a private 
> member, select the same private member). This prevents adding additional 
> cases in which the caller is able to invoke a method it can not directly 
> access.

This is a good change; see details below.

Eventually, I would like to entirely get rid of this rule, but to do so we need 
a more comprehensive solution to JDK-8021581.

> For the 3rd change we have two ways to approach this. We can leave the 
> existing invokeinterface selection/preparation alone, find private methods in 
> the receiver and its superclasses, and throw an IllegalAccessError, or we can 
> make the proposed changes and skip private methods as we do for invokevirtual 
> (because of the term "overrides") and potentially find a public method that 
> overrides the resolved method.
> 

I have not yet heard a concrete proposal to make changes here, and continue to 
think the best thing to do is merge the selection logic into one set of rules, 
as described in the nestmates spec document. (It is *possible* to achieve our 
goals through other means, but there are many pitfalls, and I haven't seen 
anyone arguing for a specific alternative. From where I sit, the current 
proposed approach seems best.)
> Run-time Exceptions
> Otherwise, if step 1 or step 2 of the lookup procedure selects a method that 
> is not public, invokeinterface throws an IllegalAccessError.
> This is the line that we believe could be restored, slightly modified to 
> apply to the selection lookup procedure steps in 5.4.5, so that the only 
> non-public selected method would be a private method which is the referenced 
> method as well as the selected method.

Concretely, we would undo this deletion, and instead modify the rule as follows:

"Otherwise, if step 1 or step 2 of the lookup procedure selects a method that 
is ~~not public~~ **neither public nor private**, invokeinterface throws an 
IllegalAccessError."

The motivation here is that invokeinterface is uniquely able to i) resolve to a 
public interface method, and ii) select a protected/package method of a 
superclass that would otherwise be inaccessible to the caller. The fact that 
the referenced method is in an interface is important, because anyone with the 
ability to extend a class can also declare a fresh superinterface that includes 
any method names+descriptors they're interested in.

—Dan

Re: Nestmates JVMS changes to selection and behavior implications

[David Holmes]

For the benefit of those on the observer list Karen sent an attachment 
which has been stripped.


David

On 21/12/2017 1:45 AM, Karen Kinnear wrote:

David Holmes and I were studying the JVMS changes for nestmates - in particular 
the selection and preparation changes which
are designed to make invoke interface more like invoke virtual (JDK-8024806).

I wanted to ensure that the behavior changes were all either error -> success, or 
error 1 -> error 2.

As I went through this again, I had a couple more questions on the JVMS changes 
for selection preparation to sanity check.

thanks,
Karen

Nestmates JVMS changes to selection and behavior implications

[Karen Kinnear]

David Holmes and I were studying the JVMS changes for nestmates - in particular 
the selection and preparation changes which
are designed to make invoke interface more like invoke virtual (JDK-8024806).

I wanted to ensure that the behavior changes were all either error -> success, 
or error 1 -> error 2.

As I went through this again, I had a couple more questions on the JVMS changes 
for selection preparation to sanity check.

thanks,
Karen



Nestmates Invocation Changes - Java Platform Group - wiki.se.pdf
Description: Adobe PDF document