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

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