¿Java guarda sus optimizaciones de tiempo de ejecución?

Question

Mi profesor hizo una prueba comparativa informal en un pequeño programa y los tiempos de Java fueron:1,7 segundos para la primera carrera y 0,8 segundos para las carreras posteriores.

• ¿Esto se debe enteramente a la carga del entorno de ejecución en el entorno operativo?

  O

• ¿Está influenciado por la optimización del código de Java y el almacenamiento de los resultados de esas optimizaciones (lo siento, no conozco el término técnico para eso)?

Answer 1

Estoy de acuerdo en que la diferencia de rendimiento vista por el cartel probablemente se deba a la latencia del disco que lleva el JRE a la memoria.El compilador Just In Time (JIT) no tendría ningún impacto en el rendimiento de una aplicación pequeña.

Java 1.6u10 (http://download.java.net/jdk6/) toca los JAR en tiempo de ejecución en un proceso en segundo plano (incluso si Java no se está ejecutando) para mantener los datos en la caché del disco.Esto reduce significativamente los tiempos de inicio (lo cual es un gran beneficio para las aplicaciones de escritorio, pero probablemente tenga un valor marginal para las aplicaciones del lado del servidor).

En aplicaciones grandes y de larga duración, el JIT marca una gran diferencia con el tiempo, pero la cantidad de tiempo necesaria para que el JIT acumule estadísticas suficientes para activarse y optimizarse (5 a 10 segundos) es muy, muy corta en comparación con la vida útil general. de la aplicación (la mayoría se ejecuta durante meses y meses).Si bien almacenar y restaurar los resultados de JIT es un ejercicio académico interesante, la mejora práctica no es muy grande (razón por la cual el equipo de JIT se ha centrado más en cosas como estrategias de GC para minimizar los errores de memoria caché, etc.).

La precompilación de las clases de tiempo de ejecución ayuda bastante a las aplicaciones de escritorio (al igual que la precarga de caché de disco 6u10 antes mencionada).

Answer 2

Bien, encontré donde leí eso.Todo esto es de "Aprendiendo Java" (O'Reilly 2005):

El problema con una compilación JIT tradicional es que optimizar el código lleva tiempo.Por lo tanto, un compilador JIT puede producir resultados decentes, pero puede sufrir una latencia significativa cuando se inicia la aplicación.Por lo general, esto no es un problema para las aplicaciones del lado del servidor que se ejecutan durante mucho tiempo, pero es un problema grave para el software del lado del cliente y las aplicaciones que se ejecutan en dispositivos más pequeños con capacidades limitadas.Para solucionar este problema, la tecnología de compilación de Sun, llamada HotSpot, utiliza un truco llamado compilación adaptativa.Si nos fijamos en lo que los programas realmente dedican su tiempo a hacer, resulta que dedican casi todo su tiempo a ejecutar una parte relativamente pequeña del código una y otra vez.El fragmento de código que se ejecuta repetidamente puede ser sólo una pequeña fracción del programa total, pero su comportamiento determina el rendimiento general del programa.La compilación adaptativa también permite que el tiempo de ejecución de Java aproveche nuevos tipos de optimizaciones que simplemente no se pueden realizar en un lenguaje compilado estáticamente, de ahí la afirmación de que el código Java puede ejecutarse más rápido que C/C++ en algunos casos.

Para aprovechar este hecho, HotSpot comienza como un intérprete normal de código de bytes de Java, pero con una diferencia:mide (perfila) el código mientras se ejecuta para ver qué partes se ejecutan repetidamente.Una vez que sabe qué partes del código son cruciales para el rendimiento, HotSpot compila esas secciones en un código de máquina nativo óptimo.Dado que compila sólo una pequeña parte del programa en código de máquina, puede permitirse el lujo de tomarse el tiempo necesario para optimizar esas partes.Es posible que no sea necesario compilar el resto del programa, solo interpretarlo, ahorrando memoria y tiempo.De hecho, la máquina virtual Java predeterminada de Sun puede ejecutarse en uno de dos modos:cliente y servidor, que le indican si debe enfatizar el tiempo de inicio rápido y la conservación de la memoria o maximizar el rendimiento.

Una pregunta natural que cabe plantearse en este punto es: ¿Por qué desechar toda esta buena información de creación de perfiles cada vez que se cierra una aplicación?Bueno, Sun ha abordado parcialmente este tema con el lanzamiento de Java 5.0 mediante el uso de clases compartidas de sólo lectura que se almacenan de forma persistente en una forma optimizada.Esto reduce significativamente tanto el tiempo de inicio como la sobrecarga de ejecutar muchas aplicaciones Java en una máquina determinada.La tecnología para hacer esto es compleja, pero la idea es simple:Optimice las partes del programa que deben ir rápido y no se preocupe por el resto.

Me pregunto qué tan lejos ha llegado Sun desde Java 5.0.

Answer 3

No conozco ninguna máquina virtual de uso generalizado que guarde datos estadísticos de uso entre invocaciones de programas, pero ciertamente es una posibilidad interesante para futuras investigaciones.

Es casi seguro que lo que estás viendo se debe al almacenamiento en caché del disco.

Answer 4

Estoy de acuerdo en que probablemente sea el resultado del almacenamiento en caché del disco.

Para su información, IBM Java 6 VM contiene un compilador anticipado (AOT).El código no está tan optimizado como lo que produciría el JIT, pero se almacena en máquinas virtuales, creo que en algún tipo de memoria compartida persistente.Su principal beneficio es mejorar el rendimiento del inicio.La máquina virtual IBM ejecuta JIT de forma predeterminada en un método después de haberlo llamado 1000 veces.Si sabe que se llamará a un método 1000 veces solo durante el inicio de la VM (piense en un método de uso común como java.lang.String.equals(...) ), entonces es beneficioso almacenarlo en la caché de AOT para que nunca tenga que perder tiempo compilando en tiempo de ejecución.

Answer 5

Debe describir cómo se realizó su punto de referencia.Especialmente en ese momento empiezas a medir el tiempo.

Si incluye el tiempo de inicio de JVM (que es útil para evaluar la experiencia del usuario pero no tan útil para optimizar el código Java), entonces podría ser un efecto de almacenamiento en caché del sistema de archivos o puede ser causado por una característica llamada "Compartir datos de clases Java":

Para el sol:

http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

Esta es una opción en la que la JVM guarda una imagen preparada de las clases de tiempo de ejecución en un archivo, para permitir cargarlas (y compartirlas) más rápido en el siguiente inicio.Puede controlar esto con -Xshare:on o -Xshare:off con una JVM Sun.El valor predeterminado es -Xshare:auto que cargará la imagen de clases compartidas si está presente y, si no está presente, la escribirá en el primer inicio si el directorio tiene capacidad de escritura.

Con IBM Java 5, esto es, por cierto, aún más potente:

http://www.ibm.com/developerworks/java/library/j-ibmjava4/

No conozco ninguna JVM convencional que guarde estadísticas JIT.

Answer 6

Java JVM (en realidad puede cambiar de diferentes implementaciones de JVM) cuando se inicia por primera vez interpretará el código de bytes.Una vez que detecta que el código se ejecutará una cantidad suficiente de veces, lo aplica mediante JIT al lenguaje de máquina nativo para que se ejecute más rápido.