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

[Joe Darcy]

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