[concurrency-interest] The very best CAS loop

Vitaly Davidovich vitalyd at gmail.com
Thu Sep 29 09:53:54 EDT 2016


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.

>
> Andrew.
>


-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160929/c407289e/attachment.html>


More information about the Concurrency-interest mailing list