JDK-8161367 : Reconsider global mark stack sizing policy
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-07-14
  • Updated: 2019-02-11
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8151996 - Revise mark stack memory management in CMMarkstack
Description
Currently, when the global mark stack overflows we double its capacity. Consider less aggressive sizing options (like incrementing by 20% each time).
Comments
Just a note: with JDK-8057003 the maximum stack size will drop considerably (i.e. by magnitudes sometimes), as arrays of references will basically not be copied on the mark stacks any more.
14-07-2016
Growing by doubling without some expectation of the size needed for a task seems too aggressive. The marking stack size is an example of that. When a marking stack overflows the needed size can as easily be 1 more entry as twice as many new entries. I agree that expanding the marking stack has a cost so expanding by 1 does not make sense but having the default be expand by 20% might be a good policy. The 20% is just a number I picked. I don't have any policy in mind. A second reason to be less aggressive about growth is that growth is sometimes a response to a spike in activity (never or seldom to be seen again) and I don't think we shrink back the marking stack.
14-07-2016