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 :  
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.

Unnecessary after JDK-6672698.

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.

SUGGESTED FIX Disable ZapUnusedHeapArea by default, or scribble in parallel.

WORK AROUND Add the command-line option -XX:-ZapUnusedHeapArea. *** (#1 of 1): [ UNSAVED ] ###@###.###

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.