[concurrency-interest] padding in Exchanger

Doug Lea dl at cs.oswego.edu
Tue Jan 17 06:52:15 EST 2012


On 01/17/12 06:39, Ruslan Cheremin wrote:
> My question is about cache-line padding in j.u.c.Exchanger.Slot class:
>
> private static final class Slot extends AtomicReference<Object>  {
>          // Improve likelihood of isolation on<= 64 byte cache lines
>          long q0, q1, q2, q3, q4, q5, q6, q7, q8, q9, qa, qb, qc, qd, qe;
> }
>
> Comments telling about<=64 byte cache line padding, but it seems for
> me what 15 longs*8 = 120 bytes (+8 bytes on object header, I suppose =
> even 128). Why to have 128 bytes padding for 64 byte cache line? It
> seems for me, what if I rely on one-side padding, I need only 7 longs
> (+header).

The short answer is that JVMs do not guarantee alignment.
For a longer answer, see the internals of the new Striped64 class at
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/Striped64.java?view=log

and/or the overhauled Exchanger class at
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/Exchanger.java?view=log

In general, especially on multisocket multicores these days,
you need to waste a lot of space to overcome crippling memory
contention effects that can easily slow down an application
by a factor of 4; sometimes more. Were trying to isolate
the cases where doing so is worthwhile inside libraries,
so that users don't need to think about it very often, so
long as they use the provided components.

-Doug


More information about the Concurrency-interest mailing list