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