RFC/RFR: Get rid of second bitmap

[Aleksey Shipilev]

On 10/05/2017 09:15 PM, Roman Kennke wrote:
> There are known problems left. JVMTI might ask for a heapdump or heap traversal after marking has
> been aborted and we don't have a valid bitmap to support heap scanning. This should now blow up
> early with the above mentioned assert. We shall tackle this problem later IMO.

I think we have to solve this before pushing. Because it may end up messy without the second bitmap,
and we would have to revert the whole thing.

> http://cr.openjdk.java.net/~rkennke/onebitmap/webrev.00/

*) I think the major thing here is that resetting the bitmap _after_ the concurrent cycle exposes
future users to thinking that nothing is alive below the TAMS. For example, subsequent *partial*
cycle would trigger this, right? My recent patch moved the bitmap cleanup before the init mark
because of this. In any case, giving up the marking bitmap just because the cycle is over seems
giving up data that might be used later.

This, and other touchups to the patch (some of these are things from my first experimental patch):
  http://cr.openjdk.java.net/~shade/shenandoah/one-bitmap-shade-review.patch

-Aleksey