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

[Remi Forax]

On 11/26/2012 08:03 PM, Vitaly Davidovich wrote:
>
> 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
>

There is an ongoing effort to try to add value type to Java.
@Contented on a field of a value type will do exactly what you want.

Rémi

> On Nov 26, 2012 1:53 PM, "Vitaly Davidovich" <vitalyd at gmail.com 
> <mailto: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 <mailto: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.
>