Les optimisations basées sur l'analyse d'échappement sont une fonctionnalité planifiée pour Proguard. En attendant, y a-t-il des outils existants comme proguard qui font déjà des optimisations qui nécessitent une analyse d'échappement?statique java bytecode optimiseur (comme proguard) avec l'analyse d'échappement?
Oui, je pense que le Soot framework effectue une analyse d'échappement.
Comment configurez-vous la suie pour effectuer des optimisations de programme complètes (telles que l'analyse d'échappement), sur les applications Android? Il semble que le framework suppose simplement que vous avez une fonction principale et construit l'arborescence d'appels à partir de là seulement, mais les applications Android n'ont pas de fonctions principales.Proguard vous permet de conserver plusieurs classes, de sorte que chaque méthode de la classe devienne une nouvelle "racine" dans l'analyse de l'arbre d'appel pour l'optimisation de l'ensemble du programme. Je ne peux pas trouver une option similaire pour la suie. –
Va marquer cela comme la réponse. J'ai ouvert une nouvelle question spécifiquement sur l'optimisation de la suie et du programme entier sans une fonction principale ici: http://stackoverflow.com/questions/3093648/how-to-use-soot-to-do-whole-program-optimizations-on- android-applications –
Qu'attendez-vous de l'analyse d'échappement au niveau du compilateur? Les classes Java sont plus comme des fichiers objet en C - elles sont liées dans la JVM, donc l'analyse d'échappement peut être effectuée uniquement au niveau d'une seule méthode, ce qui limite l'utilisation et entrave le débogage (par exemple, vous aurez des lignes de code que vous ne pouvez pas marcher).
Dans la conception de Java, le compilateur est assez bête - il vérifie l'exactitude (comme Lint), mais n'essaie pas d'optimiser. Les pièces intelligentes sont placées dans la JVM - elle utilise plusieurs techniques d'optimisation pour produire un code performant sur la plate-forme actuelle, dans les conditions actuelles. Comme la JVM connaît tout le code actuellement chargé, elle peut assumer beaucoup plus que le compilateur et effectuer des optimisations spéculatives qui sont annulées au moment où les hypothèses sont invalidées. HotSpot JVM peut remplacer le code avec une version plus optimisée à la volée pendant que la fonction est en cours d'exécution (par exemple, au milieu d'une boucle lorsque le code devient plus chaud).
Lorsqu'ils ne sont pas dans le débogueur, les variables avec des durées de vie non chevauchantes sont repliées, les invariants sont hissés de boucles, les boucles sont déroulées, etc. Tout cela se produit dans le code JIT et dépend du temps passé dans cette fonction (cela n'a pas beaucoup de sens de passer du temps à optimiser le code qui ne fonctionne jamais). Si nous effectuons certaines de ces optimisations à l'avance, le JIT aura moins de liberté et le résultat global pourrait être négatif net. Une autre optimisation est l'allocation de pile d'objets qui n'échappent pas à la méthode actuelle - ceci est fait dans certains cas, même si je lis quelque part que le temps d'effectuer une analyse d'échappement rigoureuse par rapport au temps gagné par les optimisations suggère vaut la peine, donc la stratégie actuelle est plus heuristique. Dans l'ensemble, plus la JVM dispose d'informations sur votre code d'origine, mieux elle peut l'optimiser. Et les optimisations que fait la JVM s'améliorent constamment, donc je ne penserais aux optimisations de code compilées qu'en parlant de JVM très restreintes et basiques comme les téléphones portables. Dans ce cas, vous voulez quand même exécuter votre application via obfuscator (pour raccourcir les noms de classe, etc.)
Je ne suis intéressé que par la VM dalvik, et je suis bloqué dans le ciblage de la plate-forme 1.5/1.6 pendant au moins 6 mois et 2.1 pendant au moins un an. Même si je pouvais cibler la version 2.2, le JIT est spécialement conçu pour avoir des temps de démarrage très courts et passer le moins de temps possible en JIT, les optimisations coûteuses telles que l'analyse d'échappement et le remplacement scalaire sont complètement désactivées. Ce que je recherche spécifiquement est un optimiseur de bytecode statique qui peut effectuer un remplacement scalaire basé sur l'analyse d'échappement pour des objets temporaires de courte durée. –
La HotSpot JVM de Sun est intégrée à l'analyse d'échappement depuis Sun Java 6 Update 14. Vous devez l'activer avec -XX: + DoEscapeAnalysis'. Voir: http://java.sun.com/javase/6/webnotes/6u14.html – Jesper
L'analyse d'échappement est désactivée sur u18 et versions ultérieures. – gustafc
Il est également uniquement disponible sur le serveur VM, et pas disponible du tout sur le dalvik vm de l'android, ni sur aucune variante javaME dont je suis au courant. Le but est de faire une analyse d'échappement à l'avance pour obtenir les avantages même si elle n'est pas activée dans la machine virtuelle. –