When we cannot do a GC because is GC locker is active, the general approach is to do allocations in the old generation (via the slow allocation path) until all the threads drain from the GC locker and a GC locker-induced GC is scheduled.

In G1, the GC locker is supposed to be the only cause of direct allocations into the old generation (there are currently some bugs that can invalidate this assumption; the fix for 6974966 will eliminate those cases). If we avoid doing direct-to-old allocations alltogether would simplify the code quite a lot. So, instead of direct-to-old allocations we are going to do something different. When the eden is ful, but a GC attempt fails due to the GC locker being active, what we'll do is we'll extend the eden further while we are waiting for the threads in the critical section to drain out of the GC locker and the GC locker to schedule a GC.

There will be a (user-settable) upper bound on how much the eden can grow over its intended size (so that it does not grow out of control). If we reach that, threads that want to allocate will stall until the GC locker-induced GC completes. Hopefully, this will be very rare. Most of the time, we'll only need to extend the eden by a region or two as the GC locker critical sections tend to be reasonable short.

Notice that this should be an improvement on what other GCs do today, which is to take the slow allocation path to allocate every object into the old generation. By extending the eden G1 will be able to support TLAB allocations while the GC locker is active which should have no overhead on the application threads.