RFR: Locked allocation

[Andrew Haley]

On 15/12/16 11:31, Roman Kennke wrote:
> 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()!
> 
>> 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!

Please have a look at the way SpinPause() is defined!

Maybe it's worth looking at backoff after spinning for a while.  But
it's very hard to test for consistent behaviour under extreme
conditions.  Allocating very large objects is quite likely to
result in page faults, and therefore quite likely to cause a
thread to be descheduled.  On a heavily loaded system I would
expect long delays for page faults, while the lock is held.

I fear that it's very tempting to design Shenandoah so that it
behaves extremely well when it's not being "abused".

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

Sure, but I'm thinking about systems which are overloaded.  I don't
know if gc-bench would help there.

I presume that you have considered allocating humongous object outside
of Shenandoah's regions altogether.  But even mentioning such a thing
takes me way outside my area of expertise, so...

Andrew.