[concurrency-interest] padding in Exchanger

Nathan Reynolds nathan.reynolds at oracle.com
Tue Jan 17 12:22:23 EST 2012


It would be nice if the processor could effectively tell the JVM that 
false sharing is happening.  It would be nice if the JVM could respond 
by moving objects within the heap or fields with the class to avoid 
false sharing.  Thus, we don't have to pad or worry about placing 
@Contended or other attributes into the class.

Intel was looking into to optimizing for true and false sharing.  They 
had a prototype that worked but required restarting the JVM.  Oracle was 
looking into dynamically relayout fields in objects.  I haven't heard 
anything from either group for a while...  I haven't asked either.  *IF* 
a solution becomes available, then it will be a while.  This is a very 
difficult thing to do.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 1/17/2012 9:35 AM, Vitaly Davidovich wrote:
>
> OK I see what you mean now.  I imagine @Contended will be used with 
> fields rather than classes so when the JVM lays out an instance of the 
> class I assume it will do two-sided padding on the contended field if 
> required or if natural layout is such that prior fields already fill 
> up a cache line then only one sided is needed.
>
> Sent from my phone
>
> On Jan 17, 2012 11:27 AM, "Ruslan Cheremin" <cheremin at gmail.com 
> <mailto:cheremin at gmail.com>> wrote:
>
>     2012/1/17 Vitaly Davidovich <vitalyd at gmail.com
>     <mailto:vitalyd at gmail.com>>:
>     > I think it's semantics - if you sometimes allocate with 64/128 byte
>     > alignment then if your object is smaller than 64/128 the rest of
>     the space
>     > is effectively padding.
>
>     Agree. But in case of alignment you lose sense of "one-side" or "two
>     side" padding -- you do not need "two side padding", you just make
>     sure object align on cache line boundary.
>
>     Actually I was asked is my understanding of how @Contended supposed to
>     be implemented is right?
>
>     >Or are you saying you want an @Alignment annotation
>     > instead so it's more general? What other uses of custom
>     alignment do you
>     > envision? Java is too high-level  and the underlying
>     hardware/platform too
>     > abstracted away for a general purpose custom alignment hint, IMHO.
>
>     No, I do not want such ugly thing to happen with java! It's enough C
>     for such things...
>
>
>     > Sent from my phone
>     >
>     > On Jan 17, 2012 10:56 AM, "Ruslan Cheremin" <cheremin at gmail.com
>     <mailto:cheremin at gmail.com>> wrote:
>     >>
>     >> > Yes. As a practical matter though, until an @Contended attribute
>     >> > or something like it is supported across JVMS (see list
>     archives for
>     >> > discussion), you cannot arrange reliable two-sided padding
>     >> > for objects with mixed field types (ints, longs, refs that may be
>     >> > either 32 or 64 bits, etc), so one-sided is the best you can do.
>     >>
>     >> By the way -- I was not thinking about @Contended as "make
>     padding for
>     >> me". It seems for me like padding is only dirty hack, since nothing
>     >> better available. If I would control memory allocation (like
>     JVM does)
>     >> I just can allocate @Contended objects on 64 (128... etc) bytes
>     >> boundary. I do not have to "pad" them -- nor both, nor one
>     side. And I
>     >> suppose @Contended implementation to do exactly this -- "use
>     special
>     >> allocator for objects of that type, which allocate them on
>     cache line
>     >> boundary"
>     >>
>     >> Am I wrong here?
>     >>
>     >>
>     >> >
>     >> > -Doug
>     >> > _______________________________________________
>     >> > Concurrency-interest mailing list
>     >> > Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     >> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>     >> _______________________________________________
>     >> Concurrency-interest mailing list
>     >> Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/4c209fca/attachment.html>


More information about the Concurrency-interest mailing list