Proxy.[isProxyClass|getProxyClass] scalability

[Peter Levart]

Hi Alan, David,

I think I have a solution for scalability problems of 
java.lang.reflect.Proxy:

* http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.01/index.html

I designed it along the lines mentioned in previous mail (see below). 
First I thought that both caches (a cache mapping request parameters of 
Proxy.getProxyClass to a proxy Class and a cache for resolving the 
Proxy.isProxyClass method) could be placed inside the j.l.ClassLoader. 
And they actually could. I tried this and it worked correctly, but the 
raw (single-threaded) performance of Proxy.isProxyClass was half the 
performance of current JDK8 isProxyClass method that way. The main 
performance hog I identified was the Class.getClassLoader() method. This 
method delegates to a native JVM method after checking the callers 
permissions. So the plan to keep the isProxyClass cache inside the 
ClassLoader failed. But then the ClassValue solution that I proposed in 
previous revision works beautifully and fast, so I kept this solution 
for isProxyClass cache. The ThreadLocal trick to initialize the 
ClassValue for a particular proxy class is necessary because ClassValue 
does not have a put() method. It does have actually, but it's package 
private and the comment suggests that it might not be there forever:

     // Possible functionality for JSR 292 MR 1
     /*public*/ void put(Class<?> type, T value) {
         ClassValueMap map = getMap(type);
         map.changeEntry(this, value);
     }

I could use the JavaLangAccess to access it from Proxy code though, so 
this is another refinement that is possible and would eliminate the need 
for ThreadLocal trick.
The cache for getProxyClass method on the other hand is most naturally 
hosted by j.l.ClassLoader and that's where I put it in the proposed 
patch. Currently the cross-package access to it is implemented using 
Unsafe, but the performance aspect is not so critical that It couldn't 
be changed to using JavaLangAccess instead if desired.
I did some performance testing too. Here are the results taken on 3 
different systems (i7 Linux PC, Raspberry Pi and Sun-Blade-T6320 Solaris 
machine):

* 
https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results.txt

These are the test sources i used:

* 
https://github.com/plevart/jdk8-tl/blob/proxy/test/src/test/ProxyBenchmarkTest.java
* 
https://github.com/plevart/micro-bench/blob/master/src/si/pele/microbench/TestRunner.java

Results show scalability and raw performance improvements for both 
critical Proxy methods.

So what do you think?


Regards, Peter


On 01/25/2013 06:55 PM, Peter Levart wrote:
> On 01/24/2013 03:34 PM, Peter Levart wrote:
>> On 01/24/2013 03:10 PM, Alan Bateman wrote:
>>> On 24/01/2013 13:49, Peter Levart wrote:
>>>> Should I file a RFE first?
>>> Sorry I don't have time at the moment to study the proposed patch 
>>> but just to mention that it has come up a few times, its just that 
>>> it never bubbled up to the top of anyone's list. Here's the bug 
>>> tracking it:
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=7123493
>>>
>>> -Alan.
>> I belive that is another bottleneck. It is mentioning the 
>> Proxy.getProxyClass method which also uses synchronization for 
>> maintaining a cache of proxy classes by request parameters. I could 
>> as well try to fix this too in the same patch if there is interest.
>>
>> Regards, Peter
>>
>
> Hi Alan, David,
>
> I thought about the ways to fix Proxy.isProxyClass() scalability and 
> the Proxy.getProxyClass() scalability. While they are different 
> methods, each with it's own data structure, I think that both problems 
> can be solved with a single solution and that solution does not 
> involve neither adding fields to j.l.Class nor ClassValue.
>
> The solution is actually very simple. I just want to validate my 
> reasoning before jumping to implement it:
>
> - for solving scalability of getProxyClass cache, a field with a 
> reference to ConcurrentHashMap<List<String>, Class<? extends Proxy>> 
> is added to j.l.ClassLoader
> - for solving scalability of isProxyClass, a field with a reference to 
> ConcurrentHashMap<Class<? extends Proxy>, Boolean> is added to 
> j.l.ClassLoader
>
> Both maps hold strong references to Class objects, but only for the 
> classes that are loaded by the ClassLoader that references them. Each 
> ClassLoader already holds a strong reference to all the Class objects 
> for the classes that were loaded by it in a Vector. Holding another 
> reference does not present any problem, right?
>
> I think this would be the best solution and it would solve both 
> scalability problems of j.l.Proxy in one go.
>
> Am I missing something?
>
> Regards, Peter
>