Testumgebung

Die in Java geschriebene Testumgebung, in die der Scheduler zunächst für die Versuche eingebettet wird, ist in Abbildung 3.2 dargestellt und besteht aus vier Teilen, die jeweils in einer Klasse implementiert sind:

Abbildung 3.2: Aufbau des Software-Simulators

• Fetch-Stufe: Diese simulierte Fetch-Stufe liefert die Bytecode-Befehle aus einem Puffer im Speicher in die Befehlsfenster der einzelnen Threads aus. Jeder Thread hat sein eigenes Befehlsfenster. Der Scheduler gibt vor, für welchen Thread als nächstes Befehle geholt werden sollen. Während eines Speicherzugriffes durch das Programm kann die Fetch-Stufe nicht gleichzeitig auf den Speicher zugreifen und muß einen Takt aussetzen.
• Decode-Stufe: Diese simulierte Decode-Stufe bekommt die Nummer des nächsten auszuführenden Thread vom Scheduler und holt sich den entsprechenden Bytecode von der Fetch-Stufe. Während eines Speicherzugriffs sorgt sie für die Blockierung der Fetch-Stufe. Aus den Bytecodes wird nur die Anzahl der verwendeten Mikrobefehle und die Länge der auftretenden Latenzen berechnet und an den Scheduler zurückgegeben. Zusätzlich werden Statistiken berechnet und ausgegeben.
• Signal-Einheit: Die Signaleinheit startet die einzelnen Threads und verwaltet deren Eigenschaften, wie die Deadline oder den zugewiesenen Prozentsatz. Die Werte werden aus einer Datei eingelesen.
• TestBed: Diese Klasse verbindet die drei Stufen mit dem Scheduler und sorgt für den richtigen zeitlichen Ablauf.

Zusätzliche Hilfsklassen verwalten Konstanten und Konfigurationsdaten, die als Kommandozeilenparameter übergeben werden können. Eine Übersicht über die Kommandozeilenoptionen befindet sich in Anhang B.

Der Scheduler selbst besteht aus einer Klasse, die die allgemeinen Aufgaben erledigt, und mehreren davon abgeleiteten Klassen, die für das eigentliche Scheduling zuständig sind, also die Berechnung der Prioritäten. Das ist der Teil, der in Abbildung 3.2 schattiert dargestellt ist.

Da dieser Simulator keine Execute-Stufe enthält, kann er keine echten Java Bytecodes ausführen. Daher ist es auch nicht notwendig, sie zu dekodieren. Vielmehr werden die Bytecodes in Klassen eingeteilt und aus jeder Klasse nur ein Vertreter verwendet. Eine Klasse ist bestimmt durch die Länge der enthaltenen Bytecodes, die auftretenden Latenzen und die benötigte Ausführungszeit.

Aus diesen Klassen werden Pseudoprogramme gebildet, indem zufällig eine Klasse ausgewählt und ihr Vertreter in die Programmdatei geschrieben wird. Das Verhältnis der verschiedenen Klassen zueinander wird anhand der Caffeine-Benchmarks ausgezählt. Der Anteil der Speicherbefehle kann zusätzlich variiert werden, um sehr speicherintensive Programme simulieren zu können.

Andererseits ist es auch möglich, reale Programme in ihrem Ablaufverhalten nachzubilden. Dazu wird ein Java-Programm auf einem Simulator ausgeführt, der jeden Befehl mitprotokolliert und dadurch einen Trace erzeugt, der den genauen Ablauf des Programms wiederspiegelt. Jeder Bytecode wird dann mit einem Zusatzprogramm auf die Klassen abgebildet.

Die Klassen von Befehlen, die in der Simulation unterschieden werden, sind in Tabelle 3.2 zusammengefaßt. Die Klassen der Microcodes und der Trap-Routinen teilen sich noch in mehrere Unterklassen auf, abhängig von deren Länge und Latenzverhalten.

In der Prozessorarchitektur beschreibt die Latenz üblicherweise die Verweildauer eines Befehls in einer Pipeline, ist also mindestens eins. Hier beschreibt die Latenz wie im mehrfädigen Prozessorentwurf die Anzahl der Takte, die nach einem Befehl kein weiterer Befehl des selben Thread folgen darf. Diese entsprechen in einem einfädigen Prozessor der Anzahl der Leertakte. Die Laufzeit für den Aufruf einer Trap-Routine setzt sich aus den Takten des Aufrufs und denen für den Rücksprung zusammen.

Tabelle 3.2: Die Klassen von Bytecodes

Name	Länge	Latenzen	Laufzeit	Anteil
	(Bytes)	(Takte)	(Takte)	(%)
1-Byte-Befehle	1	0	1	37,0
2-Byte-Befehle	2	0	1	33,8
3-Byte-Befehle	3	0	1	1,6
Speicher	2	1	1	13,3
Sprünge	3	2	1	13,2
Sammelklassen:
Microcode	1 oder 2	1 oder 2	mehrere	0,7
Traps	1 oder 3	2	14+7	0,4

Die Latenzen werden in der zweiten Versuchsreihe in Abschnitt 3.4 genauer betrachtet.

Der Vorteil dieser Versuchsanordnung ist, daß man die Programme sehr einfach variieren kann, ohne ein lauffähiges Programm schreiben zu müssen, das genau den gewünschten Anteil an Speicherzugriffen enthält. Durch die Softwareimplementierung können auch Situationen simuliert werden, die in Hardware so nicht möglich wären, etwa latenzfreie Sprünge, die nur mit einem Branch-Target-Buffer und einer perfekten Sprungvorhersage realisierbar wären.

Der Scheduler legt eine nach Priorität sortierte Liste aller lauffähigen Threads an, aus der im nächsten Takt vor dem Dekodieren nur noch einer der beiden vorderen Einträge ausgewählt werden muß. Wenn der höchstpriorisierte Thread im vorangegangenen Takt keine Latenz erzeugt hat, wird er ausgeführt, sonst der zweite in der Liste. An dieser Stelle kann nur noch dieser eine Thread ungültig werden, da die Ausführbarkeit für alle anderen Threads schon vor dem Scheduling feststeht.