RFR: JDK-8061259: ParNew promotion failed is serialized on a lock

[Kim Barrett]

On Nov 20, 2014, at 9:27 PM, Jungwoo Ha <jwha at google.com> wrote:
> If we are to put a wrapper around, why not just go with the original change?
> I don't see adding a single field on a nearly singleton class is a bad thing.
> The changes are well wrapped inside par_promote.

There are multiple implementations of par_promote, for different
old-space collectors.  (par_promote is a virtual function.)  At least
some of the others may have similar issues (for example, at a quick
look, ParallelOld appears to have a similar locking structure), and it
seems like all could benefit from this short-circuiting.

[One of the copy_to_survivor_space_XXX functions (the callers of
par_promote) is used exclusively when CMS is the old-space collector,
the other is used for other old-space collectors.]

> It is the fast path of the promotion, so I think it is more readable.
> We don't need a long explanation to the code reader why we are allowing the data-race.

Any intentional data race needs to have an explanation.