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