RFR: Locked allocation

[Aleksey Shipilev]

On 12/15/2016 12:44 PM, Andrew Haley wrote:
> 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.

Generally true. But I think current change only covers the freelist/region
manipulation work, which should complete very quickly. The initialization (which
is the hard part of doing "new" on large Java objects) should and will happen
outside the spinlocked path.

Think about this as coarsening the current juggling-the-knives lock-free
mechanics with a spinlocked entry to the small critical section. We are not
expected to do any heavy-lifting while holding that lock. This minimizes the
need for sophisticated backoffs, etc. Pretty much how we don't usually think
about backoffs with lock-free update code :)

Thanks,
-Aleksey