RFR: JDK-8061259: ParNew promotion failed is serialized on a lock
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