Virtuelle Maschinen (7.5 ECTS)
Prüfer: Volkmar Sieh, Beisitzer: Bernhard Heinloth
Wie immer sehr entspannte Atmosphaere. Ein oder zwei Fragen fallen mir leider nicht mehr ein…
Allgemeines
Was haben wir denn so in der Vorlesung gemacht? Welche Virtualisierungsmethoden haben wir besprochen
Emulator, JIT, hardwarebasiert, betriebssystembasiert, bibliotheksbasiert jeweils kurz erklaert
Bibliothekesbasierte Virtualisierung
Bleiben wir doch mal bei bibliotheksbasierter Virtualisierung. Was muss man dafuer tun?
Instruction set muss passen, Speichermapping muss moeglich sein, libraries umbauen
Evtl reicht es nur die unterste Bibliothek umzubauen wenn die darueberliegenden keine syscalls machen, sondern nur die unterste Bibliothek nutzen
Wann nutzen denn Programme keine Bibliotheksfunktionen?
statisch gebundene Programme
Warum? Integritaet von Bibliotheken, Updater (der wuerde sich seine eigene lib wegupdaten)
Was macht mann dann?
Personalities (+ Erklaerung was ist das)
Was sind die Vorteile und Nachteile bibliotheksbasierter Virtualisierung?
Vorteile:
Programm laeuft als normales Window im Host, man kann nebenbei weitere Sachen machen, copy-paste funktioniert, …
Nachteile:
Bibliotheken muesen umgebaut werden. Ohne sourcen/mit schlechter Doku macht das wenig Spass
Update der lib erfordert ein update von der umgebauten lib
Fehler muessen mit umgebaut werden (komische Programme nutzen bugs als feature)
Wie schaut das mit der Performance aus?
Du hast vorhin etwas davon gesagt, dass das Instruction Set passen muss. Sparc Programme unter Intel funktioniert natuerlich nicht. Aber funktioniert z.B. jedes Intel Programm unter Intel?
gemeinsames Instruction-Set muss vorhanden sein
Wenn Programme Extensions nutzen (z.B. SSE, AVX, …) und die unter dem Host nicht vorhanden sind (und das Programm kein Fallback ohne Extensions hat) kann man das Programm nicht ausfuehren
Emulation
Du hattest Eingangs erwaehnt, dass die Emulation langsam ist. Warum?
Operationen mehrfach dekodieren, Operanden mehrfach rausfriemeln, …
Flags berechnung ist in Software teuer - Flags werden aber selten gebraucht
Speicherzugriff ueber Bus langsam
Warum ist der Speicherzugriff ueber den Bus langsam. Erklaere mal wie das funktioniert.
Hier gab es noch den Hinweis, dass es in einem System ja mehrere Busse gibt
Beispiel out genommen
Value mit Port-Nr. an Bus geben
Bus ruft alle Komponenten, die sich im init() mit Callback und State registriert haben auf. Jede Komponente prueft ob sie angesprochen wurde
Evtl gehen Aufrufe auch an andere Busse. Es werden also viele Komponenten aufgerufen, obwohl nur eine angesprochen ist.
Komponenten/Ports aendern sich eigentlich nicht. Die Zuordnung Port ↔ Callback koennte man also Cachen
Was macht man wenn sich jetzt doch ein Port aendert
Das Geraet muss der CPU mitteilen, dass sich Callbacks geaendert haben
Und woher weiss das Geraet wer die CPU ist?
Das weiss das Geraet wahrscheinlich gar nicht. Also im Zweifellsfall Broadcast-Nachricht an alle, dass sich etwas geaendert hat.
Selbst wenn man Adressen cachet. Warum ist der Speicherzugriff langsam trotzdem langsam? Was wird da alles ueberprueft?
Debug Einheit (Basis/Limit pruefen)
Alignment-Check
Debug/Watchpoint pruefen
MMU: TLB nachschauen, virtuelle Adresse in physikalische Adresse umrechnen, Zugriffskontrolle, Rechte (rwx), Access-/Dirtybits setzen
Caches (falls sie mitsimuliert werden sollen): Datum vorhanden? Falls nein: Verdraenungsstrategie, Write-Back/Write-through
Irgendwas habe ich bestimmt vergessen
Ja passt. War auch schon eine ganze Menge
Wie kann man diese Abfragen noch mit in seinen Cache einbauen?
Mehrdimensionalen Cache erklaeren. Siehe Foliensatz „Speicherhierarchie“ Folie 20ff.
Beim Alignment-Check. Motiviere doch mal warum zwischen den oberen Einsen (Seitenadresse) und den unteren beiden Einsen (Alignment) noch Platz sein muss?
Cached man Seiten: unteren 12 Bits = 0 (hier ist auf jeden Fall noch Platz)
Cached man weniger (z.B. nur Cachelines) schaut das anders aus
ABER: Integer ist schon 4 Bytes gross. Man wird nicht weniger als einen int cachen ⇒ also ist noch Platz vorhanden
JIT
Du hattest auch schon dem Just-in-Time Compiler erwaehnt. Warum wird das schneller?
Dekodieren nur einmal beim Compile
CC-Flags wegoptimieren
PC nur einmal am Ende eines Basic-Blocks erhoehen
Halbkonstanten wegoptimieren
…
Wie kann uns der JIT bei den Speicherchecks von vorhin helfen?
JIT kann Segmentbasisadresse, da sie sich i.d.R. nicht aendert gleich mit reinkompilieren
Alignmentcheck, Debugcheck, … koennen wegkompiliert werden wenn sie nicht gebraucht werden
Was macht man wenn sich eine der Bedinungen aendert. Z.B. wenn die Segmentbasisadresse umgesetzt wird?
Kompilierten Code invalidieren und beim naechsten Zugriff drauf neu Kompilieren.
Bei pthreads ist die Segmentbasisadresse meistens null. Wenn sie aber auf threadlocal storage haben aendert sie sich.
Neu kompilieren ist dann potentiell bloed. Weil man sehr oft Code invalidert
Code doppelt kompilieren. Einmal mit Basisadresse null und einmal mit anderem Wert. Je nach Segmentbasisadresse wird der eine oder der andere Code angesprungen