Hi again,
By simple rearrangement of code in Proxy.getProxyClass (moved the
parameters validation to slow-path) I managed to speed-up the fast-path
getProxyClass so that now it's raw speed is 40x the speed of current
getProxyClass method:
* http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.02/index.html
Here are quick measurements (only for i7 this time):
*
https://raw.github.com/plevart/jdk8-tl/proxy/test/proxy_benchmark_results_v2.txt
Regards, Peter
On 01/27/2013 02:32 PM, Peter Levart wrote:
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
