RFR (S) CR 8008965: @Contended fails with classes having static fields

[Coleen Phillimore]

This looks okay to me.  Can the 80003985 regression test be added to the 
hotspot or jdk test set?  I would like to see it in the webrev anyway.
I don't think removing this code would break normal class layout (unless 
catastrophically) so I think the testing is sufficient.
As far as changing how oopmaps are created for static fields, which are 
allocated in the mirror, you'd have to make sure it doesn't hurt GC 
performance and see how much extra complication that you'd add for this 
special, and we hope, unusual case.

Coleen

On 03/05/2013 02:37 PM, Aleksey Shipilev wrote:
> Anyone? :)
>
> -Aleksey.
>
> On 02/26/2013 02:19 PM, Aleksey Shipilev wrote:
>> Hi,
>>
>> The jsr166 testing shows @Contended fails with the classes having the
>> static fields. The bottom line for the issue is that HS maintains
>> contiguous area of static oops within the class, and injecting padding
>> there breaks the field walk logic.
>>
>> This does not break the usual builds, because that code is not used
>> unless you have @Contended classes (in some regard, that's why it
>> slipped testing before).
>>
>> Fixing @Contended to work with static fields will require substantial
>> amount of redo in static oops map code, so at this point it seems
>> beneficial to just no-op the @Contended effect for static fields:
>>    http://cr.openjdk.java.net/~shade/8008965/webrev.00/
>>
>> Our primary use cases involve instance fields, so this shoves off the
>> low priority functionality. After we commit this fix, does anyone has
>> the problem with doing static oops maps in the same way we deal with
>> instance oops maps in the class?
>>
>> Testing:
>>    - full JPRT cycle with hotspot-rt
>>    - targeted jsr166 builds with @Contended
>>    - 8003985 regression test
>>
>> -Aleksey.
>>