RFR: Locked allocation

[Zhengyu Gu]

Great job! It simplifies the logic a lot!

A few minor suggestions:

- ShenandoahFreeSet::clear()

    I only see one path to this method and it is from safepoint. so
    replacing fence with safepoint assertion should be appropriate.

- asserting on _heap_lock == 1 on code paths that are protected by the lock
   makes code more readable.

- Will this lock be hot? and you want to check safepoint during spinning?
   I wonder if it has impact on TTSP

Thanks,

-Zhengyu

On 12/14/2016 11:36 AM, Roman Kennke wrote:
> This patch throws out all the lockfree allocation madness, and
> implements a much simpler locked allocation. Since we can't easily use
> Mutex and friends, and also don't need most of their functionality
> (wait/notify, nesting, etc), I implemented a very simple (simple as in,
> can read-and-understand it in one glance) CAS based spin-lock. This is
> wrapped around the normal allocation path, the humongous allocation
> path and the heap growing path. It is not locking around the call to
> full-gc, as this involves other locks and as CHF says, there are
> alligators there ;-)
>
> This does immensely simplify ShenandoahFreeSet, especially the racy
> humongous allocation path. It does fix the bug that some people have
> encountered about used not consistent with capacity.
>
> I've tested it using gc-bench (no regression in allocation throughput),
> SPECjvm and jtreg tests. Looks all fine.
>
> When reviewing, please pay special attention to the lock in
> ShenandoahHeap::allocate_memory()!
>
> http://cr.openjdk.java.net/~rkennke/lockedalloc/webrev.00/
>
> Ok?
>
> Roman