On 11/06/2013 11:37 AM, Remi Forax wrote:
On 11/05/2013 11:11 AM, Joel Borggrén-Franck wrote:
On 5 nov 2013, at 10:51, Peter Levart <peter.lev...@gmail.com> wrote:
On 11/05/2013 10:33 AM, Joel Borggrén-Franck wrote:
I would also restructure the Method/Constructor accessor logic
differently. The check for ReflectUtil.isVMAnonymousClass() can
be performed just once (in the
newMethodAccessor/newConstructorAccessor methods) and based on
this check, create accessor:
- for classic declaring class - as is / unchanged
- for anonymous declaring class - just create and return
NativeMethodAccessorImpl without a parent
Then in NativeMethodAccessorImpl (and same for constructor),
modify the inflation checking logic:
if (parent != null && ++numInvocations >
ReflectionFactory.inflationThreshold()) {
MethodAccessorImpl acc = (MethodAccessorImpl)
new MethodAccessorGenerator().
generateMethod(method.getDeclaringClass(),
method.getName(),
method.getParameterTypes(),
method.getReturnType(),
method.getExceptionTypes(),
method.getModifiers());
parent.setDelegate(acc);
}
I don't like adding even more special cases to this check. IMHO a
better way that we discussed and rejected, opting for a smaller
change, is to create a NonInflatingMethodAccessor and just drop in
one of those without a delegate for when creating the accessor for
methods/ctors on anonymous classes.
Even better. I would name the new class NativeMethodAccessorImpl and
the one doing inflation InflatingNativeMethodAccessorImpl which
would extend NativeMethodAccessorImpl, override invoke() and call
super.invoke()... This way, no native methods duplication is needed.
invoke() is already an interface method with 2 implementations. Now
it will have 3. Does this present any difference for dispatch
optimization?
FWIW i think the magic number is 4, but I don't know where I got
that. Anyhow, this might be slightly controversial, but for all code
I care about (reflective invocation of methods/ctors on
non-VM-anonymous classes) the check happens exactly once as is.
No, the magic number is 2 (by default),
you can look for TypeProfileWidth in the vm code.
I forgot that each generated method accessor is a separate class with a
separate method. So the number of implementations is already much more
than 2 today...
Regards, Peter
regards,
Rémi
