JDK-8155257 : ParNew/CMS: Clean up promoted object tracking
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-04-27
  • Updated: 2016-05-26
  • Resolved: 2016-05-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b120Fixed
Related Reports
Relates :  
Description
This is a spin-off from JDK-6938732 to clean up when promoted object tracking should be enabled for the parallel workers (during the main ParNew parallel phase), when it should be disabled (during reference processing), and when the the promoted object lists should be torn down (each parallel worker should tear down its list after the termination protocol).

I'm copying some text from JDK-6938732 for some background on this:

Each parallel worker also has a PromotionInfo object with which it tracks all the objects it promotes during a GC. This seems a bit counter-intuitive given that the promotion list is not needed for a parallel worker to keep track of which objects it's copied (it has its taskqueue for that). There is, however, a subtle reason for this. When promoted objects are added to a PromotionInfo list they are also marked specially so that they can be differentiated from objects that were not promoted during the GC. This allows the card table scanning code to skip objects that were just promoted and happened to end up on a dirty card. So, the PromotionInfo lists are populated during the main ParNew parallel phase. But, how are they torn down given that they are not iterated over? Serially, after the main ParNew parallel phase is done (it has to be, they can only be torn down after all card table scanning is done) and the lists tearing down time is attributed to... *drum roll* reference processing! 
Comments
I'm seeing non-trivial ParNew time improvements with this fix when ParNew promotes a lot of objects and there are some Parallel GC threads available (as tearing down the promoted object lists is done in parallel and not serially which reduces its overhead). I'm expecting some further (but maybe minor) improvements from the fact that promoted objects are not tracked during reference processing (no extra overhead to add promoted objects to the lists and no extra overhead to tear down the lists again after reference processing is done).
27-04-2016

Summary of the fix: Enable promoted object tracking in the GC prologue, not in save marks. Each parallel worker collapses its own promoted object list after it exits the termination protocol and then disables promotion tracking
27-04-2016