Vergleich unterschiedlicher virtueller Maschinen

Transkript

1 Vergleich unterschiedlicher virtueller Maschinen Seminar: Compiler-Konstruktion Fachbereich Programmiersprachen und Übersetzer Philipp Bähre

2 Gliederung: Einführung Operandenstack und virtuelle Register Vergleich Stack- und Registerbasierte VM - Bytecode - Performance Parrot VM - Überblick - Memory Allocation Alternativer Garbage Collecting Algorithmus - Tri-Color Mark 2

3 Operandenstack und virtuelle Register: Operandenstack Beliebig großer Stack Schneller Zugriff auf Operanden auf dem Stack Einfügeposition / Leseposition ist bekannt Zugriff nur auf oberstes Element Einfacher Bytecode virtuelle Register für Operanden Begrenzte Anzahl virtueller Register Einfügeposition / Leseposition muss gefunden werden Zugriff auf alle Register Explizite Registeradressierung im Bytecode 3

4 Performance: Zusammensetzung der Kosten für die Ausführung eines Bytecode Befehls auf einer virtuellen Maschine: Instruction Dispatch (Abrufen, Übersetzen und Starten des Befehls) Operandenzugriff (Speicherposition finden und Wert auslesen/schreiben) Ausführen der Berechnung 4

5 Operandenzugriff explizit: Zeitbedarf für Operandenzugriff bei Befehlen mit explizit angegebenen Operanden ergibt sich aus: z.b.: iload a Finden der Speicherposition (aus Befehl decodieren) Eigentlicher Zugriff auf den Operanden 5

6 Operandenzugriff implizit: Zugriffe auf den Stack sind daher bedeutend schneller: z.b.: iadd Speicherpositionen der Operanden sind bekannt Dekodieren aus Befehl entfällt Schneller Zugriff auf Operanden bei reinen Stack Operationen 6

7 Beispiel: Variablenzuweisung a = b + c in Java-Bytecode: iload c iload b iadd istore a 3 Adress-Bytecode: iload v1, b iload v2, c iadd v3, v1, v2 istore a, v3 Read c, Write to Stack Read b, Write to Stack Read Stack, Read Stack, Write to Stack Read from Stack, Write a Read b, Write to v1 Read c, Write to v2 Read v1, Read v2, Write to v3 Read v3, Write a 7

8 Beispiel: Variablenzuweisung a = b + c in Java-Bytecode: iload c iload b iadd istore a 3 Adress-Bytecode: iload v1, b iload v2, c iadd v3, v1, v2 istore a, v3 5 Leseoperationen + 4 Schreiboperationen 5 Leseoperationen + 4 Schreiboperationen => gleiche Kosten, aber größerer Bytecode 8

9 Beispiel: Annahme: 1 Byte pro Operand Explizite Unterscheidung zwischen lokaler Variable und Register iload v1, b iload v2, c iadd v3, v1, v2 istore a, v3 iadd a, b, c 8 Bit 256 Lokale Variablen Register 1 7 Bit 128 Lokale Variablen Register 1 Unterscheidungs Bit 7 Bit Adressierung 9

10 Instruction Dispatch: in Java-Bytecode: iload c iload b iadd istore a 3 Adress-Bytecode: iadd a, b, c 4 mal Dispatch 1 mal Dispatch Registerbasierte VM reduziert Anzahl der Dispatches Tatsächlicher Performanzgewinn? 10

11 Instruction Dispatch: Befehl aus Bytecode laden Befehl dekodieren (switch dispatch, table dispatch) Operanden-Adressen aus Bytecode dekodieren Erzeugen und Ausführen des Maschinencodes 11

12 Performance: Instruction Dispatch weniger Dispatches bei registerbasierter Architektur, aber größere Bytecodebefehle Operandenzugriff vergleichbare Kosten für beide Architekturen Ausführen der Berechnung vergleichbare Kosten für beide Architekturen 12

13 Registerallokation Stack VM: Zuweisung Stackposition => Maschinenregister e5 e4 e3 e2 e1 r4 r3 r2 r1 r4 r3 r2 r1 Maschinenregister 13

14 Registerallokation Register VM: Direkte Abbildung virtuelle Register => Maschinenregister Einfacher als Zuweisung Stackposition => Maschinenregister v1 v2 v3 v4 v5 v6... vn Virtuelle Register r1 r2 r3 r4 Maschinenregister 14

15 Beschränkung durch Architektur: Performancegewinn bei Registerbasierter VM stark abhängig von der Zielarchitektur z.b. x86 Architektur: 4 allgemeine Register AX,BX,CX,DX spezielle opcodes für einzelne Register ( [AX]++ => 04h, [BX]++ => 80C3h ) Eventuell nicht alle Register für alle Operationen verwendbar z.b. ARM Architektur: 16 Register konsistent verwendbar 15

16 Auswirkungen auf die Performance: Register VM Bytecode-Befehl ist 4 Byte groß (Maschinenwort) Operandenadressierung 1 Byte 256 (128) virtuelle Register (evtl. zusätzliche Speicherzugriffe) Befehle in 3AdressCode werden im Schnitt zu mehr Assembler Befehlen Verschiedene mögliche Dispatch Implementierungen (threaded Dispatch, Switch dispatch...) Zielarchitektur Auswirkungen von JIT Compiling nicht untersucht 16

17 Ausführungszeit: Formel zur Annäherung der Ausführungszeit: t(vrm) t(vsm) #dispatches * t(dispatch) + #fetches * t(fetch) 17

18 Statistiken zur Performance: DalvikVM: 35% mehr Bytes für den Bytecode 30% weniger Bytecode Befehle 35% weniger Maschinenbefehle Tests mit Lua und Parrot: 44,81% mehr Bytes für den Bytecode 34,88% weniger Bytecode Befehle 18

19 Beispiel Dalvik Bytecode: public static long sumarray(int[] arr) { long sum = 0; for (int i : arr) { sum += i; } return sum; } Kompiliert in Java Bytecode Crosscompiler dx kompiliert Java Bytecode zu Dalvik Bytecode 19

20 Beispiel Dalvik Bytecode: 0000: lconst_0 0001: lstore_1 0002: aload_0 0003: astore_3 0004: aload_3 0005: arraylength 0006: istore : iconst_0 0009: istore b: iload d: iload f: if_icmpge : aload_3 0013: iload : iaload 0016: istore : lload_1 0019: iload b: i2l 001c: ladd 001d: lstore_1 001e: iinc 05, # : goto 000b 0024: lload_1 0025: lreturn 0000: const-wide/16 v0, #long : array-length v2, v8 0003: const/4 v3, #int : move v7, v3 0005: move-wide v3, v0 0006: move v0, v7 0007: if-ge v0, v2, : aget v1, v8, v0 000b: int-to-long v5, v1 000c: add-long/2addr v3, v5 000d: add-int/lit8 v0, v0, #int 1 000f: goto : return-wide v3 20

21 Beispiel Dalvik Bytecode: 0000: lconst_0 0001: lstore_1 0002: aload_0 0003: astore_3 0004: aload_3 0005: arraylength 0006: istore : iconst_0 0009: istore b: iload d: iload f: if_icmpge : aload_3 0013: iload : iaload 0016: istore : lload_1 0019: iload b: i2l 001c: ladd 001d: lstore_1 001e: iinc 05, # : goto 000b 0024: lload_1 0025: lreturn Java Bytecode: 25 Bytecode-Befehle 36 Byte Bytecode 21

22 Beispiel Dalvik Bytecode: Dalvik Bytecode 13 Bytecode-Befehle 40 Byte Bytecode Java Bytecode 25 Bytecode-Befehle 36 Byte Bytecode Ergebniss: 48% weniger Bytecode Befehle 11% größerer Bytecode 0000: const-wide/16 v0, #long : array-length v2, v8 0003: const/4 v3, #int : move v7, v3 0005: move-wide v3, v0 0006: move v0, v7 0007: if-ge v0, v2, : aget v1, v8, v0 000b: int-to-long v5, v1 000c: add-long/2addr v3, v5 000d: add-int/lit8 v0, v0, #int 1 000f: goto : return-wide v3 22

23 Parrot VM: Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a.net bytecode translator. -parrot.org Registerbasiert Unterstützt dynamische Typisierung Ermöglicht Interaktionen zwischen allen kompilierten Sprachen Crosscompiler (Trennung von Compiler und VM) Plattformunabhängiger eigener Bytecode 4 verschiedene Registertypen für: - integers, numbers, strings und Polymorphic Containers (PMCs) 23

24 Parrot VM: Compiler / Crosscompiler verfügbar für: * abc An implementation of bc * APL An implementation of APL * BASIC An implementation of BASIC * befunge An implementation of Befunge-93 * bf An implementation of Brainf**k * c99 An implementation of C, C99 dialect * Cardinal An implementation of Ruby 1.9 * chitchat An implementation of Smalltalk * dotnet A.Net bytecode translator * eclectus An implementation of Scheme * ecmascript An implementation of ECMAScript * forth An implementation of Forth * fun An implementation of Joy * gil Generic Imperative Language * hq9plus An implementation of HQ9 Plus * jako An implementation of Jako * jvm A Java VM bytecode translator * json An implementation of JSON * Kea-CL An implementation of Common Lisp * lazy-k An implementation of Lazy K * lisp An implementation of LISP * lolcode An implementation of LOLCODE * lua An implementation of Lua 5.1 * Lua2PIR An implementation of Lua 5.1 * matrixy An implementation of Octave * m4 An implementation of GNU m4 * markdown An implementation of Markdown * NQP A lightweight language used in Parrot's compiler tools * Monkey An implementation of Lua 5.1 * ook An implementation of Ook! * partcl An implementation of Tcl * pheme An implementation of Scheme * Perk An implementation of Java * Pipp An implementation of PHP * Pirate An implementation of Python * PJS An implementation of ECMAScript * primitivearc An implementation of Arc * Punie An implementation of Perl 1.0 * Pynie An implementation of Python * Rakudo Perl 6 An implementation of Perl 6 * scheme An implementation of Scheme * Scheme to PIR with Chicken An implementation of Scheme * shakespeare-parrot An implementation of Shakespeare * squaak A tutorial language * unlambda An implementation of Unlambda * WMLScript An implementation of WMLScript 24

25 Memory Allocation Arena: Parrot reserviert Speicher in Blocks die Arena genant werden. Eine Arena kann genau N Objekte der Größe M enthalten und liegt dicht im Speicher Arena1[x] Arena2[x] Arena3[y] obj1a obj1b obj1c obj2a 25

26 Memory Allocation Pool: Mehrere Arenen vom selben Typ werden in einem Pool zusammengefasst ein Pool ist als verkettete Liste implementiert ein Pool enthält keine, eine oder mehrere Arenen welche alle Objekte derselben Größe speichern können Arena1[x] Arena2[x] Arena3[y] obj1a obj1b obj1c obj2a free_list Pool 1 Pool 2 free_list 26

27 Memory Allocation: alle Pools werden von der arena_base structure im Interpreter referenziert Interpreter arena_base Arena1[x] Arena2[x] Arena3[y] obj1a obj1b obj1c obj2a Pool 1 free_list Pool 2 free_list 27

28 Memory Allocation: Jeder Pool enthält eine Liste der enthaltenen, nicht benötigten Objekte, die free_list. Bei der Garbage Collection werden freigegebene Objekte vom Garbage Collector der free_list hinzugefügt Ist die free_list leer wird die Garbage Collection gestartet oder eine neue Arena alloziiert die feste Größe der Objekte in einer Arena erleichtert Compacting / Copying / Defragmenting Collection 28

29 Alternativer GC Ansatz: Tri-Color Mark: Objekte werden in drei Bereiche aufgeteilt - weiss dead Objects - grau live Objects deren referenzierte Objekte noch nicht markiert sind. - schwarz live Objects deren referenzierte Objekte markiert sind. 29

30 Alternativer GC Ansatz: Initialer Durchlauf: Alle Objekte starten als weisse Objekte Die root Objekte werden grau markiert 30

31 Alternativer GC Ansatz: Phase 1: Wähle ein graues Objekt und markiere alle direkt referenzierten Objekte grau Markiere das gewählte Objekt schwarz 31

32 Alternativer GC Ansatz: Phase 2: Alle weissen Objekte können von der GC entfernt werden Alle Objekte werden weiss und die root elemente grau markiert 32

33 Alternativer GC Ansatz: Tri-Mark kann problemlos in Teilschritte zerlegt werden Teilschritte können jeweils während minimal kurzer Pausen im Programmablauf durchgeführt werden Problematische Sonderfälle: (Objekt erzeugt Objekt erzeugt Objekt usw.) Compacting kann jedoch zu längeren Pausen führen. Dank Arena Struktur kann Compacting auch in Teilschritte zerlegt werden. 33

34 Fazit: Registerbasierte virtuelle Maschinen können potenziell eine bessere Performance haben als stackbasierte VMs. Aber: abhängig von vielen Faktoren Performancegewinn sinkt stark mit schnellerem Dispatch und bei Verwendung von JIT Compiling mit linear scan. Parrot VM bietet anhand der Struktur ihrer Memory Allocation und des Tri-Mark Garbage Collecting eine mögliche Alternative Umgebung für realtime Anwendungen. 34

35 Fragen? 35

36 Literatur D. Gregg, A. Beatty, K. Casey, B. Davis, and A. Nisbet. The case for virtual register machines. S cience of Computer P rogramming, S pecial Issue on Interpreters Virtual Machines and E mulators, To appear. Yunhe Shi, David Gregg, Andrew Beatty, and M. Anton Ertl. Virtual machine s howdown: s tack vers us regis ters. In C onference on Virtual execution environments (VEE),