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

[Peter Levart]

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