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
