http://cr.openjdk.java.net/~jrose/7030453/webrev.00
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
