Proxy.isProxyClass scalability

Peter Levart peter.levart at
Wed Apr 24 08:11:26 UTC 2013

On 04/24/2013 08:58 AM, Peter Levart wrote:
>> In your revisions, you optimize for 0-interface and 1-interface proxy 
>> class.  What I hacked up earlier was just to use Class<?>[] as the 
>> key (need to make a copy of the array to prevent that being mutated 
>> during runtime) that is a simpler and straightforward 
>> implementation.  I didn't measure the footprint and compare the 
>> performance of your versions. *Have you seen any performance 
>> difference which led you to make the recent changes?*
> I developed two different approaches:
> 1. Key made of WeakReference-s to interface Class objects.
> Strong points:
> - no key aliasing, validation can be pushed entirely to slow-path
> - quick and scalable
> - less memory usage than original code for 0 and 1-interface proxies

That's the sole reason for optimized: WekaReferece<Class> -> 
WeakReference<Class> -> ... -> WeakReference<Class> linked list instead 
of the WeakReference<Class>[] array approach. And it's not using any 
recursion for equals/hashCode, so the peformance is comparable to array 
approach and it doesn't suffer from StackOverflowExceptions for lots of 

> Weak points:
> - more memory usage for 2+ -interface proxies
> Latest webrev:
> Comments:
>   I like this one. If 2+ -interface proxies are relatively rare and 
> you don't mind extra space consumption for them,  I would go with this 
> approach.
> 2. Key made of interned Strings (names of interfaces)
> Strong points:
> - quick and scalable
> - much less memory usage than original code for all variations of 
> interface counts and in particular for 0, 1 and 2-interface proxies

The special-cased keys for 1 and 2-interface proxies (the most frequent) 
make for additional space savings.

> Weak points:
> - key is aliased, so the validation of interfaces has to be done - I 
> tried to do it post-festum with intf.isAssignableFrom(proxyClass) but 
> you say that is not reliable. If the validation is performed on 
> fast-path before proxy class is obtained, using Class.forName, the 
> slow-down is huge.
> Latest webrev:
> Comments:
>   This is the best space-saving approach. With tricks for single and 
> two-interface keys, the savings are noticable.

Regards, Peter

More information about the core-libs-dev mailing list