2011-06-28 11 views

Respuesta

17

Sí, probablemente sea una optimización de reflexión.

En Sun JVM, el acceso reflexivo a propiedades y métodos se realiza inicialmente llamando a través de JNI a la implementación de JVM. Si la JVM nota que un método o campo está siendo accedido por reflexión mucho, generará bytecode para hacer lo mismo, un mecanismo que llama "inflación". Esto tiene un golpe de velocidad inicial, pero después de eso se ejecuta unas 20 veces más rápido. Una gran victoria si reflexionas mucho.

Ese bytecode vive en las clases creadas por las instancias DelegatingClassLoader. Vigílalo: esas clases pueden ejercer presión sobre el espacio permgen y causar los temidos fallos "java.lang.OutOfMemoryError: PermGen space". Si es un problema, puede desactivar la inflación configurando la propiedad del sistema sun.reflect.inflationThreshold en 0 (cero).

+0

Advertencia, la propiedad funciona en Oracle/OpenJDK e IBM JDK; sin embargo, en IBM activa la inflación, en Sun se infla instantáneamente (se intentó usar -verbose: clase que devuelve en DelegatedClassLoaders instanciada, como el código de IBM no está disponible). En ambos, el valor predeterminado es 15, pensaría en configurarlo en 1000 o en algo para reducir las inflaciones, pero aún así beneficiarme de la aceleración. – eckes

3

no veo (al menos para Hotspot), cuando se mira en el código

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

y

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

que un ajuste de cero desactivar la función. Me parece que solo un gran valor para sun.reflect.inflationThreshold hará el trabajo.

+0

IBM se comporta de manera diferente, lo apagará con 0 o 1. (No estoy seguro si hace algo diferente para 0 o 1, pero con ambos no veo que se cargue un DelegatingClassLoader). – eckes

Cuestiones relacionadas