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

Vitaly Davidovich vitalyd at gmail.com
Mon Nov 26 11:43:58 PST 2012

I don't see what burying this in sun.misc really accomplishes. Look at Unsafe - it's still widely used except have to jump through reflection hoops. Also, sun.misc is apparently going away in java 9.

I also don't understand the reasoning behind trying to "prevent people from shooting themselves in the foot" - we should consider java developers as responsible adults. Nobody is forcing anyone to use this annotation. Otherwise, we should throw out GC tuning knobs, JIT tuning knobs, weak/soft/phantom refs, finalizers, thread locals, direct byte buffers, etc. This entire "java devs are too immature/dumb/irresponsible/etc" sentiment is ridiculous, IMHO.

By the way, if you think only Doug/Cliff Click/etc are using Unsafe, then don't tell Cassandra/Hbase developers :). Cassandra goes as far as using pluggable C heap allocators (accessed via Unsafe behind the scenes) to allocate off-heap memory - this is in addition to using unsafe comparators for byte arrays, and other "tricks". That's the price of admission when trying to squeeze perf ...

Sent from my phone On Nov 26, 2012 2:19 PM, "Kirk Pepperdine" <kirk at kodewerk.com> wrote:

Actually, sun.misc.Contended right beside sun.misc.Unsafe doesn't sound like such a bad idea.

-- Kirk On 2012-11-26, at 8:08 PM, Doug Lea <dl at cs.oswego.edu> wrote: > 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