RFC/RFR: Get rid of second bitmap

[Roman Kennke]

As Aleksey mentioned and we discussed, there shouldn't really be a need 
for a 2nd bitmap in Shenandoah.

I made an experiment and looked around the code, and we already seem to 
be doing the right thing to avoid the worst known problem, that is to 
attempt to iterate over heap regions with unreachable objects that have 
dangling Klass* in them from previously unloaded classes.

This patch throws away bitmap#2 and renames the renaming bitmap to just 
'mark_bitmap', and also changes all related code (e.g. TAMS) accodingly. 
I added a flag to indicate whether or not the marking bitmap should be 
considered valid, and an assert in front of marked_object_iterate() to 
check that flag.

This passes specjvm with -f 0 and with some aggressive settings: 
-XX:ShenandoahUnloadCandoahRefProcFrequency=1 
-XX:ShenandoahFullGCThreshold=0

It also passes hotspot_gc_test without problems.

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.

http://cr.openjdk.java.net/~rkennke/onebitmap/webrev.00/ 
<http://cr.openjdk.java.net/%7Erkennke/onebitmap/webrev.00/>

Please let me know what you think. Give it a spin and test the guts out 
of it.

Roman