[concurrency-interest] padding in Exchanger

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 17 11:35:03 EST 2012


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> wrote:

> 2012/1/17 Vitaly Davidovich <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> 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
> >> > 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/9455901c/attachment-0001.html>


More information about the Concurrency-interest mailing list