[concurrency-interest] The very best CAS loop

Vitaly Davidovich vitalyd at gmail.com
Wed Sep 28 21:26:03 EDT 2016


On Wednesday, September 28, 2016, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

>
> > On 28 Sep 2016, at 06:08, Andrew Haley <aph at redhat.com <javascript:;>>
> wrote:
> >
> > I did a few experiments, with simpler code.
> >
> > The version with the direct byte buffer was not very efficient: it
> > does many reads of memory unrelated to the actual thing we're trying
> > to test.  This is a shame, given that one of the goals of JEP 193 is
> > that the API should be at least as good as Unsafe.  Right now we'e a
> > long way from that goal.
> >
>
> 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".  .NET is a
close analog of a managed safe runtime, and it has it.  Perhaps something
needs to be available for those cases? Unsafe has kind of been it thus far.

>
> Project Panama is likely to run into similar challenges with it’s Pointer
> and (Bounded)MemoryRegion.
>
> Paul.
>


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


More information about the Concurrency-interest mailing list