What for Sun JVM creates instances of sun.reflect.DelegatingClassLoader at runtime?

Question

While analyzing a heap dump using jhat I have observed many instances of DelegatingClassLoader created although they were not called explicitly in code. I expect this to be some sort of reflection optimization mechanism. Does anybody know the details?

Answer 1

Yes, it is probably a reflection optimisation.

On the Sun JVM, reflective access to properties and methods is initially performed by calling through JNI into the JVM implementation. If the JVM notices that a method or field is being accessed by reflection a lot, it will generate bytecode to do the same thing -- a mechanism that it calls "inflation". This has an initial speed hit, but after that runs about 20 times faster. A big win if you do a lot of reflection.

That bytecode lives in classes created by DelegatingClassLoader instances. Keep an eye on it: those classes can put pressure on the permgen space and cause the dreaded "java.lang.OutOfMemoryError: PermGen space" failures. If it is a problem, you can turn inflation off by setting the system property sun.reflect.inflationThreshold to 0 (zero).

Answer 2

I don't see (at least for Hotspot), when looking at code

http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/reflect/ReflectionFactory.java.html

and

http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/reflect/NativeMethodAccessorImpl.java.html

that a setting of zero will turn off the feature. Seems to me only a large value for sun.reflect.inflationThreshold will do the job.