Isolated Methods JEP

Peter Levart peter.levart at gmail.com
Sat Aug 13 07:42:16 UTC 2016


Hi Michael, John,


On 08/13/2016 12:46 AM, John Rose wrote:
>>> So there will be no class hosting this method? Not even the "caller" 
>>> class of the Lookup instance that loadCode was invoked upon? What 
>>> will be reported by Reflection.getCallerClass() invoked in a 
>>> @CallerSensitive method invoked from the isolated method?
>
> That last question is easy:  When you create a MH on a @CS method, via 
> the Lookup API, the caller is permanently bound to the caller class in 
> the Lookup object.  (If you are wondering about security, note that 
> you can't get a MH on a @CS method without a full-power Lookup 
> object.)  After that, it is irrelevant where and how the MH is 
> eventually invoked, including from an isolated method.


On 08/13/2016 12:46 AM, John Rose wrote:
>>> A can see now that defining an isolated method in the context of a 
>>> lookup class can only be allowed when the Lookup instance contains 
>>> ALL_MODES in the mode bits as such method would have access to any 
>>> members that a normal method defined in the lookup class has.
>>
>> Not sure. I think this suggestion implies something like class 
>> membership, when in fact the IM should have the access rights defined 
>> by the Lookup, without belonging to the lookupClass. I may be 
>> misunderstanding your point.
>
> Since access rights are permanently bound into the MH's stored in the 
> isolated constant pool, there should be little or no reason to ask 
> about access rights for the IM itself.  Access rights are checked 
> during symbolic resolution of class, method, and field references. 
>  (Class object access rights are a tricky case, since classes are easy 
> to grab.)  Inside the IM constant pool, all references are "live", and 
> previously resolved.  There's no reason for the IM to re-resolve them.


...Ah, I can see it now that I have once more looked at the 
specification about the types of entries in constant pool array:

     CONSTANT_Methodref_info: a java.lang.invoke.DirectMethodHandle of 
the right kind, obtained via the appropriate API in 
java.lang.invoke.MethodHandles.Lookup

So all methods will be pre-resolved. There will be no symbolic 
references in the isolated methods. The name "isolated" has a clear 
meaning now. Thanks.


Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160813/0aa2f722/attachment-0001.html>


More information about the mlvm-dev mailing list