44 votos

Es el CLR de una máquina virtual?

He leído un libro que se refiere .net CLR como máquina virtual ? ¿Alguien puede justificar esto ? ¿Cuál es la razón por la que necesitamos el concepto de las máquinas virtuales en algunas plataformas de desarrollo ?

No es posible desarrollar un nativo de marco [sin máquina virtual] que es completamente orientado a objetos y poderosa como .neta ?

El libro, que se refiere a CLR como máquina virtual es "Profesional .Net Framework 2.0".

82voto

Joel Coehoorn Puntos 190579

Hay un montón de ideas falsas aquí. Supongo que se podría pensar .Net como una máquina virtual si realmente quería, pero echemos un vistazo a cómo el .Net Framework realmente maneja el código. El escenario típico se parece a esto

  1. Escribir una .Neto del programa en C#, VB.Net, F#, o algún otro lenguaje compatible con.
  2. Que el código se compila a un Lenguaje Intermedio (IL), que es similar a Java bytecode, que se distribuye a los equipos de los usuarios finales.
  3. Un usuario final, se invoca el programa por primera vez en un equipo con la versión correcta de .Neta instalada
  4. El equipo considera que esta es una .Neto de la asamblea, en lugar de "raw" código de máquina, y pasa al compilador JIT
  5. El compilador JIT compila la IL completamente-código máquina nativo.
  6. El código nativo se guarda en la memoria de la vida de este programa de ejecución.
  7. El salvado de código nativo se invoca, y la IL ya no importa.

Hay un par de puntos importantes, pero la más grande es que en ningún momento es cualquier código cada vez interpretado. En su lugar, se puede ver en el paso 5 que es compilado a código nativo. Esta una gran diferencia de carga en una máquina virtual, por varias razones:

  1. El código compilado es ejecutado por la cpu directamente, en lugar de interpretado o traducido por un software adicional de la capa de abstracción, que debe ser más rápido.
  2. El compilador JIT puede tomar ventaja de optimizaciones específicas para la máquina que ejecuta el programa, en lugar de conformarse con un mínimo común denominador.
  3. Si quieres incluso puedes pre-compilar el código y en esencia ocultar el paso 5 del usuario completo.

Supongo que se podría llamar a esto una máquina virtual, en el sentido de la Fluctuación de resúmenes de distancia de los detalles de la máquina real del desarrollador. Personalmente no creo que realmente es correcto, porque para muchas personas, una máquina virtual implica un tiempo de ejecución de la abstracción, lejos de código nativo para .Programas de la red simplemente no existe.

Otro punto clave de todo este proceso que realmente lo distingue de una "máquina virtual" el medio ambiente es que es sólo el típico proceso. Si usted realmente desea, usted puede pre-compilar un .Neto de la asamblea antes de su distribución y de implementar el código nativo directamente a los usuarios finales (sugerencia: es más lento en promedio a lo largo de la vida del programa, porque se pierde la máquina de optimizaciones específicas). Por supuesto, usted todavía necesita la .Net runtime instalado, pero en este momento realmente no es muy diferente de cualquier otra API del motor de ejecución; es más como una colección de archivos dll con un buen API puede vincular en contra, como la que pueda tener con el VB o C tiempos de ejecución de Microsoft también se incluye con Visual Studio. Este tipo de toma de la IL fuera de la imagen, haciendo que la VM moniker mucho más difícil de justificar. (Digo "algo" porque la IL está siendo implementado y se utiliza para verificar el guarda el código, pero esto nunca se toca durante la ejecución).

Creo que la cosa más notoria que, sin embargo, es la falta de una máquina virtual de proceso. Al ejecutar la aplicación, no existe un "sandbox" proceso que se ejecuta. Compare esto con Java, donde si abre el administrador de tareas cuando se está ejecutando un programa verás un proceso específicamente para la máquina virtual de Java, y la aplicación real del proceso es un hilo en el interior de la caja de arena creado por la VM. En .Net, vea la aplicación del proceso en el administrador de tareas de Windows directamente.

En resumen: se podría decir que la IL + CLR + JIT juntos de alguna manera hacer una máquina virtual. Personalmente no lo creo, pero no voy a discutir con usted si usted cree que. El punto que quiero hacer es que cuando le dices a alguien que .Net se ejecuta en una máquina virtual sin más explicación, la idea de que se está comunicando a la persona que es ", interpretada código de bytes en un proceso de host." Y eso está mal.

23voto

Heath Hunnicutt Puntos 9801

Similar a la Máquina Virtual de Java (JVM), la .net CLR es un byte de código de interpretación de la máquina virtual.

La JVM interpreta los programas que contienen java códigos de byte y de la .net CLR interpreta los programas que contienen, lo que Microsoft llama "Lenguaje Intermedio (IL) las" instrucciones". Hay diferencias entre estos códigos de byte, pero las máquinas virtuales son similares y aspiran a proporcionar características similares.

Ambas implementaciones de la máquina virtual tiene la capacidad de compilar su entrada de código de bytes para el lenguaje de máquina de la computadora en que se ejecutan. Esto es llamado "Justo a Tiempo de Compilación (JIT)" y el código de salida producido se llama "JIT código." Debido a que el JIT código contienen secuencias de instrucciones en el lenguaje de la máquina de la CPU de la computadora, este código se refiere a veces como "nativo" de código.

Sin embargo, JIT código es cualitativa y cuantitativamente diferente de código nativo, como se explica a continuación. Por esa razón, en este artículo se considera JIT código a ser nada más que un nativo de la implementación de la Máquina Virtual mientras se ejecuta un determinado código de bytes del programa.

Una de las características que estas dos Máquinas Virtuales (VMs) aspiran a proporcionar es la seguridad en la forma de prevenir ciertas peligrosos errores de programación. Por ejemplo, el título de este sitio web, foro, stackoverflow, está inspirado en un tipo de peligrosos error que es posible en código nativo.

Con el fin de proporcionar la seguridad y la seguridad de la ejecución, el VMs implementar tipo de seguridad en la "Máquina Virtual". Las asignaciones de memoria de la máquina virtual son necesarios para almacenar el tipo de datos que se llevan a cabo en ese lugar de la memoria. Por ejemplo, si un entero se inserta en la pila, no es posible pop doble de la pila. C-estilo de "los sindicatos" están prohibidas. Punteros y acceso directo a la memoria están prohibidos.

No pudimos conseguir los mismos beneficios por cumplimiento de un lenguaje orientado a objetos marco de los desarrolladores de si el resultado es un binario nativo como un archivo EXE. En ese caso, podríamos no ser capaces de distinguir entre archivos binarios nativos generado usando el framework y los archivos Exe generado por un usuario malintencionado el empleo de otras fuentes de el marco.

En el caso de las máquinas de votación, el tipo de seguridad se aplica al "nivel más bajo" que el programador está permitido el acceso. (Descuidar por un momento que no es posible escribir administrado código nativo, lo que es.) Por lo tanto, ningún usuario se encontrará con una aplicación que realiza una de las actividades peligrosas que requieren acceso directo a los lugares de la memoria y punteros.

En la práctica, la .net CLR implementa una forma de escribir código nativo que puede ser llamado por .net "administrado" de código. En este caso, la carga está en el código nativo autor de no hacer que el puntero de memoria y errores.

Como tanto la JVM y .net CLR realizar la compilación JIT, ya sea VM en realidad crea un nativo binario compilado desde el código de bytes que se suministra. Este "JIT" código se ejecuta más rápidamente que el VM del intérprete de ejecución, porque incluso el lenguaje de la máquina el código producido por JIT contiene todas las VM se necesita comprobaciones de seguridad que la VM que iba a realizar. Como resultado, el JIT código de salida no es tan rápido como código nativo que por lo general no contienen numerosas comprobaciones en tiempo de ejecución. Sin embargo, esta velocidad de rendimiento inconveniente es intercambiado por una mejora de la fiabilidad, incluida la seguridad; en particular, el uso de no inicializada de almacenamiento es impedido, de seguridad de tipo de tareas es forzada, la comprobación de rango en que se realiza (por lo tanto de la pila y el montón basado en los desbordamientos de búfer impedido), la duración de los objetos son administrados por la recolección de basura, la asignación dinámica es el tipo de seguro. Un entorno de ejecución de tal comportamiento en tiempo de ejecución control de la implementación de la especificación de una máquina virtual y es poco más que un lenguaje de máquina de la realización de una máquina virtual.

17voto

QrystaL Puntos 2606

Brad Abrams: Es el CLR de una Máquina Virtual?

6voto

RichAmberale Puntos 3294

La "Máquina Virtual" que parte se refiere al hecho de que .NET de código se compila en EXE y DLL como "Intermedio" lenguaje ensamblador (IL) para que se ejecute en una máquina virtual, como contraposición a la real de la CPU lenguaje ensamblador. Luego, en tiempo de ejecución de la ILM se convierte en real de la CPU de la asamblea para su ejecución (conocido como Just-in-time, o la compilación JIT).

Claro, usted podría escribir una .NET compilador para que se compilarán en la CPU lenguaje ensamblador en lugar de IL. Sin embargo, este no sería el portátil a todas las CPUs - tendrías que compilar una versión diferente para cada OS/CPU par. Pero al compilar en ILM, deja que la "Máquina Virtual" de la manija de la CPU y el sistema operativo específico cosas.

2voto

Ben Lakey Puntos 5454

La ventaja de la CLR es la libertad para escribir código en cualquier lenguaje de programación el programador elige, ya que el código se compilará abajo a CLR antes de ser interpretado en nativos de llamadas. El .NET framework utiliza esta compilación JIT para tratar todo de manera uniforme y salida de los programas que trabajan para la plataforma desplegada la aplicación, que está ausente de los lenguajes compilados.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X