Perché la JVM stack-based e basata registrarsi Dalvik VM?

Question

Sono curioso, perché Sun decide di fare dello stack basata la JVM e Google decidono di fare basato su registri il DalvikVM?

Suppongo che la JVM non può davvero dare per scontato che un certo numero di registri sono disponibili sulla piattaforma di destinazione, in quanto si suppone che sia indipendente dalla piattaforma. Perciò solo rimanda al registro-allocazione, ecc, per il compilatore JIT. (Correggetemi se sbaglio).

Così i ragazzi di Android pensato, "hey, questo è inefficiente, andiamo a fare una macchina virtuale basata registro subito ..."? Ma l'attesa, ci sono più dispositivi Android diversi, quale numero di registri ha fatto il bersaglio Dalvik? Sono i codici operativi Dalvik hardcoded per un certo numero di registri?

Non tutti gli attuali dispositivi Android sul mercato hanno circa lo stesso numero di registri? Oppure, c'è un registro riallocazione eseguita durante dex-caricamento? Come c'entra tutto questo insieme?

Answer 1

Ci sono alcuni attributi di una macchina virtuale basato su stack che si adattano bene con i concetti di base di Java:

1. Un design stack-based rende molto pochi ipotesi circa la destinazione hardware (registri, caratteristiche della CPU), quindi è facile da implementare una VM su un ampia gamma di hardware.

2. Dato che gli operandi per le istruzioni sono in gran parte implicita, l'oggetto Codice tenderà ad essere più piccoli. Questo è importante se si sta andando ad essere il download del codice nel corso di un lento rete di collegamento.

Vuoi utilizzare uno schema basato su registri probabilmente significa che il generatore di codice di Dalvik non deve lavorare duro per produrre codice performante. In esecuzione su un registro estremamente ricco o registrati poveri architettura sarebbe probabilmente handicap Dalvik, ma non è il solito bersaglio -. ARM è un'architettura molto middle-of-the-road

---

I aveva anche dimenticato che la versione iniziale di Dalvik non include un JIT a tutti. Se avete intenzione di interpretare direttamente le istruzioni, quindi uno schema basato su registri è probabilmente un vincitore per le prestazioni di interpretazione.

Answer 2

Non riesco a trovare un riferimento, ma penso che Sun ha deciso per l'approccio bytecode stack-based perché rende facile eseguire il JVM su un'architettura con alcuni registri (ad esempio IA32).

VM Dalvik Internals da Google I / O 2008, il Dalvik creatore Dan Bornstein dà i seguenti argomenti per la scelta di una macchina virtuale basato su registri sulla slitta 35 della slide di presentazione :

  

Registrati macchina

     

Perché?

     

  
• istruzioni evitare di spedizione
  
• evitare inutili accesso alla memoria
  
• consumare flusso di istruzioni in modo efficiente (più alta densità semantica per istruzione)
  

e sul vetrino 36:

  

Registrati macchina

     

Le statistiche

     

  
• 30% in meno di istruzioni
  
• 35% in meno di unità di codice
  
• 35% in più byte nel flusso di istruzioni      
    
  • , ma si arriva a consumare due alla volta   
  

Secondo Bornstein si tratta di "una generale aspettativa quello che si poteva trovare quando si converte un insieme di file di classe per i file DEX".

La parte rilevante dei inizia video di presentazione a 25:00 .

C'è anche un documento dal titolo perspicace "Virtual Machine Showdown: Stack Versus Registri" di Shi et al. (2005) , che esplora le differenze tra le macchine virtuali e basati su stack- registro.

Answer 3

Non so il motivo per cui Sun ha deciso di fare base JVM stack. Erlangs macchina virtuale, BEAM è registrarsi basa per motivi di prestazioni. E Dalvik sembrano anche essere basata registro a causa di motivi di prestazioni.

Pro Android 2 :

  

Dalvik utilizza registri principalmente come unità di memorizzazione dati invece della pila. Google spera di raggiungere il 30 per cento un minor numero di istruzioni di conseguenza.

E per quanto riguarda la dimensione del codice:

  

Il Dalvik VM prende i file di classe Java generati e li combina in una o più Dalvik eseguibili (.dex) file. Riutilizza le informazioni duplicate da file di classe multipli, riducendo il fabbisogno di spazio (non compresso) della metà da file .jar tradizionale. Ad esempio, il file .dex del browser web app in Android è di circa 200k, mentre la versione non compressa .jar equivalente è di circa 500k. Il file .dex della sveglia è di circa 50k, e circa due volte quella dimensione nella sua versione .jar.

E come mi ricordo Computer Architecture: A Quantitative Approach anche concludere che un registrare la macchina esegue meglio di una macchina basata stack.