[concurrency-interest] padding in Exchanger

Ruslan Cheremin cheremin at gmail.com
Tue Jan 17 13:18:47 EST 2012


Just wait "a few decades" :)

2012/1/17 Vitaly Davidovich <vitalyd at gmail.com>:
> I'd love to be proven wrong though :)
>
> Sent from my phone
>
> On Jan 17, 2012 1:06 PM, "Ruslan Cheremin" <cheremin at gmail.com> wrote:
>>
>> I'm sure the same things was said by people against GC few decades ago :)
>>
>> 2012/1/17 Vitaly Davidovich <vitalyd at gmail.com>:
>> > Doing dynamic re-layout and contention adjustment seems nice in thought
>> > but
>> > how practical is that? I can't see how that would be cheap enough where
>> > it's
>> > worth the cost. What if the app goes through phases of contention?
>> > Initially
>> > high but then no sharing - would the bloated object layout be worth it
>> > at
>> > that point? Seems like this is a place where explicit developer
>> > instructions
>> > is better than heuristics with potentially expensive consequences.
>> >
>> > Sent from my phone
>> >
>> > On Jan 17, 2012 12:44 PM, "Nathan Reynolds" <nathan.reynolds at oracle.com>
>> > wrote:
>> >>
>> >> Assuming that the JVM can optimize for true and false sharing (and that
>> >> is
>> >> a big assumption at the moment), then you can focus your time on
>> >> writing
>> >> useful code.  Furthermore, optimizing for true and false sharing will
>> >> never
>> >> be able to fix actual data contention.  We still need clever ways of
>> >> sharing
>> >> data without bottlenecks.
>> >>
>> >> Nathan Reynolds | Consulting Member of Technical Staff | 602.333.9091
>> >> Oracle PSR Engineering | Server Technology
>> >>
>> >> On 1/17/2012 10:29 AM, Ruslan Cheremin wrote:
>> >>
>> >> 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