RFC/RFR: Get rid of second bitmap

[Roman Kennke]

Am 10.10.2017 um 13:16 schrieb Aleksey Shipilev:
> On 10/10/2017 11:20 AM, Roman Kennke wrote:
>> http://cr.openjdk.java.net/~rkennke/onebitmap/webrev.04/
>   *) No, we don't now (happens twice in the patch):
>
>   1371     log_warning(gc)("Hold my beer, we are about to crash this VM.");
;-) (Removed in updated patch)

>   *) So, previous version of ShenandoahHeap::safe_object_iterate used to fix up the fields in
> reported objects. This new version does not seem to do that, and I think that is a deal-breaker: we
> cannot really report from-space oops in the fields, because users would not expect the need to
> perform RBs on them?
We do RB whenever we follow through a ref in the new impl. All users 
*inside* the JVM are expected to do appropriate barriers if they ever 
access an object field or such (e.g. through oopDesc accessors). Users 
*outside* the JVM (i.e. JVMTI consumers) don't get to see the internals. 
They only get APIs which do the correct barriers. I see nothing to worry 
about here, and we certainly don't need to fix up any refs as we go. (In 
fact, my plan was to not touch/change/depend-on *anything* in this 
implementation, no roots, no heap, no auxiliary data structures).
>   *) I think the JVMTI test should construct the object graph, and verify that the same number o
> objects is returned, regardless of the GC phase we are currently in. Actually touching the oop
> fields would be the plus, to verify that thing from above.
Ok, I extended the test to create 5 test objects, stick them in a 
thread-local array, and have the heapdump count those objects and verify 
we get 5. Test passes.

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

Good now?