RFR: Locked allocation

[Roman Kennke]

Am Donnerstag, den 15.12.2016, 10:15 +0000 schrieb Andrew Haley:
> On 14/12/16 16:36, Roman Kennke wrote:
> > When reviewing, please pay special attention to the lock in
> > ShenandoahHeap::allocate_memory()!
> 
> I'm always rather nervous about anybody who invents their own
> spinlocks.

Yeah, understandable. We are too, which is why we went to great efforts
to implement a lock-free allocatoin scheme a while ago. But it was
always buggy and very complex and hard to understand+debug. And
humongous allocation was inherently racy: how would you deal with
multiple regions in one go, without taking a lock, and while other
threads are taking regions from under your feet? The same goes for
expanding the heap.

And since we couldn't use Mutex (and don't need most of their
functionality), the next best way to do it was implement a small cas-
based spinlock.

Besides, we already have been doing it, for heap expansion, but now
it's better (using the right fences, etc). With my upcoming patch, it
will also provide a scoped locker, and additional checks, for our
sanity.


> I presume the idea here is that the native allocation is going to be
> fairly rare because threads will usually allocate inline from their
> own TLABs.

Yes.

>   However, please consider the situation where a thread
> holding the lock is descheduled.

Yes. We're doing a SpinPause() when spinning, this should get us back
to the thread holding the lock quickly. If you have an idea how to
improve this, let me know!

gc-bench provides a couple of tests that bash the allocation code with
multiple threads, and it did not find performance regressions or bugs.

Roman