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

Remi Forax forax at univ-mlv.fr
Mon Nov 26 09:35:48 PST 2012

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

But the construction of @Contended has nothing to do with atomics, right? (Yes, the sanest use case is to protect atomically-updated fields.)

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

You should mention that marking @Contented a field which is not volatile is useless unless there is proper fences. And also mention that it may consume a lot of memory thus it should only be used if there is a known issue.

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.

"Nanny-state folks" would naturally presume annotating the plain field with @Contended will turn all operations on that field into atomics :)

Alternatives: java.util.concurrent.hints.Contended java.util.concurrent.expert.Contended java.util.concurrent.unsafe.Contended java.util.concurrent.herebedragons.Contended :) I think the high-level annotation is already good. -Aleksey.

Rémi

More information about the hotspot-dev mailing list