Warum ist die JVM-Stack-basierten und die Dalvik VM registerbasierte?

Question

Ich bin neugierig, warum Sun entscheiden, die JVM-Stack-basierten zu machen und Google entscheidet die DalvikVM registergestützter machen?

Ich nehme an, die JVM kann nicht wirklich davon ausgehen, dass eine bestimmte Anzahl von Registern auf der Zielplattform zur Verfügung stehen, da es sollte plattformunabhängig sein. Dafür ist es verschiebt nur die Registerzuweisung usw., an den JIT-Compiler. (Korrigiert mich wenn ich falsch liege).

So ist die Android Jungs dachten: „Hey, das ineffizient ist, geht sie für ein Register basierend vm sofort ...“? Aber warten Sie, es gibt mehrere verschiedene Android-Geräte, welche Anzahl von Registern hat die Dalvik Ziel? Ist die Dalvik Opcodes für eine bestimmte Anzahl von Registern fest einprogrammiert?

Sie alle aktuellen Android-Geräte auf dem Markt etwa die gleiche Anzahl von Registern haben? Oder gibt es ein Register Neuzuweisung während Dex-Laden durchgeführt? Wie funktioniert das alles zusammen?

Answer 1

Es gibt ein paar Attribute eines Stack-basierten VM, die passen gut mit Java-Design Ziele:

1. Ein Stapel-basiertes Design macht nur sehr wenige Annahmen über das Ziel Hardware (Register, CPU-Funktionen), so ist es einfach, eine VM auf einem implementieren Vielzahl von Hardware.

2. Da die Operanden für Befehle das Objekt weitgehend implizit sind, Code wird dazu neigen, kleiner zu sein. Dies wichtig ist, wenn Sie sein werden Herunterladen des Codes über eine langsame Netzwerkverbindung.

Möchten Sie ein Register-basiertes Schema bedeutet wahrscheinlich, dass Dalvik des Code-Generator nicht zur Arbeit hat so hart performant Code zu erzeugen. Laufen auf eine extrem registrieren reicht oder registrieren arme Architektur würde wahrscheinlich Handicap Dalvik, aber das ist nicht das übliche Ziel -. ARM ist eine sehr middle-of-the-Road-Architektur

---

Ich hatte auch vergessen, dass die erste Version von Dalvik nicht enthalten einen JIT überhaupt. Wenn Sie die Anweisungen direkt zu interpretieren gehen, dann eine registerbasierte Regelung ist wahrscheinlich ein Gewinner für die Interpretation Leistung.

Answer 2

Ich kann keine Referenz finden, aber ich denke, Sun für den Stack-basierte Bytecode-Ansatz entschieden, weil es macht es einfach, die JVM auf einer Architektur mit wenigen Registern laufen (zum Beispiel IA32).

Dalvik VM Internals von Google I / O 2008 die Dalvik Schöpfer Dan Bornstein für die Auswahl eines registerbasierte VM auf Folie 35 der Präsentationsfolien

Register Maschine

Warum?

• vermeiden Befehlsausgabe
• Vermeiden unnötiger Speicherzugriff
• verbrauchen Befehlsstrom effizient (höhere semantische Dichte pro Befehl)

und auf Folie 36:

Register Maschine

Die Statistik

• 30% weniger Anweisungen
• 35% weniger Codeeinheiten
• 35% mehr Bytes in den Anweisungen Strom
  • aber wir bekommen zwei auf einmal verbrauchen

Nach Börnstein dies „eine allgemeine Erwartung, was man finden kann, wenn Sie eine Reihe von Klassendateien dex-Dateien konvertieren“.

Der relevante Teil der Präsentationsvideo beginnt bei 25:00 .

Es gibt auch eine interessante Abhandlung mit dem Titel "Virtual Machine Showdown: Stack Versus Register“von Shi et al. (2005) , die die Unterschiede zwischen Stapel- und registergestützten virtuellen Maschinen untersucht.

Answer 3

Ich weiß nicht, warum Sun entschieden JVM-Stack basieren. Erlang virtuelle Maschine wird BEAM Basis aus Performance-Gründen registrieren. Und Dalvik scheinen auch wegen der Performance-Gründen zu werden Register basiert.

Pro Android 2 :

Dalvik verwendet Register, wie in erster Linie Einheiten von Datenspeicherung anstelle des Stapels. Google hofft, dass 30 Prozent weniger Anweisungen als Ergebnis zu erreichen.

Und in Bezug auf die Codegröße:

Die Dalvik VM nimmt die erzeugten Java-Klassen-Dateien und kombiniert sie zu einem oder mehreren Dalvik Executables (.dex-Dateien). Es wieder verwendet doppelte Informationen aus mehreren Klassendateien, effektiv den Platzbedarf (unkomprimiert) um die Hälfte von traditioneller .jar-Datei zu reduzieren. Zum Beispiel ist die .dex-Datei der Web-Browser App in Android über 200k, während die äquivalente unkomprimierte .jar Version über 500k ist. Die .dex Datei des Weckers ist etwa 50k, und etwa doppelt so groß in seiner .jar Version.

Und wie ich Rechnerarchitektur erinnern: ein quantitativer Ansatz schließen auch, dass ein registrieren Maschine besser als ein Stapel basierte Maschine.