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