JDK-6325682 : VM lockup with -XX:+UseConcMarkSweepGC while loading classes with custom classloader
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-09-19
  • Updated: 2022-11-22
  • Resolved: 2005-09-28
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
6 b54Fixed
Related Reports
Relates :  
JDK-5093520 - objects being kept alive in perm gen and old gen when debugger attached
Relates :  
JDK-6263371 - SEGV in MarkFromRootsClosure::scanOopsInOop
Relates :  
JDK-6319688 - Incorrect locking in CMSPermGen::mem_allocate()
Relates :  
JDK-6319671 - CMS should use Heap_lock for protecting heap resizing, instead of CMS token
Description
While trying to develop a testcase for 5093520, I have come across a lock up which happens with -XX:+UseConcMarkSweepGC.

How to reproduce:
- unzip LoadUnloadGC2.zip to some directory
- javac -cp . gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java
  javac -cp . nsk/share/classload/TemplateClass.java
- java -XX:+UseConcMarkSweepGC -XX:+TraceClassLoading -XX:+TraceClassUnloading -XX:+PrintGCDetails -cp . gc.gctests.LoadUnloadGC2.LoadUnloadGC2

Run logs attached: dump_normal.log, pstack.log (pstack on locked up process).
Fastdebug version dumps core instead of locking up, logs attached: dump.log, hs_err_pid6835.log.

Without -XX:+UseConcMarkSweepGC, the test eventually OOMs, which is also a problem.
Comments
EVALUATION This bug has been fixed in Tiger U7b01 as well, as a result of the fixes needed for 6319688.
03-01-2006
WORK AROUND Increase perm size. However, for programs that have no bound on perm space allocation, there is no known workaround.
21-09-2005
EVALUATION See suggsted fix section.
20-09-2005
SUGGESTED FIX *** src/share/vm/memory/permGen.cpp- Fri Sep 9 10:59:38 2005 --- src/share/vm/memory/permGen.cpp Tue Sep 20 00:42:41 2005 *** 1,7 **** #ifdef USE_PRAGMA_IDENT_SRC ! #pragma ident "@(#)permGen.cpp 1.45 05/09/06 12:42:05 JVM" #endif /* * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ --- 1,7 ---- #ifdef USE_PRAGMA_IDENT_SRC ! #pragma ident "@(#)permGen.cpp 1.46 05/09/20 00:42:13 JVM" #endif /* * Copyright 2005 Sun Microsystems, Inc. All rights reserved. * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. */ *** 120,139 **** obj = _gen->expand_and_allocate(size, false, false); if (obj == NULL && _gen->capacity() == _gen->max_capacity()) { // We have reached the max capacity limit but have not been // able to satisfy the allocation request. Let's see if a // stop-world collection will free up enough space. ! SharedHeap::heap()->collect(GCCause::_permanent_generation_full); obj = _gen->allocate(size, false); if (obj == NULL && _gen->capacity() == _gen->max_capacity()) { // We have reached our maximum size, and have tried a // stop-world collection, but have not been able to allocate. // We now make a last-ditch collection attempt that will try // to reclaim as much space as possible. If even that does // not succeed in freeing space to accomodate the allocation // then we are truly out of space. ! SharedHeap::heap()->collect(GCCause::_last_ditch_collection); obj = _gen->allocate(size, false); if (_gen->capacity() == _gen->max_capacity()) { break; } // Else we can try expanding the heap again --- 120,139 ---- obj = _gen->expand_and_allocate(size, false, false); if (obj == NULL && _gen->capacity() == _gen->max_capacity()) { // We have reached the max capacity limit but have not been // able to satisfy the allocation request. Let's see if a // stop-world collection will free up enough space. ! SharedHeap::heap()->collect_locked(GCCause::_permanent_generation_full); obj = _gen->allocate(size, false); if (obj == NULL && _gen->capacity() == _gen->max_capacity()) { // We have reached our maximum size, and have tried a // stop-world collection, but have not been able to allocate. // We now make a last-ditch collection attempt that will try // to reclaim as much space as possible. If even that does // not succeed in freeing space to accomodate the allocation // then we are truly out of space. ! SharedHeap::heap()->collect_locked(GCCause::_last_ditch_collection); obj = _gen->allocate(size, false); if (_gen->capacity() == _gen->max_capacity()) { break; } // Else we can try expanding the heap again
20-09-2005