The reason we need the second "complete" bitmap is that after class unloading (at Remark at this time) there will be objects that are not parseable in the old gen heap. We could make the heap parseable again by stuffing integer arrays into these places.

Previously we thought that iterating over the heap was too expensive to do, so g1 uses two bitmaps, the "prev" bitmap that contains current data, the "next" bitmap containing data for after completion of the marking, which are swapped at some point.

However, due to rebuild remset during concurrent cycle we already walk the heap.

So it might be useful to try this out: it would probably improve gc pause times (and refinement) too as then we would not need to ask the bitmap for liveness..

Implement and evaluate performance impact.

Advantages:
1.5% of Java heap memory saved
potential speedups during scanning cards (refinement, during GC)

Disadvantages:
additional concurrent BOT update
lengthens concurrent cycle