miércoles, 20 de agosto de 2008

Allocation, deallocation and escape analysis for Java

Enlazo con este interesante artículo en IBM Developer Works: Básicamente el anterior post trata dos temas muy interesantes desde el punto de vista teórico:
  • El mínimo coste de la creación de objetos y reserva de memoria en Java frente a C/C++. Esto es gracias a la arquitectura interna con intervención del GC.
  • La inclusión del Escape Analysis en Java 6 y cómo eso beneficia al alojamiento de objetos en el stack frente al heap, lo cual puede ser una signfiicativa mejora de rendimiento...
Pues bien, el segundo de ellos parece que todavía no es cierto en Java 6 (el artículo es de 2005). Básicamente, hasta donde yo sé, sí que está implementado el análisis de escape (con la opción -XX:+DoEscapeAnalysis) pero sólo se usa para eliminar bloqueos, no para el alojamiento en stack. Quizás en Java 7 la optimización sea completa...

En este hilo puede verse la misma conclusión: http://forums.java.net/jive/thread.jspa?threadID=22617&tstart=120. Sin embargo en este otro post de 2007 se asegura que el Escape Analysis se eliminó de Mustang, por lo que me surge la duda si en actualizaciones posteriores sí se hizo o si simplemente es que hay desinformación por ahí... ver: http://blog.nirav.name/2007/02/escape-analysis-in-mustang-ii.html.

Y en cualquier caso con los microbenchmarks que yo he hecho (Linux, kernel 2.6, 8 cores) no parece que se gane mucho en cuanto a eliminación de locks, sí que parece suponer una mínima mejora pero nada comparable con el biased locking. Con todo el miedo que tengo a los microbenchmarks, en cualquier caso lo cierto es que la opción UseBiasedLocking está activada por defecto en Java 6, mientras que DoEscapeAnalysis hay que activarla.

El sentido común me dice que la decisión de poner opciones por defecto (o no ponerlas) por algo será (si partimos de la premisa de que los ingenieros de Sun no son imbéciles profundos ;-) y por lo tanto seguramente es un análisis experimental e imperfecto, así que tendremos que esperar a Java 7 para que ambas líneas de aprovechamiento del "análisis de escape" funcionen adecuadamente.

P.D: en otro post comentaré acerca del peligro de los microbenchmarks y cómo deben hacerse para no obtener resultados equivocados (en teoría, aunque tampoco me fío del todo).

[Actualización: puede verse información más detallada sobre esta y otras opciones de optimizaciones sobre el modelo de Threading en el post ¿Funcionan las optimizaciones sobre el modelo de threading?]

[Actualización 06-09-2008: Definición de Escape analysis en la Wikipedia: http://en.wikipedia.org/wiki/Escape_analysis]

[Actualización 04-11-2008: Conceptos generales de rendimiento en Java, incluyendo estos nombrados: http://en.wikipedia.org/wiki/Java_performance]

No hay comentarios: