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

Kim Barrett kim.barrett at oracle.com
Fri Nov 21 20:44:06 UTC 2014

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.

More information about the hotspot-gc-dev mailing list