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

[Roman Kennke]

Turns out I introduced a bug when extracting it from my traversal-degen
work. I made it such that the ShenandoahConcurrentThread (can we maybe
rename it to ShenandoahControlThread or something please?!) resets the
counters. However, this runs concurrently with Java allocs pre-cycle, so
it will be racy. This little change moves the resetting to the op_init_
phases, so that it happens during STW instead.

Differential:
http://cr.openjdk.java.net/~rkennke/traversal-alloc-region/webrev.01.diff/
Full patch:
http://cr.openjdk.java.net/~rkennke/traversal-alloc-region/webrev.01/

Ok?


> I developed this as part of degen implementation for Traversal GC, but
> it fixes a bug that exists independently, and does some infrastructure
> that might be useful elsewhere.
> 
> The bug I've see was this: in traversal GC, we need to distinguish
> between mutator-allocation-regions and collector-allocation-regions. The
> former will be treated implicitely live and marked, while the latter
> does not. Mutator and collector allocations are biased from different
> ends of the free set. Eventually, they will meet in the middle, at which
> point allocations from collector and mutator will mix up. This can have
> the weird effect that a region starts out as implicitely marked+live,
> them mutator allocs something, and suddenly all those new objects are
> not marked anymore. The reason why this hasn't blown up so far is that
> when mutator and collector allocs meet in the middle, the next thing
> that usually happens is OOM and full-GC which will fix everything up
> again. But there is a chance that allocations meet, but just so fit in,
> and then we'd be doomed.
> 
> The problem is much more pronounced with (upcoming) degenerated GC,
> because there's usually no full-GC to fix it up.
> 
> The way I solved it is to extend the tracking of allocation sizes to
> per-cycle allocations, and use that to keep allocations from mixing up.
> 
> http://cr.openjdk.java.net/~rkennke/traversal-alloc-region/webrev.00/
> 
> 
> Passes all tests.
> 
> Opinions? Ok to go?
> 
> Roman
>