On 05/02/2017 06:56 PM, Mandy Chung wrote:
On May 2, 2017, at 3:14 AM, Peter Levart <peter.lev...@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.
Regards, Peter
Mandy
