[concurrency-interest] padding in Exchanger
Joe Bowbeer
joe.bowbeer at gmail.com
Tue Jan 17 18:35:11 EST 2012
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<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@**oracle.com<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<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@**oracle.com<nathan.reynolds at oracle.com>>
>>>> <mailto:nathan.reynolds@**oracle.com <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
>>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120117/d94626dc/attachment-0001.html>
More information about the Concurrency-interest
mailing list