RFR (S): JEP-142: Reduce Cache Contention on Specified Fields

[Vitaly Davidovich]

Also, one useful (but more complex to implement presumably) feature would
be to pad array elements.  I think this case of false sharing comes up
quite a bit so instead of doing manual padding, would be nice to keep java
code indexer arithmetic the same but have the interpreter/JIT do the proper
offsetting behind the scenes.

Sent from my phone
On Nov 26, 2012 1:53 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> Personally, I'd leave out the class level annotation - I don't think that
> case happens all that often.  Can always add that feature later if it turns
> out to be useful - it won't break compatibility.
>
> Can you also please turn field layout printing into either a product or
> diagnostic flag, if you didn't do that already? To reduce clutter, perhaps
> one can specify type name(s) for which this info should be shown -
> analogous to how disassembly allows this.
>
> Also, I assume heap walkers/profilers will report proper mem usage for
> objects with padding? One caveat here would be that if padding is applied
> but not somehow obvious in the tool, then the mental math of how much the
> object should take up vs how much it actually takes up may create some
> confusion.  This may be more of a tool problem in that they should perhaps
> indicate visibly instances with @Contended fields.
>
> Sent from my phone
> On Nov 26, 2012 1:42 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
> wrote:
>
>> On 11/26/2012 09:35 PM, Remi Forax wrote:
>> > On 11/26/2012 05:44 PM, Aleksey Shipilev wrote:
>> >> On 11/26/2012 08:22 PM, Doug Lea wrote:
>> >>> One small suggestion to slightly appease the nanny-state folks.
>> >>> How about burying the annotation one lever deeper to
>> >>> java.util.concurrent.atomic.
>> >
>> > +1
>> >
>>
>> Still fail to see the rationale about this.
>>
>> > I think you should re-write the javadoc to not use 'hot' (hot ->
>> > optimize -> I should use it) and talk about false sharing (with a
>> > link to the wikipedia article
>> > http://en.wikipedia.org/wiki/False_sharing).
>>
>> Yup, will do.
>>
>> > You should mention that marking @Contented a field which is not
>> > volatile is useless unless there is proper fences.
>>
>> Um. Actually, there is a lot of sense with marking plain fields with
>> @Contended, especially when visibility is guaranteed elsewhere. You
>> probably mean "marking the field @Contended does not turn it into
>> volatile"? ...does it really worth mentioning?
>>
>> > And also mention that it may consume a lot of memory thus it should
>> > only be used if there is a known issue.
>>
>> Yes, good idea.
>>
>> > Also, I'm not in favour of allowing to use @Contented on class, if
>> > you want all fields to be marked as @Contented, just mark them as is.
>> > Given that this annotation is here to solve a corner case, using the
>> > annotation in a class wide way  in my opinion a door open to stupid
>> > usages. You don't mark a class volatile if all their fields are
>> > volatile.
>>
>> >From the layout perspective, class-level @Contended is equivalent to
>> all-field @Contended with the same contention group. Do you think we
>> don't need this ask the shortcut for tuple/value/struct classes?
>>
>> I.e.
>>
>>     @Contended
>>     public class ValueClass {
>>          private int field1;
>>          private int field2;
>>          private int field3;
>>          private int field4;
>>     }
>>
>> is the shortcut for:
>>
>>     public class ValueClass {
>>          @Contended("theSame") private int field1;
>>          @Contended("theSame") private int field2;
>>          @Contended("theSame") private int field3;
>>          @Contended("theSame") private int field4;
>>     }
>>
>> That is, all the fields would be densely-packed, but will be padded as
>> the group. Note that it is not the same as:
>>
>>     public class ValueClass {
>>          @Contended private int field1;
>>          @Contended private int field2;
>>          @Contended private int field3;
>>          @Contended private int field4;
>>     }
>>
>> Maybe that is already confusing enough to drop class-level annotation?
>> What do others feel about this?
>>
>> -Aleksey.
>>
>