Why java's Exchanger.Slot cache line padding like this?
<p>When I read the 'False sharing' mechnism in java, I find the following code in <strong>java.util.concurrent.Exchanger.Slot</strong></p>

<pre><code>    /**
 * A Slot is an AtomicReference with heuristic padding to lessen
 * cache effects of this heavily CAS'ed location.  While the
 * padding adds noticeable space, all slots are created only on
 * demand, and there will be more than one of them only when it
 * would improve throughput more than enough to outweigh using
 * extra space.
 */
private static final class Slot extends AtomicReference&lt;Object&gt; {
    // Improve likelihood of isolation on &lt;= 64 byte cache lines
    long q0, q1, q2, q3, q4, q5, q6, q7, q8, q9, qa, qb, qc, qd, qe;
}
</code></pre>

<p>It's strange.Why the number of long is 15 (q0 - qe),
So I can calculate the size of the object should be:<br>
15 * 8 (long) + 8 (parent's long value) + <strong>16</strong> (object header pointer at 64 bit jvm) = 144 byte.<br>
or:<br>
15 * 8 (long) + 8 (parent's long value) + <strong>8</strong> (object header pointer at 32 bit jvm) = 136 byte.<br>
As I readed the <a href="http://mechanitis.blogspot.jp/2011/07/dissecting-disruptor-why-its-so-fast_22.html" rel="nofollow">Disruptor's implemention:</a></p>

<pre><code>public long p1, p2, p3, p4, p5, p6, p7; // cache line padding

private volatile long cursor = INITIAL_CURSOR_VALUE;

public long p8, p9, p10, p11, p12, p13, p14; // cache line padding
</code></pre>

<p>The size should be  7*8 + 8 + 7*8 + 8 (object head opinter'size at 32 bit jvm) = 128 = 64 * 2. <br>
As the default cache line size of most cpu is 64 byte, so the discruptor's impl can avoid the 'False sharing'.
<br>So my question is the number of padded long at class 
<strong>java.util.concurrent.Exchanger.Slot</strong> is right or wrong ? </p>