¿Cuál es la diferencia entre el funcionamiento interno de JVM de Java y el CLR de .NET?

Question

¿Cuál es la diferencia entre el funcionamiento interno de JVM de Java y CLR de .NET?

Quizás un punto de partida sería, ¿son básicamente lo mismo en sus respectivos entornos (Java> JVM> Código de máquina) (C#> CLR> IL).

---

Actualización: Varias personas han aludido a los puntos que estaba tratando de cubrir:

1. recolección de elementos
2. boxeo/Unboxing
3. JIT de depuración
4. Genéricos/Plantillas
5. Por favor, siéntase libre de sugerir otros buenos temas que diferencien los dos.

@George Mauer - esto suena muy interesante:

Ya ha publicado esto una vez, pero aquí es una series of interviews con C# diseñador jefe lenguaje Anders Hejlsberg.

Answer 1

ya ha publicado esto una vez, pero here is a series of interviews con C# diseñador jefe lenguaje Anders Hejlsberg. aunque sobre todo hablando de las diferencias entre C# y Java lo hace sumergirse en las diferencias entre las máquinas virtuales también.

Answer 2

De here. No podría haberlo dicho mejor (Bueno, con la excepción de una guerra de llamas, este es un lugar sin llama :-)).

Hola,

En respuesta a su pregunta parece lleno de peligros iniciando una guerra de mensajes , así que voy a proceder con cautela.

Hay una serie de similitudes técnicas fundamentales entre la de ejecución de Java y el lenguaje común tiempo de ejecución, incluyendo basura recogida memoria, un lenguaje intermedio (Microsoft IL frente Java ByteCode), bibliotecas de sistema núcleo, y el apoyo para lenguajes de alto nivel, seguridad de código y despliegue.

Sin embargo, cada una de estas áreas 'similares' también tienen un número de tamaño considerable y pequeñas diferencias, y es más allá del alcance de un simple mensaje Foro de describen la mayoría de ellos.

Yo sugeriría hacer una pregunta más targetted sobre cualquiera de las características de tiempo de ejecución diversos componentes y áreas (por ejemplo, gestión de memoria, de compilación, las bibliotecas del sistema, de seguridad, etc.) y entonces podemos proporcionar una mayor respuesta dirigida (por ejemplo, un blog, un artículo técnico o algunos libros).

Answer 3

Esto debería ser un gran hilo.

Una de las mayores diferencias es entre el CLR y JVM es el CLR "s integración nativa de los genéricos.

Java en vez elimina los tipos genéricos y la JVM sólo puede trabajar con objetos por autoboxing los objetos que parece ser genéricos seudo.

Answer 4

como Vinko dijo, los detalles completos son más allá del alcance de una publicación en el foro. Las diferencias/similitudes se reducen a esto:

Ambos son un entorno de tiempo de ejecución "sandbox" que incluye un compilador "just-in-time" para traducir las instrucciones del programa en un lenguaje intermedio (MSIL o ByteCode) al código máquina nativo y proporcionar administración de memoria automática (recolección de basura). Sentados sobre los respectivos entornos de tiempo de ejecución hay un conjunto de bibliotecas de clases que proporcionan abstracciones de mayor nivel a los desarrolladores para simplificar las tareas de desarrollo.

Los aspectos internos de cómo se implementan realmente estos entornos de tiempo de ejecución son, en su mayoría, propiedad de Microsoft y Sun. Los algoritmos utilizados por los sistemas de recolección de basura, por ejemplo, aunque probablemente sean similares en funcionalidad técnica, son diferentes en la implementación.

Answer 5

Miguel de Icaza menciona here:

programadores experimentados de la industria se dará cuenta de que lo anterior es muy parecido a Java y la máquina virtual de Java. Tienen razón, el anterior es como Java.

El CIL tiene una característica que no se encuentra en Java sin embargo: es byte representación de código que es lo suficientemente potente como para ser utilizado como un objetivo para muchos idiomas: de C++, C, Fortran y Eiffel a Lisp y Haskell incluidos cosas como Java, C#, JavaScript y Visual Básico en la mezcla.

Ojalá tuviera tiempo para entrar en más detalles, pero por el bien de este argumento, bastará con lo anterior.

Sin embargo, los comentarios entran en algunos detalles, como las optimizaciones de cola de cola. Sin embargo, el lote ha cambiado desde 2002: tanto CLR como JVM ahora tienen múltiples idiomas dirigidos a él. Pero, no obstante, vale la pena leerlo.

Answer 6

Una diferencia esencial es que la JVM es portátil en todas las plataformas y se ejecuta en Linux, Macintosh y muchos teléfonos celulares y dispositivos integrados.

CLR se ejecuta en plataformas compatibles con Microsoft con el proyecto Mono que brinda compatibilidad parcial con versiones anteriores de CLR en algunos más.

Internamente, esto significa que el rendimiento de la JVM variará en esas diferentes plataformas en función de las capacidades proporcionadas por las propias plataformas.

Answer 7

Por lo que sé, .Net CLR todavía tiene una seguridad de acceso de código mucho más flexible y potente integrada en el tiempo de ejecución, lo que permite permisos mucho más finos y una política de ejecución.

Answer 8

Existen diferencias en la recolección de basura también. JVM usa Copiar colector y Marcar y arrastrar. Usuario de .NET Copia del recopilador y Marca y compacta (Mucho más difícil de implementar).

También es importante el tipo de borrado mencionado por Flyswat. JVM no tiene ni idea sobre los genéricos y todo es objeto y perf. Asociado. pena de boxeo y desembalaje. Además, la reflexión no le dará información genérica. CLR admite genéricos de forma nativa.

Answer 9

CLR y JVM tienen metas y filosofías que difieren más de lo que piensas. En general, la JVM tiene como objetivo optimizar un código más dinámico y de mayor nivel, mientras que CLR le brinda más herramientas de bajo nivel para realizar este tipo de optimizaciones.

Un buen ejemplo es la asignación de la pila. En el CLR tiene una asignación de pila explícita de tipos de valores personalizados. En la JVM, los únicos tipos personalizados son tipos de referencia, pero la JVM puede convertir las asignaciones de pila a las asignaciones de la pila en determinadas circunstancias a través del Análisis de escape.

Otro ejemplo. En Java, los métodos son virtuales por defecto. En C# al menos, no lo son. Es mucho más difícil optimizar las llamadas a métodos virtuales porque el código que se ejecuta en un sitio de llamadas determinado no se puede determinar estáticamente.

Debajo del capó, sus sistemas de ejecución son bastante diferentes. La mayoría de las JVM (en particular, Hotspot) comienzan con un intérprete de bytecode y solo partes de compilación JIT del código que se ejecutan en gran medida, p. bucles apretados. También pueden volver a compilar estos datos una y otra vez utilizando las estadísticas de ejecución recopiladas de las ejecuciones anteriores para generar optimizaciones. Esto permite que se apliquen más esfuerzos de optimización a las partes del programa que más lo necesitan. Esto se llama optimización adaptativa.

El CLR compila todo por adelantado solo una vez. Hace menos optimización, ya que tiene más código para compilar y, por lo tanto, tiene que ser rápido y porque no tiene ninguna estadística de las rutas de ejecución reales tomadas para alimentar sus optimizaciones. Este enfoque tiene la gran ventaja de permitirle almacenar en caché los resultados de compilación en todos los procesos, lo que hace CLR pero JVM no.

Un gran porcentaje del código JVM de Hotspot está dedicado a estas optimizaciones adaptativas y es lo que coloca a Java en el mismo estadio de rendimiento como código nativo para el cálculo más general a principios de la década de 2000. También son lo que hace que la JVM sea un objetivo decente para los lenguajes dinámicos. Estoy excluyendo aquí los desarrollos más recientes de Dynamic Languages ​​Runtime e invochedynamic ya que no sé lo suficiente sobre el DLR.