RFC: One marking bitmap

[Aleksey Shipilev]

Hi,

I am trying to understand why do we need two marking bitmaps. "Next" bitmap is built during
concurrent mark, and then gets swapped for the "complete" one at the end of concurrent mark. After
that, all users poll "complete" bitmap for the actual data. But, there seem to be no users that need
to do that when concmark is running, or they can poll "next" bitmap too!

There are two problematic points I see:
 a) with single bitmap, concurrent mark cannot be abandoned without additional action, because
marking bitmaps may be incomplete on abort. But in our code, aborted concurrent mark leads either to
degenerate final mark, or to full GC, where we finish building the bitmaps again;
 b) with single bitmap, we need to clean the bitmaps *before* the init mark, and that means before
setting TAMS -- which means is_marked() is unreliable in that time window. That seems not to be a
problem, since nothing polls marked data when the concurrent cycle is initiated;

This experimental patch cuts out one bitmap, and thus trims down our native footprint ~2x:
  http://cr.openjdk.java.net/~shade/shenandoah/wip-one-bitmap/webrev.01/
 (passes hotspot_gc_shenandoah)

Thoughts? What do I miss?

Thanks,
-Aleksey