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

Joe Darcy joe.darcy at oracle.com
Sun Dec 4 19:38:23 UTC 2011

Hi John,

Are there alternatives to adding two new fields to java.lang.Class? I assume most Class'es won't have ClassValue information associated with them.

-Joe

On 12/3/2011 7:59 PM, John Rose wrote:

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? Thanks, -- John On Sep 20, 2011, at 4:10 PM, John Rose wrote:

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

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