JDK-6672574 : parallel gc can no longer afford to scribble on memory with a single thread
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs11
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2008-03-07
  • Updated: 2014-04-08
  • Resolved: 2013-10-29
Related Reports
Relates :  
JDK-6672698 - mangle_unused_area() should not remangle the entire heap at each collection.
Description
The following is from a run of SPECjvm98 with a 64-bit fastdebug JVM (jdk7-b24) on a machine w/28G of RAM:

[GC [PSYoungGen: 28418K->480K(1888448K)] 30878K->2939K(2195648K), 23.4082886 secs] [Times: user=23.40 sys=0.04, real=23.41 secs]

23 secs is way too long to copy the 480K of data that survives in the young gen.
Comments
Unnecessary after JDK-6672698.
29-10-2013
Not sure how much of a problem this still is. It seems like the conclusion in the comments is that we can improve performance of debug and fastdebug builds by using multiple threads to mangle memory areas. This seems like an enhancement rather than a bug. Changing this issue to be an enhancement.
03-05-2013
SUGGESTED FIX Disable ZapUnusedHeapArea by default, or scribble in parallel.
07-03-2008
WORK AROUND Add the command-line option -XX:-ZapUnusedHeapArea. *** (#1 of 1): [ UNSAVED ] ###@###.###
07-03-2008
EVALUATION In debug and fastdebug builds, parallel gc writes a recognizable value (badHeapWord, 0xBAADBABE) onto unused portions of the heap to help detect errors. Unfortunately, it's done using a single thread. After the recent increase in default max heap size for the 64-bit VM, this can take a long time on hardware with lots of memory.
07-03-2008