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

John Rose john.r.rose at
Sun Dec 4 03:59:25 UTC 2011

The caching ClassValue is still under review.  I took the opportunity to remove -Xlint warnings (adding type parameters) and refactor for better readability.

Also, Mike Duigou pointed out that there was still a dependency on ClassValue.equals == Object.equals, which could create a side-channel between independent CVs.  I removed this by replacing ClassValue with ClassValue.Identity as the hash table key.

The cache access is racy, for speed, but all races are (thought to be) benign.  For cache hits, end-user values are obtained from non-racing accesses.  All cache state changes happen either under a per-class lock or during GC (nulling of weak references).

Could I have a re-review?

-- John

On Sep 20, 2011, at 4:10 PM, John Rose wrote:

> On Sep 19, 2011, at 2:58 PM, John Rose wrote:
> After some comments from David Holmes (thanks David!) I added internal comments about race conditions.
> I refreshed the webrev with the additional comments.  I also changed one variable to be volatile, with a paragraph of comments explaining why.
> (The change to volatile will inhibit CSE of ClassValue.get calls, but I think such CSE was unlikely anyway.  There should be no other performance effects.)
> -- John

More information about the core-libs-dev mailing list