JDK-6672778 : G1 should trim task queues more aggressively during evacuation pauses
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-07
  • Updated: 2021-07-29
  • Resolved: 2018-04-27
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 11
11 b12Fixed
Related Reports
Relates :  
JDK-8201313 - Times of sub-phases of ext root scan may be larger than the sum of individual timings
Relates :  
JDK-8204287 - Phase timings not updated correctly after JDK-6672778
Relates :  
JDK-8224759 - Investigate block splitting during heap root scan
Relates :  
JDK-8027547 - G1 should not push already forwarded objects into the object task queue but special case them
Relates :  
JDK-8230706 - Waiting on completion of strong nmethod processing causes long pause times with G1
Description
During the work for 6622424, we took a decision to only trim the task queues after we've finished all root scanning, instead of more aggressively as it was done before. Just in case this causes performance problems (due to excessive overflows), we might want to revisit this approach. Opening this CR to track this.
Comments
Pause times with a suggested change improve across the board, depending on how much task queue activity there is. Most impacted are obviously large non-generational applications where G1 copies a lot. Seeing halved total pause times.
05-04-2018
The suspicion is correct, evacuation performance is significantly negatively impacted by first collecting references and only later processing them. The cause is not excessive overflows though, it also increases memory usage/traffic (due to very large buffers), and useless prefetches (G1 prefetches basically every reference it pushes on the stacks, and so potentially prefetches millions of addresses).
05-04-2018
There is nothing confidential about this CR at this time, so opening it.
05-04-2018