JDK-6423256 : GC stacks should use a better data structure
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6,6u6,6u14,6u20
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,linux_2.4,windows
  • CPU: generic,unknown,x86
  • Submitted: 2006-05-08
  • Updated: 2011-03-25
  • Resolved: 2011-03-25
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 6 JDK 7 Other
6u17-revFixed 7Fixed hs14.3Fixed
Related Reports
Duplicate :  
JDK-6405799 - JVM Exits with OutOfMemoryError for vm\utilities\growableArray.cpp
Relates :  
JDK-6942771 - SEGV in ParScanThreadState::take_from_overflow_stack
Relates :  
JDK-2191789 - SEGV in ParScanThreadState::take_from_overflow_stack
Relates :  
JDK-6988678 - fatal error deadlock handling was unintentionally disabled
Relates :  
JDK-6988210 - gc/gctests/ManyObjects VM crashes with growableArray.cpp. Out of swap space?
Relates :  
JDK-6935839 - excessive marking stack growth during full gcs
Relates :  
JDK-2200149 - SEGV in ParScanThreadState::take_from_overflow_stack
Description
The marking stack used by MarkSweep currently uses a GrowableArray<oop>.  That's overkill, since we only use the marking stack as a stack.  In contrast, GrowableArray implements an array, so when it expands, it reallocs and copies the whole array to a new, larger, piece of contiguous memory.  Since the marking stack is often large, this often requires a large contiguous chunk of memory, which can be difficult to acquire.  Since GrowableArray grows by doubling, on average 25% of the array will be empty.  When the marking stack is large, this can be a substantial waste of space.  

Instead, the stack could be implemented as a chained series of small regions.  This could allow us to balance the storage for the chain pointers  against the increment of growth, to use an appropriate amount of space in modest chunks.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/894b1d7c7e01
09-10-2010
EVALUATION http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/0c5c902506a0
08-10-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/894b1d7c7e01
29-09-2010
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/master/rev/c475b10a610b
17-04-2010
EVALUATION http://hg.openjdk.java.net/hsx/hsx17/baseline/rev/c475b10a610b
17-04-2010
EVALUATION Still more stack types that should be converted: the stacks used by parallel collectors to handle task queue overflows; promotion failure scan stacks, revisit klass stacks, revisit mdo stacks. Changing the synopsis to broaden the scope.
21-09-2009
EVALUATION The preserved_mark_stack and preserved_oop_stack used by mark sweep and CMS should also be converted to GrowableStacks (assuming they are used only as stacks). Scott Marlow of <company unknown> was testing the growable marking stacks fix and his JVM died when trying to allocate an 80MB preserved mark stack.
07-01-2009
EVALUATION Since the mark sweep algorithm is used as a backstop collector for many of our collectors (e.g., -XX:+UseParallelGC, -XX:+UseParNewGC, -XX:+UseConcMarkSweepGC) in addition to its obvious use with -XX:+UseSerialGC, this issue may be present in non-obvious places.
16-06-2006