JDK-7011855 : G1: non-product flag to artificially grow the heap
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs20
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-01-12
  • Updated: 2013-09-18
  • Resolved: 2011-05-10
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 7 Other
7Fixed hs21Fixed
Description
It will be very helpful to have a non-product flag in G1 that artificially allocates regions in the heap to increase the rate at which the used space in the heap grows. This will increase the frequency of marking cycles as well as cleanup opererations and will allow us to stress test that code when we need to.

We could use specially written tests which fill up the heap quickly to achieve the same effect. But this feature will be generally more helpful as it will do the same while running any application in order to generate different loads on the marking cycle (mutation patterns, object graph shapes, etc.) and stress it in different ways.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/49a67202bc67
05-05-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/49a67202bc67
20-04-2011
SUGGESTED FIX I'll introduce a develop parameter call G1DummyRegionsPerGC which specifies how many dummy regions will be allocated at the end of each GC. I use GCs here as a way to get a regular "callback" to perform the dummy region allocations. An alternative would have been to introduce a special thread that regularly issues allocation requests but that'd probably be overkill. Another alternative might be for the parameter to be an Growth Rate (e.g., MBs/sec) and at the end of each GC to allocate enough regions to meet that rate if necessary (it might be that the application is already growing the heap at the desired rate).
12-01-2011