Proxy.isProxyClass scalability

Mandy Chung mandy.chung at
Fri Apr 12 21:31:16 UTC 2013

Hi Peter,

Thank you for rebasing the patch. This is very good work and I hope to 
make time to work with you to get your patch to jdk8 over the next 
couple weeks.

On 4/10/2013 5:35 AM, Peter Levart wrote:
> Hi Alan,
> I have prepared new webrev of the patch rebased to current tip of 
> jdk8/tl repo:
> I also devised an alternative caching mechanism with scalability in 
> mind which uses WeakReferences for keys (for example ClassLoader) and 
> values (for example Class) that could be used in this situation in 
> case adding a field to ClassLoader is not an option:

I would also consider any alternative to avoid adding the 
proxyClassCache field in ClassLoader as Alan commented previously.

My observation of the typical usage of proxies is to use the interface's 
class loader to define the proxy class. So is it necessary to maintain a 
per-loader cache?  The per-loader cache maps from the interface names to 
a proxy class defined by one loader. I would think it's reasonable to 
assume the number of loaders to define proxy class with the same set of 
interfaces is small.  What if we make the cache as "interface names" as 
the key to a set of proxy class suppliers that can have only one proxy 
class per one unique defining loader.  If the proxy class is being 
generated i.e. ProxyClassFactory supplier, the loader is available for 
comparison. When there are more than one matching proxy classes, it 
would have to iterate all in the set.

This alternative is sub-optimal than the per-loader cache. I'd be 
interested in your thought of this alternative and any rough idea of the 
performance difference with and without the per-loader cache approach 
for the annotation case.

Coding convention: we use /** ... */ for javadoc and /*...*/ or // for 
comments.  Your patch uses /**...*/ style as comments that need fixing.  
The style you have for
    try {
    catch {
    finally {


> Regards, Peter

More information about the core-libs-dev mailing list