¿Por qué la JVM está basada en pila y la VM de Dalvik basada en registros?

Tengo curiosidad, ¿por qué Sun decidió hacer que la JVM se basara en pilas y Google decidió hacer que DalvikVM se basara en registros?

Supongo que la JVM realmente no puede asumir que una cierta cantidad de registros están 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 me equivoco.)

Entonces, los chicos de Android pensaron, "oye, eso es ineficiente, vamos a buscar una máquina virtual basada en registros de inmediato ...". Pero espere, hay varios dispositivos Android diferentes, ¿a qué número de registros apuntó Dalvik? ¿Están codificados los códigos de operación de Dalvik para un cierto número de registros?

¿Todos los dispositivos Android actuales del mercado tienen aproximadamente el mismo número de registros? O, ¿se realiza una reasignación de registros durante la carga 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:

1. Un diseño basado en pila hace muy pocas suposiciones sobre el hardware de destino (registros, características de la CPU), por lo que es fácil implementar una máquina virtual en una amplia variedad de hardware.

2. Dado que los operandos de las instrucciones son en gran parte implícitos, el código 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 registros probablemente signifique que el generador de código de Dalvik no tiene que trabajar tan duro para producir un código eficaz. Ejecutar en una arquitectura extremadamente rica en registros o con pocos registros probablemente perjudicaría a Dalvik, pero ese no es el objetivo habitual: ARM es una arquitectura muy intermedia.

También había olvidado que la versión inicial de Dalvik no incluía un JIT en absoluto. Si va a interpretar las instrucciones directamente, entonces un esquema basado en registros probablemente sea un ganador para el desempeño de la interpretación.

No puedo encontrar una referencia, pero creo que Sun se decidió por el enfoque de código de bytes basado en pila porque facilita la ejecución de 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 VM basada en registros en la diapositiva 35 de las diapositivas de la presentación :

Registrar máquina

¿Por qué?

• evitar el envío de instrucciones
• evitar el acceso innecesario a la memoria
• consumir el flujo de instrucciones de manera eficiente (mayor densidad semántica por instrucción)

y en la diapositiva 36:

Registrar máquina

Las estadísticas

• 30% menos de instrucciones
• 35% menos de unidades de código
• 35% más de bytes en el flujo de instrucciones
  • pero llegamos a consumir dos a la vez

Según Bornstein, esto es "una expectativa general de lo que puede encontrar cuando convierte un conjunto de archivos de clase en archivos dex".

La parte relevante del video de presentación comienza a las 25:00 .

También hay un artículo revelador titulado "Virtual Machine Showdown: Stack Versus Registers" de Shi et al. (2005) , que explora las diferencias entre máquinas virtuales basadas en registros y en pilas.

No sé por qué Sun decidió hacer una pila JVM. La máquina virtual de Erlangs, BEAM se basa en registros por razones de rendimiento. Y Dalvik también parece estar basado en registros debido a razones de rendimiento.

Desde Pro Android 2 :

Dalvik utiliza los registros principalmente como unidades de almacenamiento de datos en lugar de la pila. Como resultado, Google espera lograr un 30 por ciento menos de instrucciones.

Y con respecto al tamaño del código:

La máquina virtual Dalvik toma los archivos de clase Java generados y los combina en uno o más archivos Dalvik Executables (.dex). Reutiliza información duplicada de varios archivos de clase, reduciendo efectivamente el requisito de espacio (sin comprimir) a la mitad del archivo .jar tradicional. Por ejemplo, el archivo .dex de la aplicación del 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 despertador es de aproximadamente 50k, y aproximadamente el doble de ese tamaño en su versión .jar.

Y, según recuerdo, Computer Architecture: A Quantitative Approach también concluyo que una máquina de registro funciona mejor que una máquina basada en pilas.