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

[Vitaly Davidovich]

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.
>