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

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

Thanks, Roman