RFR: Locked allocation

[Zhengyu Gu]

On 12/14/2016 01:10 PM, Zhengyu Gu wrote:

> 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.

Or make _heap_lock an opaque object and store owner thread pointer, so
can have assertion like assert(owned_by_self() ...), at least for debug mode.

-Zhengyu

>
> - 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
>