RFC/RFR: Get rid of second bitmap

[Roman Kennke]

Am 06.10.2017 um 10:03 schrieb 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?
Right. I have actually seen partial GC failing on this.
>   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
Nice, thank you!! I am testing it now.
Roman