Por que a JVM baseada em pilha e a Dalvik VM baseada em registro?

Estou curioso, por que a Sun decidiu fazer o JVM baseado em pilha e o Google decidiu fazer o DalvikVM baseado em registro?

Suponho que a JVM não pode realmente assumir que um certo número de registros estão disponíveis na plataforma de destino, uma vez que é suposto ser independente da plataforma. Portanto, ele apenas adia a alocação de registro, etc., para o compilador JIT. (Corrija-me se eu estiver errado.)

Então os caras do Android pensaram, "ei, isso é ineficiente, vamos começar a usar uma VM baseada em registro imediatamente ..."? Mas espere, existem vários dispositivos Android diferentes, que número de registros o Dalvik tinha como alvo? Os opcodes Dalvik são codificados para um determinado número de registros?

Todos os dispositivos Android atuais no mercado têm aproximadamente o mesmo número de registros? Ou, há uma realocação de registro realizada durante o carregamento dex? Como tudo isso se encaixa?

Existem alguns atributos de uma VM baseada em pilha que se adaptam bem aos objetivos de design do Java:

1. Um design baseado em pilha faz poucas suposições sobre o hardware de destino (registradores, recursos da CPU), portanto, é fácil implementar uma VM em uma ampla variedade de hardware.

2. Como os operandos para instruções são amplamente implícitos, o código-objeto tenderá a ser menor. Isso é importante se você for fazer download do código por um link de rede lento.

Adotar um esquema baseado em registro provavelmente significa que o gerador de código da Dalvik não precisa trabalhar tanto para produzir código de bom desempenho. Rodar em uma arquitetura extremamente rica em registros ou pobre em registros provavelmente prejudicaria o Dalvik, mas esse não é o alvo usual - ARM é uma arquitetura intermediária.

Eu também tinha esquecido que a versão inicial do Dalvik não incluía um JIT. Se você vai interpretar as instruções diretamente, um esquema baseado em registro é provavelmente um vencedor para desempenho de interpretação.

Não consigo encontrar uma referência, mas acho que a Sun decidiu pela abordagem de bytecode baseada em pilha porque torna mais fácil executar a JVM em uma arquitetura com poucos registros (por exemplo, IA32).

Em Dalvik VM Internals do Google I / O 2008, o criador da Dalvik Dan Bornstein apresenta os seguintes argumentos para escolher uma VM baseada em registro no slide 35 dos slides da apresentação :

Maquina registradora

Por quê?

• evite o envio de instruções
• evite acesso desnecessário à memória
• consumir fluxo de instrução de forma eficiente (maior densidade semântica por instrução)

e no slide 36:

Maquina registradora

As estatísticas

• 30% menos instruções
• 35% menos unidades de código
• 35% mais bytes no fluxo de instruções
  • mas podemos consumir dois de cada vez

De acordo com Bornstein, esta é "uma expectativa geral o que você pode encontrar ao converter um conjunto de arquivos de classe em arquivos dex".

A parte relevante do vídeo de apresentação começa às 25:00 .

Há também um artigo perspicaz intitulado "Virtual Machine Showdown: Stack Versus Registers" por Shi et al. (2005) , que explora as diferenças entre máquinas virtuais baseadas em pilha e em registro.

Não sei por que a Sun decidiu fazer uma pilha JVM baseada. Máquina virtual Erlangs, BEAM é baseado em registro por motivos de desempenho. E a Dalvik também parece ser baseada em registros por motivos de desempenho.

Do Pro Android 2 :

Dalvik usa registradores principalmente como unidades de armazenamento de dados ao invés da pilha. Como resultado, o Google espera realizar 30% menos instruções.

E quanto ao tamanho do código:

O Dalvik VM pega os arquivos de classe Java gerados e os combina em um ou mais arquivos Dalvik Executables (.dex). Ele reutiliza informações duplicadas de vários arquivos de classe, reduzindo efetivamente o requisito de espaço (descompactado) pela metade do arquivo .jar tradicional. Por exemplo, o arquivo .dex do aplicativo do navegador da web no Android tem cerca de 200k, enquanto a versão .jar não compactada equivalente tem cerca de 500k. O arquivo .dex do despertador tem cerca de 50k e quase o dobro desse tamanho na versão .jar.

E, pelo que me lembro, Computer Architecture: A Quantitative Approach, também concluo que uma máquina de registro tem um desempenho melhor do que uma máquina baseada em pilha.