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.
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.
- relates to
-
JDK-5093520 objects being kept alive in perm gen and old gen when debugger attached
- Resolved
-
JDK-6319671 CMS should use Heap_lock for protecting heap resizing, instead of CMS token
- Resolved
-
JDK-6319688 Incorrect locking in CMSPermGen::mem_allocate()
- Resolved
-
JDK-6263371 SEGV in MarkFromRootsClosure::scanOopsInOop
- Closed