[concurrency-interest] padding in Exchanger

Ruslan Cheremin cheremin at gmail.com
Wed Jan 18 04:23:49 EST 2012

I also like this idea -- because even if it support by JVM will be
delayed, it is not a hard task to make simple annotation processor,
which will implement @Contended via padding. And -- in case of run
time enchancer -- it is even possible to make some native call to find
out actual cache line size on current arch.

Such solution, although not ideal one, at least stop programmers to
invent it's own padding methods.

2012/1/18 Joe Bowbeer <joe.bowbeer at gmail.com>:
> I like the generic annotation idea.
> Note that optimizer/obfuscator/compactor tools that are commonly used in
> some tool chains (e.g., proguard w/Android), will need to be instructed to
> preserve these annotations.
> On Tue, Jan 17, 2012 at 11:36 AM, Brian Goetz wrote:
>> Having the VM automagically figure this out would be great, but it seems a
>> cheaper / faster-to-market solution to give developers the ability to detect
>> false sharing during development and testing and on the basis of such
>> observations give padding hints (say, with annotations) that the VM could
>> use or ignore as it saw fit.  False sharing will happen with a relatively
>> few concurrent building blocks (like, say, Exchanger) and maintainers of
>> such classes are probably (willing to be) on the lookout for it anyway.
>> On 1/17/2012 1:33 PM, Nathan Reynolds wrote:
>>> If an application is contending on a cache line, then the processors
>>> will look 100% busy but very little work will get done. Fixing the
>>> contention will almost always get huge gains.
>>> Let's say the contention is due to 2 objects being next to each other.
>>> The solution is to separate them by moving 1 object to another place in
>>> the heap. Moving an object in the heap is fairly cheap. GC does it a lot!
>>> Let's say the contention is due to 2 fields being next to each other.
>>> The solution is to separate them by rearranging the fields. This is
>>> probably expensive. Once that is done, the contention will go away but
>>> the memory will increase. Very few locks actually contend. Even fewer
>>> fields contend on cache lines. So, the memory impact should be fairly
>>> small and probably insignificant.
>>> 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 11:03 AM, Vitaly Davidovich wrote:
>>>> 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 <mailto: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
>>>>    <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
>>>>    Consulting Member of Technical Staff | 602.333.9091
>>>> <tel:602.333.9091>
>>>>    Oracle PSR Engineering <http://psr.us.oracle.com/> | 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>
>>>>>  <mailto: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  <tel: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>
>>>>>>  <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
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list