Perché la JVM è basata sullo stack e la Dalvik VM è basata sul registro?

Sono curioso, perché Sun ha deciso di rendere la JVM basata sullo stack e Google ha deciso di rendere la DalvikVM basata sul registro?

Suppongo che la JVM non possa davvero presumere che un certo numero di registri sia disponibile sulla piattaforma di destinazione, poiché dovrebbe essere indipendente dalla piattaforma. Quindi rimanda semplicemente l'allocazione dei registri, ecc., Al compilatore JIT. (Correggimi se sbaglio.)

Quindi i ragazzi di Android hanno pensato, "ehi, è inefficiente, andiamo subito per un vm basato su registri ..."? Ma aspetta, ci sono più dispositivi Android diversi, quale numero di registri ha preso di mira il Dalvik? Gli opcode Dalvik sono codificati per un certo numero di registri?

Tutti gli attuali dispositivi Android sul mercato hanno circa lo stesso numero di registri? Oppure, è stata eseguita una riallocazione del registro durante il caricamento del dex? Come funziona tutto questo insieme?

Ci sono alcuni attributi di una VM basata su stack che si adattano bene agli obiettivi di progettazione di Java:

1. Un design basato su stack fa pochissime supposizioni sull'hardware di destinazione (registri, funzionalità della CPU), quindi è facile implementare una VM su un'ampia varietà di hardware.

2. Poiché gli operandi per le istruzioni sono in gran parte impliciti, il codice dell'oggetto tenderà ad essere più piccolo. Questo è importante se stai per scaricare il codice su un collegamento di rete lento.

Andare con uno schema basato su registri probabilmente significa che il generatore di codice di Dalvik non deve lavorare così duramente per produrre codice performante. L'esecuzione su un'architettura estremamente ricca di registri o povera di registri probabilmente ostacolerebbe Dalvik, ma questo non è il solito obiettivo: ARM è un'architettura molto a metà strada.

Avevo anche dimenticato che la versione iniziale di Dalvik non includeva affatto un JIT. Se intendi interpretare le istruzioni direttamente, allora uno schema basato su registri è probabilmente un vincitore per le prestazioni di interpretazione.

Non riesco a trovare un riferimento, ma penso che Sun abbia deciso per l'approccio bytecode basato su stack perché rende facile eseguire la JVM su un'architettura con pochi registri (ad es. IA32).

In Dalvik VM Internals da Google I / O 2008, il creatore di Dalvik Dan Bornstein fornisce i seguenti argomenti per la scelta di una VM basata su registro nella diapositiva 35 delle diapositive della presentazione :

Registra macchina

Perché?

• evitare l'invio di istruzioni
• evitare accessi inutili alla memoria
• consumare il flusso di istruzioni in modo efficiente (densità semantica più alta per istruzione)

e sulla diapositiva 36:

Registra macchina

Le statistiche

• 30% di istruzioni in meno
• 35% di unità di codice in meno
• 35% di byte in più nel flusso di istruzioni
  • ma possiamo consumarne due alla volta

Secondo Bornstein questa è "un'aspettativa generale che cosa potresti trovare quando converti un insieme di file di classe in file dex".

La parte rilevante del video di presentazione inizia alle 25:00 .

C'è anche un approfondito documento intitolato "Virtual Machine Showdown: Stack Versus Registers" di Shi et al. (2005) , che esplora le differenze tra macchine virtuali basate su stack e registrate.

Non so perché Sun abbia deciso di creare una JVM basata sullo stack. Macchina virtuale Erlangs, BEAM è basata sul registro per motivi di prestazioni. E anche Dalvik sembra essere basato sui registri per motivi di prestazioni.

Da Pro Android 2 :

Dalvik utilizza i registri principalmente come unità di archiviazione dei dati invece che come stack. Di conseguenza, Google spera di ottenere il 30% di istruzioni in meno.

E per quanto riguarda la dimensione del codice:

La Dalvik VM prende i file di classe Java generati e li combina in uno o più file Dalvik Executables (.dex). Riutilizza le informazioni duplicate da più file di classe, riducendo in modo efficace lo spazio richiesto (non compresso) della metà rispetto al file .jar tradizionale. Ad esempio, il file .dex dell'app browser Web in Android è di circa 200k, mentre la versione equivalente non compressa di .jar è di circa 500k. Il file .dex della sveglia è di circa 50k e circa il doppio di quella dimensione nella sua versione .jar.

E mentre ricordo Computer Architecture: A Quantitative Approach concludo anche che una macchina a registro funziona meglio di una macchina basata su stack.