As part of 6484965, the following behavior was observed:

During root scanning of an initial mark pause, an object A is successfully forwarded by thread 1; thread 1 then proceeded to copy A to A'.

At the same time thread 2 sees that A has been forwarded, checks to see if A' has been marked (it has not yet), and successfully sets the bit for A' in the next marking bitmap.

After thread 1 has finished copying object A -> A', it calls mark_forwardee which checks to see if A' has been marked and it has.

The issue is that while thread 1 is copying A -> A', there is a window where if thread 2 attempts to get the size of A', it could see an unitialized object.

This has an implication for the preferred solution for 6484965. In the preferred solution, when an object is marked, we obtain its size in order to add to the marked bytes total.

The solution is to refactor the marking code in the G1 copy closures so that the thread that successfully for forwards and copies A is also responsible for marking A'.