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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
