Comment est-il sûr à utiliser-XX:-UseSplitVerifier?

Question

Il y a des problèmes de compatibilité connus avec JDK7 code compilé à l'aide de l'instrumentation. Comme pour http://www.oracle.com/technetwork/java/javase/compatibility-417013.html

Classfiles avec le numéro de version 51 sont exclusivement vérifié à l'aide de la vérification de type vérificateur, et donc les méthodes doivent avoir StackMapTable attributs lorsque cela est approprié. Pour classfiles avec la version 50, le Hotspot de la JVM (et continue) de basculement pour le type d'inférence verifier si le stackmaps dans le fichier manquant ou incorrect. Ce comportement de basculement ne se produit pas pour classfiles avec la version 51 (la version par défaut de Java SE 7). Tout outil qui modifie le bytecode dans une version 51 classfile devez être sûr de mettre à jour le stackmap de l'information pour être cohérent avec le pseudo-code afin de passer à la vérification.

La solution est d'utiliser -XX:-UseSplitVerifier comme l'a résumé ici: http://weblogs.java.net/blog/fabriziogiudici/archive/2012/05/07/understanding-subtle-new-behaviours-jdk-7

Comment il est sûr? Je suppose que Oracle a mis cette case pour une raison. Si je ne l'utilise pas, j'ai peut-être risquer quelques autres questions.

Quelles peuvent être les conséquences de l'utilisation de -XX:-UseSplitVerifier?

Merci,

Piotr.

Answer 1

En bref, il est parfaitement sûr.

Depuis la version 6 de Java, Oracle compilateur a fait des fichiers de classe avec un StackMapTable. L'idée de base est que le compilateur peut spécifier explicitement que le type d'un objet, au lieu de faire le runtime de le faire. Qui fournit une petite accélération dans l'exécution, en échange d'un peu de temps supplémentaire lors de la compilation et une certaine complexité dans la classe compilée fichier (celle-ci StackMapTable).

Comme une fonctionnalité expérimentale, il n'était pas activé par défaut dans la version 6 de Java compilateur. Le moteur d'exécution par défaut pour vérifier les types d'objet lui-même si aucun StackMapTable existe.

Jusqu'À Ce Que Java 7. Oracle rendu obligatoire: le compilateur génère, et le moteur d'exécution vérifie. Il utilise encore l'ancien verifier si le StackMapTable n'est pas là... mais seulement sur les fichiers de classe Java 6 ou version antérieure (version 50). Java 7 fichiers de classe (version 51) sont requis pour utiliser le StackMapTable, et donc le moteur d'exécution ne sera pas coupé de la même mou.

C'est seulement un problème si votre classfiles ont été générés sans StackMapTable. Par exemple, si vous avez utilisé un non-Oracle de la JVM. Ou si vous raté avec le bytecode par la suite-comme l'instrumentation pour l'utiliser avec un débogueur, optimizer, ou de la couverture de code de l'analyseur.

Mais vous pouvez obtenir autour d'elle! Oracle JVM fournit la -XX:+UseSplitVerifier pour forcer l'exécution à revenir à l'ancien type de vérificateur. Il ne s'occupe pas StackMapTable.

Dans la pratique, l'espoir d'optimisation de la vitesse d'exécution et l'efficacité n'a pas concrétisé: si elle existe, elle n'a pas été suffisant pour quiconque de préavis. Comme le nouveau type de vérificateur ne fournit pas toutes les nouvelles fonctionnalités (juste de l'optimisation), il est parfaitement sûr pour l'éteindre.

Oracle explication est à http://www.oracle.com/technetwork/java/javase/compatibility-417013.html si vous recherchez JSR 202.

Answer 2

Oui, c'est sûr. Comme Judebert dit, c'est juste ralentit le chargement des classes légèrement.

Pour ajouter un peu plus d'infos: Quel est exactement un StackMap Table? Eh bien, le Bytecode verifier doit faire deux passes dans le code dans le fichier de classe afin de valider le bon type de données qui sont transmis et utilisé. La première passe, ce qui est le plus lent, n'a analyse des flux de toutes les branches de voir ce type de données pourrait être sur la pile à chaque instruction bytecode. Le deuxième passage, regarde chaque instruction pour voir si elle peut valablement fonctionner sur tous les types.

Voici la clé: le compilateur dispose déjà de toutes les informations à portée de main que la première passe ne génère donc (en Java 6 et 7), il les stocke dans un StackMap table dans le fichier de classe.

Cela accélère le chargement des classes, parce que le chargeur de classe n'a pas à le faire passer. C'est pourquoi il est appelé un Split Vérificateur, car le travail est divisé entre le compilateur et l'exécution du mécanisme de chargement. Lorsque vous utilisez l'option-XX:-UseSplitVerifier option, vous dites Java à faire deux passes à la classe de charge temps (et d'ignorer tout StackMap tableau). De nombreux produits (comme les profileurs qui modifient le bytecode au moment du chargement) ne connaissent pas l'StackMap table dès le début, de sorte que quand ils ont modifié les classes au moment du chargement, le StackMap table du compilateur était pas à jour et provoqué des erreurs.

DONC, pour résumer, la -XX:-UseSplitVerifier option ralentit le chargement des classes. Il n'affecte pas la sécurité, les performances d'exécution ou de la fonctionnalité.

Answer 3

La pile de la Carte des Cadres ont été ajoutés dans Java 7, et "prashant" soutient que l'idée est erronée, et propose que les développeurs utilisent toujours l' -XX:-UseSplitVerifier drapeau pour éviter de les utiliser.

Lire la suite: Java 7 Bytecode Verifier: Énorme pas en arrière pour la JVM