Utilisation de -noverify lors du lancement d'applications java

Question

J'ai vu de nombreuses applications prenant des classes d'instruments et prenant -javaagent comme paramètre lors du chargement, insérez également un -noverify sur la ligne de commande.

Le document Java indique que -noverify désactive la vérification de classe.

Cependant, pourquoi voudrait-on désactiver la vérification même s’ils instrumentent des classes?

Answer 1

Le temps de démarrage, je dirais. La vérification de l'exactitude des classes prend un certain temps lorsque la classe est chargée. Étant donné que les classes peuvent être chargées paresseusement (pas au démarrage de l'application, mais lors de la première utilisation), cela peut entraîner des retards d'exécution inattendus et non souhaités.

En fait, la classe n'a pas besoin d'être vérifiée en général. Le compilateur n'émettra aucun code octet ou construction de classe non valide. La raison de la vérification est que la classe peut être construite sur un seul système, être hébergée en ligne et vous être transmise via Internet non protégé. Sur ce chemin, un attaquant malveillant pourrait modifier le bytecode et créer quelque chose que le compilateur ne pourrait jamais créer. quelque chose qui peut planter la machine virtuelle ou même contourner les restrictions de sécurité. Ainsi, la classe est vérifiée avant son utilisation. S'il s'agit d'une application locale, il n'est généralement pas nécessaire de vérifier à nouveau le bytecode.

Answer 2

Lorsqu'il est utilisé avec -javaagent , il est fort probable que non , pour des raisons de performances, mais parce que l'agent a créé intentionnellement " invalide " bytecode.

Il convient de noter que le bytecode non valide peut toujours s'exécuter correctement, car certaines règles de vérification sont assez strictes. Par exemple, il ne faut pas accéder à this dans un constructeur avant l'appel du super-constructeur, car les variables ne sont pas initialisées à ce stade. Mais il y a peut-être d'autres choses que vous voulez faire (voir l'exemple de JRebel). Ensuite, vous utilisez -noverify pour contourner cette règle.

Answer 3

Débogage! En fait, c'est ce que je suis en train de faire et comment je suis tombé sur cette question. Chez Terracotta, nous utilisons beaucoup d’instruments de bytecode, et il est parfois utile de désactiver le vérificateur lors du débogage de nos adaptateurs de classe afin de pouvoir voir exactement où ils échouent au moment de l’exécution.

Vous avez raison, nous voulons que le vérificateur reste en production.

Answer 4

Utiliser JRebel sans -noverify donnera cet avertissement au démarrage:

  

JRebel: "-noverify" manquant, la modification / l'ajout / la suppression de constructeurs ne sera pas activée!

Il semble donc que -noverify permet à la ré-instrumentation du bytecode de faire certaines choses qui ne seraient autrement pas possibles.

Answer 5

Le temps de démarrage était un peu un problème. Cependant, les vérificateurs sont maintenant plus rapides, de même que les processeurs. Le code compilé avec JDK6, javac inclura par défaut des informations supplémentaires pour accélérer le processus de vérification. Apache Harmony utilise simplement un algorithme de vérification beaucoup plus rapide.

Certaines très anciennes versions de javac produisaient du bytecode incorrect. En effet, Sun PlugIn inclut toujours du code de réparation pour permettre la vérification de certains fichiers de classe cassés.

Answer 6

Le nouveau vérificateur introduit dans JAVA 6 est très compliqué à traiter pour les manipulations de code.

Regardez ceci: http: // chrononsystems .com / blog / java-7-design-faille-conduit-à-énorme-en arrière-pas-pour-le-jvm

et le rapport de bogue associé: http://bugs.sun.com/view_bug.do?bug_id=8009595