Keep track of per-cycle mutator/collector allocs. Fix mutator/collector alloc region overlap in traversal.

[Roman Kennke]

Am 16.03.2018 um 22:20 schrieb Roman Kennke:
> Am 16.03.2018 um 12:06 schrieb Aleksey Shipilev:
>> On 03/16/2018 11:45 AM, Roman Kennke wrote:
>>> I can give your proposal a try, but I must admit that I don't fully understand it. 
>>
>> Fine then, push your fix, then we can work it into freeset mechanics.
>>
>>> You propose to essentially have 2 separate disjoint freesets, one for collector, and one for
>>> mutator allocs.
>> This is not about splitting the freeset, this is about maintaining two bitmap views within the
>> freeset. There is no "transfer" involved: free set gets all the regions, but treats them differently
>> in during the selection. E.g. you have 10 regions, mutator bitmap says {1, 2, 3, 4, 5} are available
>> for mutator allocations, {6, 7, 8, 9, 10} are available for GC allocs.
>>
>>> By which measure would you divide free regions? 50/50? Or based on cset live size plus some
>>> wiggle-room? 
>>
>> I would say this is the question for evac-reserve work. With borrowing scheme, we can make it
>> mutator/gc = 100/0 split, and rely on borrowing to get GC its allocations.
>>
>>> And when one is depleted, you'd transfer regions from one to the other set (which
>>> sounds like adding complexity...)
>>
>>  case _alloc_tlab:
>>  case _alloc_shared:
>>    for (mutator-bitmap):
>>      if (try_allocate(...)):
>>        return result;
>>
>>    // add here when evac-reserve arrives
>>    if (ShenandoahEvacReserve):
>>      // sorry, cannot borrow from GC at all
>>      return NULL;
>>
>>    // or steal empty region from GC
>>    for (gc-bitmap):
>>      if (is_empty() && try_allocate(...)):
>>        unmark(region, gc-bitmap);
>>        mark(region, mutator-bitmap);
>>        return result;
>>
>>    // or mix in into non-empty region from GC
>>    if (ShenandoahAllowMixedAllocs):
>>      for (gc-bitmap):
>>        if (try_allocate(...)):
>>          return result;
>>
>>    return NULL;
>>
> 
> Ok, I bite the bullet and implement that scheme:
> http://cr.openjdk.java.net/~rkennke/traversal-alloc-region/webrev.04/
> 
> It starts out with 100%mutator/0%collector regions, and then steals from
> the other set if depleted.
> 
> Please review carefully. I am not sure I've always got the index
> bookkeeping correct.
> 
> It passes hotspot_gc_shenandoah tests.

Ping?

Roman