RFC/RFR: Get rid of second bitmap

[Aleksey Shipilev]

On 10/06/2017 02:27 PM, Roman Kennke wrote:
> AFAICT, The whole problem boils down to ShenandoahHeap::object_iterate() and related *public*
> methods being problematic when called at random times, in particular when the marking bitmap is not
> valid (e.g. marking aborted, bitmap just clearing/cleared, marking in progress).

Yes, exactly.

> We could help it by squeezing in a marking pass before doing the iteration. However, if we do this,
> we can just as well report the visited objects to the ObjectClosure while traversing. It shouldn't
> matter for consumers of object_iterate() in which order the objects arrive, right?

The object order should not matter.

> E.g. we can make all those methods do a safe 'iteration' by doing a single-threaded marking pass,
> reporting objects while we go, using a single work stack, and using 2nd marking bitmap (to avoid
> double-visiting objects) that we can allocate just for this purpose and deallocate when done (after
> all, this should be a rare situation which is not performance-critical). Right? 

Yes, that makes sense. So this just makes another traversal through the heap, returning all
reachable objects. Yes, Verifier does that already, and it does not take much of the code. The
trouble with this approach is that we would need to test it separately, because it will exercise the
non-usual code path.

Heap dump on OOME can also fail, because we would try to commit some native memory for bitmap at
that point.

> I am assuming that all consumers would call object_iterate() during a safepoint (need to check
> this, but I'm pretty sure this is the case). We'd also need to ensure that we don't call those
> iterations ourselves from inside Shenandoah, unless we really want to (e.g. verification?). And
> provide the fast iteration - marked_object_iterate() - to use ourselves when we know that it is
> safe.

Verification uses neither object_iterate(), nor marked_object_iterate(), because it takes things
slowly, carefully, and on its own :)

-Aleksey