hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...
Peter Levart
peter.levart at gmail.com
Tue Nov 5 09:51:03 UTC 2013
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?
Regards, Peter
>
> cheers
> /Joel
More information about the core-libs-dev
mailing list