It appears as though a large number of ParallelClassLoading tests fail
routinely (in some configurations, see below) with the following error:-

[2010-12-31T03:24:40.34] java.lang.NoClassDefFoundError exception is caught in "Loading Thread #1": custom/A4
[2010-12-31T03:24:40.34] java.lang.NoClassDefFoundError: custom/A4
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.defineClass1(Native Method)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.defineClass(ClassLoader.java:786)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.defineClass(ClassLoader.java:628)
[2010-12-31T03:24:40.34] at runtime.ParallelClassLoading.shared.SecureClassLoaderController$CustomSecureClassLoader.findClass(SecureClassLoaderController.java:64)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.loadClass(ClassLoader.java:422)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.loadClass(ClassLoader.java:355)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.defineClass1(Native Method)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.defineClass(ClassLoader.java:786)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.defineClass(ClassLoader.java:628)
[2010-12-31T03:24:40.34] at runtime.ParallelClassLoading.shared.SecureClassLoaderController$CustomSecureClassLoader.findClass(SecureClassLoaderController.java:64)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.loadClass(ClassLoader.java:422)
[2010-12-31T03:24:40.34] at java.lang.ClassLoader.loadClass(ClassLoader.java:355)
[2010-12-31T03:24:40.34] at custom.C.<clinit>(C.java:13)
[2010-12-31T03:24:40.34] at java.lang.Class.forName0(Native Method)
[2010-12-31T03:24:40.34] at java.lang.Class.forName(Class.java:264)
[2010-12-31T03:24:40.34] at runtime.ParallelClassLoading.shared.ProvokeType.provoke(ProvokeType.java:85)
[2010-12-31T03:24:40.34] at runtime.ParallelClassLoading.shared.ProvokeType.provoke(ProvokeType.java:132)
[2010-12-31T03:24:40.34] at runtime.ParallelClassLoading.shared.ClassLoadingThread.run(ClassLoadingThread.java:81)
[2010-12-31T03:24:40.34] Caused by: java.lang.ClassNotFoundException: custom.A4
[2010-12-31T03:24:40.34] at runtime.ParallelClassLoading.shared.SecureClassLoaderController$CustomSecureClassLoader.findClass(SecureClassLoaderController.java:66)
[2010-12-31T03:24:40.35] at java.lang.ClassLoader.loadClass(ClassLoader.java:422)
[2010-12-31T03:24:40.35] at java.lang.ClassLoader.loadClass(ClassLoader.java:355)
[2010-12-31T03:24:40.35] ... 18 more


This appears to be the result of not specifying a sufficiently small old/perm heap size
so that no GC is required during the run for space for meta-data in the perm gen or
java object in the java heap. As a result, we never run Finalization which is needed to
close the file descriptors opened for class loading. This results in the process eventually
running out of file descriptors and failing with the stack retrace shown above.

A workaround is to specify a small -Xms and -Xmx for the heap and for the perm gen,
so as to force GC to happen sufficiently often to prevent the file descriptor exhaustion,
or to otherwise increase the file descriptor limit so that the test completes
without the need for finalization. The other possibility is to explicitly have the
test itself periodically call a manual gc and finalization so as to reap the
zombie file descriptors.

Of course this workaround would not be needed if there were some means for the
JVM to be informed when certain native resources were reaching their limits;
see CR/RFE 6293787, 4797189.
http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-12-29/Main_Baseline/vm/linux-amd64/server/mixed/linux-amd64_vm_server_mixed_vm.parallel_class_loading.testlist/analysis.html
This should be refiled for JDK 9 when that targeted release is available.
We should investigate notification mechanisms for resource limits (which will probably require new APIs for the java source code to register for and be owned by serviceability).