Proxy.isProxyClass scalability

[Peter Levart]

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