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

para que sirve visual basic net (9)

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

Quizás un punto de partida sería, básicamente, son 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:

Recolección de basura
Boxeo / Unboxing
Depuración JIT
Genéricos / Plantillas
Por favor, siéntase libre de sugerir otros buenos temas que los diferencien.

@George Mauer : esto suena muy interesante:

Ya publicado esta vez, pero aquí hay una serie de entrevistas con el diseñador de lenguaje principal de c #, Anders Hejlsberg.

Como dijo Vinko, los detalles completos están 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 esos 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.

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

Hola,
Responder a su pregunta parece plagado de peligros al iniciar una guerra de llamas, así que procederé con cautela.
Hay una serie de similitudes técnicas fundamentales entre Java Runtime y Common Language Runtime, incluida la memoria recolectada, un lenguaje intermedio (Microsoft IL versus Java ByteCode), bibliotecas del sistema central y soporte para lenguajes de alto nivel, seguridad del código y despliegue.
Sin embargo, cada una de estas áreas "similares" también tiene una cantidad de diferencias considerables y pequeñas, y está más allá del alcance de una simple publicación del Foro describir la mayoría de ellas.
Sugeriría hacer una pregunta más específica sobre cualquiera de las diversas características de tiempo de ejecución y áreas componentes (por ejemplo, administración de memoria, compilación, bibliotecas de sistema, seguridad, etc.) y luego podemos proporcionar una respuesta más específica (por ejemplo, un blog, un artículo técnico , o algunos libros).

Esto debería ser un gran hilo.

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

En su lugar, Java elimina los tipos genéricos y la JVM solo puede trabajar con objetos mediante el autoboxeo de los objetos que parece ser pseudo genéricos.

Miguel de Icaza menciona aquí :

Los programadores experimentados de la industria notarán que lo anterior se parece mucho a Java y Java VM. Tienen razón, lo anterior es como Java.
Sin embargo, el CIL tiene una característica que no se encuentra en Java: es la representación de códigos de bytes lo suficientemente poderosa como para ser utilizada como destino para muchos idiomas: desde C ++, C, Fortran y Eiffel a Lisp y Haskell incluyendo cosas como Java, C #, JavaScript y Visual Basic en la mezcla.
Desearía tener el tiempo para entrar en más detalles, pero por el bien de esta discusión, lo anterior será suficiente.

Sin embargo, los comentarios entran en algunos detalles, como 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.

Ya publicado esta vez, pero aquí hay una serie de entrevistas con el diseñador de lenguaje principal de c #, Anders Hejlsberg. Aunque habla principalmente sobre las diferencias entre C # y Java, también se sumerge en las diferencias entre las máquinas virtuales.

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 las plataformas compatibles de Microsoft con el proyecto Mono que proporciona compatibilidad parcial de 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.

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

Hay diferencias en la recolección de basura también. JVM usa Copying collector y Mark and sweep. 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.

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.

Bajo el capó, sus sistemas de ejecución son bastante diferentes. La mayoría de las JVM (en particular, Hotspot) comienzan con un intérprete de código de bytes y solo partes de compilación JIT del código que se ejecutan en gran medida, por ejemplo, bucles ajustados. 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.