Proxy.isProxyClass scalability

[Mandy Chung]

On 4/16/2013 7:18 AM, Peter Levart wrote:
> Hi Mandy,
>
> I prepared a preview variant of j.l.r.Proxy using WeakCache (turned 
> into an interface and a special FlattenedWeakCache implementation in 
> anticipation to create another variant using two-levels of 
> ConcurrentHashMaps for backing storage, but with same API) just to 
> compare performance:
>
> https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.01/index.html
>


thanks for getting this prototype done quickly.

> As the values (Class objects of proxy classes) must be wrapped in a 
> WeakReference, the same instance of WeakReference can be re-used as a 
> key in another ConcurrentHashMap to implement quick look-up for 
> Proxy.isProxyClass() method eliminating the need to use ClassValue, 
> which is quite space-hungry.
>

I also think maintaining another ConcurrentHashMap is a good replacement 
with the use of ClassValue to avoid its memory overhead.

> Comparing the performance, here's a summary of all 3 variants 
> (original, patched using a field in ClassLoader and this variant):
>
> [...]
>
> The improvement is still quite satisfactory, although a little slower 
> than the direct-field variant. The scalability is the same as with 
> direct-field variant.
>

Agree - the improvement is quite good.

> Space consumption of cache structure, calculated as deep-size of the 
> structure, ignoring interned Strings, Class and ClassLoader objects 
> unsing single non-bootstrap ClassLoader for defining the proxy classes 
> and using 32 bit addressing is the following:
>
> [...]
>
> So with new ConcurrentHashMap the patched Proxy uses about 32 bytes 
> more per proxy class.
>
> Is this satisfactory or should we also try a variant with two-levels 
> of ConcurrentHashMaps?
>

The overhead seems okay to trade off the scalability.

Since you have prepared for doing another variant, it'd be good to 
compare two prototypes if this doesn't bring too much work :)  I would 
imagine that there might be slight difference in your measurement when 
comparing with proxies defined by a single class loader but the code 
might be simpler (might not be if you keep the same API but different 
implementation).

Regardless of which approach to use - you have added a general purpose 
WeakCache and the implementation class in the sun.misc package.  While 
it's good to have such class for other jdk class to use, I am more 
comfortable in keeping it as a private class for proxy implementation to 
use.  We need existing applications to migrate away from sun.misc and 
other private APIs to prepare for modularization.

Nits: can you wrap the lines around 80 columns including comments? 
try-catch-finally statements need some formatting fixes.  Our convention 
is to have 'catch', or 'finally' following the closing bracket '}' in 
the same line.  Your editor breaks 'catch' or 'finally' into the next line.

>
> Even without SecurityManager installed the performance of native 
> getClassLoader0 was a hog. I don't know why? Isn't there an implicit 
> reference to defining ClassLoader from every Class object?

That's right - it looks for the caller class only if the security 
manager is installed.   The defining class loader is kept in the VM's 
Klass object (language-level Class instance representation in the VM) 
and there is no computation needed to obtain a defining class loader of 
a given Class object.  I can only think of the Java <-> native 
transition overhead that could be one factor. Class.getClassLoader0 is 
not intrinsified.  I'll find out (others on this mailing list may 
probably know).

Mandy