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

Kim Barrett kim.barrett at oracle.com
Mon Nov 24 15:13:31 UTC 2014

On Nov 23, 2014, at 10:08 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> On Nov 21, 2014, at 3:44 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 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.]
> Except I’ve now been reminded that ParNew doesn’t get used with ParallelOld.
> In fact, several combinations of old/new collectors were deprecated in jdk8 and
> are slated to be removed in jdk9 (some already have), and it looks like ParNew
> will only remain in conjunction with CMS, making the split of ParNew’s
> copy_to_survivor_space into two variants no longer needed, and one of them
> redundant, making this wrapper vs comment duplication vs whatever issue moot.

To be clear, what I'm suggesting is that, in light of the deprecation
and expected removal of some combinations with ParNew, only
copy_to_survivor_space_avoiding_promotion_undo() really needs the
proposed change, and copy_to_survivor_space_with_undo() could be left

More information about the hotspot-gc-dev mailing list