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