Uso de -noverify al iniciar aplicaciones java

Question

He visto muchas aplicaciones que toman clases de instrumentos y toman -javaagent como parámetro cuando se carga, también coloco un -noverify en la línea de comando.

El documento de Java dice que -noverify desactiva la verificación de clase.

Sin embargo, ¿por qué alguien querría desactivar la verificación incluso si están instrumentando clases?

Answer 1

Hora de inicio, diría. La verificación de que las clases son correctas lleva algún tiempo cuando se carga la clase. Dado que las clases pueden cargarse de forma perezosa (no en el inicio de la aplicación, sino cuando se usan por primera vez), esto puede causar retrasos de tiempo de ejecución inesperados y no deseados.

En realidad, la clase no necesita ser revisada en general. El compilador no emitirá ningún bytecode o construcción de clase no válida. El motivo de la verificación es que la clase puede construirse en un sistema, alojarse en línea y transmitirse a través de Internet sin protección. En este camino, un atacante malintencionado podría modificar el código de bytes y crear algo que el compilador nunca podría crear; algo que puede bloquear la JVM o posiblemente elude las restricciones de seguridad. Por lo tanto, la clase se verifica antes de ser utilizada. Si se trata de una aplicación local, generalmente no es necesario volver a verificar el código de bytes.

Answer 2

Cuando se usa junto con -javaagent , lo más probable es que no sea por razones de rendimiento, sino porque el agente crea intencionalmente " inválido " bytecode.

Debe tenerse en cuenta que el código de bytes no válido aún podría ejecutarse bien, porque algunas de las reglas de verificación son bastante estrictas. Por ejemplo, no se debe acceder a this en un constructor antes de llamar al superconstructor, porque las variables no se inicializan en este punto. Pero aún puede haber otras cosas que desee hacer (consulte el ejemplo de JRebel). Luego, usa -noverify para eludir esa regla.

Answer 3

Depuración! De hecho, eso es lo que estoy haciendo ahora, y cómo me topé con esta pregunta. En Terracotta hacemos una gran cantidad de instrumentación de bytecode, y a veces ayuda apagar el verificador a medida que depuramos nuestros adaptadores de clase, para que podamos ver exactamente dónde fallan en tiempo de ejecución.

Tienes razón, queremos que el verificador permanezca en producción.

Answer 4

Usar JRebel sin -noverify dará esta advertencia al inicio:

  

JRebel: falta '-noverify', ¡no se habilitará el cambio / agregado / eliminación de constructores!

Parece que -noverify permite que la reinstrumentación de bytecode haga algunas cosas que de otra forma no serían posibles.

Answer 5

El tiempo de inicio solía ser un poco problemático. Sin embargo, los verificadores ahora son más rápidos, al igual que los procesadores. El código compilado con JDK6 javac incluirá por defecto información adicional para acelerar el paso del verificador. Apache Harmony solo utiliza un algoritmo de verificación mucho más rápido.

Algunas versiones muy antiguas de javac producían bytecode incorrecto. De hecho, Sun PlugIn todavía incluye código de reparación para verificar algunos archivos de clase rotos.

Answer 6

El nuevo verificador que se introduce en JAVA 6 es muy complicado de procesar para manipulaciones de código.

Mira esto: http: // chrononsystems .com / blog / java-7-design-flaw-leads-to-huge-backward-step-for-the-jvm

y el informe de error relacionado: http://bugs.sun.com/view_bug.do?bug_id=8009595