que - ¿Por qué la JVM se basa en la pila y la Dalvik VM está basada en registros?
qué es la máquina virtual de dalvik (3)
Tengo curiosidad, ¿por qué Sun decidió hacer la JVM basada en la pila y Google decidió hacer la base de registro de DalvikVM?
Supongo que la JVM realmente no puede suponer que hay una cierta cantidad de registros disponibles en la plataforma de destino, ya que se supone que es independiente de la plataforma. Por lo tanto, simplemente pospone la asignación de registros, etc., al compilador JIT. (Corrígeme si estoy equivocado.)
Entonces, los chicos de Android pensaron: "hey, eso es ineficiente, vamos a buscar un vM basado en registro de inmediato ..."? Pero espere, hay múltiples dispositivos Android diferentes, ¿a cuántos registros se dirigió Dalvik? ¿Están codificados los códigos de operación de Dalvik para un cierto número de registros?
¿Todos los dispositivos Android actuales en el mercado tienen aproximadamente la misma cantidad de registros? O bien, ¿hay una reasignación de registros realizada durante la carga de dex? ¿Cómo encaja todo esto?
Hay algunos atributos de una máquina virtual basada en pila que encajan bien con los objetivos de diseño de Java:
Un diseño basado en pila hace muy pocas suposiciones sobre el hardware de destino (registros, características de CPU), por lo que es fácil implementar una VM en una amplia variedad de hardware.
Como los operandos para las instrucciones son en gran parte implícitos, el código del objeto tenderá a ser más pequeño. Esto es importante si va a descargar el código a través de un enlace de red lento.
Ir con un esquema basado en registro probablemente significa que el generador de código de Dalvik no tiene que trabajar tan duro para producir el código de rendimiento. Correr en una arquitectura extremadamente rica en registros o pobre en registros probablemente sea una desventaja para Dalvik, pero ese no es el objetivo habitual: ARM es una arquitectura muy de la mitad de la carretera.
También había olvidado que la versión inicial de Dalvik no incluía un JIT en absoluto. Si vas a interpretar las instrucciones directamente, entonces un esquema basado en registro es probablemente un ganador para el rendimiento de la interpretación.
No puedo encontrar una referencia, pero creo que Sun decidió el enfoque de código de bytes basado en la pila porque hace que sea más fácil ejecutar la JVM en una arquitectura con pocos registros (por ejemplo, IA32).
En Dalvik VM Internals de Google I / O 2008, el creador de Dalvik Dan Bornstein ofrece los siguientes argumentos para elegir una máquina virtual basada en registro en la diapositiva 35 de las diapositivas de la presentación :
Registrar la máquina
¿Por qué?
- evitar el envío de instrucciones
- evitar el acceso innecesario a la memoria
- consume la secuencia de instrucciones de manera eficiente (mayor densidad semántica por instrucción)
y en la diapositiva 36:
Registrar la máquina
Las estadísticas
- 30% menos de instrucciones
- 35% menos unidades de código
- 35% más de bytes en la secuencia de instrucciones
- pero podemos consumir dos a la vez
Según Bornstein, esto es "una expectativa general de lo que podrías encontrar al convertir un conjunto de archivos de clase a archivos dex".
La parte relevante del video de presentación comienza a las 25:00 .
No sé por qué Sun decidió hacer la pila de JVM. Máquina virtual Erlangs, BEAM se registra por motivos de rendimiento. Y Dalvik también parece estar basado en registros por motivos de rendimiento.
De Pro Android 2 :
Dalvik utiliza registros como unidades principalmente de almacenamiento de datos en lugar de la pila. Google espera lograr un 30 por ciento menos de instrucciones como resultado.
Y con respecto al tamaño del código:
La máquina virtual de Dalvik toma los archivos de clase Java generados y los combina en uno o más archivos ejecutables de Dalvik (.dex). Reutiliza información duplicada de múltiples archivos de clase, reduciendo efectivamente el espacio requerido (sin comprimir) a la mitad del archivo .jar tradicional. Por ejemplo, el archivo .dex de la aplicación de navegador web en Android es de aproximadamente 200k, mientras que la versión .jar sin comprimir equivalente es de aproximadamente 500k. El archivo .dex del reloj de alarma tiene aproximadamente 50k, y aproximadamente el doble de ese tamaño en su versión .jar.
Y como recuerdo Computer Architecture: A Quantitative Approach también concluye que una máquina de registro funciona mejor que una máquina basada en pila.