CRR: 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally (L)

[Tony Printezis]

Hi,

This is the long-awaited :-) GC alloc region refactoring for G1 that 
I've been working on for a while now (in the background).

A lot of that allocation code during GC is very similar to the code that 
manages the mutator allocation regions so we might as well share it. We 
recently introduced the G1AllocRegion abstraction for mutator alloc 
regions. Now we're going to re-use it for GC alloc regions too (and 
remove a lot of replicated code in the process).

The webrev is here:

http://cr.openjdk.java.net/~tonyp/7039627/webrev.0/

(don't let the number of lines changed intimidate you; over 60% of them 
correspond to code that was removed)

Quick summary of the improvements:

- Removed most of the code that manages the GC alloc regions and 
replaced it with subclasses of  G1AllocRegion (one for survivor regions, 
the other for old regions). We now keep the two GC alloc regions 
separate (before they could point to the same physical region) as we 
have to handle them differently (do/don't do BOT updates, retire them 
differently, etc.) and we don't want to have to add checks everywhere.
- No BOT updates for survivor regions (the same way we do not need them 
for mutator allocation regions).
- The cards of survivor regions are now dirtied incrementally (the same 
way it's done for mutator allocation regions).
- We do not link the GC alloc regions into a list any more in order to 
do any post-GC cleanup on them at the end of the GC. Instead, any 
cleanup that needs to be done it's done as each region is retired. So we 
save the extra post-GC step.
- Apart from not linking the GC alloc regions, I also removed the 
"is_gc_alloc" flag as we do not need to check it any more (and this 
saves us having to reset the flag at the end of the GC, which helped in 
eliminating the post-GC cleanup step).
- The new code also fixes a subtle bug. In the old code, when a GC 
thread allocated a new region is allowed other threads to allocate out 
of it before attempting its allocation (the allocation that essentially 
caused the new region to be allocated). But, that allocation is not 
guaranteed to succeeded (given that other threads might have meanwhile 
filled up the region) and this was not handled correctly in the code. 
This would cause an unnecessary evacuation failure. The new code fixes 
this bug as this case is handled correctly in the G1AllocRegion class 
(the thread that allocates the region will first satisfy its own 
allocation request before allowing anybody else to allocate out of the 
new region).

I'd like a couple of reviews please. :-)

Tony