RFR: Refactor allocation failure and explicit GC handling

[Zhengyu Gu]

On 01/17/2018 03:32 AM, Aleksey Shipilev wrote:
> On 01/17/2018 03:45 AM, Zhengyu Gu wrote:
>> ShenandoahConcurrentThread::handle_alloc_failure() now takes monitor lock, and this method is in
>> ShenandoahHeap::allocate_memory() path, in turn, can be called inside write barrier ... seems to be
>> the scenario we talked before, that we *can not* do.
> 
> Note that allocate_memory on the *shared/TLAB* allocation path was taking a lock in the old code
> too: see the path in ShHeap::allocate_memory -> ShHeap::collect(_allocation_failure) ->
> ShConcThread::do_full_gc. The trick here is not to lock when shared_gc/GCLAB allocation fails, and
> this is why we have separate ::handle_alloc_failure_evac().

Ah, it is a bit hard to read, could you add some comments like:

ShenandoahHeap:
  726   if (type == _alloc_tlab || type == _alloc_shared) {
    ....
  } else {
     assert(type == _alloc_gclab || type == _alloc_shared_gc, ...");
     // OOM handled by ....
  }


Thanks,

-Zhengyu


> 
> Thanks,
> -Aleksey
>