RFR (S): JEP-142: Reduce Cache Contention on Specified Fields (original) (raw)
Kirk Pepperdine kirk at kodewerk.com
Mon Nov 26 11:07:45 PST 2012
- Previous message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Next message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This isn't really atomic, it's about concurrent so I'd vote for inclusion in the concurrent package.. given that everyone seems intent on barreling down this path without thought to my earlier email.
Regards, Kirk
On 2012-11-26, at 7:40 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/Falsesharing). 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.
- Previous message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Next message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]