review request (L): 7030453: JSR 292 ClassValue.get method is too slow

[Christian Thalinger]

On Sep 19, 2011, at 11:58 PM, John Rose wrote:

> http://cr.openjdk.java.net/~jrose/7030453/webrev.00

src/share/classes/java/lang/ClassValue.java:

 233     /** Value stream for for hashCodeForCache.  See similar structure in ThreadLocal. */

Two for's.

 578      *  from the ehad of a non-null run, which would allow them

"ehad"?

Otherwise I think this looks good.

-- Christian

> 
> The existing JDK 7 implementation of ClassValue is a place-holder which is defective in several ways:
> - It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to values, which is slow.
> - It does not lock the root WeakHashMap, which can cause a race condition the first time a class is encountered.
> - It relies on internal details of WeakHashMap to avoid other race conditions.
> 
> The new implementation uses a concurrently readable cache per Class object with entry versioning to manage lookups.  It is more correct and scalable.
> 
> The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by looking at the behavior of artificial workloads.  Experience with real workloads will probably lead to further modifications (under new Change Requests).  I thought of making them tunable from JVM command line properties, but since no other class in java.lang does this, I held back.
> 
> The previous implementation had a store barrier which pushed (via lazySet) pending store values from the user-supplied value before the ClassValue mapping was published.  I removed it because it is a false fix for user-caused race conditions.  (False because it has the desired effect only on some platforms.)  I think it is better to put that issue back onto the user.  We still need a memory fence API to give users the right hook for such problems.
> 
> There is a package-private change to java.lang.Class, adding two new fields (to the existing 19 fields declared in Class.java).
> 
> Although this class is in java.lang, it is part of JSR 292.  Therefore the review comments will be collected in mlvm-dev.  The review request is CC-ed to hotspot-compiler (where JSR 292 changes are pushed) and core-libs (which is responsible for java.lang).
> 
> -- John