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

[Tony Printezis]

PS Sorry, I should have said:

I did some before/after performance measurements. Here are the findings:

- intel : didn't see much change, even though collect/analyze did show 
that the number of cache misses / branch mispredictions during 
allocation went down dramatically in the new version.
- sparc (Niagara and non-Niagara) : I saw some modest GC time 
improvements with the new workspace (a few %).

Note that the allocation code that does BOT updates takes a lock. So, by 
decreasing the number of BOT updates we do will decrease a potential 
scalability bottleneck. This might be why I saw benefit on sparc : the 
sparc boxes had more HW parallelism than the intel box I ran on.

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