Proxy.isProxyClass scalability (original) (raw)

Peter Levart peter.levart at gmail.com
Fri Jan 25 17:55:03 UTC 2013


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/viewbug.do?bugid=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:

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



More information about the core-libs-dev mailing list