Pourquoi le nombre de variables locales utilisées dans une méthode Java bytecode pas le plus économique de?

pf_miles:

J'ai un extrait de code simple Java:

public static void main(String[] args) {
    String testStr = "test";
    String rst = testStr + 1 + "a" + "pig" + 2;
    System.out.println(rst);
}

Compiler avec le compilateur Java Eclipse, et d'examiner le bytecode en utilisant AsmTools. Ça montre:

Il y a trois variables locales dans la méthode. L'argument est à l'emplacement 0, et les emplacements 1 et 2 sont supposés être utilisés par le code. Mais je pense que 2 variables locales sont juste assez - l'index 0 est l'argument de toute façon, et le code ne nécessite qu'une seule plus variable.

Pour voir si mon idée est correcte, j'edited le bytecode textuel, réduit le nombre de variables locales à 2 et ajusté des instructions connexes:

Je recompilé avec AsmTools et il fonctionne très bien!

Alors, pourquoi ne pas Javac ou le compilateur Eclipse faire ce genre d'optimisation pour utiliser les variables locales minimales?

GhostCat de Monica C.:

Tout simplement parce que la performance gagne Java à partir du compilateur juste à temps.

Ce que vous faites dans la source Java, et même ce qui apparaît dans les fichiers de classe n'est pas ce qui permet des performances lors de l'exécution. Bien sûr, vous ne devez pas négliger cette partie, mais seulement dans le sens d'éviter de faire « stupide » ici.

Signification: le jvm décide à l'exécution si une méthode est une valeur dans la traduction (hautement optimisé!) Code machine. Si le jvm décide « pas la peine d'optimisation », pourquoi faire javac plus complexe et plus lent en ayant beaucoup d'optimisation là-dedans? Plus: plus simple et basique le code octet entrant, plus il est facile pour le JIT pour analyser et améliorer cette entrée!