[concurrency-interest] padding in Exchanger

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Tue Jan 17 09:40:05 EST 2012


The more the padding the less the contention in cache. Is this the
general idea apart from the calculation ?

Thanks,
Mohan

On Tue, Jan 17, 2012 at 5:22 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> 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
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list