[concurrency-interest] padding in Exchanger

Ruslan Cheremin cheremin at gmail.com
Tue Jan 17 12:29:04 EST 2012


You made my day. Few months ago I was dreaming (in my blog) about
complexity of false sharing prevention with padding. And come to two
options, one better another. First one was @PreventFalseSharing
annotation, next was atomatically contention detection and relocation
of contended objects by JIT. Readers of my blog soon pointed me to
@Contended annotation. And now you telling the second -- the best --
option is also being explored!

Just want to ask -- if all good things will be done by JIT -- what I
will be paid for?

2012/1/17 Nathan Reynolds <nathan.reynolds at oracle.com>:
> 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 | Consulting Member of Technical Staff | 602.333.9091
> Oracle PSR Engineering | 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> 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
>
>
>
> _______________________________________________
> 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