In a recent discussion on a somewhat different topic with ###@###.###,
it was pointed out that not delaying the installation of the forwarding pointer
until a copy is completed may help speed up scavenges in the presence of large
objects. This would be especially true when working with large Eden and
survivor spaces; the idea is that larger objects may end up becoming more
popular the longer they are in the young gen, and then there is a possibility
of several workers spinning their wheels waiting for the forwarding pointer
to show up while one worker plods through the copying of the object before
installing the forwarding pointer in the old copy. Some restructuring of the
associated code/interfaces would be necessary to implement this, so this
may take a bit more time to do than it seems from the simple description
above (especially for some collectors).

In the case of CMS+ParNew things are as described above. From memory, in the
case of Tenured+ParNew or ParallelGC, two workers who "collide" on a large
object copy both do the copying and the winner intalls the pointer, so the
cost here is also an opportunity cost for the redundant copies rather than
stalled workers waiting for the forwarding pointer, which is arguably a
bit worse even. I suspect though that most workloads / application codes
we have tested will not have stressed this aspect, so it is possible that
this theoretical concern turns out not to be a concern in practice. Nonetheless,
fixing it (if the resulting code restructuring is not too onerous, a topic
that i have not investigated as of this bug filing) might be good in the
sense that it files off another sharp performance corner (or pathology,
if you prefer a medical metaphor to one from carpentry).

I'll mark this jdk 7 because i do not know if anyone has the cycles to take this on
at the moment, but feel free to claim and modify (pun intended :-).