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

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to