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
