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

Doug Lea dl at cs.oswego.edu
Mon Nov 26 11:08:12 PST 2012

On 11/26/12 13:40, Aleksey Shipilev 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.

All things considered, I'm back to agreeing with you -- Just j.u.c.Contended

I think you should re-write the javadoc ...

The Contended.java file and its javadoc in Aleksey's webrev is just a placeholder to get things moving. We expect to solicit reviews in the usual way (mainly on concurrency-interest list) for a version that will make it into JDK8.

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?

I think that the most common and most-recommended case will be class-level, so it should be kept. We can work on the usage advice in the javadocs.

-Doug

More information about the hotspot-dev mailing list