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.

regards,
Rémi

Reply via email to