[concurrency-interest] padding in Exchanger

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 17 13:12:47 EST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/67b2fcd2/attachment-0001.html>


More information about the Concurrency-interest mailing list