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

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


-Aleksey