hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...

Joel Borggrén-Franck joel.franck at oracle.com
Tue Nov 5 09:33:10 UTC 2013


Hi Peter,

Narrowing this to core-libs-dev.

On 5 nov 2013, at 09:25, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Robert,
> 
> I think this fix is not complete. When one sets the system property sun.reflect.noInflation=true, reflection proxy is still attempted to be generated for anonymous classes (see ReflectionFactory.newMethodAccessor/newConstructorAccessor).
> 

Thanks for catching this.

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

cheers
/Joel


More information about the core-libs-dev mailing list