¿En qué se diferencian las implementaciones de JVM (excepto las licencias)? ¿Cada JVM implementa Type Erasure para el manejo genérico?Diferencias entre las implementaciones de JVM
¿Dónde están las diferencias entre:
.... ¿Ofrece uno de ellos con Tail-Call-Optimization?
Las implementaciones de JVM pueden diferir en la forma en que implementan compilación JIT, optimizaciones, recolección de basura, plataformas compatibles, versión de Java admitida, etc. Todas deben cumplir un conjunto de características y comportamientos para que ejecute sus códigos de bytes de Java correctamente.
Como ha señalado, la principal diferencia suele ser la concesión de licencias. Otras diferencias no técnicas suelen ser las opciones de soporte gratuito/pago, la integración con otras tecnologías (generalmente servidores J2EE) y el acceso al código fuente.
Nota: Mientras que un servidor J2EE se ejecuta en la JVM, algunos servidores tienen herramientas integradas para supervisar, analizar y ajustar el rendimiento de JVM.
En cuanto a las diferencias técnicas, han ido perdiendo importancia a lo largo de los años. Érase una vez, las JVM de IBM y JRockit tenían un rendimiento muy superior a la implementación de Sun de referencia. Esto se debió a las diferencias significativas en los tipos de optimizaciones de tiempo de ejecución, las diferencias en la recolección de elementos no utilizados y las diferencias en el código nativo (y la cantidad de código nativo que usan varias clases). Estas diferencias de rendimiento ya no son tan significativas.
Algunas JVM también incluyen o integran herramientas de diagnóstico y monitoreo. JRockit incluye un conjunto de herramientas para controlar el rendimiento de su JVM. Sun proporciona varias herramientas basadas en JMX con funciones superpuestas para hacer lo mismo. IBM Websphere alguna vez incluyó un conjunto similar de herramientas para todo su servidor de aplicaciones J2EE (no estoy seguro si todavía lo hacen, pero supongo que eso sigue siendo cierto) ...
Algunas de las JVM de código abierto tienden a tener un rendimiento un poco más lento porque se han reconstruido desde cero. Como tal, tienen un poco más de ponerse al día para hacerlo. La última vez que lo revisé, hace 2 años, Blackdown fue significativamente más lento (1.5x-2x?) Que Sun JVM. También estaba un poco atrás de las versiones compatibles de Java.
La borradura de tipo es compiler function y, como tal, independiente de JVM.
La compilación JIT es algo que algunas JVM: s no tienen.
¿Qué hay del sol JVM? http://java.sun.com/javase/technologies/hotspot/ Parece que el compilador JIT de punto de acceso se toma con cada versión de JVM. –
No estoy seguro de lo que quiere decir allí, pero sí, Hotspot es parte de Sun JVM. –
¿Por qué dice que evey JVM no tiene compilación de JIT cuando es parte de la mayoría de las JVM? ¿Por qué me votas? –
El compilador hace cosas como el tipo de borrado para que sea compatible con versiones anteriores de JVM. La mayoría de las JVM deben ser compatibles con todas las características que necesita, pero algunas pueden estar más optimizadas que otras. Supongo que Sun JVM es probablemente el más rápido.
Si la JVM pretende ser Java, debe pasar el TCK, lo que proporciona una gran cantidad de funciones de stock.
Las diferencias se encuentran en lugares no básicos, como la recolección de basura, el jconsole/VisualVM en la JVM de Sun, etc. compilación previa
aclaración: TCK es el conjunto de pruebas de que una máquina virtual tiene que pasar para ser oficialmente compatible con Java.
Kit de compatibilidad de tecnología. http://jcp.org/en/resources/tdk –
La optimización de llamadas atrasadas aún no es compatible con Java. John Rose lidera los esfuerzos para incluir esto en una versión futura, y ha descrito el approach, and some of the issues involucrado.
Recuerdo las opciones para Java6 (características experimentales), ¿quizás el Sun JDK lo admite como experimental? ¿Qué pasa con el "VM Da vinchi" oí que debería ser compatible con TCO! –
Sí, el proyecto da Vinci está orientado a la compatibilidad con otros idiomas, y es allí donde se está creando prototipos de soporte. – erickson
Algún tipo de esta optimización (solo recursión de cola) es compatible con IBM JVM (algo así como un goto al comienzo del método) –
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).
JVM es como una máquina virtual que funciona para cargar la clase y el varificador Bytcode, ejecuta el código. mientras que Applocaion Programming Interface es Collection of Packages. y los Paquetes son una colección de clase. El programa Java se ejecuta donde JVM está instalado y funciona.
Como alguien forzado a utilizar JRockit por más de 5 años, diría que, en general, no es más rápido que el Hotspot, pero definitivamente no es tan robusto. Sacrifican la fiabilidad por la velocidad y terminan sin nada. – erickson
@erickson, como alguien que ha usado JRockit voluntariamente por más de 5 años, puedo decir que sus experiencias no son universales. JRockit también ha guardado al menos una vez con su herramienta de detección de fugas de memoria. :) No he tenido más accidentes con él que con las VM de Sun (aunque ha habido 1 o dos). – jsight