java - Diferencias entre implementaciones JVM

generics jvm-languages (8)

El borrado de tipo es una función de compilación y, como tal, JVM es independiente.

¿En qué difieren las implementaciones de JVM (excepto las licencias)? ¿Implementa cada JVM el borrado de tipo para el manejo genérico?

¿Dónde están las diferencias entre:

JRockit
IBM JVM
SOL JVM
Abrir JDK
Negro abajo
Kaffe

..... ¿Trata uno de ellos con Tail-Call-Optimization?

El compilador hace cosas como el borrado de tipos para que sean compatibles con versiones anteriores de JVM anteriores. La mayoría de las JVM deben ser compatibles con todas las funciones que necesita, pero algunas pueden estar más optimizadas que otras. Supongo que la Sun JVM es probablemente la más rápida.

JVM es como una máquina virtual que funciona para cargar la clase y el varificador Bytcode, ejecutar el código. mientras que la Interfaz de Programación de Applocaion es Colección de Paquetes. Y los paquetes son colección de clase. El programa Java se ejecuta donde JVM se instala y funciona.

La compilación de JIT es una cosa que algunos JVM: s no tienen.

La optimización de llamadas de cola aún no es compatible con Java. John Rose está liderando los esfuerzos para incluir esto en una versión futura, y ha descrito el enfoque y algunos de los problemas involucrados.

Las implementaciones de JVM pueden diferir en la forma en que implementan la compilación JIT, las optimizaciones, la recolección de basura, las plataformas compatibles, la versión de Java compatible, etc.

Como usted ha señalado, la principal diferencia suele ser la de las licencias. Otras diferencias no técnicas tienden a ser en las opciones de soporte gratuito / pagado, la integración con otras tecnologías (generalmente servidores J2EE) y el acceso al código fuente.

Nota: mientras un servidor J2EE se ejecuta en la JVM, algunos servidores tienen herramientas integradas para monitorear, analizar y ajustar el rendimiento de la JVM.

En cuanto a las diferencias técnicas, éstas se han vuelto menos significativas con los años. Una vez, las JVM de IBM y JRockit tuvieron un rendimiento muy superior al de la implementación de Sun de referencia. Esto se debió a diferencias significativas en los tipos de optimizaciones de tiempo de ejecución, diferencias en la recolección de basura y diferencias en el código nativo (y la cantidad de código nativo que utilizan varias clases). Estas diferencias de rendimiento ya no son tan significativas.

Algunas JVM también incluyen o se integran con herramientas de diagnóstico y monitoreo. JRockit incluye un conjunto de herramientas para monitorear el rendimiento de su JVM. Sun proporciona varias herramientas basadas en JMX con funciones superpuestas para hacer lo mismo. Una vez, IBM Websphere incluyó un conjunto similar de herramientas para todo su servidor de aplicaciones J2EE (no estoy seguro de si todavía lo hacen, pero supongo que todavía es cierto) ...

Algunas de las JVM de código abierto tienden a tener un rendimiento un poco más lento porque se han vuelto a desarrollar desde cero. Como tales, tienen un poco más para ponerse al día. La última vez que verifiqué hace aproximadamente 2 años, Blackdown fue significativamente más lento (¿1.5x-2x?) Que el Sun JVM. También estaba un poco por detrás de las versiones soportadas de Java.

Otra diferencia entre las JVM es el comportamiento en la API no documentada. (por ejemplo, com.sun.xxx) Por ejemplo, la JVM de Sun y la JVM de IBM tienen un comportamiento ligeramente diferente en el manejo de la señal. (La JVM de IBM no permite que la aplicación atrape la señal "INT" en ciertos casos).

Si la JVM dice ser Java, debe pasar el TCK, proporcionando una gran cantidad de funciones de stock.

Las diferencias se encuentran en lugares no centrales, como la recolección de basura, jconsole / visualvm en Sun JVM, precompilación, etc.

Aclaración: TCK es el conjunto de pruebas que debe pasar una máquina virtual para ser oficialmente compatible con Java.