[concurrency-interest] The very best CAS loop

Andrew Haley aph at redhat.com
Thu Sep 29 10:07:59 EDT 2016


On 29/09/16 14:53, Vitaly Davidovich wrote:
> On Thursday, September 29, 2016, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 29/09/16 02:26, Vitaly Davidovich wrote:
>>>
>>>     Alas, it’s tricky to do better while retaining safe access, there
>> are:
>>>
>>>     - bounds checks;
>>>     - read only checks;
>>>     - alignment checks; and
>>>     - that the buffer is effectively a box of the address (base &
>>>     offset, where base == null for off-heap).
>>>
>>>     When looping the checks can be hoisted, and unrolling should
>>>     result in efficient addressing. So, e.g. for plain access, a the
>>>     generated hot-loop is similar to that as if Unsafe was directly
>>>     used.
>>>
>>> So maybe we do need Unsafe after all? :) I mean it's fairly clear
>>> that safety checks can only be amortized when compiler is dealing
>>> with them in bulk - should work well for loops (assuming inlining
>>> doesn't fail), although OSR wouldn't I think.
>>>
>>> But what about non-loop cases or when compiler's compilation horizon
>>> doesn't see the loop? Other languages have unsafe escape hatches for
>>> when you really want to subvert the system because "you know
>>> better".
>>
>> Well, some do.  I'd argue that you need high-speed access to raw
>> memory in the cases when you have a lot of bulk data.  And in those
>> cases a skilled programmer can work with JVM to make sure that the
>> compiler gets what it needs to do a good job.
> 
> This argument leans heavily on the Sufficiently Smart Compiler fallacy.  In
> particular, "bulk data" or looping might be hidden from compiler's
> optimization horizon.

Perhaps, but if so I would argue that getting good performance out of
HotSpot for anything relies on the Sufficiently Smart Compiler
fallacy.

Andrew.


More information about the Concurrency-interest mailing list