DE10015675A1 - Spekulative Auswahl von heißen Spuren in einem dynamischen CACHE-Übersetzer mit geringem Aufwand - Google Patents

Abstract

Ein Verfahren und eine Vorrichtung zum Auswählen von heißen Spuren für eine Übersetzung und/oder Optimierung wird bezüglich eines dynamischen Cache-Übersetzers beschrieben. Der Code-Cache-Speicher speichert die heißen Spuren. Die Profilbildung wird an Positionen durchgeführt, die eine Spuranfangbedingung erfüllen, z. B. an den Zielen von rückwärts genommenen Verzweigungen. Ein heißes Ziel einer rückwärts genommenen Verzweigung wird ohne die Notwendigkeit, ein Profil der Blöcke zu bilden, aus denen sich die Spur zusammensetzt, spekulativ als der Beginn einer heißen Spur identifiziert. Die Erstreckung der spekulativ ausgewählten heißen Spur ist durch eine Spurendebedingung, z. B. eine rückwärts genommene Verzweigung oder eine Anzahl von interpretierten oder nativen Befehlen, bestimmt. Der Interpretierer wird durch einen Modus ergänzt, bei dem derselbe native Befehle ausgibt, die Cache-mäßig gespeichert werden. Eine Spur wird Cache-mäßig gespeichert, indem ein heißer Start einer Spur identifiziert wird, und daraufhin die Interpretation fortgeführt wird, während der ausgegebene native Befehlsstrom gespeichert wird, bis eine Spurendebedingung erfüllt ist.

Description

Die vorliegende Erfindung bezieht sich auf Techniken zum Identifizieren von Computerprogrammabschnitten, die beson­ ders häufig ausgeführt werden. Die vorliegende Erfindung ist insbesondere bei dynamischen Übersetzern nützlich, die Kan­ didatenabschnitte eines Codes für eine Cache-Speicherung und/oder Optimierung identifizieren müssen.

Dynamischer Übersetzer übersetzen eine Sequenz von Befehlen in eine weitere Sequenz von Befehlen, die ausgeführt wird. Die zweite Sequenz von Befehlen sind "native" Befehle - sie können von der Maschine, auf der der Übersetzer läuft, di­ rekt ausgeführt werden (diese "Maschine" kann eine Hardware sein oder diese Maschine kann durch Software definiert sein, die auf einer weiteren Maschine mit ihrer eigenen Architek­ tur läuft). Ein dynamischer Übersetzer kann entworfen sein, um Befehle für eine Maschinenarchitektur (d. h. einen Be­ fehlssatz) auf einer Maschine einer unterschiedlichen Ar­ chitektur (d. h. mit einem unterschiedlichen Befehlssatz) auszuführen. Alternativ kann ein dynamischer Übersetzer Be­ fehle nehmen, die für die Maschine, auf der der dynamische Übersetzer läuft, nativ sind, und an diesem Befehlsstrom wirken, um einen optimierten Befehlsstrom zu erzeugen. Ein dynamischer Übersetzer kann ferner beide dieser Funktionen aufweisen (eine Übersetzung von einer Architektur in eine andere und eine Optimierung).

Dynamische Cache-Übersetzer versuchen, Programm-Hot-Spots (häufig ausgeführte Abschnitte des Programms, wie z. B. be­ stimmte Schleifen) in Laufzeit zu identifizieren, und ver­ wenden einen Code-Cache-Speicher, um Übersetzungen dieser häufig ausgeführten Abschnitte zu speichern. Eine an­ schließende Ausführung dieser Abschnitte kann die Cache­ mäßig gespeicherten Übersetzungen verwenden, wodurch der Aufwand zum Ausführen dieser Abschnitte des Programms re­ duziert wird.

Ein dynamischer Übersetzer kann Befehle in einem Befehlssatz nehmen und Befehle in einem unterschiedlichen Befehlssatz erzeugen. Oder ein dynamischer Übersetzer kann eine Optimie­ rung durchführen: Erzeugen von Befehlen in demselben Be­ fehlssatz wie demjenigen des ursprünglichen Befehlsstromes; folglich ist die dynamische Optimierung ein spezieller Na­ tiv-zu-Nativ-Fall einer dynamischen Übersetzung. Oder ein dynamischer Übersetzer kann beides durchführen - Umwandeln zwischen Befehlssätzen sowie Durchführen einer Optimierung.

Im allgemeinen gilt, daß, je komplizierter das Ausführungs­ profilbildungsschema ist, desto präziser die Hot-Spot-Iden­ tifizierung sein kann, und folglich (i) desto kleiner der übersetzte Code-Cache-Speicher-Platz sein kann, der erfor­ derlich ist, um den kompakteren Satz von identifizierten Hot-Spots des Arbeitssatzes des laufenden Programms zu hal­ ten, und (ii) desto weniger Zeit aufgewendet wird, um Hot- Spots in einen nativen Code (oder in einen optimierten nati­ ven Code) zu übersetzen. Falls keine spezielle Hardware­ unterstützung für die Profilbildung vorgesehen ist, liegt allgemein der Fall vor, daß ein komplexeres Profilbildungs­ schema einen größeren Aufwand nach sich zieht. Folglich müssen dynamische Übersetzer typischerweise einen Ausgleich zwischen dem Minimieren der Verwaltung auf der einen Seite und dem sehr sorgfältigen Auswählen von Hot-Spots auf der anderen Seite finden.

Abhängig von der verwendeten Profilbildungstechnik kann die Granularität der ausgewählten Hot-Spots variieren. Eine Feinkörnungstechnik kann beispielsweise einzelne Blöcke identifizieren (eine schleifenfreie Codesequenz ohne jeg­ liche dazwischen angeordnete Verzweigungen), wohingegen ein gröberer Lösungsansatz für eine Profilbildung vollständige Prozeduren identifizieren kann. Da es typischerweise ver­ glichen zu Prozeduren viel mehr Blöcke gibt, die ausgeführt werden, erfordern die Prozeduren viel mehr Profilbildungs­ aufwand (sowohl Speicherplatz für die Ausführungshäufig­ keitszähler als auch Zeit, die zum Aktualisieren dieser Zähler aufgewendet wird) als die Blöcke. Bei Systemen, die eine Programmoptimierung vornehmen, besteht ein weiterer, zu berücksichtigender Faktor in der Wahrscheinlichkeit einer nützlichen Optimierung und/oder dem Grad der Optimierungs­ möglichkeit, die bei dem ausgewählten Hot-Spot verfügbar ist. Ein Block bietet einen viel geringeren Optimierungswir­ kungsbereich als eine Prozedur (und folglich können weniger Typen von Optimierungstechniken angewendet werden), obwohl ein Block einfacher zu optimieren ist, da demselben jeg­ licher Steuerungsfluß fehlt (Verzweigungen und Verbindun­ gen).

Spuren bieten noch einen unterschiedlichen Satz von Abwä­ gungen. Spuren (ferner bekannt als Pfade) sind dynamische Einzel-Eingang-Mehr-Ausgang-Sequenzen von Blöcken. Obwohl Spuren häufig einen Optimierungswirkungsbereich aufweisen, der zwischen demjenigen für Blöcke und demjenigen für Pro­ zeduren liegt, können Spuren mehrere Prozedurkörper durch­ laufen, und können sogar vollständige Prozedurkörper ent­ halten. Spuren bieten einen ziemlich großen Optimierungs­ wirkungsbereich, während dieselben immer noch einen ein­ fachen Steuerungsfluß aufweisen, was das Optimieren dersel­ ben viel einfacher macht als das Optimieren einer Prozedur. Der einfache Steuerungsfluß ermöglicht ferner eine schnelle­ re Optimiererimplementierung. Eine dynamische Spur kann sich sogar über mehrere Prozeduraufrufe und -Rücksprünge ein­ schließlich dynamisch verbundener Bibliotheken (DLLs) er­ strecken. Dies ermöglicht einem Optimierer, ein "Inlining" durchzuführen, was eine Optimierung ist, die redundante Auf­ ruf- und Rücksprung-Verzweigungen entfernt, was die Lei­ stungsfähigkeit wesentlich verbessern kann.

Ungünstigerweise ist der erforderliche Aufwand, um ein Pro­ fil von heißen Spuren unter Verwendung existierender Verfah­ ren (wie z. B. demjenigen, das in "Efficient Path Pro­ filing", Proceedings of the 29th Symposium on Micro Architecture (MICRO-29), Dezember 1996, von T. Ball und J. Larus beschrieben wird) zu bilden, ohne eine Hardwareunter­ stützung unakzeptabel hoch. Solche Verfahren erfordern das Instrumentieren der Programm-Binär-Struktur (das Einfügen von Befehlen, um die Profilbildung zu unterstützen), was die Profilbildung undurchsichtig macht, und eine Aufblähung des Binärcodes ergeben kann. Die Ausführung der eingefügten Instrumentierungsbefehle verlangsamt außerdem die gesamte Programmausführung, und sobald die Instrumentierung einge­ fügt worden ist, ist es schwierig, dieselbe in Laufzeit zu entfernen. Zusätzlich erfordert ein solches Verfahren eine ausreichend komplexe Analyse der Zählerwerte, um die heißen Pfade in dem Programm aufzudecken, so daß ein solches Ver­ fahren, während das Programm ausgeführt wird, schwierig während der Ausführung wirksam zu verwenden ist. All dies macht herkömmliche Schemata für eine Verwendung bei einem dynamischen Cache-Übersetzer uneffizient.

Heiße Spuren können ferner indirekt unter Verwendung einer Verzweigungs- oder Grundblock-Profilbildung aufgebaut werden (im Gegensatz zu einer Spurprofilbildung, bei der das Profil Spurinformationen direkt liefert). Bei diesem Schema wird einem Zähler das genommene Ziel jeder Verzweigung zugeordnet (es gibt andere Variationen hierfür, aber der Aufwand ist ähnlich). Wenn der dynamische Cache-Übersetzer den Programm­ code interpretiert, imkrementiert derselbe einen solchen Zähler jedesmal, wenn eine angenommene Verzweigung interpre­ tiert wird. Wenn ein Zähler einen voreingestellten Schwel­ lenwert überschreitet, wird sein entsprechender Block als heiß markiert. Diese heißen Blöcke können aneinandergereiht werden, um eine heiße Spur zu erzeugen. Eine solche Profil­ bildungstechnik weist die folgenden Nachteile auf:

• 1. Es ist eine große Zählertabelle erforderlich, da die Anzahl von getrennten Blöcken, die von einem Programm ausgeführt werden, sehr groß sein kann.
• 2. Der Aufwand für eine Spurauswahl ist hoch. Der Grund kann intuitiv erklärt werden: falls eine Spur aus N Blöcken besteht, wird das Schema so lange warten müssen, bis alle N Zähler ihre Schwellenwerte überschritten ha­ ben, bevor dieselben in eine Spur eingereiht werden kön­ nen. Dasselbe schlägt keinen Vorteil aus der Tatsache, daß, nachdem der erste Zähler heiß geworden ist, die nächsten N-1 Zähler sehr wahrscheinlich in einer schnel­ len Aufeinanderfolge heiß werden, wodurch es unnötig wird, mit dem Inkrementieren derselben und der Buchfüh­ rung bezüglich der durchlaufenen Blöcke, die gerade aus­ geführt worden sind, fortzufahren.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren zum Auswählen von heißen Spuren bei einem dyna­ mischen Übersetzer und einen dynamischen Übersetzer selbst zu schaffen, so daß eine Profilbildung mit weniger Aufwand durchgeführt werden kann.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, 9 oder 10 und einen dynamischen Übersetzer gemäß Anspruch 5 gelöst.

Gemäß der vorliegenden Erfindung werden Spuren auf einer spekulativen Basis als heiß identifiziert und nicht basie­ rend auf vollständigen Spurprofildaten. Die Reihe von Blöcken, die an einer heißen Spuranfangbedingung beginnt und sich bis zu einer Spurendebedingung erstreckt, wird als eine heiße Spur identifiziert. Eine solche Spur wird ohne die Notwendigkeit, den Aufwand des tatsächlichen Messens, ob aufeinanderfolgende Blöcke eine ausreichende Anzahl von Malen ausgeführt worden sind, zu erfordern, um als heiß betrachtet zu werden, als heiß identifiziert.

Die Identifizierung dessen, aus was sich die Spur zusammen­ setzt, wird durchgeführt, während die Spur ausgeführt wird. Eine Übersetzung der Spur wird ausgegeben, wenn die Spur ausgeführt wird, ist für eine Optimierung bei einem System, das eine Optimierung durchführt, verfügbar und wird in dem Code-Cache-Speicher erfaßt.

Eine besonders nützliche Spuranfangbedingung liegt vor, wenn die letzte interpretierte Verzweigung rückwärts genommen wurde. Eine nützliche Spurendebedingung liegt vor, wenn eine der folgenden drei Bedingungen erfüllt ist: (1) die letzte interpretierte Verzweigung wurde rückwärts genommen, (2) die Anzahl von interpretierten Verzweigungen überschritt einen Schwellenwert, oder (3) die Anzahl von nativen Befehlen, die für die Spur ausgegeben wurden, überschritt einen weiteren Schwellenwert.

Folglich muß gemäß der vorliegenden Erfindung eine Profil­ bildung lediglich an bestimmten wohldefinierten Programm­ adressen, wie z. B. den Zielen von rückwärts genommenen Verzweigungen, durchgeführt werden, und es müssen nicht komplizierte Profilbildungstechniken mit einem höheren Auf­ wand zum Identifizieren von Programm-Hot-Spots in Laufzeit verwendet werden. Wenn eine solche Adresse heiß wird (d. h. ihr zugeordneter Zähler einen Schwellenwert überschreitet), wird die anschließende Sequenz von ausgeführten Blöcken (oder die Spur) spekulativ als ein heißer Pfad ausgewählt.

Dieses Schema wählt spekulativ die anschließende Sequenz von interpretierten Blöcken, die bestimmten heißen Verzweigungs­ zielen - insbesondere bestimmten Verzweigungszielen, die wahrscheinlich Schleifenanfangsblöcke sind - folgen, als eine heiße Spur aus. Sogar obwohl dieses Schema keine müh­ same Profilbildung umfaßt, kann die Qualität der Spuren, die durch diese Technik ausgewählt werden, exzellent sein. Wieso dieses Schema effektiv ist, kann man folgendermaßen verste­ hen: Sequenzen von heißen Blöcken sind häufig korreliert; bei einem laufenden Programm tendieren vollständige Pfade und nicht ein unverbundener Satz von Blöcken dazu, heiß zu werden.

Die vorliegende Erfindung liefert eine Vorrichtung für eine Spurauswahl mit einem reduzierten Profilbildungsaufwand.

Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, daß eine Spur sogar dann aufgebaut werden kann, wenn dieselbe ungerichtete Verzweigungen enthält (Verzweigungen, deren Ergebnisse lediglich dann bekannt sind, wenn die Ver­ zweigung ausgeführt wird, und die nicht durch einfaches Decodieren des Verzweigungsbefehls bestimmt werden können). Im Gegensatz dazu ist es für Spuraufbauschemata, die auf Verzweigungsvorhersageinformationen beruhen, ungünstig, un­ gerichtete Verzweigungen zu handhaben, da es keinen ein­ fachen Weg gibt, um das Ergebnis solcher Verzweigungen vor­ herzusagen.

Ein weiterer Vorteil der Erfindung besteht darin, daß der Speicher, der für die Speicherung von Zählern erforderlich ist, verglichen zu herkömmlichen Profilbildungsschemata, die auf einer Verzweigungs- oder Grundblockzählung basieren, kleiner, da es bei der vorliegenden Erfindung nicht erfor­ derlich ist, den Zählwert für jeden Block oder für jede Ver­ zweigung zu überwachen.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Zeich­ nungen näher erläutert. Es zeigen:

Fig. 1 die Komponenten eines dynamischen Übersetzers, wie z. B. eines Übersetzers, bei dem die vorliegende Erfindung verwendet werden kann;

Fig. 2 einen Fluß von Operationen bei einer Implementie­ rung eines dynamischen Übersetzers, der die vorlie­ gende Erfindung verwendet; und

Fig. 3 einen Programmfluß über vier Blöcke eines Program­ mes hinweg, der veranschaulicht, daß es mehrere unterschiedliche Spuren geben kann, die mit einem gemeinsamen Block beginnen.

Unter Bezugnahme auf Fig. 1 weist ein dynamischer Übersetzer einen Interpretierer 110 auf, der einen Eingangsbefehlsstrom 160 empfängt. Dieser "Interpretierer" stellt die Befehlsaus­ wertungsmaschine dar; er kann auf mehrere Weisen implemen­ tiert sein (z. B. als eine Software-Hol-Decodier-Auswerte- Schleife, ein Just-In-Time-Compiler (Zur-rechten-Zeit-Compi­ ler) oder sogar eine Hardware-CPU).

Bei einer Implementierung liegen die Befehle des Eingangsbe­ fehlsstroms 60 in demselben Befehlssatz wie demjenigen der Maschine vor, auf der der Übersetzer läuft (Nativ-zu-Nativ- Übersetzung). In dem Nativ-zu-Nativ-Fall ergibt sich der Hauptvorteil, der durch den Übersetzer erhalten wird, aus der dynamischen Optimierung 150, die der Übersetzer durch­ führen kann. Bei einer anderen Implementierung liegen die Eingangsbefehle in einem anderen Befehlssatz als demjenigen der nativen Befehle vor.

Der Spurauswähler 120 identifiziert Befehlsspuren, die in dem Code-Cache-Speicher 130 gespeichert werden sollen. Der Spurauswähler ist die Komponente, die für das Zuordnen von Zählern zu interpretierten Programmadressen, zum Bestimmen, wann der Interpretiererzustand hin- und hergeschaltet wer­ den soll (zwischen einem normalen Modus und einem Spurauf­ baumodus), und zum Bestimmen, wann eine "heiße Spur" erfaßt worden ist, verantwortlich ist.

Ein Großteil der Arbeit des dynamischen Übersetzers findet in einer Interpretierer-Spurauswähler-Schleife statt. Nach­ dem der Interpretierer 110 einen Block von Befehlen inter­ pretiert hat (d. h. bis zu einer Verzweigung), wird die Steuerung an den Spurauswähler 120 weitergegeben, um die Beobachtungen des Programmverhaltens durchzuführen, so daß derselbe Spuren für eine spezielle Verarbeitung und eine Plazierung in dem Cache-Speicher auswählen kann. Die Inter­ pretierer-Spurauswähler-Schleife wird so lange ausgeführt, bis eine der folgenden Bedingungen erfüllt ist: (a) ein Cache-Treffer tritt auf, wobei in diesem Fall die Steuerung in den Code-Cache-Speicher springt, oder (b) ein heißes Start-Einer-Spur bzw. ein heißer Spuranfang wird erreicht.

Wenn ein heißes Start-Einer-Spur vorgefunden wird, schaltet der Spurauswähler 120 den Zustand des Interpretierers 110 um, so daß der Interpretierer die Spurbefehle ausgibt, bis die entsprechende Spurendebedingung (Bedingung (b)) erfüllt ist. An diesem Punkt ruft der Spurauswähler den Spuropti­ mierer 150 auf. Der Spuroptimierer ist verantwortlich für das Optimieren der Spurbefehle für eine bessere Leistungs­ fähigkeit auf dem zugrundeliegenden Prozessor. Nachdem die Optimierung durchgeführt ist, gibt der Codegenerator 140 den Spurcode tatsächlich in den Code-Cache-Speicher 130 aus und springt zu dem Spurauswähler 120 zurück, um die Interpretie­ rer-Spurauswähler-Schleife fortzusetzen.

Fig. 2 stellt den Betrieb einer Implementierung eines dy­ namischen Übersetzers dar, der die vorliegende Erfindung verwendet. Die durchgezogenen Pfeile stellen einen Steue­ rungsfluß dar, während der gestrichelte Pfeil die Erzeugung von Daten darstellt. In diesem Fall sind die erzeugten "Da­ ten" tatsächlich ausführbare Sequenzen von Befehlen (Spu­ ren), die in dem Cache-Speicher 130 von übersetztem Code gespeichert werden.

Das Wirken des Interpretierers 110, 210, 245 in dem dyna­ mischen Übersetzer gemäß dem dargestellten Ausführungsbei­ spiel ist erweitert worden, so daß derselbe einen neuen Betriebszustand aufweist (im folgenden als "Spuraufbaumodus" bezeichnet): wenn sich derselbe in diesem neuen Zustand befindet, wird als ein Nebeneffekt der Interpretierung ein nativer Code für eine Spur ausgegeben. Für eine Nativ-zu- Nativ-Übersetzung beläuft sich dieser Prozeß des Ausgebens von Befehlen lediglich auf das Weiterleiten der relevanten Befehle von dem Eingangsbefehlsstrom 160. Für andere Über­ setzungen werden die Eingangsbefehle in native Befehle über­ setzt, wobei diese nativen Befehle in einem Puffer aufge­ zeichnet werden. Die übersetzten nativen Befehle werden daraufhin ausgeführt und dann ausgegeben - der Puffer von übersetzten Befehlen wird für eine weitere Verarbeitung (d. h. eine Optimierung 255 und Plazierung in den Cache-Speicher 260) verfügbar gemacht. Obwohl ein Block eine nützliche Ein­ heit zum Übersetzen, Ausführen und Ausgeben ist, kann der Interpretierer übersetzte Befehle in anderen Einheiten aus­ geben, und der Interpretierer kann die Übersetzungs-Aus­ führ-Schleife bezüglich einer Größe, wie z. B. einem Befehl oder einem Block) durchführen und übersetzte Befehle für eine weitere Verarbeitung in unterschiedlichen Einheiten (wie z. B. einem Block oder einer Spur) weiterleiten. Es sind ferner verschiedene alternative Implementierungen eines Interpretierers möglich, der übersetzte Befehle ausgibt.

Der native Code, der von dem Interpretierer 245 ausgegeben wird, ist bei dem nächsten Mal, wenn dieser Abschnitt des Programms ausgeführt wird, für eine Ausführung ohne die Notwendigkeit für eine Interpretation in dem Cache-Speicher 130 von übersetztem Code gespeichert (falls nicht Störfakto­ ren ergeben haben, daß dieser Code aus dem Cache-Speicher abgeräumt worden ist). In Fig. 2 ist der "Normal-Modus"- Betrieb des Interpretierers 110 bei 210 gezeigt, wobei der "Spuraufbaumodus"-Betrieb des Interpretierers bei 245 ge­ zeigt ist.

Der Spuraufbaumodus 245 des Interpretierers 110 wird bei der vorliegenden Erfindung als ein Mechanismus zum Identifizie­ ren der Erstreckung einer Spur ausgenutzt; der Spuraufbaumo­ dus erzeugt nicht nur Daten (Befehle), die in dem Cache- Speicher gespeichert werden sollen, sondern derselbe spielt ferner bei dem Spurauswahlprozeß selbst eine Rolle. Wie es im vorhergehenden beschrieben wurde, leitet die vorliegende Erfindung eine Spurauswahl basierend auf einer begrenzten Profilbildung ein: bestimmte Adressen, die Spuranfangbedin­ gungen erfüllen, werden überwacht, ohne daß die Notwendig­ keit besteht, Profildaten für vollständige Spuren beizube­ halten. Eine Spur wird basierend auf einer heißen Spuran­ fangbedingung ausgewählt. Diese Auswahl ist spekulativ, da die tatsächliche Spur, die ausgewählt wird, (und die be­ stimmt werden wird, während der Interpretierer in dem Spur­ aufbaumodus seinen Weg durch die Spur abarbeitet) nicht eine häufig ausgeführte sein muß, sogar obwohl dieselbe an einer häufig ausgeführten Startadresse beginnt. Zu dem Zeitpunkt, da eine Spur als heiß identifiziert wird (basierend darauf, daß der Ausführungszähler einen Schwellenwert überschrei­ tet), ist die Erstreckung der Befehle, die die Spur bilden, nicht bekannt. Der Prozeß, daß der Interpretierer Befehle ausgibt, ist es, was die Erstreckung der Spur festlegt; der Spuraufbaumodus wird verwendet, um die Spur während der Aus­ führung zu entwirren.

Bezugnehmend auf Fig. 3 sind beispielsweise vier Blöcke ei­ nes Programmes gezeigt, um zu veranschaulichen, wie eine Identifizierung eines Spuranfangspunktes nicht an sich eine Spur vollständig identifiziert. Ein Block A erfüllt die Spuranfangbedingung (derselbe ist das Ziel einer Rückwärts­ verzweigung von D). Bei vier Blöcken mit der Verzweigungsbe­ ziehung, die in Fig. 3 gezeigt ist, verwenden die folgenden Spuren gemeinschaftlich denselben Anfangspunkt (A): ABDC, ABD, ACD. Die Spur, der das Programm zu dem Zeitpunkt folgt, zu dem der Zähler für A heiß wird, ist die Spur, die für eine Speicherung in dem Cache-Speicher ansprechend darauf, daß der Zähler heiß wird, ausgewählt wird - es könnte jede dieser drei Spuren sein (in Wirklichkeit kann es mehr als drei mögliche Spuren geben, falls sich die Spuren über D hi­ naus erstrecken).

Bezugnehmend auf Fig. 2 beginnt der dynamische Übersetzer mit dem Interpretieren von Befehlen, bis eine genommene Ver­ zweigung interpretiert wird 210. An diesem Punkt wird eine Überprüfung durchgeführt, um zu erkennen, ob eine Spur, die an dem Ziel der genommenen Verzweigung beginnt, in dem Code-Cache-Speicher 215 existiert. Falls es eine solche Spur gibt (d. h. einen Cache-"Treffer"), wird die Steuerung an das vordere Ende dieser Version der Spur, die in dem Cache- Speicher 130 gespeichert ist, übergeben.

Wenn die Steuerung nach dem Ausführen der Befehle, die in dem Cache-Speicher 130 gespeichert sind, den Cache-Speicher über eine Ausgangverzweigung verläßt, wird ein Zähler, der dem Ausgangverzweigungsziel zugeordnet ist, als Teil der "Trampolin"-Befehlssequenz, die ausgeführt wird, um die Steuerung an den dynamischen Übersetzer zurückzugeben, in­ krementiert 235. Wenn die Spur für eine Speicherung in dem Cache-Speicher 130 gebildet wird, wird in der Spur für jede Ausgangverzweigung in der Spur ein Satz von Trampolinbe­ fehlen einbezogen. Diese Befehle (ferner bekannt als ein Übersetzungs-"Epilog") übergeben die Steuerung von den Befehlen in dem Cache-Speicher zurück an die Interpretie­ rer-Spurauswähler-Schleife. Dem Trampolin, das jeder Aus­ gangverzweigung entspricht, ist ein Ausgangverzweigungs­ zähler zugeordnet. Entsprechend der Speicherung für die Trampulinbefehle für eine Cache-mäßig gespeicherte Spur wird die Speicherung für die Spurausgangzähler ebenfalls automa­ tisch zugewiesen, wenn der native Code für die Spur in den Cache-Speicher von übersetztem Code ausgegeben wird. Bei dem dargestellten Ausführungsbeispiel werden aus Übersichtlich­ keitsgründen die Ausgangzähler mit den Trampolinbefehlen gespeichert; der Zähler könnte jedoch auch anderswo ge­ speichert werden, wie z. B. in einem Array von Zählern.

Wiederum bezugnehmend auf 215 in Fig. 2 wird, falls, wenn der Cache-Speicher auf eine Spur hin, die an dem Ziel der genommenen Verzweigung beginnt, untersucht wird, keine sol­ che Spur in dem Cache-Speicher existiert, eine Bestimmung durchgeführt, ob eine "Spuranfang"-Bedingung existiert 230. Bei dem dargestellten Ausführungsbeispiel liegt Spuran­ fangbedingung dann vor, wenn die soeben interpretierte Ver­ zweigung eine rückwärts genommene Verzweigung war. Alterna­ tiv könnte ein System unterschiedliche Spuranfangbedingungen verwenden, die mit rückwärts genommenen Verzweigungen kombi­ niert sind oder dieselben nicht umfassen: Prozeduraufruf- Befehle, Ausgänge aus dem Code-Cache-Speicher, Systemauf­ ruf-Befehle oder Maschinenbefehl-Cache-Fehlgriffe (falls die Hardware eine solche Einrichtung zum Nachverfolgen solcher Dinge aufweist).

Eine rückwärts genommene Verzweigung ist eine nützliche Spuranfangbedingung, da dieselbe die Beobachtung ausnutzt, daß das Ziel einer rückwärts genommenen Verzweigung sehr wahrscheinlich (obwohl nicht notwendigerweise) der Start einer Schleife ist. Da die meisten Programme eine erhebliche Zeitdauer in Schleifen verbringen, sind Schleifenanfangs­ blöcke gute Kandidaten für mögliche Hot-Spot-Eintritte. Da es ferner üblicherweise weitaus weniger Schleifenanfangs­ blöcke in einem Programm als Ziele von genommenen Verzwei­ gungen gibt, wird die Anzahl von Zählern und die Zeitdauer, die zum Aktualisieren der Zähler verwendet wird, erheblich reduziert, wenn man sich auf die Ziele von rückwärts genom­ menen Verzweigungen (die wahrscheinlich Schleifenanfangs­ blöcke sind) und nicht auf alle Verzweigungsziele konzen­ triert.

Falls die Spuranfangbedingung nicht erfüllt ist, tritt die Steuerung neu in den Grundinterpretiererzustand ein, wobei die Interpretation fortschreitet. In diesem Fall besteht keine Notwendigkeit dafür, einen Zähler beizubehalten; eine Zählerinkrementierung findet lediglich dann statt, falls eine Spuranfangbedingung erfüllt ist. Dies steht im Gegen­ satz zu herkömmlichen dynamischen Übersetzerimplementie­ rungen, die Zähler für jedes Verzweigungsziel beibehalten. Bei dem dargestellten Ausführungsbeispiel werden lediglich den Adressen der Ziele der rückwärts genommenen Verzweigun­ gen und der Ziele von Verzweigungen, die den Cache-Speicher von übersetztem Code verlassen, Zähler zugeordnet; folglich ermöglicht die vorliegende Erfindung einem System, weniger Zählerspeicherung zu verwenden, und weniger Zählerinkremen­ tierungsaufwand zu erfordern.

Falls die Bestimmung, ob eine "Spuranfang"-Bedingung vor­ liegt 230, ergibt, daß die Spuranfangbedingung erfüllt ist, wird, falls kein Zähler für das Ziel existiert, ein Zähler erzeugt, oder, falls ein Zähler für das Ziel existiert, die­ ser Zähler inkrementiert.

Falls der Zählerwert für das Verzweigungsziel den Heiß- Schwellenwert 240 nicht überschreitet, tritt die Steuerung in den Grundinterpretiererzustand neu ein, wobei die Inter­ pretation fortschreitet 210.

Falls der Zählerwert einen Heiß-Schwellenwert 240 über­ schreitet, ist dieses Verzweigungsziel der Beginn dessen, was als eine heiße Spur erachtet wird. An diesem Punkt wird der Zählerwert nicht länger benötigt, wobei dieser Zähler wieder verwendet werden kann (alternativ könnte der Zähler­ speicher für eine Verwendung für andere Zwecke neu bean­ sprucht werden). Dies stellt einen Vorteil über Profilbil­ dungsschemata dar, die das Instrumentieren der Binär-Struk­ tur umfassen.

Da die Profildaten, die durch die Spuranfangzähler gesammelt werden, während der Ausführung verwendet werden (während das Programm ausgeführt wird), können diese Zähler neu verwendet werden, wenn ihre Informationen nicht mehr erforderlich sind; insbesondere kann, sobald ein Spuranfangzähler heiß geworden ist, und verwendet worden ist, um eine Spur für eine Speicherung in dem Cache-Speicher auszuwählen, dieser Zähler neu verwendet werden. Das dargestellte Ausführungs­ beispiel weist eine Tabelle von Spuranfangzählern mit einer festen Größe auf. Die Tabelle ist assoziativ - auf jeden Zähler kann mittels der Spuranfangadresse zugegriffen wer­ den, für die der Zähler zählt. Wenn ein Zähler für eine spe­ zielles Start-Einer-Spur neu verwendet werden soll, wird dieser Eintrag in der Tabelle einer Frei-Liste hinzugefügt, oder auf andere Weise als frei markiert.

Je niedriger der Schwellenwert ist, desto weniger Zeit wird bei dem Interpretierer aufgewendet, und desto größer ist die Anzahl von Start-von-Spuren, die möglicherweise heiß werden. Dies ergibt eine größere Anzahl von Spuren, die in den Code-Cache-Speicher erzeugt werden (und desto spekulativer ist die Auswahl von heißen Spuren), und die wiederum den Druck auf die Code-Cache-Ressourcen und folglich den Aufwand zum Verwalten des Code-Cache-Speichers erhöhen können. Ande­ rerseits gilt, je höher der Schwellenwert ist, desto größer der Interpretationsaufwand (z. B. das Zuweisen und das In­ krementieren von Zählern, die den Start-von-Spuren zugeord­ net sind). Folglich muß die Auswahl des Schwellenwertes diese zwei Kräfte ausgleichen. Sie hängt ferner von dem tat­ sächlichen Interpretations- und Code-Cache-Verwaltungs-Auf­ wand bei der speziellen Implementierung ab. Bei unserer spezifischen Implementierung, bei der der Interpretierer als eine Software-Hol-Decodier-Evaluier-Schleife in C geschrie­ ben worden ist, wurde ein Schwellenwert von 50 als der beste Kompromiß ausgewählt.

Falls der Zählerwert einen Heiß-Schwellenwert 240 über­ schreitet, wird, wie es im vorhergehenden angezeigt wurde, die Adresse, die diesem Zähler entspricht, als der Start einer heißen Spur erachtet. Zu dem Zeitpunkt, da die Spur als heiß identifiziert ist, bleibt immer noch die Er­ streckung der Spur zu bestimmen (durch die Spurendebedin­ gung, die im folgenden beschrieben wird). Es wird ferner darauf hingewiesen, daß die Auswahl der Spur als "heiß" ebenfalls spekulativ ist, nämlich darin, daß lediglich der Anfangsblock der Spur tatsächlich bemessen worden ist, heiß zu sein.

An dieser Stelle wechselt der Interpretierer von dem Nor­ mal-Modus 210 zu dem Spuraufbaumodus 245 über. In diesem Modus fährt die Interpretation, wie es im vorhergehenden beschrieben wurde, fort, ausgenommen darin, daß, während die Befehle interpretiert werden, die native Übersetzung der Befehle ebenfalls ausgegeben wird, so daß dieselben in dem Code-Cache-Speicher 130 gespeichert werden können. Der In­ terpretierer speichert die nativen Befehle in einen Puffer.

Wenn eine Spurendebedingung erreicht ist 250, wird der Puf­ fer mit der vollständigen Spur einem Optimierer 255 ausge­ händigt. Nach einer Optimierung werden die optimierten na­ tiven Befehle in den Cache-Speicher plaziert, wobei der Zählerspeicher, der der Anfangsadresse der Spur zugeordnet ist, wiederverwendet wird 260. (Alternativ könnte der Zäh­ lerspeicher sogleich benutzt werden, wenn bestimmt worden ist, daß der Zähler den Heiß-Schwellenwert überschreitet). Ferner wechselt der Interpretierer 110, ausgelöst durch die Spurendebedingung, zu dem normalen Interpretiererzustand zurück.

Eine Spurendebedingung ist einfach eine heuristische Aus­ sage, die aussagt, wann das Aufbauen der gegenwärtigen Spur gestoppt werden soll. Folgende Bedingungen sind Beispiele für einige mögliche Spurendebedingungen: das Beenden einer Spur, wenn eine rückwärts genommene Verzweigung erreicht wird, vermeidet ein unnötiges Entfalten von Zyklen und erfaßt ferner Schleifen; eine "Rückkehr"-Verzweigung kann eine nützliche Spurendebedingung sein, da dieselbe das Ende eines Prozedurkörpers anzeigen kann; im allgemeinen ist es wünschenswert ein Ende-Einer-Spur auszulösen, falls ein neues Start-Einer-Spur aufgetritt.

Bei dem dargestellten Ausführungsbeispiel ist die Spuren­ debedingung erfüllt, wenn (a) eine rückwärts genommene Verzweigung interpretiert wird, oder (b) wenn seit dem Eintreten in den Spuraufbaumodus eine bestimmte Anzahl von Verzweigungsbefehlen interpretiert worden ist (bei dem dargestellten Ausführungsbeispiel beträgt diese Anzahl 20) (das Beschränken der Anzahl von Verzweigungen an der Spur nach oben hin begrenzt die Anzahl von Stellen, an denen die Steuerung die Spur verlassen kann - je größer die Anzahl von Verzweigungen ist, die die Spur verlassen können, desto geringer ist die Wahrscheinlichkeit, daß die gesamte Spur verwendet werden wird, und desto größer ist die Wahrschein­ lichkeit eines frühzeitigen Verlassens der Spur) oder (c) eine bestimmte Anzahl von nativen übersetzten Befehlen für die gegenwärtige Spur in den Code-Cache-Speicher ausgegeben worden ist. Die Grenze für die Anzahl von Befehlen in einer Spur ist ausgewählt, um übermäßig lange Spuren zu vermeiden. Bei dem dargestellten Ausführungsbeispiel sind dies 1024 Befehle, was es einer bedingten Verzweigung an der Spur ermöglicht, ihre Enden zu erreichen (dies folgt aus der An­ zahl von Versetzungsbits in dem Befehl der bedingten Ver­ zweigung auf dem PA-RISC-Prozessor, auf dem das dargestellte Ausführungsbeispiel implementiert ist).

Obwohl der Cache-Speicher groß genug proportioniert werden kann, so daß eine Ersetzung von Einträgen nicht erforderlich ist, wird typischerweise ein Ersetzungsschema verwendet. Ein Lösungsansatz besteht darin, den Cache-Speicher zu räumen, wenn derselbe voll ist und Platz für einen neuen Eintrag erforderlich ist. Ein weiterer Lösungsansatz, der Vorteile bietet, besteht jedoch darin, den Cache-Speicher basierend auf einem gewissen Anzeichen, daß sich der Arbeitssatz des Programms ändert, preemtiv zu räumen. Ein solcher preemtiver Lösungsansatz wird in der von der gleichen Anmelderin und am selben Tag eingereichten Patentanmeldung mit dem Titel "Eine preemtive Ersetzungsstrategie für einen dynamischen Cache- Speicher" beschrieben.

Wenn eine Spur aus dem Code-Cache-Speicher entfernt wird, wird der Speicher, der für die Zählerspeicherung für jede der Austrittsverzweigungen der Spur verwendet wird, automa­ tisch wiederverwendet. Folglich ist die Speicherung für die­ se Austrittsverzweigungzielzähler in diesem Sinne "frei", da dieselben nicht unabhängig zugewiesen werden müssen, und nicht wie die anderen Zähler, die den Zielen interpretierter Verzweigungen zugeordnet sind, verwaltet werden müssen (die­ jenigen Ziele, die Spuranfangbedingungen erfüllt haben, aber für die der zugeordnete Zähler den "Heiß"-Schwellenwert noch nicht überschritten hat); wie es im vorhergehenden erörtert wurde, werden die Austrittsverzweigungzielzähler als ein Teil des Erzeugens des Trampolins für die Austrittsverzwei­ gung zugewiesen.

Bei dem dargestellten Ausführungsbeispiel sind Fig. 1 und 2 wie folgt miteinander verwandt; einem Fachmann auf diesem Gebiet wird klar sein, daß diese Funktionen bei anderen Implementierungen auf andere Weisen organisiert werden kön­ nen. Der Interpretierer 210 implementiert 210 und 245. Der Codegeneratoreinrichtung 140 implementiert 260. Der Spurop­ timierer 150 implementiert 255. Der Spurauswähler 120 imple­ mentiert 215, 220, 230, 235, 240 und 250.

Das dargestellte Ausführungsbeispiel der vorliegenden Erfin­ dung ist als eine Software implementiert, die auf einem Allzweckcomputer läuft, und die vorliegende Erfindung ist insbesondere für eine Softwareimplementierung geeignet. Be­ züglich der Erfindung kann ferner eine Spezialzweckhardware nützlich sein (beispielsweise ein Hardware-"Interpretierer", eine Hardware, die das Sammeln von Profilbildungsdaten ver­ einfacht, oder eine Cache-Hardware).

Im vorhergehenden ist ein spezifisches Ausführungsbeispiel der Erfindung beschrieben worden. Zusätzliche Variationen werden Fachleuten auf diesem Gebiet offensichtlich sein. Obwohl beispielsweise die Erfindung in dem Kontext eines dynamischen Übersetzers beschrieben worden ist, kann die­ selbe ferner bei anderen Systemen verwendet werden, die Interpretierer oder Just-In-Time-Compilierer (JITs) verwen­ den. Die Erfindung könnte ferner bei anderen Systemen ver­ wendet werden, die jedes Nicht-native-System emulieren, wie z. B. bei einem Simulator. Folglich ist die Erfindung nicht auf die spezifischen Details und das dargestellte Ausfüh­ rungsbeispiel, das in dieser Beschreibung gezeigt und be­ schrieben wurde, beschränkt. Vielmehr ist es die Aufgabe der anhängigen Ansprüche, alle solche Variationen und Modifi­ kationen abzudecken, die in den Schutzbereich der Erfindung fallen.

Claims (11)

1. Verfahren zum Auswählen von heißen Spuren in einem Pro­ gramm, das übersetzt wird, bei einem dynamischen Über­ setzer, mit folgenden Schritten:

• A) Dynamisches Zuordnen von Zählern zu Adressen in dem Programm, das übersetzt wird, bezüglich derer während der Programm-Übersetzung und -ausführung bestimmt wird, daß dieselben eine Spuranfangbe­ dingung (235) erfüllen;
• B) wenn ein Befehl mit einem entsprechenden Zähler ausgeführt wird, Inkrementieren dieses Zählers (235); und
• C) wenn ein Zähler einen Schwellenwert überschreitet, Bestimmen der speziellen Spur, die an der Adresse beginnt, die diesem Zähler entspricht, und die durch den Ausführungspfad definiert ist, der von dem Programm nach dieser speziellen Ausführung dieses Befehls eingeschlagen wird und sich fort­ setzt, bis eine Spurendebedingung erfüllt ist, und Identifizieren dieser Spur als eine heiße Spur (240, 245, 250).

2. Verfahren gemäß Anspruch 1, bei dem der dynamische Übersetzer einen Interpretierer aufweist, der zwischen einem Normalmodus und einem Spuraufbaumodus, bei dem der Interpretierer als ein Nebeneffekt der Interpreta­ tion native Befehle ausgibt, hin- und hergeschaltet werden kann, wobei das Verfahren ferner folgende Schritte aufweist:

• A) wenn ein Zähler einen Schwellenwert überschreitet, Umschalten des Interpretierers in den Spuraufbau­ modus (245);
• B) wenn sich der Interpretierer in dem Spuraufbaumo­ dus befindet, und eine Spurendebedingung erfüllt ist, Umschalten des Interpretierers in den Normal­ modus (250);
• C) Verwenden der Befehle, die von dem Interpretierer ausgegeben werden, um die Spur zu bestimmen, die als eine heiße Spur (255) identifiziert werden soll.

3. Verfahren gemäß Anspruch 1 oder 2, bei dem ansprechend auf das Identifizieren einer Spur als eine heiße Spur der entsprechende Zähler wiederverwendet wird.

4. Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Spuranfangbedingung erfüllt ist, wenn die zu­ letzt interpretierte Verzweigung rückwärts genommen wurde.

5. Ein dynamischer Übersetzer mit folgenden Merkmalen:

• A) Zählern zum Speichern von Zählwerten der Anzahl, wie oft Befehle an Adressen ausgeführt werden, die den Zählern (235) zugeordnet sind;
• B) einer Einrichtung zum Identifizieren der Adressen, die eine Spuranfangbedingung erfüllen, und zum Zu­ ordnen solcher Adressen zu Zählern (230);
• C) eine Einrichtung zum Bestimmen, wenn ein Zähler einen Schwellenwert (240) überschreitet; und
• D) einer Spuridentifizierungseinrichtung zum Identi­ fizieren einer Reihe von Befehlen, die nach dem Befehl an der Adresse, die dem Zähler zugeordnet ist, ausgeführt werden, als eine heiße Spur (245).

6. Dynamischer Übersetzer gemäß Anspruch 5, der ferner einen Interpretierer (210, 245) aufweist, der zwischen einem Normalmodus und einem Spuraufbaumodus, bei dem der Interpretierer als ein Nebeneffekt der Interpreta­ tion native Befehle ausgibt, hin- und hergeschaltet werden kann, wobei der Interpretierer ansprechend da­ rauf, daß ein Zähler einen Schwellenwert überschreitet, in den Spuraufbaumodus umgeschaltet wird, und wobei die Spuridentifizierungseinrichtung die ausgegebenen Befeh­ le bei ihrer Identifizierung einer heißen Spur verwen­ det.

7. Dynamischer Übersetzer gemäß Anspruch 5 oder 6, bei dem ansprechend auf das Identifizieren einer Spur als eine heiße Spur der entsprechende Zähler wiederverwendet wird.

8. Dynamischer Übersetzer gemäß einem der Ansprüche 5 bis 7, bei dem die Spuranfangbedingung erfüllt ist, wenn die zuletzt interpretierte Verzweigung rückwärts genom­ men wurde.

9. Verfahren zum Auswählen von heißen Spuren bei einem dy­ namischen Übersetzer, mit folgenden Schritten:

• A) Beibehalten von Zählwerten für Adressen, die eine Spuranfangbedingung (235) erfüllen;
• B) Erfassen, wenn einer dieser Zähler einen Schwel­ lenwert (240) überschreitet;
• C) ansprechend darauf, daß ein Zähler einen Schwel­ lenwert überschreitet, Identifizieren der Befehle, die an der Adresse beginnen, der der Zähler zuge­ ordnet wurde, und sich fortsetzen, bis eine Spur­ endebedingung (245, 250) erreicht wird, als eine heiße Spur.

10. Verfahren zum Auswählen von heißen Spuren bei einem dy­ namischen Übersetzer mit einem Cache-Speicher, mit fol­ genden Schritten:

• A) wenn eine Rückwärts-Verzweigung genommen wird, Er­ zeugen eines Zählers, falls kein solcher Zähler für das Verzweigungsziel existiert, und Inkremen­ tieren des Zählers (235), falls ein solcher Zähler existiert;
• B) falls ein Zähler einen Schwellenwert überschrei­ tet, Speichern einer Übersetzung von derjenigen Befehlen, die beginnend an dem Verzweigungsziel, das dem Zähler zugeordnet ist, der den Schwel­ lenwert überschritten hat, ausgeführt werden und sich fortsetzen, bis eine Spurendebedingung er­ reicht wird (240, 245, 250), in dem Speicher.

11. Verfahren gemäß Anspruch 10, bei dem, wenn eine Über­ setzung in dem Cache-Speicher gespeichert wird, der entsprechende Zähler wiederverwendet wird.