Customer observes with pmap, the C-heap is growing slowly.

We got them to apply the libumem for memory leak detection and found the leak.
Posted Date : 2008-03-17 08:49:20.0

N/A

The first problem is ChunkTaskQueueWithOverflow (CTQWO) in taskqueue.cpp.  The initialize() method allocates a growable array for the _overflow_stack from the c heap that is never freed.  CTQWO doesn't include a destructor or other method to do cleanup.  

The CTQWO is allocated by the ParCompactionManager constructor (psCompactionManager.cpp). The second problem is that the ParCompactionManager destructor doesn't delete or cleanup the CTQWO allocated by the ctor.  ParCompactionManager was cloned from PSPromotionManager, which assumes all instances live for the lifetime of the JVM.

There is one instance of ParCompactionManager allocated during each full gc--the "serial_CM" which is used primarily for compaction of the perm gen.
Posted Date : 2008-04-09 06:25:31.0

The items described in the previous entry are problems, but they are not the source of the noticeable leak.  The real leak is because GCTaskThreads fail to release memory allocated in the ResourceArea.  The threads all have ResourceMarks in place, but the scope of the ResourceMarks within the GCTaskThread::run method is never exited.  The parallel compaction code is missing a call to GCTaskManager::release_all_resources(), which informs the GCTaskThreads to release resources.  In parallel scavenge, this is called during gc setup.
Posted Date : 2008-05-06 01:07:23.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/05712c37c828
Posted Date : 2008-06-21 07:39:45.0