Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Lehrstuhl 4 » Virtuelle Maschinen (7.5 ECTS)   (Übersicht)

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?

  • geringer Overhead (man muss kein ganzes BS simulieren obwohl man nur eine Anwendung braucht)
  • ABER: Wenn Programme/hoehere Bibliotheken Sachen nutzen die unter dem Guest-OS performant sind, sind sie nicht unbeding performant unter dem Host (z.B. Signale, fork() unter Windows schlecht)

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