A number of tests related to class loading fails with the OOME "PermGen space", but heap exhaustion isn't observed(-XX:+PrintHeapAtGC is used). Failing tests perform intensive class loading for a quite a long time.
Here is the sample GC debug output just before the OOM occured:
{Heap before GC invocations=1405 (full 369):
PSYoungGen total 175232K, used 63501K [0xf1400000, 0xfc000000, 0xfc000000)
eden space 174336K, 36% used [0xf1400000,0xf517abf0,0xfbe40000)
from space 896K, 61% used [0xfbe40000,0xfbec8b20,0xfbf20000)
to space 896K, 0% used [0xfbf20000,0xfbf20000,0xfc000000)
PSOldGen total 352256K, used 911K [0xdbc00000, 0xf1400000, 0xf1400000)
object space 352256K, 0% used [0xdbc00000,0xdbce3c60,0xf1400000)
PSPermGen total 65536K, used 65534K [0xd7c00000, 0xdbc00000, 0xdbc00000)
object space 65536K, 99% used [0xd7c00000,0xdbbff8f8,0xdbc00000)
Heap after GC invocations=1405 (full 369):
PSYoungGen total 175232K, used 648K [0xf1400000, 0xfc000000, 0xfc000000)
eden space 174336K, 0% used [0xf1400000,0xf1400000,0xfbe40000)
from space 896K, 72% used [0xfbf20000,0xfbfc2088,0xfc000000)
to space 896K, 0% used [0xfbe40000,0xfbe40000,0xfbf20000)
PSOldGen total 352256K, used 911K [0xdbc00000, 0xf1400000, 0xf1400000)
object space 352256K, 0% used [0xdbc00000,0xdbce3c60,0xf1400000)
PSPermGen total 65536K, used 65534K [0xd7c00000, 0xdbc00000, 0xdbc00000)
object space 65536K, 99% used [0xd7c00000,0xdbbff8f8,0xdbc00000)
}
{Heap before GC invocations=1406 (full 370):
PSYoungGen total 175232K, used 648K [0xf1400000, 0xfc000000, 0xfc000000)
eden space 174336K, 0% used [0xf1400000,0xf1400000,0xfbe40000)
from space 896K, 72% used [0xfbf20000,0xfbfc2088,0xfc000000)
to space 896K, 0% used [0xfbe40000,0xfbe40000,0xfbf20000)
PSOldGen total 352256K, used 911K [0xdbc00000, 0xf1400000, 0xf1400000)
object space 352256K, 0% used [0xdbc00000,0xdbce3c60,0xf1400000)
PSPermGen total 65536K, used 65534K [0xd7c00000, 0xdbc00000, 0xdbc00000)
object space 65536K, 99% used [0xd7c00000,0xdbbff8f8,0xdbc00000)
Heap after GC invocations=1406 (full 370):
PSYoungGen total 175232K, used 0K [0xf1400000, 0xfc000000, 0xfc000000)
eden space 174336K, 0% used [0xf1400000,0xf1400000,0xfbe40000)
from space 896K, 0% used [0xfbf20000,0xfbf20000,0xfc000000)
to space 896K, 0% used [0xfbe40000,0xfbe40000,0xfbf20000)
PSOldGen total 352256K, used 1074K [0xdbc00000, 0xf1400000, 0xf1400000)
object space 352256K, 0% used [0xdbc00000,0xdbd0cac0,0xf1400000)
PSPermGen total 65536K, used 5142K [0xd7c00000, 0xdbc00000, 0xdbc00000)
object space 65536K, 7% used [0xd7c00000,0xd8105ac0,0xdbc00000)
}
{Heap before GC invocations=1407 (full 370):
PSYoungGen total 175232K, used 0K [0xf1400000, 0xfc000000, 0xfc000000)
eden space 174336K, 0% used [0xf1400000,0xf1400000,0xfbe40000)
from space 896K, 0% used [0xfbf20000,0xfbf20000,0xfc000000)
to space 896K, 0% used [0xfbe40000,0xfbe40000,0xfbf20000)
PSOldGen total 352256K, used 1074K [0xdbc00000, 0xf1400000, 0xf1400000)
object space 352256K, 0% used [0xdbc00000,0xdbd0cac0,0xf1400000)
PSPermGen total 65536K, used 5160K [0xd7c00000, 0xdbc00000, 0xdbc00000)
object space 65536K, 7% used [0xd7c00000,0xd810a220,0xdbc00000)
Heap after GC invocations=1407 (full 370):
PSYoungGen total 174400K, used 0K [0xf1400000, 0xfc000000, 0xfc000000)
eden space 174336K, 0% used [0xf1400000,0xf1400000,0xfbe40000)
from space 64K, 0% used [0xfbe40000,0xfbe40000,0xfbe50000)
to space 960K, 0% used [0xfbf10000,0xfbf10000,0xfc000000)
PSOldGen total 352256K, used 1074K [0xdbc00000, 0xf1400000, 0xf1400000)
object space 352256K, 0% used [0xdbc00000,0xdbd0cac0,0xf1400000)
PSPermGen total 65536K, used 5160K [0xd7c00000, 0xdbc00000, 0xdbc00000)
object space 65536K, 7% used [0xd7c00000,0xd810a220,0xdbc00000)
}
The bug is very similar to the CR 6417036 (fixed in b91), but -XX:-UseSplitVerifier doesn't help in banishing this leak. So I suppose the origins are different.
The tests start to fail since b99.
How to reproduce:
1. Go to /net/vmsqe-amd-01.russia/export2/homes/vi158347/OOME_In_PermGen
2. Specify tested JDK in JAVA_HOME environment variable
3. Run reproduce.sh
Optional:
additional JVM flags can be passed through EXT_FLAGS variable
Affected tests:
runtime/ParallelClassLoading/mixed/combine/forName/mixed_2
runtime/ParallelClassLoading/mixed/combine/forName/mixed_3
runtime/ParallelClassLoading/mixed/combine/forName/mixed_4
runtime/ParallelClassLoading/mixed/combine/forName/mixed_5
runtime/ParallelClassLoading/mixed/combine/forName/mixed_6
runtime/ParallelClassLoading/mixed/combine/forName/mixed_7
runtime/ParallelClassLoading/mixed/combine/forName/mixed_8
runtime/ParallelClassLoading/mixed/combine/forName/mixed_9
runtime/ParallelClassLoading/mixed/combine/forName/mixed_10
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_2
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_3
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_4
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_5
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_6
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_7
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_8
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_9
runtime/ParallelClassLoading/mixed/combine/loadClass/mixed_10
runtime/ParallelClassLoading/delegate-system/dynamic-init/anonymous-complex
runtime/ParallelClassLoading/stress/holdLock/loadClass/dynamic-init/abstract
runtime/ParallelClassLoading/stress-redefine/holdLock/loadClass/anonymous-simple