2010-03-24 22 views
12

Sé que Microsoft .NET utiliza el CLR como un compilador JIT mientras que Java tiene el Hotspot. ¿Cuáles son las diferencias entre ellos?Cuáles son las diferencias en JIT entre Java y .Net

+2

¿Diferencia en términos de ...? – medopal

+1

NGen se utiliza para precompilar MSIL a código nativo y lo hace para todo un conjunto, sin embargo cuando uno no tiene código NGen, el compilador JIT en .Net CLR lo hará sobre la marcha para usted. Una comparación entre los dos se haría mejor con el compilador JIT en el CLR y no con NGen vs Hotspot. – saret

Respuesta

22

Son bestias muy diferentes. Como señalaron las personas, CLR compila el código máquina antes de ejecutar una parte de MSIL. Esto permite, además de la típica eliminación de código muerto y la optimización de privates privados para aprovechar la arquitectura de CPU particular de la máquina de destino (aunque no estoy seguro de si lo hace). Esto también tiene un impacto para cada clase (aunque el compilador es bastante rápido y muchas bibliotecas de plataforma son solo una capa delgada sobre la API de Win32).

El HotSpot VM tiene un enfoque diferente. Establece que la mayor parte del código se ejecuta de forma rara, por lo que no vale la pena perder tiempo compilando. Todos los códigos de bytes se inician en modo interpretado. La máquina virtual mantiene estadísticas en los sitios de llamada e intenta identificar los métodos que se llaman más que un número predefinido de veces. Luego compila solo estos métodos con un rápido compilador JIT (C1) y cambia el método mientras se está ejecutando (esa es la salsa especial de HS). Después de que el método compilado C1 ha sido invocado algunas veces más, el mismo método se compila con un compilador lento pero sofisticado y el código se intercambia de nuevo sobre la marcha.

Dado que HotSpot puede intercambiar métodos mientras se están ejecutando, los compiladores de VM pueden realizar algunas optimizaciones especulativas que no son seguras en el código compilado estáticamente. Un ejemplo canónico es el envío/en línea estático de llamadas monomórficas (método polimórfico con una sola implementación). Esto se hace si la VM ve que este método siempre se resuelve en el mismo destino. Lo que solía ser invocación compleja se reduce a unas pocas instrucciones de guardia de la CPU, que son predichas y canalizadas por las CPU modernas. Cuando la condición de guarda deja de ser cierta, la VM puede tomar una ruta de código diferente o incluso regresar al modo de interpretación. Según las estadísticas y la carga de trabajo del programa, el código máquina generado puede ser diferente en diferentes momentos. Muchas de estas optimizaciones se basan en la información recopilada durante la ejecución del programa y no son posibles si compila una vez que carga la clase.

Es por eso que necesita calentar la JVM y emular la carga de trabajo realista cuando compara algoritmos (los datos sesgados pueden llevar a una evaluación poco realista de las optimizaciones). Otras optimizaciones son elisión de bloqueo, bloqueo de giro adaptable, análisis de escape y asignación de pila, etc.

Dicho esto, HotSpot es solo una de las máquinas virtuales. JRockit, Azul, J9 de IBM y el RVM reajustable, todos tienen diferentes perfiles de rendimiento.

+0

Véase también http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html – ddimitrov

+0

¿Es cierto que para Java "todos los códigos de bytes se inician en modo interpretado"? Creo que también hay un conteo de llamadas al inicio y, si supera el umbral, se compilarán al inicio. Esto puede depender del compilador: https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/understanding/jit_overview.html – swdon

Cuestiones relacionadas