[concurrency-interest] Fwd: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Nov 23 04:30:04 EST 2012

On 11/23/2012 12:43 PM, Jeff Hain wrote:
>>FYI. Although the implementation is Hotspot-specific, the API is not.
>>Would like to hear the opinions :)
> Great news.
> How does it fit with classes such as AtomicLong?
> Will there be padded versions of these, or would
> it be possible to have @Contended applied on a
> final reference, have the same effect than
> @Contended applied to the class of the referenced
> instance, which would allow to do things such as:
> class SomeClass {
>     @Contended
>     final AtomicLong counter = new AtomicLong();
> }
> and
> void someMethod() {
>     @Contended
>     final AtomicLong counter = new AtomicLong();
> }
> ?
> (since AtomicLong only holds one non-final field,
> and @Contended should have no effect on final fields)

Sorry, the current implementation works on class loading level only, and
it requires the non-trivial GC interop to work in the cases you
outlined, basically aligning the contended objects on their own cache
lines during the GCs. (The open question though is whether @Contended
applies to the entire object tree then, and to what extent).

At this point you have to do the padded version of AtomicLong:

 class PaddedAtomicLong extends AtomicLong {}

However, this still has a drawback that the subclass annotation will
only affect the fields in the subclass, and not in the superclasses
(laying the superclass fields on the same offsets in the subclass is
important to get cheap polymorphism).

Another option for library designers like Doug would be rolling out the
distinct version of Atomic* with @Contended involved on the exact field.
It's unlikely plain old Atomic*-s will get this annotation, because it
plays against the memory footprint.

FWIW, this annotation is useful for library designers only; there are
just a few places in j.u.c.* where it is clearly helpful, and that dozen
of places really, really hurt once stepped upon false sharing. I do
believe it would help to construct saner concurrent primitives for other
people as well.

I'm open for the suggestions how to fit these needs without blowing up
the conceptual and implementation complexity beyond what is acceptable
to consider in JDK8.


More information about the Concurrency-interest mailing list