Las optimizaciones basadas en el análisis de escape son una función planificada para Proguard. Mientras tanto, ¿hay alguna herramienta existente como proguard que ya haga optimizaciones que requieran análisis de escape?optimizador de bytecode estático de java (como proguard) con análisis de escape?
Sí, creo que el Soot framework realiza el análisis de escape.
¿Cómo se configura el hollín para optimizar todo el programa (como el análisis de escape) en aplicaciones de Android? Parece que el marco simplemente supone que tiene una función principal y crea el árbol de llamadas solo desde allí, pero las aplicaciones de Android no tienen funciones principales.Proguard le permite mantener múltiples clases, de modo que cada método en la clase se convierta en una nueva "raíz" en el análisis de árbol de llamadas para la optimización de todo el programa. No puedo encontrar una opción similar para el hollín. –
Vamos a marcar esto como la respuesta. Abrí una nueva pregunta específicamente sobre hollín y optimización de todo el programa sin una función principal aquí: http://stackoverflow.com/questions/3093648/how-to-use-soot-to-do-do-whole-program-optimizations-on- android-applications –
¿Qué esperas del análisis de escape en el nivel de compilación? Las clases de Java se parecen más a los archivos de objeto en C: están vinculadas en la JVM, por lo tanto, el análisis de escape solo puede realizarse en un único método, que es de uso limitado y obstaculizará la depuración (por ejemplo, tendrá líneas de código que no puedes pisar).
En el diseño de Java, el compilador es bastante tonto: comprueba la corrección (como Lint), pero no intenta optimizar. Las piezas inteligentes se colocan en la JVM: utiliza múltiples técnicas de optimización para producir un código que funcione bien en la plataforma actual, en las condiciones actuales. Como la JVM conoce todo el código que está actualmente cargado, puede asumir mucho más que el compilador y realizar optimizaciones especulativas que se revierten en el momento en que se invalidan las suposiciones. HotSpot JVM puede reemplazar el código con una versión más optimizada sobre la marcha mientras la función se está ejecutando (por ejemplo, en el medio de un ciclo a medida que el código se "calienta").
Cuando no está en el depurador, las variables con tiempos de vida que no se superponen se colapsan, las invariantes se levantan de los bucles, los bucles se desenrollan, etc. Todo esto sucede en el código JIT-ted y depende de la cantidad de tiempo invertido en esta función (no tiene mucho sentido perder tiempo optimizando el código que nunca se ejecuta). Si realizamos algunas de estas optimizaciones por adelantado, el JIT tendrá menos libertad y el resultado general podría ser un resultado negativo neto.
Otra optimización es la asignación de apilamiento de objetos que no escapan al método actual - esto se hace en ciertos casos, aunque leo un documento en algún lugar que el tiempo para realizar un análisis de escape riguroso contra el tiempo ganado por optimizaciones sugiere que no es vale la pena, por lo que la estrategia actual es más heurística.
En general, cuanta más información tenga la JVM sobre su código original, mejor podrá optimizarlo. Y las optimizaciones que hace la JVM mejoran constantemente, por lo tanto, pensaría en las optimizaciones de código compiladas solo cuando se trata de JVMs muy restringidas y básicas como teléfonos móviles. En estos casos, desea ejecutar su aplicación a través de ofuscador de todos modos (para acortar nombres de clase, etc.)
Solo estoy interesado en la máquina virtual dalvik, y estoy bloqueado en la orientación de la plataforma 1.5/1.6 durante al menos otros 6 meses y 2.1 durante al menos un año. Incluso si pudiera apuntar a 2.2, el JIT está específicamente ajustado para tener tiempos de arranque muy rápidos y pasar el menor tiempo posible en JIT, por lo que las optimizaciones costosas como el análisis de escape más el reemplazo escalar están completamente fuera. Lo que estoy buscando específicamente es un optimizador de bytecode estático que puede hacer un reemplazo escalar basado en el análisis de escape para objetos temporales efímeros. –
Sun's HotSpot JVM tiene incorporado el análisis de escape desde Sun Java 6 Update 14. Debe habilitarlo con '-XX: + DoEscapeAnalysis'. Ver: http://java.sun.com/javase/6/webnotes/6u14.html – Jesper
El análisis de escape está desactivado en u18 y posterior. – gustafc
También está disponible solo en la VM del servidor, y no está disponible en el dalvik vm de Android, ni en ninguna variante de Java que conozca. El objetivo es hacer un análisis de escape antes de tiempo para que pueda obtener los beneficios incluso si no está habilitado en la máquina virtual. –