Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke
peter.levart at gmail.com
Tue May 2 20:17:28 UTC 2017
On 05/02/2017 06:56 PM, Mandy Chung wrote:
>> On May 2, 2017, at 3:14 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> I don't quite understand the need for bypassing the inflation of native into generated method accessor
> The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM change in this patch and so we ensure this be called via the generated bytecode for Method::invoke rather than going through the VM native reflection which reduces startup overhead.
I don't think VM native reflection implementation needs to know anything
about this alternate `reflected$XXX` mechanism. The
NativeMethodAccessorImpl is constructed with the Method argument. In
case of `reflected$XXX` mechanism, it is given the alternate Method
object that points to the alternate method, so
NativeMethodAccessorImpl.invoke0 is called with this alternate Method
object. It is like reflecting over the alternate method itself, isn't it?
Am I missing something?
>> Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated MethodAccessorImpl subclass is?
> As this case is forced not to go through VM reflection support, unless I miss something, DelegatingMethodAccessorImpl/NativeMethodAccessorImpl has no need to be changed. I will double check with the VM runtime team.
I was asking because I suspected that this might be the reason for
skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl. But if
it is not the reason (and anyway it would be a bug because other
@CallerSensitive methods would behave erratically if this was the case),
then I still don't see a reason for skipping
DelegatingMethodAccessorImpl/NativeMethodAccessorImpl and proceeding
directly with generated method accessor.
More information about the core-libs-dev