RFR: Locked allocation

[Zhengyu Gu]

>>   and you want to check safepoint during spinning?
> Nope. The whole point of this excerise was to avoid potentially
> safepointing (and thus requiring oopmap, debug-info, etc blah blah at
> write barriers) :-)

Yes, I forgot about safepointing problem.


-Zhengyu


>>     I wonder if it has impact on TTSP
> I doubt. gc-bench didn't show any such thing. In fact, it might be
> better than before now, at least when you've got threads racing to
> allocate humongous objects. The previous code was not even guaranteed
> to complete (could interleave claiming regions, never finding a
> contiguous block).
>
> Will come up with a patch later. Need food first. ;-)
>
> Roman
>
>> 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
>>