CRR (M/L - re-opened): 7039627: G1: avoid BOT updates for survivor allocations and dirty survivor regions incrementally

[Tony Printezis]

Hi,

Latest workspace after merging with the last few changesets that we've 
pushed recently:

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

(if you started looking at the first version you don't need to switch to 
this one, the contents should be mostly the same)

Tony

Tony Printezis wrote:
> Hi,
>
> I'd like to re-open this for code review. I brought the workspace 
> up-to-date. Here's the webrev:
>
> http://cr.openjdk.java.net/~tonyp/7039627/webrev.0/
>
> Still need a couple of code review pretty please. :-)
>
> Tony
>
> Tony Printezis wrote:
>> 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
>>
>>
>