Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

Mandy Chung mandy.chung at oracle.com
Tue May 2 16:56:49 UTC 2017


> 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.

> 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.

Mandy



More information about the core-libs-dev mailing list